2010-07-28 05:00:41 -07:00
|
|
|
#include "evas_common.h" /* Also includes international specific stuff */
|
2009-10-09 05:10:27 -07:00
|
|
|
#include "evas_engine.h"
|
|
|
|
|
2011-10-15 02:31:04 -07:00
|
|
|
#ifdef HAVE_DLSYM
|
|
|
|
# include <dlfcn.h> /* dlopen,dlclose,etc */
|
|
|
|
#else
|
|
|
|
# error gl_x11 should not get compiled if dlsym is not found on the system!
|
|
|
|
#endif
|
|
|
|
|
2011-05-01 19:14:00 -07:00
|
|
|
#define EVAS_GL_NO_GL_H_CHECK 1
|
|
|
|
#include "Evas_GL.h"
|
2010-01-21 00:44:11 -08:00
|
|
|
|
2009-10-09 05:10:27 -07:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2010-01-21 00:44:11 -08:00
|
|
|
// EGL / GLES
|
2009-10-09 05:10:27 -07:00
|
|
|
# if defined(GLES_VARIETY_S3C6410)
|
|
|
|
# elif defined(GLES_VARIETY_SGX)
|
|
|
|
# endif
|
2010-01-21 00:44:11 -08:00
|
|
|
#else
|
2009-10-09 05:10:27 -07:00
|
|
|
// GLX
|
2010-01-21 00:44:11 -08:00
|
|
|
#endif
|
|
|
|
|
2011-04-04 03:23:12 -07:00
|
|
|
typedef struct _Render_Engine Render_Engine;
|
|
|
|
typedef struct _Render_Engine_GL_Surface Render_Engine_GL_Surface;
|
|
|
|
typedef struct _Render_Engine_GL_Context Render_Engine_GL_Context;
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
typedef struct _Render_Engine_GL_Resource Render_Engine_GL_Resource;
|
|
|
|
typedef struct _Extension_Entry Extension_Entry;
|
2010-08-02 23:09:53 -07:00
|
|
|
|
|
|
|
struct _Render_Engine
|
|
|
|
{
|
|
|
|
Evas_GL_X11_Window *win;
|
|
|
|
Evas_Engine_Info_GL_X11 *info;
|
|
|
|
Evas *evas;
|
2011-10-21 01:58:00 -07:00
|
|
|
Tilebuf *tb;
|
2010-08-02 23:09:53 -07:00
|
|
|
int end;
|
2011-10-25 05:01:44 -07:00
|
|
|
/*
|
2010-08-02 23:09:53 -07:00
|
|
|
XrmDatabase xrdb; // xres - dpi
|
|
|
|
struct { // xres - dpi
|
|
|
|
int dpi; // xres - dpi
|
|
|
|
} xr; // xres - dpi
|
2011-10-25 05:01:44 -07:00
|
|
|
*/
|
2010-08-26 02:40:48 -07:00
|
|
|
int w, h;
|
2010-10-25 00:22:43 -07:00
|
|
|
int vsync;
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
|
2010-08-02 23:09:53 -07:00
|
|
|
};
|
|
|
|
|
2011-04-04 03:23:12 -07:00
|
|
|
struct _Render_Engine_GL_Surface
|
|
|
|
{
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
int initialized;
|
|
|
|
int fbo_attached;
|
|
|
|
int w, h;
|
|
|
|
int depth_bits;
|
|
|
|
int stencil_bits;
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
// Render target texture/buffers
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
GLuint rt_tex;
|
|
|
|
GLint rt_internal_fmt;
|
|
|
|
GLenum rt_fmt;
|
|
|
|
GLuint rb_depth;
|
|
|
|
GLenum rb_depth_fmt;
|
|
|
|
GLuint rb_stencil;
|
|
|
|
GLenum rb_stencil_fmt;
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
Render_Engine_GL_Context *current_ctx;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct _Render_Engine_GL_Context
|
|
|
|
{
|
|
|
|
int initialized;
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
|
|
|
EGLContext context;
|
2011-06-17 00:47:28 -07:00
|
|
|
#else
|
2011-04-04 03:23:12 -07:00
|
|
|
GLXContext context;
|
|
|
|
#endif
|
2011-11-10 00:59:09 -08:00
|
|
|
GLuint context_fbo;
|
2011-08-24 23:30:52 -07:00
|
|
|
GLuint current_fbo;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-04-04 03:23:12 -07:00
|
|
|
Render_Engine_GL_Surface *current_sfc;
|
|
|
|
};
|
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
// Resources used per thread
|
|
|
|
struct _Render_Engine_GL_Resource
|
|
|
|
{
|
|
|
|
// Resource context/surface per Thread in TLS for evasgl use
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
|
|
|
EGLContext context;
|
|
|
|
EGLSurface surface;
|
|
|
|
#else
|
|
|
|
GLXContext context;
|
|
|
|
#endif
|
|
|
|
};
|
|
|
|
|
|
|
|
// Extension Handling
|
2011-11-10 00:59:09 -08:00
|
|
|
struct _Extension_Entry
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
{
|
|
|
|
const char *name;
|
|
|
|
const char *real_name;
|
|
|
|
int supported;
|
|
|
|
};
|
|
|
|
|
2010-08-02 23:09:53 -07:00
|
|
|
static int initted = 0;
|
|
|
|
static int gl_wins = 0;
|
2011-08-24 23:30:52 -07:00
|
|
|
static Render_Engine_GL_Context *current_evgl_ctx;
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
static Render_Engine *current_engine;
|
|
|
|
|
|
|
|
static char _gl_ext_string[1024];
|
|
|
|
static char _evasgl_ext_string[1024];
|
|
|
|
|
|
|
|
// Resource context/surface per Thread in TLS for evasgl use
|
|
|
|
static Eina_TLS resource_key;
|
|
|
|
static Eina_List *resource_list;
|
|
|
|
LK(resource_lock);
|
|
|
|
|
|
|
|
typedef void (*glsym_func_void) ();
|
|
|
|
typedef void *(*glsym_func_void_ptr) ();
|
|
|
|
typedef int (*glsym_func_int) ();
|
|
|
|
typedef unsigned int (*glsym_func_uint) ();
|
|
|
|
typedef unsigned char (*glsym_func_uchar) ();
|
2010-08-02 23:09:53 -07:00
|
|
|
|
2010-01-21 00:44:11 -08:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2010-01-28 21:32:51 -08:00
|
|
|
|
|
|
|
#ifndef EGL_NATIVE_PIXMAP_KHR
|
|
|
|
# define EGL_NATIVE_PIXMAP_KHR 0x30b0
|
|
|
|
#endif
|
2010-01-21 00:44:11 -08:00
|
|
|
|
|
|
|
#endif
|
2010-03-01 07:51:22 -08:00
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
// GLES2 Extensions
|
|
|
|
void (*glsym_glGetProgramBinaryOES) (GLuint program, GLsizei bufSize, GLsizei *length, GLenum *binaryFormat, void *binary) = NULL;
|
2011-11-10 00:59:09 -08:00
|
|
|
void (*glsym_glProgramBinaryOES) (GLuint program, GLenum binaryFormat, const void *binary, GLint length) = NULL;
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
void* (*glsym_glMapBufferOES) (GLenum target, GLenum access) = NULL;
|
|
|
|
unsigned char (*glsym_glUnmapBufferOES) (GLenum target) = NULL;
|
|
|
|
void (*glsym_glGetBufferPointervOES) (GLenum target, GLenum pname, void** params) = NULL;
|
|
|
|
void (*glsym_glTexImage3DOES) (GLenum target, GLint level, GLenum internalformat, GLsizei width, GLsizei height, GLsizei depth, GLint border, GLenum format, GLenum type, const void* pixels) = NULL;
|
|
|
|
void (*glsym_glTexSubImage3DOES) (GLenum target, GLint level, GLint xoffset, GLint yoffset, GLint zoffset, GLsizei width, GLsizei height, GLsizei depth, GLenum format, GLenum type, const void* pixels) = NULL;
|
|
|
|
void (*glsym_glCopyTexSubImage3DOES) (GLenum target, GLint level, GLint xoffset, GLint yoffset, GLint zoffset, GLint x, GLint y, GLsizei width, GLsizei height) = NULL;
|
|
|
|
void (*glsym_glCompressedTexImage3DOES) (GLenum target, GLint level, GLenum internalformat, GLsizei width, GLsizei height, GLsizei depth, GLint border, GLsizei imageSize, const void* data) = NULL;
|
|
|
|
void (*glsym_glCompressedTexSubImage3DOES) (GLenum target, GLint level, GLint xoffset, GLint yoffset, GLint zoffset, GLsizei width, GLsizei height, GLsizei depth, GLenum format, GLsizei imageSize, const void* data) = NULL;
|
|
|
|
void (*glsym_glFramebufferTexture3DOES) (GLenum target, GLenum attachment, GLenum textarget, GLuint texture, GLint level, GLint zoffset) = NULL;
|
|
|
|
void (*glsym_glGetPerfMonitorGroupsAMD) (GLint* numGroups, GLsizei groupsSize, GLuint* groups) = NULL;
|
|
|
|
void (*glsym_glGetPerfMonitorCountersAMD) (GLuint group, GLint* numCounters, GLint* maxActiveCounters, GLsizei counterSize, GLuint* counters) = NULL;
|
|
|
|
void (*glsym_glGetPerfMonitorGroupStringAMD) (GLuint group, GLsizei bufSize, GLsizei* length, char* groupString) = NULL;
|
|
|
|
void (*glsym_glGetPerfMonitorCounterStringAMD) (GLuint group, GLuint counter, GLsizei bufSize, GLsizei* length, char* counterString) = NULL;
|
|
|
|
void (*glsym_glGetPerfMonitorCounterInfoAMD) (GLuint group, GLuint counter, GLenum pname, void* data) = NULL;
|
|
|
|
void (*glsym_glGenPerfMonitorsAMD) (GLsizei n, GLuint* monitors) = NULL;
|
|
|
|
void (*glsym_glDeletePerfMonitorsAMD) (GLsizei n, GLuint* monitors) = NULL;
|
|
|
|
void (*glsym_glSelectPerfMonitorCountersAMD) (GLuint monitor, GLboolean enable, GLuint group, GLint numCounters, GLuint* countersList) = NULL;
|
|
|
|
void (*glsym_glBeginPerfMonitorAMD) (GLuint monitor) = NULL;
|
|
|
|
void (*glsym_glEndPerfMonitorAMD) (GLuint monitor) = NULL;
|
|
|
|
void (*glsym_glGetPerfMonitorCounterDataAMD) (GLuint monitor, GLenum pname, GLsizei dataSize, GLuint* data, GLint* bytesWritten) = NULL;
|
|
|
|
void (*glsym_glDiscardFramebufferEXT) (GLenum target, GLsizei numAttachments, const GLenum* attachments) = NULL;
|
|
|
|
void (*glsym_glMultiDrawArraysEXT) (GLenum mode, GLint* first, GLsizei* count, GLsizei primcount) = NULL;
|
|
|
|
void (*glsym_glMultiDrawElementsEXT) (GLenum mode, const GLsizei* count, GLenum type, const GLvoid** indices, GLsizei primcount) = NULL;
|
|
|
|
void (*glsym_glDeleteFencesNV) (GLsizei n, const GLuint* fences) = NULL;
|
|
|
|
void (*glsym_glGenFencesNV) (GLsizei n, GLuint* fences) = NULL;
|
|
|
|
unsigned char (*glsym_glIsFenceNV) (GLuint fence) = NULL;
|
|
|
|
unsigned char (*glsym_glTestFenceNV) (GLuint fence) = NULL;
|
|
|
|
void (*glsym_glGetFenceivNV) (GLuint fence, GLenum pname, GLint* params) = NULL;
|
|
|
|
void (*glsym_glFinishFenceNV) (GLuint fence) = NULL;
|
|
|
|
void (*glsym_glSetFenceNV) (GLuint, GLenum) = NULL;
|
|
|
|
void (*glsym_glGetDriverControlsQCOM) (GLint* num, GLsizei size, GLuint* driverControls) = NULL;
|
|
|
|
void (*glsym_glGetDriverControlStringQCOM) (GLuint driverControl, GLsizei bufSize, GLsizei* length, char* driverControlString) = NULL;
|
|
|
|
void (*glsym_glEnableDriverControlQCOM) (GLuint driverControl) = NULL;
|
|
|
|
void (*glsym_glDisableDriverControlQCOM) (GLuint driverControl) = NULL;
|
|
|
|
void (*glsym_glExtGetTexturesQCOM) (GLuint* textures, GLint maxTextures, GLint* numTextures) = NULL;
|
|
|
|
void (*glsym_glExtGetBuffersQCOM) (GLuint* buffers, GLint maxBuffers, GLint* numBuffers) = NULL;
|
|
|
|
void (*glsym_glExtGetRenderbuffersQCOM) (GLuint* renderbuffers, GLint maxRenderbuffers, GLint* numRenderbuffers) = NULL;
|
|
|
|
void (*glsym_glExtGetFramebuffersQCOM) (GLuint* framebuffers, GLint maxFramebuffers, GLint* numFramebuffers) = NULL;
|
|
|
|
void (*glsym_glExtGetTexLevelParameterivQCOM) (GLuint texture, GLenum face, GLint level, GLenum pname, GLint* params) = NULL;
|
|
|
|
void (*glsym_glExtTexObjectStateOverrideiQCOM) (GLenum target, GLenum pname, GLint param) = NULL;
|
|
|
|
void (*glsym_glExtGetTexSubImageQCOM) (GLenum target, GLint level, GLint xoffset, GLint yoffset, GLint zoffset, GLsizei width, GLsizei height, GLsizei depth, GLenum format, GLenum type, void* texels) = NULL;
|
|
|
|
void (*glsym_glExtGetBufferPointervQCOM) (GLenum target, void** params) = NULL;
|
|
|
|
void (*glsym_glExtGetShadersQCOM) (GLuint* shaders, GLint maxShaders, GLint* numShaders) = NULL;
|
|
|
|
void (*glsym_glExtGetProgramsQCOM) (GLuint* programs, GLint maxPrograms, GLint* numPrograms) = NULL;
|
|
|
|
unsigned char (*glsym_glExtIsProgramBinaryQCOM) (GLuint program) = NULL;
|
|
|
|
void (*glsym_glExtGetProgramBinarySourceQCOM) (GLuint program, GLenum shadertype, char* source, GLint* length) = NULL;
|
|
|
|
|
|
|
|
|
|
|
|
//------ GLES 2.0 Extensions supported in EvasGL -----//
|
|
|
|
static Extension_Entry _gl_ext_entries[] = {
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
//--- Function Extensions ---//
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
{ "GL_OES_get_program_binary", "get_program_binary", 0 },
|
|
|
|
{ "GL_OES_mapbuffer", "mapbuffer", 0 },
|
|
|
|
{ "GL_OES_texture_3D", "texture_3D", 0 },
|
|
|
|
{ "AMD_performance_monitor", "AMD_performance_monitor", 0 },
|
|
|
|
{ "GL_EXT_discard_framebuffer", "discard_framebuffer", 0 },
|
|
|
|
{ "GL_EXT_multi_draw_arrays", "multi_draw_arrays", 0 },
|
|
|
|
{ "GL_NV_fence", "NV_fence", 0 },
|
|
|
|
{ "GL_QCOM_driver_control", "QCOM_driver_control", 0 },
|
|
|
|
{ "GL_QCOM_extended_get", "QCOM_extended_get", 0 },
|
|
|
|
{ "GL_QCOM_extended_get2", "QCOM_extended_get2", 0 },
|
|
|
|
|
|
|
|
//--- Define Extensions ---//
|
|
|
|
{ "GL_OES_compressed_ETC1_RGB8_texture", "compressed_ETC1_RGB8_texture", 0 },
|
|
|
|
{ "GL_OES_compressed_paletted_texture", "compressed_paletted_texture", 0 },
|
|
|
|
{ "GL_OES_depth24", "depth24", 0 },
|
|
|
|
{ "GL_OES_depth32", "depth32", 0 },
|
2011-11-10 00:59:09 -08:00
|
|
|
{ "GL_OES_EvasGL_image", "EGL_image", 0 },
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
{ "GL_OES_packed_depth_stencil", "packed_depth_stencil", 0 },
|
|
|
|
{ "GL_OES_rgb8_rgba8", "rgb8_rgba8", 0 },
|
2011-11-10 00:59:09 -08:00
|
|
|
{ "GL_OES_standard_derivatives", "standard_derivatives", 0 },
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
{ "GL_OES_stencil1", "stencil1", 0 },
|
|
|
|
{ "GL_OES_stencil4", "stencil4", 0 },
|
|
|
|
{ "GL_OES_texture_float", "texture_float", 0 },
|
|
|
|
{ "GL_OES_texture_half_float", "texture_half_float", 0 },
|
|
|
|
{ "GL_OES_texture_half_float_linear", "texture_half_float_linear", 0 },
|
2011-11-10 00:59:09 -08:00
|
|
|
{ "GL_OES_texture_npot", "texture_npot", 0 },
|
|
|
|
{ "GL_OES_vertex_half_float", "vertex_half_float", 0 },
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
{ "GL_OES_vertex_type_10_10_10_2", "vertex_type_10_10_10_2", 0 },
|
|
|
|
{ "GL_AMD_compressed_3DC_texture", "compressed_3DC_texture", 0 },
|
|
|
|
{ "GL_AMD_compressed_ATC_texture", "compressed_ATC_texture", 0 },
|
|
|
|
{ "GL_AMD_program_binary_Z400", "program_binary_Z400", 0 },
|
|
|
|
{ "GL_EXT_blend_minmax", "blend_minmax", 0 },
|
2011-11-10 00:59:09 -08:00
|
|
|
{ "GL_EXT_read_format_bgra", "read_format_bgra", 0 },
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
{ "GL_EXT_texture_filter_anisotropic", "texture_filter_anisotrophic", 0 },
|
2011-11-10 00:59:09 -08:00
|
|
|
{ "GL_EXT_texture_format_BGRA8888", "texture_format_BGRA8888", 0 },
|
|
|
|
{ "GL_EXT_texture_type_2_10_10_10_REV", "texture_type_2_10_10_10_rev", 0 },
|
|
|
|
{ "GL_IMG_program_binary", "IMG_program_binary", 0 },
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
{ "GL_IMG_read_format", "IMG_read_format", 0 },
|
|
|
|
{ "GL_IMG_shader_binary", "IMG_shader_binary", 0 },
|
|
|
|
{ "GL_IMG_texture_compression_pvrtc", "IMG_texture_compression_pvrtc", 0 },
|
|
|
|
{ "GL_QCOM_perfmon_global_mode", "QCOM_perfmon_global_mode", 0 },
|
|
|
|
{ "GL_QCOM_writeonly_rendering", "QCOM_writeonly_rendering", 0 },
|
|
|
|
#else
|
|
|
|
//--- Function Extensions ---//
|
|
|
|
{ "GL_OES_get_program_binary", "get_program_binary", 0 },
|
|
|
|
{ "GL_OES_mapbuffer", "mapbuffer", 0 },
|
|
|
|
{ "GL_OES_texture_3D", "texture_3D", 0 },
|
|
|
|
{ "AMD_performance_monitor", "AMD_performance_monitor", 0 },
|
|
|
|
{ "GL_EXT_discard_framebuffer", "discard_framebuffer", 0 },
|
|
|
|
{ "GL_EXT_multi_draw_arrays", "multi_draw_arrays", 0 },
|
|
|
|
{ "GL_NV_fence", "NV_fence", 0 },
|
|
|
|
{ "GL_QCOM_driver_control", "QCOM_driver_control", 0 },
|
|
|
|
{ "GL_QCOM_extended_get", "QCOM_extended_get", 0 },
|
|
|
|
{ "GL_QCOM_extended_get2", "QCOM_extended_get2", 0 },
|
|
|
|
|
|
|
|
//--- Define Extensions ---//
|
|
|
|
{ "GL_OES_compressed_ETC1_RGB8_texture", "compressed_ETC1_RGB8_texture", 0 },
|
|
|
|
{ "GL_OES_compressed_paletted_texture", "compressed_paletted_texture", 0 },
|
|
|
|
{ "GL_OES_depth24", "depth24", 0 },
|
|
|
|
{ "GL_OES_depth32", "depth32", 0 },
|
2011-11-10 00:59:09 -08:00
|
|
|
{ "GL_OES_EvasGL_image", "EGL_image", 0 },
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
{ "GL_OES_packed_depth_stencil", "packed_depth_stencil", 0 },
|
|
|
|
{ "GL_OES_rgb8_rgba8", "rgb8_rgba8", 0 },
|
2011-11-10 00:59:09 -08:00
|
|
|
{ "GL_OES_standard_derivatives", "standard_derivatives", 0 },
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
{ "GL_OES_stencil1", "stencil1", 0 },
|
|
|
|
{ "GL_OES_stencil4", "stencil4", 0 },
|
|
|
|
{ "GL_OES_texture_float", "texture_float", 0 },
|
|
|
|
{ "GL_OES_texture_half_float", "texture_half_float", 0 },
|
|
|
|
{ "GL_OES_texture_half_float_linear", "texture_half_float_linear", 0 },
|
|
|
|
{ "GL_OES_texture_npot", "texture_non_power_of_two", 0 }, // Desktop differs
|
|
|
|
{ "GL_OES_vertex_half_float", "half_float_vertex", 0 }, // Desktop differs
|
|
|
|
{ "GL_OES_vertex_type_10_10_10_2", "vertex_type_10_10_10_2", 0 },
|
|
|
|
{ "GL_AMD_compressed_3DC_texture", "compressed_3DC_texture", 0 },
|
|
|
|
{ "GL_AMD_compressed_ATC_texture", "compressed_ATC_texture", 0 },
|
|
|
|
{ "GL_AMD_program_binary_Z400", "program_binary_Z400", 0 },
|
|
|
|
{ "GL_EXT_blend_minmax", "blend_minmax", 0 },
|
|
|
|
{ "GL_EXT_read_format_bgra", "bgra", 0 }, // Desktop differs
|
|
|
|
{ "GL_EXT_texture_filter_anisotropic", "texture_filter_anisotrophic", 0 },
|
|
|
|
{ "GL_EXT_texture_format_BGRA8888", "bgra", 0 }, // Desktop differs
|
|
|
|
{ "GL_EXT_texture_type_2_10_10_10_REV", "vertex_type_2_10_10_10_rev", 0 }, // Desktop differs ???
|
2011-11-10 00:59:09 -08:00
|
|
|
{ "GL_IMG_program_binary", "IMG_program_binary", 0 },
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
{ "GL_IMG_read_format", "IMG_read_format", 0 },
|
|
|
|
{ "GL_IMG_shader_binary", "IMG_shader_binary", 0 },
|
|
|
|
{ "GL_IMG_texture_compression_pvrtc", "IMG_texture_compression_pvrtc", 0 },
|
|
|
|
{ "GL_QCOM_perfmon_global_mode", "QCOM_perfmon_global_mode", 0 },
|
|
|
|
{ "GL_QCOM_writeonly_rendering", "QCOM_writeonly_rendering", 0 },
|
|
|
|
|
|
|
|
#endif
|
|
|
|
{ NULL, NULL, 0}
|
|
|
|
};
|
|
|
|
|
|
|
|
//------ Extensions supported in EvasGL -----//
|
|
|
|
static Extension_Entry _evasgl_ext_entries[] = {
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
|
|
|
{ "EvasGL_KHR_image", "EGL_KHR_image", 0 },
|
|
|
|
{ "EvasGL_KHR_vg_parent_image", "EGL_KHR_vg_parent_image", 0 },
|
|
|
|
{ "EvasGL_KHR_gl_texture_2D_image", "EGL_KHR_gl_texture_2D_image", 0 },
|
|
|
|
{ "EvasGL_KHR_gl_texture_cubemap_image", "EGL_KHR_gl_texture_cubemap_image", 0 },
|
|
|
|
{ "EvasGL_KHR_gl_texture_3D_image", "EGL_KHR_gl_texture_3D_image", 0 },
|
|
|
|
{ "EvasGL_KHR_gl_renderbuffer_image", "EGL_KHR_gl_renderbuffer_image", 0 },
|
|
|
|
#else
|
|
|
|
#endif
|
|
|
|
{ NULL, NULL, 0 }
|
2011-11-10 00:59:09 -08:00
|
|
|
};
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
|
2010-01-21 00:44:11 -08:00
|
|
|
static void
|
|
|
|
_sym_init(void)
|
|
|
|
{
|
|
|
|
static int done = 0;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-01-21 00:44:11 -08:00
|
|
|
if (done) return;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-01-21 00:44:11 -08:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2010-09-18 17:28:58 -07:00
|
|
|
#define FINDSYM(dst, sym, typ) \
|
|
|
|
if ((!dst) && (glsym_eglGetProcAddress)) dst = (typ)glsym_eglGetProcAddress(sym); \
|
|
|
|
if (!dst) dst = (typ)dlsym(RTLD_DEFAULT, sym)
|
2008-04-11 17:32:30 -07:00
|
|
|
#else
|
2010-09-18 17:28:58 -07:00
|
|
|
#define FINDSYM(dst, sym, typ) \
|
|
|
|
if ((!dst) && (glsym_glXGetProcAddress)) dst = (typ)glsym_glXGetProcAddress(sym); \
|
|
|
|
if (!dst) dst = (typ)dlsym(RTLD_DEFAULT, sym)
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
#endif
|
|
|
|
|
|
|
|
//----------- GLES 2.0 Extensions ------------//
|
|
|
|
// If the symbol's not found, they get set to NULL
|
|
|
|
// If one of the functions in the extension exists, the extension in supported
|
|
|
|
/* GL_OES_get_program_binary */
|
|
|
|
FINDSYM(glsym_glGetProgramBinaryOES, "glGetProgramBinary", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glGetProgramBinaryOES, "glGetProgramBinaryEXT", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glGetProgramBinaryOES, "glGetProgramBinaryARB", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glGetProgramBinaryOES, "glGetProgramBinaryOES", glsym_func_void);
|
|
|
|
|
|
|
|
FINDSYM(glsym_glProgramBinaryOES, "glProgramBinary", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glProgramBinaryOES, "glProgramBinaryEXT", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glProgramBinaryOES, "glProgramBinaryARB", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glProgramBinaryOES, "glProgramBinaryOES", glsym_func_void);
|
|
|
|
|
|
|
|
// Check the first function to see if the extension is supported...
|
|
|
|
if (glsym_glGetProgramBinaryOES) _gl_ext_entries[0].supported = 1;
|
|
|
|
|
|
|
|
|
|
|
|
/* GL_OES_mapbuffer */
|
|
|
|
FINDSYM(glsym_glMapBufferOES, "glMapBuffer", glsym_func_void_ptr);
|
|
|
|
FINDSYM(glsym_glMapBufferOES, "glMapBufferEXT", glsym_func_void_ptr);
|
|
|
|
FINDSYM(glsym_glMapBufferOES, "glMapBufferARB", glsym_func_void_ptr);
|
|
|
|
FINDSYM(glsym_glMapBufferOES, "glMapBufferOES", glsym_func_void_ptr);
|
|
|
|
|
|
|
|
FINDSYM(glsym_glUnmapBufferOES, "glUnmapBuffer", glsym_func_uchar);
|
|
|
|
FINDSYM(glsym_glUnmapBufferOES, "glUnmapBufferEXT", glsym_func_uchar);
|
|
|
|
FINDSYM(glsym_glUnmapBufferOES, "glUnmapBufferARB", glsym_func_uchar);
|
|
|
|
FINDSYM(glsym_glUnmapBufferOES, "glUnmapBufferOES", glsym_func_uchar);
|
|
|
|
|
|
|
|
FINDSYM(glsym_glGetBufferPointervOES, "glGetBufferPointerv", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glGetBufferPointervOES, "glGetBufferPointervEXT", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glGetBufferPointervOES, "glGetBufferPointervARB", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glGetBufferPointervOES, "glGetBufferPointervOES", glsym_func_void);
|
|
|
|
|
|
|
|
if (glsym_glMapBufferOES) _gl_ext_entries[1].supported = 1;
|
|
|
|
|
|
|
|
/* GL_OES_texture_3D */
|
|
|
|
FINDSYM(glsym_glTexImage3DOES, "glTexImage3D", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glTexImage3DOES, "glTexImage3DEXT", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glTexImage3DOES, "glTexImage3DARB", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glTexImage3DOES, "glTexImage3DOES", glsym_func_void);
|
|
|
|
|
|
|
|
FINDSYM(glsym_glTexSubImage3DOES, "glTexSubImage3D", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glTexSubImage3DOES, "glTexSubImage3DEXT", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glTexSubImage3DOES, "glTexSubImage3DARB", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glTexSubImage3DOES, "glTexSubImage3DOES", glsym_func_void);
|
|
|
|
|
|
|
|
FINDSYM(glsym_glCopyTexSubImage3DOES, "glCopyTexSubImage3D", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glCopyTexSubImage3DOES, "glCopyTexSubImage3DARB", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glCopyTexSubImage3DOES, "glCopyTexSubImage3DEXT", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glCopyTexSubImage3DOES, "glCopyTexSubImage3DOES", glsym_func_void);
|
|
|
|
|
|
|
|
FINDSYM(glsym_glCompressedTexImage3DOES, "glCompressedTexImage3D", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glCompressedTexImage3DOES, "glCompressedTexImage3DARB", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glCompressedTexImage3DOES, "glCompressedTexImage3DEXT", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glCompressedTexImage3DOES, "glCompressedTexImage3DOES", glsym_func_void);
|
|
|
|
|
|
|
|
FINDSYM(glsym_glCompressedTexSubImage3DOES, "glCompressedTexSubImage3D", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glCompressedTexSubImage3DOES, "glCompressedTexSubImage3DARB", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glCompressedTexSubImage3DOES, "glCompressedTexSubImage3DEXT", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glCompressedTexSubImage3DOES, "glCompressedTexSubImage3DOES", glsym_func_void);
|
|
|
|
|
|
|
|
FINDSYM(glsym_glFramebufferTexture3DOES, "glFramebufferTexture3D", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glFramebufferTexture3DOES, "glFramebufferTexture3DARB", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glFramebufferTexture3DOES, "glFramebufferTexture3DEXT", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glFramebufferTexture3DOES, "glFramebufferTexture3DOES", glsym_func_void);
|
|
|
|
|
|
|
|
if (glsym_glTexSubImage3DOES) _gl_ext_entries[2].supported = 1;
|
|
|
|
|
|
|
|
/* AMD_performance_monitor */
|
|
|
|
FINDSYM(glsym_glGetPerfMonitorGroupsAMD, "glGetPerfMonitorGroupsAMD", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glGetPerfMonitorCountersAMD, "glGetPerfMonitorCountersAMD", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glGetPerfMonitorGroupStringAMD, "glGetPerfMonitorGroupStringAMD", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glGetPerfMonitorCounterStringAMD, "glGetPerfMonitorCounterStringAMD", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glGetPerfMonitorCounterInfoAMD, "glGetPerfMonitorCounterInfoAMD", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glGenPerfMonitorsAMD, "glGenPerfMonitorsAMD", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glDeletePerfMonitorsAMD, "glDeletePerfMonitorsAMD", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glSelectPerfMonitorCountersAMD, "glSelectPerfMonitorCountersAMD", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glBeginPerfMonitorAMD, "glBeginPerfMonitorAMD", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glEndPerfMonitorAMD, "glEndPerfMonitorAMD", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glGetPerfMonitorCounterDataAMD, "glGetPerfMonitorCounterDataAMD", glsym_func_void);
|
|
|
|
|
|
|
|
if (glsym_glGetPerfMonitorGroupsAMD) _gl_ext_entries[3].supported = 1;
|
|
|
|
|
|
|
|
/* GL_EXT_discard_framebuffer */
|
|
|
|
FINDSYM(glsym_glDiscardFramebufferEXT, "glDiscardFramebuffer", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glDiscardFramebufferEXT, "glDiscardFramebufferARB", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glDiscardFramebufferEXT, "glDiscardFramebufferEXT", glsym_func_void);
|
|
|
|
|
|
|
|
if (glsym_glDiscardFramebufferEXT) _gl_ext_entries[4].supported = 1;
|
|
|
|
|
|
|
|
/* GL_EXT_multi_draw_arrays */
|
|
|
|
FINDSYM(glsym_glMultiDrawArraysEXT, "glMultiDrawArrays", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glMultiDrawArraysEXT, "glMultiDrawArraysARB", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glMultiDrawArraysEXT, "glMultiDrawArraysEXT", glsym_func_void);
|
|
|
|
|
|
|
|
FINDSYM(glsym_glMultiDrawElementsEXT, "glMultiDrawElements", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glMultiDrawElementsEXT, "glMultiDrawElementsARB", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glMultiDrawElementsEXT, "glMultiDrawElementsEXT", glsym_func_void);
|
|
|
|
|
|
|
|
if (glsym_glMultiDrawArraysEXT) _gl_ext_entries[5].supported = 1;
|
|
|
|
|
|
|
|
/* GL_NV_fence */
|
|
|
|
FINDSYM(glsym_glDeleteFencesNV, "glDeleteFencesNV", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glGenFencesNV, "glGenFencesNV", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glIsFenceNV, "glIsFenceNV", glsym_func_uchar);
|
|
|
|
FINDSYM(glsym_glTestFenceNV, "glTestFenceNV", glsym_func_uchar);
|
|
|
|
FINDSYM(glsym_glGetFenceivNV, "glGetFenceivNV", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glFinishFenceNV, "glFinishFenceNV", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glSetFenceNV, "glSetFenceNV", glsym_func_void);
|
|
|
|
|
|
|
|
if (glsym_glDeleteFencesNV) _gl_ext_entries[6].supported = 1;
|
|
|
|
|
|
|
|
/* GL_QCOM_driver_control */
|
|
|
|
FINDSYM(glsym_glGetDriverControlsQCOM, "glGetDriverControlsQCOM", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glGetDriverControlStringQCOM, "glGetDriverControlStringQCOM", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glEnableDriverControlQCOM, "glEnableDriverControlQCOM", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glDisableDriverControlQCOM, "glDisableDriverControlQCOM", glsym_func_void);
|
|
|
|
|
|
|
|
if (glsym_glGetDriverControlsQCOM) _gl_ext_entries[7].supported = 1;
|
|
|
|
|
|
|
|
/* GL_QCOM_extended_get */
|
|
|
|
FINDSYM(glsym_glExtGetTexturesQCOM, "glExtGetTexturesQCOM", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glExtGetBuffersQCOM, "glExtGetBuffersQCOM", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glExtGetRenderbuffersQCOM, "glExtGetRenderbuffersQCOM", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glExtGetFramebuffersQCOM, "glExtGetFramebuffersQCOM", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glExtGetTexLevelParameterivQCOM, "glExtGetTexLevelParameterivQCOM", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glExtTexObjectStateOverrideiQCOM, "glExtTexObjectStateOverrideiQCOM", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glExtGetTexSubImageQCOM, "glExtGetTexSubImageQCOM", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glExtGetBufferPointervQCOM, "glExtGetBufferPointervQCOM", glsym_func_void);
|
|
|
|
|
|
|
|
if (glsym_glExtGetTexturesQCOM) _gl_ext_entries[8].supported = 1;
|
|
|
|
|
|
|
|
/* GL_QCOM_extended_get2 */
|
|
|
|
FINDSYM(glsym_glExtGetShadersQCOM, "glExtGetShadersQCOM", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glExtGetProgramsQCOM, "glExtGetProgramsQCOM", glsym_func_void);
|
|
|
|
FINDSYM(glsym_glExtIsProgramBinaryQCOM, "glExtIsProgramBinaryQCOM", glsym_func_uchar);
|
|
|
|
FINDSYM(glsym_glExtGetProgramBinarySourceQCOM, "glExtGetProgramBinarySourceQCOM", glsym_func_void);
|
|
|
|
|
|
|
|
if (glsym_glExtGetShadersQCOM) _gl_ext_entries[9].supported = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
_extensions_init(Render_Engine *re)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
const char *glexts, *evasglexts;
|
|
|
|
|
|
|
|
memset(_gl_ext_string, 0, 1024);
|
|
|
|
memset(_evasgl_ext_string, 0, 1024);
|
|
|
|
|
|
|
|
// GLES 2.0 Extensions
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glexts = (const char*)glsym_glGetString(GL_EXTENSIONS);
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
|
|
|
|
DBG("--------GLES 2.0 Extensions--------");
|
|
|
|
for (i = 0; _gl_ext_entries[i].name != NULL; i++)
|
|
|
|
{
|
|
|
|
if ( (strstr(glexts, _gl_ext_entries[i].name) != NULL) ||
|
|
|
|
(strstr(glexts, _gl_ext_entries[i].real_name) != NULL) )
|
|
|
|
{
|
|
|
|
_gl_ext_entries[i].supported = 1;
|
|
|
|
strcat(_gl_ext_string, _gl_ext_entries[i].name);
|
|
|
|
strcat(_gl_ext_string, " ");
|
|
|
|
DBG("\t%s", _gl_ext_entries[i].name);
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
DBG(" ");
|
2011-06-17 00:47:28 -07:00
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
|
|
|
// EGL Extensions
|
|
|
|
evasglexts = glsym_eglQueryString(re->win->egl_disp, EGL_EXTENSIONS);
|
|
|
|
#else
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
evasglexts = glsym_glXQueryExtensionsString(re->info->info.display,
|
|
|
|
re->info->info.screen);
|
2008-04-11 17:32:30 -07:00
|
|
|
#endif
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
|
|
|
|
DBG("--------EvasGL Extensions----------");
|
|
|
|
for (i = 0; _evasgl_ext_entries[i].name != NULL; i++)
|
|
|
|
{
|
|
|
|
if ( (strstr(evasglexts, _evasgl_ext_entries[i].name) != NULL) ||
|
|
|
|
(strstr(evasglexts, _evasgl_ext_entries[i].real_name) != NULL) )
|
|
|
|
{
|
|
|
|
_evasgl_ext_entries[i].supported = 1;
|
|
|
|
strcat(_evasgl_ext_string, _evasgl_ext_entries[i].name);
|
|
|
|
strcat(_evasgl_ext_string, " ");
|
|
|
|
DBG("\t%s", _evasgl_ext_entries[i].name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
DBG(" ");
|
2010-01-21 00:44:11 -08:00
|
|
|
}
|
2008-04-11 17:32:30 -07:00
|
|
|
|
2009-10-22 08:22:22 -07:00
|
|
|
int _evas_engine_GL_X11_log_dom = -1;
|
2006-12-09 00:52:08 -08:00
|
|
|
/* function tables - filled in later (func and parent func) */
|
|
|
|
static Evas_Func func, pfunc;
|
2006-02-27 20:07:49 -08:00
|
|
|
|
2011-05-01 19:14:00 -07:00
|
|
|
/* Function table for GL APIs */
|
|
|
|
static Evas_GL_API gl_funcs;
|
2011-10-25 05:01:44 -07:00
|
|
|
/*
|
2010-04-29 08:32:47 -07:00
|
|
|
struct xrdb_user
|
|
|
|
{
|
|
|
|
time_t last_stat;
|
|
|
|
time_t last_mtime;
|
|
|
|
XrmDatabase db;
|
|
|
|
};
|
|
|
|
static struct xrdb_user xrdb_user = {0, 0, NULL};
|
|
|
|
|
|
|
|
static Eina_Bool
|
|
|
|
xrdb_user_query(const char *name, const char *cls, char **type, XrmValue *val)
|
|
|
|
{
|
|
|
|
time_t last = xrdb_user.last_stat, now = time(NULL);
|
|
|
|
|
|
|
|
xrdb_user.last_stat = now;
|
2011-10-25 05:01:44 -07:00
|
|
|
if (last != now) // don't stat() more than once every second
|
2010-04-29 08:32:47 -07:00
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
struct stat st;
|
|
|
|
const char *home = getenv("HOME");
|
|
|
|
char tmp[PATH_MAX];
|
2010-04-29 08:32:47 -07:00
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
if (!home) goto failed;
|
|
|
|
snprintf(tmp, sizeof(tmp), "%s/.Xdefaults", home);
|
|
|
|
if (stat(tmp, &st) != 0) goto failed;
|
|
|
|
if (xrdb_user.last_mtime != st.st_mtime)
|
|
|
|
{
|
|
|
|
if (xrdb_user.db) XrmDestroyDatabase(xrdb_user.db);
|
|
|
|
xrdb_user.db = XrmGetFileDatabase(tmp);
|
|
|
|
if (!xrdb_user.db) goto failed;
|
|
|
|
xrdb_user.last_mtime = st.st_mtime;
|
|
|
|
}
|
2010-04-29 08:32:47 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!xrdb_user.db) return EINA_FALSE;
|
|
|
|
return XrmGetResource(xrdb_user.db, name, cls, type, val);
|
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
failed:
|
2010-04-29 08:32:47 -07:00
|
|
|
if (xrdb_user.db)
|
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
XrmDestroyDatabase(xrdb_user.db);
|
|
|
|
xrdb_user.db = NULL;
|
2010-04-29 08:32:47 -07:00
|
|
|
}
|
|
|
|
xrdb_user.last_mtime = 0;
|
|
|
|
return EINA_FALSE;
|
|
|
|
}
|
2011-10-25 05:01:44 -07:00
|
|
|
*/
|
2011-11-10 00:59:09 -08:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
static void *
|
2006-02-27 20:07:49 -08:00
|
|
|
eng_info(Evas *e)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Evas_Engine_Info_GL_X11 *info;
|
2010-01-21 00:44:11 -08:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
info = calloc(1, sizeof(Evas_Engine_Info_GL_X11));
|
|
|
|
info->magic.magic = rand();
|
2006-02-27 20:07:49 -08:00
|
|
|
info->func.best_visual_get = eng_best_visual_get;
|
|
|
|
info->func.best_colormap_get = eng_best_colormap_get;
|
|
|
|
info->func.best_depth_get = eng_best_depth_get;
|
2010-05-21 00:10:45 -07:00
|
|
|
info->render_mode = EVAS_RENDER_MODE_BLOCKING;
|
2002-11-08 00:02:15 -08:00
|
|
|
return info;
|
|
|
|
e = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2009-02-28 02:08:45 -08:00
|
|
|
eng_info_free(Evas *e __UNUSED__, void *info)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Evas_Engine_Info_GL_X11 *in;
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// dont free! why bother? its not worth it
|
|
|
|
// eina_log_domain_unregister(_evas_engine_GL_X11_log_dom);
|
2002-11-08 00:02:15 -08:00
|
|
|
in = (Evas_Engine_Info_GL_X11 *)info;
|
|
|
|
free(in);
|
|
|
|
}
|
|
|
|
|
2010-08-26 02:40:48 -07:00
|
|
|
static int
|
|
|
|
_re_wincheck(Render_Engine *re)
|
|
|
|
{
|
|
|
|
if (re->win->surf) return 1;
|
|
|
|
eng_window_resurf(re->win);
|
|
|
|
if (!re->win->surf)
|
|
|
|
{
|
2010-10-07 16:46:42 -07:00
|
|
|
ERR("GL engine can't re-create window surface!");
|
2010-08-26 02:40:48 -07:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
_re_winfree(Render_Engine *re)
|
|
|
|
{
|
|
|
|
if (!re->win->surf) return;
|
|
|
|
eng_window_unsurf(re->win);
|
|
|
|
}
|
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
static Render_Engine_GL_Resource *
|
|
|
|
_create_internal_glue_resources(void *data)
|
|
|
|
{
|
|
|
|
Render_Engine *re = (Render_Engine *)data;
|
|
|
|
Render_Engine_GL_Resource *rsc;
|
|
|
|
|
|
|
|
rsc = calloc(1, sizeof(Render_Engine_GL_Resource));
|
|
|
|
|
|
|
|
if (!rsc) return NULL;
|
|
|
|
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
|
|
|
// EGL
|
|
|
|
int context_attrs[3];
|
|
|
|
context_attrs[0] = EGL_CONTEXT_CLIENT_VERSION;
|
|
|
|
context_attrs[1] = 2;
|
|
|
|
context_attrs[2] = EGL_NONE;
|
|
|
|
|
|
|
|
// Create resource surface for EGL
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
rsc->surface = glsym_eglCreateWindowSurface(re->win->egl_disp,
|
|
|
|
re->win->egl_config,
|
|
|
|
(EGLNativeWindowType)DefaultRootWindow(re->info->info.display),
|
|
|
|
NULL);
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
if (!rsc->surface)
|
|
|
|
{
|
|
|
|
ERR("Creating internal resource surface failed.");
|
|
|
|
free(rsc);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Create a resource context for EGL
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
rsc->context = glsym_eglCreateContext(re->win->egl_disp,
|
|
|
|
re->win->egl_config,
|
|
|
|
re->win->egl_context[0], // Evas' GL Context
|
|
|
|
context_attrs);
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
if (!rsc->context)
|
2011-11-10 00:59:09 -08:00
|
|
|
{
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
ERR("Internal Resource Context Creations Failed.");
|
|
|
|
free(rsc);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Add to the resource resource list for cleanup
|
|
|
|
LKL(resource_lock);
|
|
|
|
resource_list = eina_list_prepend(resource_list, rsc);
|
|
|
|
LKU(resource_lock);
|
|
|
|
|
|
|
|
// Set the resource in TLS
|
|
|
|
if (eina_tls_set(resource_key, (void*)rsc) == EINA_FALSE)
|
|
|
|
{
|
|
|
|
ERR("Failed setting TLS Resource");
|
|
|
|
free(rsc);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
#else
|
|
|
|
// GLX
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
rsc->context = glsym_glXCreateContext(re->info->info.display,
|
|
|
|
re->win->visualinfo,
|
|
|
|
re->win->context, // Evas' GL Context
|
|
|
|
1);
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
if (!rsc->context)
|
2011-11-10 00:59:09 -08:00
|
|
|
{
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
ERR("Internal Resource Context Creations Failed.");
|
|
|
|
free(rsc);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Add to the resource resource list for cleanup
|
|
|
|
LKL(resource_lock);
|
|
|
|
resource_list = eina_list_prepend(resource_list, rsc);
|
|
|
|
LKU(resource_lock);
|
|
|
|
|
|
|
|
// Set the resource in TLS
|
|
|
|
if (eina_tls_set(resource_key, (void*)rsc) == EINA_FALSE)
|
|
|
|
{
|
|
|
|
ERR("Failed setting TLS Resource");
|
|
|
|
free(rsc);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
|
|
return rsc;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
_destroy_internal_glue_resources(void *data)
|
|
|
|
{
|
|
|
|
Render_Engine *re = (Render_Engine *)data;
|
|
|
|
Eina_List *l;
|
|
|
|
Render_Engine_GL_Resource *rsc;
|
|
|
|
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
|
|
|
// EGL
|
|
|
|
// Delete the Resources
|
|
|
|
LKL(resource_lock);
|
|
|
|
EINA_LIST_FOREACH(resource_list, l, rsc)
|
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
if (rsc->surface) glsym_eglDestroySurface(re->win->egl_disp, rsc->surface);
|
|
|
|
if (rsc->context) glsym_eglDestroyContext(re->win->egl_disp, rsc->context);
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
free(rsc);
|
|
|
|
}
|
|
|
|
eina_list_free(resource_list);
|
|
|
|
LKU(resource_lock);
|
|
|
|
|
|
|
|
// Destroy TLS
|
|
|
|
eina_tls_free(resource_key);
|
|
|
|
#else
|
|
|
|
// GLX
|
|
|
|
// Delete the Resources
|
|
|
|
LKL(resource_lock);
|
|
|
|
EINA_LIST_FOREACH(resource_list, l, rsc)
|
|
|
|
{
|
2011-11-10 00:59:09 -08:00
|
|
|
if (rsc)
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glXDestroyContext(re->info->info.display, rsc->context);
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
free(rsc);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
eina_list_free(resource_list);
|
|
|
|
LKU(resource_lock);
|
|
|
|
|
|
|
|
// Destroy TLS
|
|
|
|
eina_tls_free(resource_key);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-24 02:05:32 -07:00
|
|
|
static int
|
2006-02-27 20:07:49 -08:00
|
|
|
eng_setup(Evas *e, void *in)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
|
|
|
Evas_Engine_Info_GL_X11 *info;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
info = (Evas_Engine_Info_GL_X11 *)in;
|
|
|
|
if (!e->engine.data.output)
|
2006-12-09 00:52:08 -08:00
|
|
|
{
|
2009-10-09 05:10:27 -07:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2011-06-17 00:47:28 -07:00
|
|
|
#else
|
2010-01-21 21:55:46 -08:00
|
|
|
int eb, evb;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
if (!glsym_glXQueryExtension(info->info.display, &eb, &evb)) return 0;
|
2009-10-09 05:10:27 -07:00
|
|
|
#endif
|
2011-11-10 00:59:09 -08:00
|
|
|
re = calloc(1, sizeof(Render_Engine));
|
|
|
|
if (!re) return 0;
|
2010-01-24 03:01:20 -08:00
|
|
|
re->info = info;
|
|
|
|
re->evas = e;
|
2011-11-10 00:59:09 -08:00
|
|
|
e->engine.data.output = re;
|
2010-08-26 02:40:48 -07:00
|
|
|
re->w = e->output.w;
|
|
|
|
re->h = e->output.h;
|
2011-11-10 00:59:09 -08:00
|
|
|
re->win = eng_window_new(re->info->info.display,
|
|
|
|
re->info->info.drawable,
|
2010-08-26 02:40:48 -07:00
|
|
|
re->info->info.screen,
|
2011-11-10 00:59:09 -08:00
|
|
|
re->info->info.visual,
|
|
|
|
re->info->info.colormap,
|
|
|
|
re->info->info.depth,
|
2010-08-26 02:40:48 -07:00
|
|
|
re->w,
|
|
|
|
re->h,
|
|
|
|
re->info->indirect,
|
|
|
|
re->info->info.destination_alpha,
|
|
|
|
re->info->info.rotation);
|
2011-11-10 00:59:09 -08:00
|
|
|
if (!re->win)
|
|
|
|
{
|
|
|
|
free(re);
|
|
|
|
e->engine.data.output = NULL;
|
|
|
|
return 0;
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
}
|
|
|
|
|
2010-05-17 21:22:33 -07:00
|
|
|
gl_wins++;
|
2011-10-25 05:01:44 -07:00
|
|
|
/*
|
2010-01-07 23:10:53 -08:00
|
|
|
{
|
|
|
|
int status;
|
|
|
|
char *type = NULL;
|
|
|
|
XrmValue val;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-01-07 23:10:53 -08:00
|
|
|
re->xr.dpi = 75000; // dpy * 1000
|
Load Xft.dpi from ~/.Xdefaults as well.
Do this for consistency with other applications, some people just set
.Xdefaults but do not have xrdb to load it to screen. This works with
most of the systems, like Gtk and Qt, but not in Evas, so we get
different font sizes as they calculate based on DPI.
HOWEVER, and this may be a big thing, so RASTERMAN take a look, this
might impose a performance hit on window creation... remember that
every E17 popup/tooltip will hit this process of reading the file (if
exists) and then query X server (round trip).
I'd rather make this a global resource, loaded just once for all
created windows, we can store the mtime to know when it changed and
invalidate the pointer... but as Raster did not keep the
XrmGetDatabase() result as global, I'm not doing it here either.
SVN revision: 48403
2010-04-28 13:26:04 -07:00
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
status = xrdb_user_query("Xft.dpi", "Xft.Dpi", &type, &val);
|
|
|
|
if ((!status) || (!type))
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
{
|
|
|
|
if (!re->xrdb) re->xrdb = XrmGetDatabase(re->info->info.display);
|
|
|
|
if (re->xrdb)
|
|
|
|
status = XrmGetResource(re->xrdb,
|
|
|
|
"Xft.dpi", "Xft.Dpi", &type, &val);
|
|
|
|
}
|
Load Xft.dpi from ~/.Xdefaults as well.
Do this for consistency with other applications, some people just set
.Xdefaults but do not have xrdb to load it to screen. This works with
most of the systems, like Gtk and Qt, but not in Evas, so we get
different font sizes as they calculate based on DPI.
HOWEVER, and this may be a big thing, so RASTERMAN take a look, this
might impose a performance hit on window creation... remember that
every E17 popup/tooltip will hit this process of reading the file (if
exists) and then query X server (round trip).
I'd rather make this a global resource, loaded just once for all
created windows, we can store the mtime to know when it changed and
invalidate the pointer... but as Raster did not keep the
XrmGetDatabase() result as global, I'm not doing it here either.
SVN revision: 48403
2010-04-28 13:26:04 -07:00
|
|
|
|
2010-01-07 23:10:53 -08:00
|
|
|
if ((status) && (type))
|
|
|
|
{
|
|
|
|
if (!strcmp(type, "String"))
|
|
|
|
{
|
|
|
|
const char *str, *dp;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-01-07 23:10:53 -08:00
|
|
|
str = val.addr;
|
|
|
|
dp = strchr(str, '.');
|
|
|
|
if (!dp) dp = strchr(str, ',');
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-01-07 23:10:53 -08:00
|
|
|
if (dp)
|
|
|
|
{
|
|
|
|
int subdpi, len, i;
|
|
|
|
char *buf;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-01-07 23:10:53 -08:00
|
|
|
buf = alloca(dp - str + 1);
|
|
|
|
strncpy(buf, str, dp - str);
|
|
|
|
buf[dp - str] = 0;
|
|
|
|
len = strlen(dp + 1);
|
|
|
|
subdpi = atoi(dp + 1);
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-01-07 23:10:53 -08:00
|
|
|
if (len < 3)
|
|
|
|
{
|
|
|
|
for (i = len; i < 3; i++) subdpi *= 10;
|
|
|
|
}
|
|
|
|
else if (len > 3)
|
|
|
|
{
|
|
|
|
for (i = len; i > 3; i--) subdpi /= 10;
|
|
|
|
}
|
|
|
|
re->xr.dpi = atoi(buf) * 1000;
|
|
|
|
}
|
|
|
|
else
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
re->xr.dpi = atoi(str) * 1000;
|
2010-01-30 18:50:01 -08:00
|
|
|
evas_common_font_dpi_set(re->xr.dpi / 1000);
|
2010-01-07 23:10:53 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2011-10-25 05:01:44 -07:00
|
|
|
*/
|
2010-05-17 21:22:33 -07:00
|
|
|
if (!initted)
|
|
|
|
{
|
|
|
|
evas_common_cpu_init();
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-05-17 21:22:33 -07:00
|
|
|
evas_common_blend_init();
|
|
|
|
evas_common_image_init();
|
|
|
|
evas_common_convert_init();
|
|
|
|
evas_common_scale_init();
|
|
|
|
evas_common_rectangle_init();
|
|
|
|
evas_common_polygon_init();
|
|
|
|
evas_common_line_init();
|
|
|
|
evas_common_font_init();
|
|
|
|
evas_common_draw_init();
|
|
|
|
evas_common_tilebuf_init();
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
|
|
|
|
// Initialize TLS
|
|
|
|
if (eina_tls_new(&resource_key) == EINA_FALSE)
|
|
|
|
ERR("Error creating tls key");
|
|
|
|
DBG("TLS KEY create... %d", resource_key);
|
|
|
|
|
2010-05-17 21:22:33 -07:00
|
|
|
initted = 1;
|
|
|
|
}
|
2006-12-09 00:52:08 -08:00
|
|
|
}
|
2006-03-08 00:02:34 -08:00
|
|
|
else
|
|
|
|
{
|
2011-11-10 00:59:09 -08:00
|
|
|
re = e->engine.data.output;
|
2010-08-26 02:40:48 -07:00
|
|
|
if (_re_wincheck(re))
|
2010-01-25 06:02:14 -08:00
|
|
|
{
|
2010-08-26 02:40:48 -07:00
|
|
|
if ((re->info->info.display != re->win->disp) ||
|
|
|
|
(re->info->info.drawable != re->win->win) ||
|
|
|
|
(re->info->info.screen != re->win->screen) ||
|
|
|
|
(re->info->info.visual != re->win->visual) ||
|
|
|
|
(re->info->info.colormap != re->win->colormap) ||
|
|
|
|
(re->info->info.depth != re->win->depth) ||
|
|
|
|
(re->info->info.destination_alpha != re->win->alpha) ||
|
|
|
|
(re->info->info.rotation != re->win->rot))
|
2010-07-28 01:11:30 -07:00
|
|
|
{
|
2010-08-26 02:40:48 -07:00
|
|
|
int inc = 0;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-08-26 02:40:48 -07:00
|
|
|
if (re->win)
|
|
|
|
{
|
|
|
|
re->win->gl_context->references++;
|
|
|
|
eng_window_free(re->win);
|
|
|
|
inc = 1;
|
|
|
|
gl_wins--;
|
|
|
|
}
|
|
|
|
re->w = e->output.w;
|
|
|
|
re->h = e->output.h;
|
|
|
|
re->win = eng_window_new(re->info->info.display,
|
|
|
|
re->info->info.drawable,
|
|
|
|
re->info->info.screen,
|
|
|
|
re->info->info.visual,
|
|
|
|
re->info->info.colormap,
|
|
|
|
re->info->info.depth,
|
|
|
|
re->w,
|
|
|
|
re->h,
|
|
|
|
re->info->indirect,
|
|
|
|
re->info->info.destination_alpha,
|
|
|
|
re->info->info.rotation);
|
2011-04-06 03:11:01 -07:00
|
|
|
eng_window_use(re->win);
|
2010-08-26 02:40:48 -07:00
|
|
|
if (re->win) gl_wins++;
|
|
|
|
if ((re->win) && (inc))
|
|
|
|
re->win->gl_context->references--;
|
|
|
|
}
|
|
|
|
else if ((re->win->w != e->output.w) ||
|
|
|
|
(re->win->h != e->output.h))
|
|
|
|
{
|
|
|
|
re->w = e->output.w;
|
|
|
|
re->h = e->output.h;
|
|
|
|
re->win->w = e->output.w;
|
|
|
|
re->win->h = e->output.h;
|
|
|
|
eng_window_use(re->win);
|
|
|
|
evas_gl_common_context_resize(re->win->gl_context, re->win->w, re->win->h, re->win->rot);
|
2010-07-28 01:11:30 -07:00
|
|
|
}
|
2010-01-25 06:02:14 -08:00
|
|
|
}
|
2006-03-08 00:02:34 -08:00
|
|
|
}
|
2010-05-17 20:49:59 -07:00
|
|
|
if (!re->win)
|
|
|
|
{
|
|
|
|
free(re);
|
|
|
|
return 0;
|
|
|
|
}
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-05-17 20:49:59 -07:00
|
|
|
if (!e->engine.data.output)
|
|
|
|
{
|
2010-05-17 21:22:33 -07:00
|
|
|
if (re->win)
|
|
|
|
{
|
|
|
|
eng_window_free(re->win);
|
|
|
|
gl_wins--;
|
|
|
|
}
|
2010-05-17 20:49:59 -07:00
|
|
|
free(re);
|
|
|
|
return 0;
|
|
|
|
}
|
2011-11-10 00:59:09 -08:00
|
|
|
re->tb = evas_common_tilebuf_new(re->win->w, re->win->h);
|
2011-10-21 01:58:00 -07:00
|
|
|
if (!re->tb)
|
|
|
|
{
|
|
|
|
if (re->win)
|
|
|
|
{
|
|
|
|
eng_window_free(re->win);
|
|
|
|
gl_wins--;
|
|
|
|
}
|
|
|
|
free(re);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
evas_common_tilebuf_set_tile_size(re->tb, TILESIZE, TILESIZE);
|
2011-11-10 00:59:09 -08:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
if (!e->engine.data.context)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
e->engine.data.context =
|
|
|
|
e->engine.func->context_new(e->engine.data.output);
|
2009-10-13 02:40:39 -07:00
|
|
|
eng_window_use(re->win);
|
2011-04-04 03:23:12 -07:00
|
|
|
|
2010-10-25 00:22:43 -07:00
|
|
|
re->vsync = 0;
|
2010-01-21 00:44:11 -08:00
|
|
|
_sym_init();
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
_extensions_init(re);
|
|
|
|
|
|
|
|
// This is used in extensions. Not pretty but can't get display otherwise.
|
|
|
|
current_engine = re;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2009-03-24 02:05:32 -07:00
|
|
|
return 1;
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2006-02-27 20:07:49 -08:00
|
|
|
eng_output_free(void *data)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-05-17 20:49:59 -07:00
|
|
|
if (re)
|
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// NOTE: XrmGetDatabase() result is shared per connection, do not free it.
|
|
|
|
// if (re->xrdb) XrmDestroyDatabase(re->xrdb);
|
2010-04-29 08:32:47 -07:00
|
|
|
|
2010-05-17 21:22:33 -07:00
|
|
|
if (re->win)
|
|
|
|
{
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
if ((initted == 1) && (gl_wins == 1))
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
_destroy_internal_glue_resources(re);
|
2010-05-17 21:22:33 -07:00
|
|
|
eng_window_free(re->win);
|
|
|
|
gl_wins--;
|
|
|
|
}
|
2011-10-21 01:58:00 -07:00
|
|
|
evas_common_tilebuf_free(re->tb);
|
2010-05-17 20:49:59 -07:00
|
|
|
free(re);
|
|
|
|
}
|
2010-05-17 21:22:33 -07:00
|
|
|
if ((initted == 1) && (gl_wins == 0))
|
|
|
|
{
|
|
|
|
evas_common_image_shutdown();
|
|
|
|
evas_common_font_shutdown();
|
|
|
|
initted = 0;
|
|
|
|
}
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2006-02-27 20:07:49 -08:00
|
|
|
eng_output_resize(void *data, int w, int h)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2003-09-04 00:40:34 -07:00
|
|
|
re->win->w = w;
|
|
|
|
re->win->h = h;
|
2009-10-13 02:40:39 -07:00
|
|
|
eng_window_use(re->win);
|
2010-05-08 22:15:20 -07:00
|
|
|
evas_gl_common_context_resize(re->win->gl_context, w, h, re->win->rot);
|
2011-10-21 01:58:00 -07:00
|
|
|
evas_common_tilebuf_free(re->tb);
|
|
|
|
re->tb = evas_common_tilebuf_new(w, h);
|
|
|
|
if (re->tb)
|
|
|
|
evas_common_tilebuf_set_tile_size(re->tb, TILESIZE, TILESIZE);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2011-10-21 01:58:00 -07:00
|
|
|
eng_output_tile_size_set(void *data, int w, int h)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
2011-10-21 01:58:00 -07:00
|
|
|
Render_Engine *re;
|
2011-11-10 00:59:09 -08:00
|
|
|
|
2011-10-21 01:58:00 -07:00
|
|
|
re = (Render_Engine *)data;
|
|
|
|
evas_common_tilebuf_set_tile_size(re->tb, w, h);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2006-02-27 20:07:49 -08:00
|
|
|
eng_output_redraws_rect_add(void *data, int x, int y, int w, int h)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2011-08-24 23:30:52 -07:00
|
|
|
eng_window_use(re->win);
|
2010-05-08 22:15:20 -07:00
|
|
|
evas_gl_common_context_resize(re->win->gl_context, re->win->w, re->win->h, re->win->rot);
|
2011-10-21 01:58:00 -07:00
|
|
|
evas_common_tilebuf_add_redraw(re->tb, x, y, w, h);
|
|
|
|
/*
|
2010-02-11 06:41:44 -08:00
|
|
|
RECTS_CLIP_TO_RECT(x, y, w, h, 0, 0, re->win->w, re->win->h);
|
|
|
|
if ((w <= 0) || (h <= 0)) return;
|
2003-09-04 00:40:34 -07:00
|
|
|
if (!re->win->draw.redraw)
|
|
|
|
{
|
2005-05-21 19:49:50 -07:00
|
|
|
#if 0
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
re->win->draw.x1 = x;
|
|
|
|
re->win->draw.y1 = y;
|
|
|
|
re->win->draw.x2 = x + w - 1;
|
|
|
|
re->win->draw.y2 = y + h - 1;
|
2004-06-18 08:56:30 -07:00
|
|
|
#else
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
re->win->draw.x1 = 0;
|
|
|
|
re->win->draw.y1 = 0;
|
|
|
|
re->win->draw.x2 = re->win->w - 1;
|
|
|
|
re->win->draw.y2 = re->win->h - 1;
|
2005-05-21 19:49:50 -07:00
|
|
|
#endif
|
2003-09-04 00:40:34 -07:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
if (x < re->win->draw.x1) re->win->draw.x1 = x;
|
|
|
|
if (y < re->win->draw.y1) re->win->draw.y1 = y;
|
|
|
|
if ((x + w - 1) > re->win->draw.x2) re->win->draw.x2 = x + w - 1;
|
|
|
|
if ((y + h - 1) > re->win->draw.y2) re->win->draw.y2 = y + h - 1;
|
2003-09-04 00:40:34 -07:00
|
|
|
}
|
|
|
|
re->win->draw.redraw = 1;
|
2011-10-21 01:58:00 -07:00
|
|
|
*/
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2011-12-05 16:44:25 -08:00
|
|
|
eng_output_redraws_rect_del(void *data, int x, int y, int w, int h)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
2011-10-21 01:58:00 -07:00
|
|
|
Render_Engine *re;
|
|
|
|
|
|
|
|
re = (Render_Engine *)data;
|
|
|
|
evas_common_tilebuf_del_redraw(re->tb, x, y, w, h);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2006-02-27 20:07:49 -08:00
|
|
|
eng_output_redraws_clear(void *data)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2011-10-21 01:58:00 -07:00
|
|
|
evas_common_tilebuf_clear(re->tb);
|
|
|
|
/* re->win->draw.redraw = 0;*/
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// INF("GL: finish update cycle!");
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
2007-03-03 08:05:15 -08:00
|
|
|
/* vsync games - not for now though */
|
2010-01-29 09:14:50 -08:00
|
|
|
#define VSYNC_TO_SCREEN 1
|
2007-03-03 08:05:15 -08:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
static void *
|
2006-02-27 20:07:49 -08:00
|
|
|
eng_output_redraws_next_update_get(void *data, int *x, int *y, int *w, int *h, int *cx, int *cy, int *cw, int *ch)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2011-10-21 01:58:00 -07:00
|
|
|
Tilebuf_Rect *rects;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2003-09-04 00:40:34 -07:00
|
|
|
/* get the upate rect surface - return engine data as dummy */
|
2011-10-21 01:58:00 -07:00
|
|
|
rects = evas_common_tilebuf_get_render_rects(re->tb);
|
|
|
|
if (rects)
|
|
|
|
{
|
2011-10-21 02:59:13 -07:00
|
|
|
/*
|
|
|
|
Tilebuf_Rect *r;
|
|
|
|
|
|
|
|
printf("REAAAAACCTS\n");
|
|
|
|
EINA_INLIST_FOREACH(EINA_INLIST_GET(rects), r)
|
|
|
|
{
|
|
|
|
printf(" %i %i %ix%i\n", r->x, r->y, r->w, r->h);
|
|
|
|
}
|
|
|
|
*/
|
2011-10-21 01:58:00 -07:00
|
|
|
evas_common_tilebuf_free_render_rects(rects);
|
|
|
|
evas_common_tilebuf_clear(re->tb);
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
|
|
|
// dont need to for egl - eng_window_use() can check for other ctxt's
|
|
|
|
#else
|
|
|
|
eng_window_use(NULL);
|
|
|
|
#endif
|
|
|
|
eng_window_use(re->win);
|
|
|
|
if (!_re_wincheck(re)) return NULL;
|
|
|
|
evas_gl_common_context_flush(re->win->gl_context);
|
|
|
|
evas_gl_common_context_newframe(re->win->gl_context);
|
|
|
|
if (x) *x = 0;
|
|
|
|
if (y) *y = 0;
|
|
|
|
if (w) *w = re->win->w;
|
|
|
|
if (h) *h = re->win->h;
|
|
|
|
if (cx) *cx = 0;
|
|
|
|
if (cy) *cy = 0;
|
|
|
|
if (cw) *cw = re->win->w;
|
|
|
|
if (ch) *ch = re->win->h;
|
|
|
|
return re->win->gl_context->def_surface;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
/*
|
2010-02-11 06:41:44 -08:00
|
|
|
if (!re->win->draw.redraw) return NULL;
|
2011-01-07 02:16:17 -08:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
|
|
|
// dont need to for egl - eng_window_use() can check for other ctxt's
|
|
|
|
#else
|
2010-12-02 00:01:19 -08:00
|
|
|
eng_window_use(NULL);
|
2011-06-17 00:47:28 -07:00
|
|
|
#endif
|
2010-12-02 00:01:19 -08:00
|
|
|
eng_window_use(re->win);
|
2010-08-26 02:40:48 -07:00
|
|
|
if (!_re_wincheck(re)) return NULL;
|
2010-05-20 08:24:28 -07:00
|
|
|
evas_gl_common_context_flush(re->win->gl_context);
|
|
|
|
evas_gl_common_context_newframe(re->win->gl_context);
|
2003-09-04 00:40:34 -07:00
|
|
|
if (x) *x = re->win->draw.x1;
|
|
|
|
if (y) *y = re->win->draw.y1;
|
|
|
|
if (w) *w = re->win->draw.x2 - re->win->draw.x1 + 1;
|
|
|
|
if (h) *h = re->win->draw.y2 - re->win->draw.y1 + 1;
|
|
|
|
if (cx) *cx = re->win->draw.x1;
|
|
|
|
if (cy) *cy = re->win->draw.y1;
|
|
|
|
if (cw) *cw = re->win->draw.x2 - re->win->draw.x1 + 1;
|
|
|
|
if (ch) *ch = re->win->draw.y2 - re->win->draw.y1 + 1;
|
2009-11-12 23:22:31 -08:00
|
|
|
return re->win->gl_context->def_surface;
|
2011-10-21 01:58:00 -07:00
|
|
|
*/
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
2010-03-31 02:25:21 -07:00
|
|
|
//#define FRAMECOUNT 1
|
|
|
|
|
|
|
|
#ifdef FRAMECOUNT
|
|
|
|
double
|
|
|
|
get_time(void)
|
|
|
|
{
|
|
|
|
struct timeval timev;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-03-31 02:25:21 -07:00
|
|
|
gettimeofday(&timev, NULL);
|
|
|
|
return (double)timev.tv_sec + (((double)timev.tv_usec) / 1000000);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2010-10-25 00:22:43 -07:00
|
|
|
static int safe_native = -1;
|
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
static void
|
2009-02-28 02:08:45 -08:00
|
|
|
eng_output_redraws_next_update_push(void *data, void *surface __UNUSED__, int x __UNUSED__, int y __UNUSED__, int w __UNUSED__, int h __UNUSED__)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2010-03-31 02:25:21 -07:00
|
|
|
#ifdef FRAMECOUNT
|
|
|
|
static double pt = 0.0;
|
|
|
|
double ta, tb;
|
|
|
|
#endif
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2003-09-04 00:40:34 -07:00
|
|
|
/* put back update surface.. in this case just unflag redraw */
|
2010-08-26 02:40:48 -07:00
|
|
|
if (!_re_wincheck(re)) return;
|
2003-09-04 00:40:34 -07:00
|
|
|
re->win->draw.redraw = 0;
|
2007-03-04 09:06:13 -08:00
|
|
|
re->win->draw.drew = 1;
|
2009-10-09 05:10:27 -07:00
|
|
|
evas_gl_common_context_flush(re->win->gl_context);
|
2010-10-22 01:17:37 -07:00
|
|
|
if (safe_native == -1)
|
|
|
|
{
|
|
|
|
const char *s = getenv("EVAS_GL_SAFE_NATIVE");
|
|
|
|
safe_native = 0;
|
|
|
|
if (s) safe_native = atoi(s);
|
2010-10-24 18:57:48 -07:00
|
|
|
else
|
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
s = (const char *)glsym_glGetString(GL_RENDERER);
|
2010-10-24 18:57:48 -07:00
|
|
|
if (s)
|
|
|
|
{
|
2011-07-10 23:29:20 -07:00
|
|
|
if (strstr(s, "PowerVR SGX 540") ||
|
2011-08-11 20:50:57 -07:00
|
|
|
strstr(s, "Mali-400 MP"))
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
safe_native = 1;
|
2010-10-24 18:57:48 -07:00
|
|
|
}
|
|
|
|
}
|
2010-10-22 01:17:37 -07:00
|
|
|
}
|
2010-02-01 21:30:19 -08:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2010-02-06 00:38:26 -08:00
|
|
|
// this is needed to make sure all previous rendering is flushed to
|
|
|
|
// buffers/surfaces
|
2010-03-31 02:25:21 -07:00
|
|
|
#ifdef FRAMECOUNT
|
|
|
|
double t0 = get_time();
|
|
|
|
ta = t0 - pt;
|
|
|
|
pt = t0;
|
|
|
|
#endif
|
2010-10-22 01:17:37 -07:00
|
|
|
// previous rendering should be done and swapped
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
if (!safe_native) glsym_eglWaitNative(EGL_CORE_NATIVE_ENGINE);
|
2010-03-31 02:25:21 -07:00
|
|
|
#ifdef FRAMECOUNT
|
|
|
|
double t1 = get_time();
|
|
|
|
tb = t1 - t0;
|
|
|
|
printf("... %1.5f -> %1.5f | ", ta, tb);
|
2011-06-17 00:47:28 -07:00
|
|
|
#endif
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// if (glsym_eglGetError() != EGL_SUCCESS)
|
|
|
|
// {
|
|
|
|
// printf("Error: glsym_eglWaitNative(EGL_CORE_NATIVE_ENGINE) fail.\n");
|
|
|
|
// }
|
2010-02-01 21:30:19 -08:00
|
|
|
#else
|
2010-10-22 01:17:37 -07:00
|
|
|
// previous rendering should be done and swapped
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
if (!safe_native) glsym_glXWaitX();
|
2010-02-01 21:30:19 -08:00
|
|
|
#endif
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
//x// printf("frame -> push\n");
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2006-02-27 20:07:49 -08:00
|
|
|
eng_output_flush(void *data)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2010-08-26 02:40:48 -07:00
|
|
|
if (!_re_wincheck(re)) return;
|
2007-03-04 09:06:13 -08:00
|
|
|
if (!re->win->draw.drew) return;
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
//x// printf("frame -> flush\n");
|
2007-03-04 09:06:13 -08:00
|
|
|
re->win->draw.drew = 0;
|
2006-03-06 18:44:16 -08:00
|
|
|
eng_window_use(re->win);
|
2003-09-04 00:40:34 -07:00
|
|
|
|
2010-01-24 03:01:20 -08:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2010-03-31 02:25:21 -07:00
|
|
|
#ifdef FRAMECOUNT
|
|
|
|
double t0 = get_time();
|
2010-08-01 23:44:23 -07:00
|
|
|
#endif
|
2010-10-25 00:22:43 -07:00
|
|
|
if (!re->vsync)
|
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
if (re->info->vsync) glsym_eglSwapInterval(re->win->egl_disp, 1);
|
|
|
|
else glsym_eglSwapInterval(re->win->egl_disp, 0);
|
2010-10-25 00:22:43 -07:00
|
|
|
re->vsync = 1;
|
|
|
|
}
|
2011-05-11 02:14:59 -07:00
|
|
|
if (re->info->callback.pre_swap)
|
|
|
|
{
|
|
|
|
re->info->callback.pre_swap(re->info->callback.data, re->evas);
|
|
|
|
}
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_eglSwapBuffers(re->win->egl_disp, re->win->egl_surface[0]);
|
|
|
|
if (!safe_native) glsym_eglWaitGL();
|
2011-05-11 02:14:59 -07:00
|
|
|
if (re->info->callback.post_swap)
|
|
|
|
{
|
|
|
|
re->info->callback.post_swap(re->info->callback.data, re->evas);
|
|
|
|
}
|
2010-03-31 02:25:21 -07:00
|
|
|
#ifdef FRAMECOUNT
|
|
|
|
double t1 = get_time();
|
|
|
|
printf("%1.5f\n", t1 - t0);
|
2011-06-17 00:47:28 -07:00
|
|
|
#endif
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// if (glsym_eglGetError() != EGL_SUCCESS)
|
|
|
|
// {
|
|
|
|
// printf("Error: glsym_eglSwapBuffers() fail.\n");
|
|
|
|
// }
|
2009-10-09 05:10:27 -07:00
|
|
|
#else
|
2011-06-17 00:47:28 -07:00
|
|
|
#ifdef VSYNC_TO_SCREEN
|
2010-02-11 06:41:44 -08:00
|
|
|
if ((re->info->vsync)/* || (1)*/)
|
2010-01-29 09:14:50 -08:00
|
|
|
{
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
if (glsym_glXSwapIntervalEXT)
|
2011-03-08 03:20:49 -08:00
|
|
|
{
|
|
|
|
if (!re->vsync)
|
|
|
|
{
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
if (re->info->vsync) glsym_glXSwapIntervalEXT(re->win->disp, re->win->win, 1);
|
|
|
|
else glsym_glXSwapIntervalEXT(re->win->disp, re->win->win, 0);
|
2011-03-08 03:20:49 -08:00
|
|
|
re->vsync = 1;
|
|
|
|
}
|
|
|
|
}
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
if (glsym_glXSwapIntervalSGI)
|
2010-01-29 09:14:50 -08:00
|
|
|
{
|
2010-12-26 02:15:28 -08:00
|
|
|
if (!re->vsync)
|
|
|
|
{
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
if (re->info->vsync) glsym_glXSwapIntervalSGI(1);
|
|
|
|
else glsym_glXSwapIntervalSGI(0);
|
2010-12-26 02:15:28 -08:00
|
|
|
re->vsync = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if ((glsym_glXGetVideoSync) && (glsym_glXWaitVideoSync))
|
|
|
|
{
|
|
|
|
unsigned int rc;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-12-26 02:15:28 -08:00
|
|
|
glsym_glXGetVideoSync(&rc);
|
|
|
|
glsym_glXWaitVideoSync(1, 0, &rc);
|
|
|
|
}
|
2010-01-29 09:14:50 -08:00
|
|
|
}
|
|
|
|
}
|
2009-10-09 05:10:27 -07:00
|
|
|
# endif
|
2010-01-24 03:01:20 -08:00
|
|
|
if (re->info->callback.pre_swap)
|
|
|
|
{
|
|
|
|
re->info->callback.pre_swap(re->info->callback.data, re->evas);
|
|
|
|
}
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
/*
|
|
|
|
if ((1)
|
|
|
|
// (re->win->draw.x1 == 0) &&
|
|
|
|
// (re->win->draw.y1 == 0) &&
|
|
|
|
// (re->win->draw.x2 == (re->win->w - 1)) &&
|
|
|
|
// (re->win->draw.y2 == (re->win->h - 1))
|
|
|
|
)
|
|
|
|
*/
|
2010-02-14 07:12:39 -08:00
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glXSwapBuffers(re->win->disp, re->win->win);
|
|
|
|
if (!safe_native) glsym_glXWaitGL();
|
2010-02-14 07:12:39 -08:00
|
|
|
}
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
/*
|
|
|
|
else
|
|
|
|
{
|
|
|
|
// FIXME: this doesn't work.. why oh why?
|
|
|
|
int sx, sy, sw, sh;
|
|
|
|
|
|
|
|
// fimxe - reset when done
|
|
|
|
// glEnable(GL_SCISSOR_TEST);
|
|
|
|
glDrawBuffer(GL_FRONT);
|
|
|
|
|
|
|
|
sx = re->win->draw.x1;
|
|
|
|
sy = re->win->draw.y1;
|
|
|
|
sw = (re->win->draw.x2 - re->win->draw.x1) + 1;
|
|
|
|
sh = (re->win->draw.y2 - re->win->draw.y1) + 1;
|
|
|
|
sy = re->win->h - sy - sh;
|
|
|
|
|
|
|
|
// glScissor(sx, sy, sw, sh);
|
|
|
|
glRasterPos2i(sx, re->win->h - sy);
|
|
|
|
glCopyPixels(sx, sy, sw, sh, GL_COLOR);
|
|
|
|
glRasterPos2i(0, 0);
|
|
|
|
|
|
|
|
// glDisable(GL_SCISSOR_TEST);
|
|
|
|
glDrawBuffer(GL_BACK);
|
|
|
|
glFlush();
|
|
|
|
}
|
|
|
|
*/
|
2010-01-24 03:01:20 -08:00
|
|
|
if (re->info->callback.post_swap)
|
|
|
|
{
|
|
|
|
re->info->callback.post_swap(re->info->callback.data, re->evas);
|
|
|
|
}
|
2010-02-28 20:44:23 -08:00
|
|
|
#endif
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
2007-06-16 19:56:59 -07:00
|
|
|
static void
|
|
|
|
eng_output_idle_flush(void *data)
|
|
|
|
{
|
2010-04-12 01:23:53 -07:00
|
|
|
Render_Engine *re;
|
|
|
|
|
|
|
|
re = (Render_Engine *)data;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
eng_output_dump(void *data)
|
|
|
|
{
|
|
|
|
Render_Engine *re;
|
|
|
|
|
|
|
|
re = (Render_Engine *)data;
|
|
|
|
evas_common_image_image_all_unload();
|
|
|
|
evas_common_font_font_all_unload();
|
|
|
|
evas_gl_common_image_all_unload(re->win->gl_context);
|
2010-08-26 02:40:48 -07:00
|
|
|
_re_winfree(re);
|
2007-06-16 19:56:59 -07:00
|
|
|
}
|
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
static void
|
cleanup: fix some "unused" errors from -Wextra.
As we're heading for a release we better remove as much errors as
possible and as the first step I'm removing warnings due unused
parameters, variables and functions. These tend to pollute real errors
spotted by -Wall and clang/llvm.
This does not fixes all, just the clear that could be set to
__UNUSED__, particularly to do (and I'd like some help from the
authors):
* src/lib/engines/common/evas_font_{draw,query}.c (tasn):
intl_props is just used while doing BIDI, but also used in other
#ifdef blocks :-/
* evas_map_* (raster):
huge amount of warnings, code is quite confusing and thus I'm not
touching it. I have no idea whenever the commented blocks or extra
parameters are intended to be used or no.
* src/modules/engines/fbevas_fb_main.c (raster?):
is fb_setvt() to be used? If not do you mind removing it?
* src/modules/engines/gl_{common,x11} (raster):
huge amount of warnings, code is quite nested and full of #ifdefs
that does not help to give a clear picture of what's going on.
* src/bin/evas_cserve_main.c (raster):
I could have ignored most of the errors, but is the code correct? I
mean, there is no unload of images being applied. If you confirm
none of those warnings are harmful I can flag them as unused.
* src/lib/engines/common_8 (dottedmag):
lots of unused functions that were acquired from common_16, they
are unused and if they will not, then they should be removed.
SVN revision: 52421
2010-09-18 12:17:41 -07:00
|
|
|
eng_context_cutout_add(void *data __UNUSED__, void *context, int x, int y, int w, int h)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// Render_Engine *re;
|
|
|
|
//
|
|
|
|
// re = (Render_Engine *)data;
|
|
|
|
// re->win->gl_context->dc = context;
|
2009-02-20 19:13:49 -08:00
|
|
|
evas_common_draw_context_add_cutout(context, x, y, w, h);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
cleanup: fix some "unused" errors from -Wextra.
As we're heading for a release we better remove as much errors as
possible and as the first step I'm removing warnings due unused
parameters, variables and functions. These tend to pollute real errors
spotted by -Wall and clang/llvm.
This does not fixes all, just the clear that could be set to
__UNUSED__, particularly to do (and I'd like some help from the
authors):
* src/lib/engines/common/evas_font_{draw,query}.c (tasn):
intl_props is just used while doing BIDI, but also used in other
#ifdef blocks :-/
* evas_map_* (raster):
huge amount of warnings, code is quite confusing and thus I'm not
touching it. I have no idea whenever the commented blocks or extra
parameters are intended to be used or no.
* src/modules/engines/fbevas_fb_main.c (raster?):
is fb_setvt() to be used? If not do you mind removing it?
* src/modules/engines/gl_{common,x11} (raster):
huge amount of warnings, code is quite nested and full of #ifdefs
that does not help to give a clear picture of what's going on.
* src/bin/evas_cserve_main.c (raster):
I could have ignored most of the errors, but is the code correct? I
mean, there is no unload of images being applied. If you confirm
none of those warnings are harmful I can flag them as unused.
* src/lib/engines/common_8 (dottedmag):
lots of unused functions that were acquired from common_16, they
are unused and if they will not, then they should be removed.
SVN revision: 52421
2010-09-18 12:17:41 -07:00
|
|
|
eng_context_cutout_clear(void *data __UNUSED__, void *context)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// Render_Engine *re;
|
|
|
|
//
|
|
|
|
// re = (Render_Engine *)data;
|
|
|
|
// re->win->gl_context->dc = context;
|
2009-02-20 19:13:49 -08:00
|
|
|
evas_common_draw_context_clear_cutouts(context);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2009-11-12 23:22:31 -08:00
|
|
|
eng_rectangle_draw(void *data, void *context, void *surface, int x, int y, int w, int h)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2006-03-06 18:44:16 -08:00
|
|
|
eng_window_use(re->win);
|
2009-11-12 23:22:31 -08:00
|
|
|
evas_gl_common_context_target_surface_set(re->win->gl_context, surface);
|
2006-09-30 03:18:37 -07:00
|
|
|
re->win->gl_context->dc = context;
|
|
|
|
evas_gl_common_rect_draw(re->win->gl_context, x, y, w, h);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2009-11-12 23:22:31 -08:00
|
|
|
eng_line_draw(void *data, void *context, void *surface, int x1, int y1, int x2, int y2)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2009-10-09 05:10:27 -07:00
|
|
|
eng_window_use(re->win);
|
2009-11-12 23:22:31 -08:00
|
|
|
evas_gl_common_context_target_surface_set(re->win->gl_context, surface);
|
2006-09-30 03:18:37 -07:00
|
|
|
re->win->gl_context->dc = context;
|
2009-12-30 03:35:40 -08:00
|
|
|
evas_gl_common_line_draw(re->win->gl_context, x1, y1, x2, y2);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void *
|
2009-02-28 02:08:45 -08:00
|
|
|
eng_polygon_point_add(void *data, void *context __UNUSED__, void *polygon, int x, int y)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2009-12-26 16:40:25 -08:00
|
|
|
return evas_gl_common_poly_point_add(polygon, x, y);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void *
|
2009-02-28 02:08:45 -08:00
|
|
|
eng_polygon_points_clear(void *data, void *context __UNUSED__, void *polygon)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2009-12-26 16:40:25 -08:00
|
|
|
return evas_gl_common_poly_points_clear(polygon);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2010-03-16 06:23:37 -07:00
|
|
|
eng_polygon_draw(void *data, void *context, void *surface __UNUSED__, void *polygon, int x, int y)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2009-10-09 05:10:27 -07:00
|
|
|
eng_window_use(re->win);
|
2009-11-12 23:22:31 -08:00
|
|
|
evas_gl_common_context_target_surface_set(re->win->gl_context, surface);
|
2006-09-30 03:18:37 -07:00
|
|
|
re->win->gl_context->dc = context;
|
2010-03-16 06:23:37 -07:00
|
|
|
evas_gl_common_poly_draw(re->win->gl_context, polygon, x, y);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
2006-12-17 07:48:52 -08:00
|
|
|
static int
|
cleanup: fix some "unused" errors from -Wextra.
As we're heading for a release we better remove as much errors as
possible and as the first step I'm removing warnings due unused
parameters, variables and functions. These tend to pollute real errors
spotted by -Wall and clang/llvm.
This does not fixes all, just the clear that could be set to
__UNUSED__, particularly to do (and I'd like some help from the
authors):
* src/lib/engines/common/evas_font_{draw,query}.c (tasn):
intl_props is just used while doing BIDI, but also used in other
#ifdef blocks :-/
* evas_map_* (raster):
huge amount of warnings, code is quite confusing and thus I'm not
touching it. I have no idea whenever the commented blocks or extra
parameters are intended to be used or no.
* src/modules/engines/fbevas_fb_main.c (raster?):
is fb_setvt() to be used? If not do you mind removing it?
* src/modules/engines/gl_{common,x11} (raster):
huge amount of warnings, code is quite nested and full of #ifdefs
that does not help to give a clear picture of what's going on.
* src/bin/evas_cserve_main.c (raster):
I could have ignored most of the errors, but is the code correct? I
mean, there is no unload of images being applied. If you confirm
none of those warnings are harmful I can flag them as unused.
* src/lib/engines/common_8 (dottedmag):
lots of unused functions that were acquired from common_16, they
are unused and if they will not, then they should be removed.
SVN revision: 52421
2010-09-18 12:17:41 -07:00
|
|
|
eng_image_alpha_get(void *data __UNUSED__, void *image)
|
2006-12-17 07:48:52 -08:00
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// Render_Engine *re;
|
2006-12-17 07:48:52 -08:00
|
|
|
Evas_GL_Image *im;
|
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// re = (Render_Engine *)data;
|
2006-12-17 08:46:30 -08:00
|
|
|
if (!image) return 1;
|
2006-12-17 07:48:52 -08:00
|
|
|
im = image;
|
2010-01-21 04:43:53 -08:00
|
|
|
return im->alpha;
|
2006-12-17 07:48:52 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
cleanup: fix some "unused" errors from -Wextra.
As we're heading for a release we better remove as much errors as
possible and as the first step I'm removing warnings due unused
parameters, variables and functions. These tend to pollute real errors
spotted by -Wall and clang/llvm.
This does not fixes all, just the clear that could be set to
__UNUSED__, particularly to do (and I'd like some help from the
authors):
* src/lib/engines/common/evas_font_{draw,query}.c (tasn):
intl_props is just used while doing BIDI, but also used in other
#ifdef blocks :-/
* evas_map_* (raster):
huge amount of warnings, code is quite confusing and thus I'm not
touching it. I have no idea whenever the commented blocks or extra
parameters are intended to be used or no.
* src/modules/engines/fbevas_fb_main.c (raster?):
is fb_setvt() to be used? If not do you mind removing it?
* src/modules/engines/gl_{common,x11} (raster):
huge amount of warnings, code is quite nested and full of #ifdefs
that does not help to give a clear picture of what's going on.
* src/bin/evas_cserve_main.c (raster):
I could have ignored most of the errors, but is the code correct? I
mean, there is no unload of images being applied. If you confirm
none of those warnings are harmful I can flag them as unused.
* src/lib/engines/common_8 (dottedmag):
lots of unused functions that were acquired from common_16, they
are unused and if they will not, then they should be removed.
SVN revision: 52421
2010-09-18 12:17:41 -07:00
|
|
|
eng_image_colorspace_get(void *data __UNUSED__, void *image)
|
2006-12-17 07:48:52 -08:00
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// Render_Engine *re;
|
2006-12-17 07:48:52 -08:00
|
|
|
Evas_GL_Image *im;
|
2009-02-21 00:19:58 -08:00
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// re = (Render_Engine *)data;
|
2006-12-17 08:46:30 -08:00
|
|
|
if (!image) return EVAS_COLORSPACE_ARGB8888;
|
2006-12-17 07:48:52 -08:00
|
|
|
im = image;
|
|
|
|
return im->cs.space;
|
|
|
|
}
|
|
|
|
|
2011-04-05 22:38:38 -07:00
|
|
|
static void
|
|
|
|
eng_image_mask_create(void *data __UNUSED__, void *image)
|
|
|
|
{
|
|
|
|
Evas_GL_Image *im;
|
|
|
|
|
|
|
|
if (!image) return;
|
|
|
|
im = image;
|
|
|
|
if (!im->im->image.data)
|
|
|
|
evas_cache_image_load_data(&im->im->cache_entry);
|
|
|
|
if (!im->tex)
|
|
|
|
im->tex = evas_gl_common_texture_new(im->gc, im->im);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2006-12-17 07:48:52 -08:00
|
|
|
static void *
|
|
|
|
eng_image_alpha_set(void *data, void *image, int has_alpha)
|
|
|
|
{
|
|
|
|
Render_Engine *re;
|
|
|
|
Evas_GL_Image *im;
|
|
|
|
|
|
|
|
re = (Render_Engine *)data;
|
2006-12-19 06:12:40 -08:00
|
|
|
if (!image) return NULL;
|
2006-12-17 07:48:52 -08:00
|
|
|
im = image;
|
2010-08-18 22:18:17 -07:00
|
|
|
if (im->alpha == has_alpha) return image;
|
2010-01-21 01:42:26 -08:00
|
|
|
if (im->native.data)
|
|
|
|
{
|
|
|
|
im->alpha = has_alpha;
|
|
|
|
return image;
|
|
|
|
}
|
2010-01-21 04:43:53 -08:00
|
|
|
eng_window_use(re->win);
|
2010-08-18 22:18:17 -07:00
|
|
|
if ((im->tex) && (im->tex->pt->dyn.img))
|
|
|
|
{
|
|
|
|
im->alpha = has_alpha;
|
|
|
|
im->tex->alpha = im->alpha;
|
|
|
|
return image;
|
|
|
|
}
|
2006-12-17 07:48:52 -08:00
|
|
|
/* FIXME: can move to gl_common */
|
|
|
|
if (im->cs.space != EVAS_COLORSPACE_ARGB8888) return im;
|
2008-06-03 02:09:39 -07:00
|
|
|
if ((has_alpha) && (im->im->cache_entry.flags.alpha)) return image;
|
|
|
|
else if ((!has_alpha) && (!im->im->cache_entry.flags.alpha)) return image;
|
2006-12-17 07:48:52 -08:00
|
|
|
if (im->references > 1)
|
2009-10-09 05:10:27 -07:00
|
|
|
{
|
|
|
|
Evas_GL_Image *im_new;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-08-25 02:29:56 -07:00
|
|
|
im_new = evas_gl_common_image_new_from_copied_data
|
2011-06-17 00:47:28 -07:00
|
|
|
(im->gc, im->im->cache_entry.w, im->im->cache_entry.h,
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
im->im->image.data,
|
|
|
|
eng_image_alpha_get(data, image),
|
|
|
|
eng_image_colorspace_get(data, image));
|
2009-10-09 05:10:27 -07:00
|
|
|
if (!im_new) return im;
|
|
|
|
evas_gl_common_image_free(im);
|
|
|
|
im = im_new;
|
2006-12-17 07:48:52 -08:00
|
|
|
}
|
|
|
|
else
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
evas_gl_common_image_dirty(im, 0, 0, 0, 0);
|
2010-02-21 07:49:44 -08:00
|
|
|
return evas_gl_common_image_alpha_set(im, has_alpha ? 1 : 0);
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// im->im->cache_entry.flags.alpha = has_alpha ? 1 : 0;
|
|
|
|
// return image;
|
2006-12-17 07:48:52 -08:00
|
|
|
}
|
|
|
|
|
2008-11-04 01:19:35 -08:00
|
|
|
static void *
|
cleanup: fix some "unused" errors from -Wextra.
As we're heading for a release we better remove as much errors as
possible and as the first step I'm removing warnings due unused
parameters, variables and functions. These tend to pollute real errors
spotted by -Wall and clang/llvm.
This does not fixes all, just the clear that could be set to
__UNUSED__, particularly to do (and I'd like some help from the
authors):
* src/lib/engines/common/evas_font_{draw,query}.c (tasn):
intl_props is just used while doing BIDI, but also used in other
#ifdef blocks :-/
* evas_map_* (raster):
huge amount of warnings, code is quite confusing and thus I'm not
touching it. I have no idea whenever the commented blocks or extra
parameters are intended to be used or no.
* src/modules/engines/fbevas_fb_main.c (raster?):
is fb_setvt() to be used? If not do you mind removing it?
* src/modules/engines/gl_{common,x11} (raster):
huge amount of warnings, code is quite nested and full of #ifdefs
that does not help to give a clear picture of what's going on.
* src/bin/evas_cserve_main.c (raster):
I could have ignored most of the errors, but is the code correct? I
mean, there is no unload of images being applied. If you confirm
none of those warnings are harmful I can flag them as unused.
* src/lib/engines/common_8 (dottedmag):
lots of unused functions that were acquired from common_16, they
are unused and if they will not, then they should be removed.
SVN revision: 52421
2010-09-18 12:17:41 -07:00
|
|
|
eng_image_border_set(void *data __UNUSED__, void *image, int l __UNUSED__, int r __UNUSED__, int t __UNUSED__, int b __UNUSED__)
|
2008-11-04 01:19:35 -08:00
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// Render_Engine *re;
|
|
|
|
//
|
|
|
|
// re = (Render_Engine *)data;
|
2008-11-04 01:19:35 -08:00
|
|
|
return image;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
cleanup: fix some "unused" errors from -Wextra.
As we're heading for a release we better remove as much errors as
possible and as the first step I'm removing warnings due unused
parameters, variables and functions. These tend to pollute real errors
spotted by -Wall and clang/llvm.
This does not fixes all, just the clear that could be set to
__UNUSED__, particularly to do (and I'd like some help from the
authors):
* src/lib/engines/common/evas_font_{draw,query}.c (tasn):
intl_props is just used while doing BIDI, but also used in other
#ifdef blocks :-/
* evas_map_* (raster):
huge amount of warnings, code is quite confusing and thus I'm not
touching it. I have no idea whenever the commented blocks or extra
parameters are intended to be used or no.
* src/modules/engines/fbevas_fb_main.c (raster?):
is fb_setvt() to be used? If not do you mind removing it?
* src/modules/engines/gl_{common,x11} (raster):
huge amount of warnings, code is quite nested and full of #ifdefs
that does not help to give a clear picture of what's going on.
* src/bin/evas_cserve_main.c (raster):
I could have ignored most of the errors, but is the code correct? I
mean, there is no unload of images being applied. If you confirm
none of those warnings are harmful I can flag them as unused.
* src/lib/engines/common_8 (dottedmag):
lots of unused functions that were acquired from common_16, they
are unused and if they will not, then they should be removed.
SVN revision: 52421
2010-09-18 12:17:41 -07:00
|
|
|
eng_image_border_get(void *data __UNUSED__, void *image __UNUSED__, int *l __UNUSED__, int *r __UNUSED__, int *t __UNUSED__, int *b __UNUSED__)
|
2008-11-04 01:19:35 -08:00
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// Render_Engine *re;
|
|
|
|
//
|
|
|
|
// re = (Render_Engine *)data;
|
2008-11-04 01:19:35 -08:00
|
|
|
}
|
|
|
|
|
2006-12-17 07:48:52 -08:00
|
|
|
static char *
|
cleanup: fix some "unused" errors from -Wextra.
As we're heading for a release we better remove as much errors as
possible and as the first step I'm removing warnings due unused
parameters, variables and functions. These tend to pollute real errors
spotted by -Wall and clang/llvm.
This does not fixes all, just the clear that could be set to
__UNUSED__, particularly to do (and I'd like some help from the
authors):
* src/lib/engines/common/evas_font_{draw,query}.c (tasn):
intl_props is just used while doing BIDI, but also used in other
#ifdef blocks :-/
* evas_map_* (raster):
huge amount of warnings, code is quite confusing and thus I'm not
touching it. I have no idea whenever the commented blocks or extra
parameters are intended to be used or no.
* src/modules/engines/fbevas_fb_main.c (raster?):
is fb_setvt() to be used? If not do you mind removing it?
* src/modules/engines/gl_{common,x11} (raster):
huge amount of warnings, code is quite nested and full of #ifdefs
that does not help to give a clear picture of what's going on.
* src/bin/evas_cserve_main.c (raster):
I could have ignored most of the errors, but is the code correct? I
mean, there is no unload of images being applied. If you confirm
none of those warnings are harmful I can flag them as unused.
* src/lib/engines/common_8 (dottedmag):
lots of unused functions that were acquired from common_16, they
are unused and if they will not, then they should be removed.
SVN revision: 52421
2010-09-18 12:17:41 -07:00
|
|
|
eng_image_comment_get(void *data __UNUSED__, void *image, char *key __UNUSED__)
|
2006-12-17 07:48:52 -08:00
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// Render_Engine *re;
|
2006-12-17 07:48:52 -08:00
|
|
|
Evas_GL_Image *im;
|
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// re = (Render_Engine *)data;
|
2006-12-19 06:12:40 -08:00
|
|
|
if (!image) return NULL;
|
2006-12-17 07:48:52 -08:00
|
|
|
im = image;
|
2010-01-21 04:43:53 -08:00
|
|
|
if (!im->im) return NULL;
|
2006-12-17 07:48:52 -08:00
|
|
|
return im->im->info.comment;
|
|
|
|
}
|
|
|
|
|
|
|
|
static char *
|
cleanup: fix some "unused" errors from -Wextra.
As we're heading for a release we better remove as much errors as
possible and as the first step I'm removing warnings due unused
parameters, variables and functions. These tend to pollute real errors
spotted by -Wall and clang/llvm.
This does not fixes all, just the clear that could be set to
__UNUSED__, particularly to do (and I'd like some help from the
authors):
* src/lib/engines/common/evas_font_{draw,query}.c (tasn):
intl_props is just used while doing BIDI, but also used in other
#ifdef blocks :-/
* evas_map_* (raster):
huge amount of warnings, code is quite confusing and thus I'm not
touching it. I have no idea whenever the commented blocks or extra
parameters are intended to be used or no.
* src/modules/engines/fbevas_fb_main.c (raster?):
is fb_setvt() to be used? If not do you mind removing it?
* src/modules/engines/gl_{common,x11} (raster):
huge amount of warnings, code is quite nested and full of #ifdefs
that does not help to give a clear picture of what's going on.
* src/bin/evas_cserve_main.c (raster):
I could have ignored most of the errors, but is the code correct? I
mean, there is no unload of images being applied. If you confirm
none of those warnings are harmful I can flag them as unused.
* src/lib/engines/common_8 (dottedmag):
lots of unused functions that were acquired from common_16, they
are unused and if they will not, then they should be removed.
SVN revision: 52421
2010-09-18 12:17:41 -07:00
|
|
|
eng_image_format_get(void *data __UNUSED__, void *image)
|
2006-12-17 07:48:52 -08:00
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// Render_Engine *re;
|
2006-12-17 07:48:52 -08:00
|
|
|
Evas_GL_Image *im;
|
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// re = (Render_Engine *)data;
|
2006-12-17 07:48:52 -08:00
|
|
|
im = image;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
eng_image_colorspace_set(void *data, void *image, int cspace)
|
|
|
|
{
|
|
|
|
Render_Engine *re;
|
|
|
|
Evas_GL_Image *im;
|
2009-02-21 00:19:58 -08:00
|
|
|
|
2006-12-17 07:48:52 -08:00
|
|
|
re = (Render_Engine *)data;
|
2006-12-19 06:12:40 -08:00
|
|
|
if (!image) return;
|
2006-12-17 07:48:52 -08:00
|
|
|
im = image;
|
2010-01-21 01:42:26 -08:00
|
|
|
if (im->native.data) return;
|
2006-12-17 07:48:52 -08:00
|
|
|
/* FIXME: can move to gl_common */
|
|
|
|
if (im->cs.space == cspace) return;
|
2009-10-09 05:10:27 -07:00
|
|
|
eng_window_use(re->win);
|
2008-04-11 17:32:30 -07:00
|
|
|
evas_cache_image_colorspace(&im->im->cache_entry, cspace);
|
2006-12-17 07:48:52 -08:00
|
|
|
switch (cspace)
|
|
|
|
{
|
|
|
|
case EVAS_COLORSPACE_ARGB8888:
|
2011-11-10 00:59:09 -08:00
|
|
|
if (im->cs.data)
|
|
|
|
{
|
|
|
|
if (!im->cs.no_free) free(im->cs.data);
|
|
|
|
im->cs.data = NULL;
|
|
|
|
im->cs.no_free = 0;
|
|
|
|
}
|
|
|
|
break;
|
2006-12-17 07:48:52 -08:00
|
|
|
case EVAS_COLORSPACE_YCBCR422P601_PL:
|
|
|
|
case EVAS_COLORSPACE_YCBCR422P709_PL:
|
2011-08-23 08:13:40 -07:00
|
|
|
case EVAS_COLORSPACE_YCBCR422601_PL:
|
2011-08-29 13:56:48 -07:00
|
|
|
case EVAS_COLORSPACE_YCBCR420NV12601_PL:
|
|
|
|
case EVAS_COLORSPACE_YCBCR420TM12601_PL:
|
2011-11-10 00:59:09 -08:00
|
|
|
if (im->tex) evas_gl_common_texture_free(im->tex);
|
|
|
|
im->tex = NULL;
|
|
|
|
if (im->cs.data)
|
|
|
|
{
|
|
|
|
if (!im->cs.no_free) free(im->cs.data);
|
|
|
|
}
|
|
|
|
if (im->im->cache_entry.h > 0)
|
|
|
|
im->cs.data =
|
|
|
|
calloc(1, im->im->cache_entry.h * sizeof(unsigned char *) * 2);
|
|
|
|
else
|
|
|
|
im->cs.data = NULL;
|
|
|
|
im->cs.no_free = 0;
|
|
|
|
break;
|
2006-12-17 07:48:52 -08:00
|
|
|
default:
|
2011-11-10 00:59:09 -08:00
|
|
|
abort();
|
|
|
|
break;
|
2006-12-17 07:48:52 -08:00
|
|
|
}
|
|
|
|
im->cs.space = cspace;
|
|
|
|
}
|
|
|
|
|
2010-01-21 00:44:11 -08:00
|
|
|
/////////////////////////////////////////////////////////////////////////
|
|
|
|
//
|
|
|
|
//
|
|
|
|
typedef struct _Native Native;
|
|
|
|
|
|
|
|
struct _Native
|
|
|
|
{
|
|
|
|
Evas_Native_Surface ns;
|
|
|
|
Pixmap pixmap;
|
|
|
|
Visual *visual;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-01-21 00:44:11 -08:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2010-01-28 21:32:51 -08:00
|
|
|
void *egl_surface;
|
2010-01-21 00:44:11 -08:00
|
|
|
#else
|
2010-02-14 07:12:39 -08:00
|
|
|
void *fbc;
|
|
|
|
XID glx_pixmap;
|
2010-01-21 00:44:11 -08:00
|
|
|
#endif
|
|
|
|
};
|
|
|
|
|
2010-01-23 21:11:54 -08:00
|
|
|
// FIXME: this is enabled so updates happen - but its SLOOOOOOOOOOOOOOOW
|
|
|
|
// (i am sure this is the reason) not to mention seemingly superfluous. but
|
|
|
|
// i need to enable it for it to work on fglrx at least. havent tried nvidia.
|
2011-06-17 00:47:28 -07:00
|
|
|
//
|
2010-01-23 21:11:54 -08:00
|
|
|
// why is this the case? does anyone know? has anyone tried it on other gfx
|
|
|
|
// drivers?
|
2011-06-17 00:47:28 -07:00
|
|
|
//
|
2010-01-30 18:50:01 -08:00
|
|
|
//#define GLX_TEX_PIXMAP_RECREATE 1
|
2010-01-23 21:11:54 -08:00
|
|
|
|
2010-01-21 00:44:11 -08:00
|
|
|
static void
|
|
|
|
_native_bind_cb(void *data, void *image)
|
|
|
|
{
|
|
|
|
Evas_GL_Image *im = image;
|
|
|
|
Native *n = im->native.data;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
if (n->ns.type == EVAS_NATIVE_SURFACE_X11)
|
|
|
|
{
|
2010-01-21 00:44:11 -08:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
if (n->egl_surface)
|
|
|
|
{
|
|
|
|
if (glsym_glEGLImageTargetTexture2DOES)
|
|
|
|
{
|
|
|
|
glsym_glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, n->egl_surface);
|
|
|
|
if (glsym_eglGetError() != EGL_SUCCESS)
|
|
|
|
ERR("glEGLImageTargetTexture2DOES() failed.");
|
|
|
|
}
|
|
|
|
else
|
|
|
|
ERR("Try glEGLImageTargetTexture2DOES on EGL with no support");
|
|
|
|
}
|
2010-01-21 00:44:11 -08:00
|
|
|
#else
|
|
|
|
# ifdef GLX_BIND_TO_TEXTURE_TARGETS_EXT
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
Render_Engine *re = data;
|
|
|
|
|
|
|
|
if (glsym_glXBindTexImage)
|
|
|
|
{
|
|
|
|
glsym_glXBindTexImage(re->win->disp, n->glx_pixmap,
|
|
|
|
GLX_FRONT_LEFT_EXT, NULL);
|
|
|
|
GLERR(__FUNCTION__, __FILE__, __LINE__, "");
|
|
|
|
}
|
|
|
|
else
|
|
|
|
ERR("Try glXBindTexImage on GLX with no support");
|
2010-01-21 00:44:11 -08:00
|
|
|
# endif
|
|
|
|
#endif
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
}
|
|
|
|
else if (n->ns.type == EVAS_NATIVE_SURFACE_OPENGL)
|
|
|
|
{
|
|
|
|
glsym_glBindTexture(GL_TEXTURE_2D, n->ns.data.opengl.texture_id);
|
|
|
|
GLERR(__FUNCTION__, __FILE__, __LINE__, "");
|
|
|
|
}
|
2011-04-08 21:13:21 -07:00
|
|
|
return;
|
|
|
|
data = NULL;
|
2010-01-21 00:44:11 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
_native_unbind_cb(void *data, void *image)
|
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
Evas_GL_Image *im = image;
|
|
|
|
Native *n = im->native.data;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
if (n->ns.type == EVAS_NATIVE_SURFACE_X11)
|
|
|
|
{
|
2010-01-21 00:44:11 -08:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// nothing
|
2010-01-21 00:44:11 -08:00
|
|
|
#else
|
|
|
|
# ifdef GLX_BIND_TO_TEXTURE_TARGETS_EXT
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
Render_Engine *re = data;
|
|
|
|
|
|
|
|
if (glsym_glXReleaseTexImage)
|
|
|
|
{
|
|
|
|
glsym_glXReleaseTexImage(re->win->disp, n->glx_pixmap,
|
|
|
|
GLX_FRONT_LEFT_EXT);
|
|
|
|
GLERR(__FUNCTION__, __FILE__, __LINE__, "");
|
|
|
|
}
|
|
|
|
else
|
|
|
|
ERR("Try glXReleaseTexImage on GLX with no support");
|
2010-01-21 00:44:11 -08:00
|
|
|
# endif
|
|
|
|
#endif
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
}
|
|
|
|
else if (n->ns.type == EVAS_NATIVE_SURFACE_OPENGL)
|
|
|
|
{
|
|
|
|
glsym_glBindTexture(GL_TEXTURE_2D, 0);
|
|
|
|
GLERR(__FUNCTION__, __FILE__, __LINE__, "");
|
|
|
|
}
|
2011-04-08 21:13:21 -07:00
|
|
|
return;
|
|
|
|
data = NULL;
|
2010-01-21 00:44:11 -08:00
|
|
|
}
|
|
|
|
|
2006-12-17 07:48:52 -08:00
|
|
|
static void
|
2010-01-21 00:44:11 -08:00
|
|
|
_native_free_cb(void *data, void *image)
|
2006-12-17 07:48:52 -08:00
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
Render_Engine *re = data;
|
|
|
|
Evas_GL_Image *im = image;
|
|
|
|
Native *n = im->native.data;
|
|
|
|
uint32_t pmid, texid;
|
2010-12-05 23:09:51 -08:00
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
if (n->ns.type == EVAS_NATIVE_SURFACE_X11)
|
|
|
|
{
|
|
|
|
pmid = n->pixmap;
|
|
|
|
eina_hash_del(re->win->gl_context->shared->native_pm_hash, &pmid, im);
|
2010-01-21 00:44:11 -08:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
if (n->egl_surface)
|
|
|
|
{
|
|
|
|
if (glsym_eglDestroyImage)
|
|
|
|
{
|
|
|
|
glsym_eglDestroyImage(re->win->egl_disp,
|
|
|
|
n->egl_surface);
|
|
|
|
if (glsym_eglGetError() != EGL_SUCCESS)
|
|
|
|
ERR("glsym_eglDestroyImage() failed.");
|
|
|
|
}
|
|
|
|
else
|
|
|
|
ERR("Try glsym_eglDestroyImage on EGL with no support");
|
|
|
|
}
|
2010-01-21 00:44:11 -08:00
|
|
|
#else
|
|
|
|
# ifdef GLX_BIND_TO_TEXTURE_TARGETS_EXT
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
if (n->glx_pixmap)
|
|
|
|
{
|
|
|
|
if (im->native.loose)
|
|
|
|
{
|
|
|
|
if (glsym_glXReleaseTexImage)
|
|
|
|
{
|
|
|
|
glsym_glXReleaseTexImage(re->win->disp, n->glx_pixmap,
|
|
|
|
GLX_FRONT_LEFT_EXT);
|
|
|
|
GLERR(__FUNCTION__, __FILE__, __LINE__, "");
|
|
|
|
}
|
|
|
|
else
|
|
|
|
ERR("Try glXReleaseTexImage on GLX with no support");
|
|
|
|
}
|
|
|
|
if (glsym_glXDestroyPixmap)
|
|
|
|
{
|
|
|
|
glsym_glXDestroyPixmap(re->win->disp, n->glx_pixmap);
|
2010-02-16 20:21:59 -08:00
|
|
|
GLERR(__FUNCTION__, __FILE__, __LINE__, "");
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
}
|
|
|
|
else
|
|
|
|
ERR("Try glXDestroyPixmap on GLX with no support");
|
|
|
|
n->glx_pixmap = 0;
|
|
|
|
}
|
2010-01-21 00:44:11 -08:00
|
|
|
# endif
|
|
|
|
#endif
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
}
|
|
|
|
else if (n->ns.type == EVAS_NATIVE_SURFACE_OPENGL)
|
|
|
|
{
|
|
|
|
texid = n->ns.data.opengl.texture_id;
|
|
|
|
eina_hash_del(re->win->gl_context->shared->native_tex_hash, &texid, im);
|
|
|
|
}
|
|
|
|
im->native.data = NULL;
|
|
|
|
im->native.func.data = NULL;
|
|
|
|
im->native.func.bind = NULL;
|
|
|
|
im->native.func.unbind = NULL;
|
|
|
|
im->native.func.free = NULL;
|
|
|
|
free(n);
|
2010-01-21 00:44:11 -08:00
|
|
|
}
|
|
|
|
|
2010-08-02 23:09:53 -07:00
|
|
|
static void *
|
2010-01-21 00:44:11 -08:00
|
|
|
eng_image_native_set(void *data, void *image, void *native)
|
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
Render_Engine *re = (Render_Engine *)data;
|
|
|
|
Evas_Native_Surface *ns = native;
|
|
|
|
Evas_GL_Image *im = image, *im2 = NULL;
|
|
|
|
Visual *vis = NULL;
|
|
|
|
Pixmap pm = 0;
|
|
|
|
Native *n = NULL;
|
|
|
|
uint32_t pmid, texid;
|
|
|
|
unsigned int tex = 0;
|
|
|
|
unsigned int fbo = 0;
|
|
|
|
|
|
|
|
if (!im)
|
|
|
|
{
|
|
|
|
if ((!ns) && (ns->type == EVAS_NATIVE_SURFACE_OPENGL))
|
|
|
|
{
|
|
|
|
im = evas_gl_common_image_new_from_data(re->win->gl_context,
|
|
|
|
ns->data.opengl.w,
|
|
|
|
ns->data.opengl.h,
|
|
|
|
NULL, 1,
|
|
|
|
EVAS_COLORSPACE_ARGB8888);
|
|
|
|
}
|
|
|
|
else
|
2011-04-04 03:23:12 -07:00
|
|
|
return NULL;
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
}
|
2011-06-17 00:47:28 -07:00
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
if (ns)
|
|
|
|
{
|
|
|
|
if (ns->type == EVAS_NATIVE_SURFACE_X11)
|
|
|
|
{
|
|
|
|
vis = ns->data.x11.visual;
|
|
|
|
pm = ns->data.x11.pixmap;
|
|
|
|
if (im->native.data)
|
|
|
|
{
|
|
|
|
Evas_Native_Surface *ens = im->native.data;
|
|
|
|
if ((ens->data.x11.visual == vis) &&
|
|
|
|
(ens->data.x11.pixmap == pm))
|
|
|
|
return im;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else if (ns->type == EVAS_NATIVE_SURFACE_OPENGL)
|
|
|
|
{
|
|
|
|
tex = ns->data.opengl.texture_id;
|
|
|
|
fbo = ns->data.opengl.framebuffer_id;
|
|
|
|
if (im->native.data)
|
|
|
|
{
|
|
|
|
Evas_Native_Surface *ens = im->native.data;
|
|
|
|
if ((ens->data.opengl.texture_id == tex) &&
|
|
|
|
(ens->data.opengl.framebuffer_id == fbo))
|
|
|
|
return im;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if ((!ns) && (!im->native.data)) return im;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
eng_window_use(re->win);
|
2011-06-17 00:47:28 -07:00
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
if (im->native.data)
|
|
|
|
{
|
|
|
|
if (im->native.func.free)
|
|
|
|
im->native.func.free(im->native.func.data, im);
|
|
|
|
evas_gl_common_image_native_disable(im);
|
|
|
|
}
|
2011-06-17 00:47:28 -07:00
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
if (!ns) return im;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
if (ns->type == EVAS_NATIVE_SURFACE_X11)
|
|
|
|
{
|
|
|
|
pmid = pm;
|
|
|
|
im2 = eina_hash_find(re->win->gl_context->shared->native_pm_hash, &pmid);
|
|
|
|
if (im2 == im) return im;
|
|
|
|
if (im2)
|
|
|
|
{
|
|
|
|
n = im2->native.data;
|
|
|
|
if (n)
|
|
|
|
{
|
|
|
|
evas_gl_common_image_ref(im2);
|
|
|
|
evas_gl_common_image_free(im);
|
|
|
|
return im2;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else if (ns->type == EVAS_NATIVE_SURFACE_OPENGL)
|
|
|
|
{
|
|
|
|
texid = tex;
|
|
|
|
im2 = eina_hash_find(re->win->gl_context->shared->native_tex_hash, &texid);
|
|
|
|
if (im2 == im) return im;
|
|
|
|
if (im2)
|
|
|
|
{
|
|
|
|
n = im2->native.data;
|
|
|
|
if (n)
|
|
|
|
{
|
|
|
|
evas_gl_common_image_ref(im2);
|
|
|
|
evas_gl_common_image_free(im);
|
|
|
|
return im2;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
im2 = evas_gl_common_image_new_from_data(re->win->gl_context,
|
|
|
|
im->w, im->h, NULL, im->alpha,
|
|
|
|
EVAS_COLORSPACE_ARGB8888);
|
|
|
|
evas_gl_common_image_free(im);
|
|
|
|
im = im2;
|
|
|
|
if (ns->type == EVAS_NATIVE_SURFACE_X11)
|
|
|
|
{
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
|
|
|
if (native)
|
|
|
|
{
|
|
|
|
n = calloc(1, sizeof(Native));
|
|
|
|
if (n)
|
|
|
|
{
|
|
|
|
EGLConfig egl_config;
|
|
|
|
int config_attrs[20];
|
|
|
|
int num_config, i = 0;
|
|
|
|
|
|
|
|
eina_hash_add(re->win->gl_context->shared->native_pm_hash, &pmid, im);
|
|
|
|
|
|
|
|
config_attrs[i++] = EGL_RED_SIZE;
|
|
|
|
config_attrs[i++] = 8;
|
|
|
|
config_attrs[i++] = EGL_GREEN_SIZE;
|
|
|
|
config_attrs[i++] = 8;
|
|
|
|
config_attrs[i++] = EGL_BLUE_SIZE;
|
|
|
|
config_attrs[i++] = 8;
|
|
|
|
config_attrs[i++] = EGL_ALPHA_SIZE;
|
|
|
|
config_attrs[i++] = 8;
|
|
|
|
config_attrs[i++] = EGL_DEPTH_SIZE;
|
|
|
|
config_attrs[i++] = 0;
|
|
|
|
config_attrs[i++] = EGL_STENCIL_SIZE;
|
|
|
|
config_attrs[i++] = 0;
|
|
|
|
config_attrs[i++] = EGL_RENDERABLE_TYPE;
|
|
|
|
config_attrs[i++] = EGL_OPENGL_ES2_BIT;
|
|
|
|
config_attrs[i++] = EGL_SURFACE_TYPE;
|
|
|
|
config_attrs[i++] = EGL_PIXMAP_BIT;
|
|
|
|
config_attrs[i++] = EGL_NONE;
|
|
|
|
|
|
|
|
if (!glsym_eglChooseConfig(re->win->egl_disp, config_attrs,
|
|
|
|
&egl_config, 1, &num_config))
|
|
|
|
ERR("glsym_eglChooseConfig() failed for pixmap 0x%x, num_config = %i", (unsigned int)pm, num_config);
|
|
|
|
memcpy(&(n->ns), ns, sizeof(Evas_Native_Surface));
|
|
|
|
n->pixmap = pm;
|
|
|
|
n->visual = vis;
|
|
|
|
if (glsym_eglCreateImage)
|
|
|
|
n->egl_surface = glsym_eglCreateImage(re->win->egl_disp,
|
|
|
|
EGL_NO_CONTEXT,
|
|
|
|
EGL_NATIVE_PIXMAP_KHR,
|
|
|
|
(void *)pm,
|
|
|
|
NULL);
|
|
|
|
else
|
|
|
|
ERR("Try glsym_eglCreateImage on EGL with no support");
|
|
|
|
if (!n->egl_surface)
|
|
|
|
ERR("glsym_eglCreatePixmapSurface() for 0x%x failed", (unsigned int)pm);
|
|
|
|
im->native.yinvert = 1;
|
|
|
|
im->native.loose = 0;
|
|
|
|
im->native.data = n;
|
|
|
|
im->native.func.data = re;
|
|
|
|
im->native.func.bind = _native_bind_cb;
|
|
|
|
im->native.func.unbind = _native_unbind_cb;
|
|
|
|
im->native.func.free = _native_free_cb;
|
|
|
|
im->native.target = GL_TEXTURE_2D;
|
|
|
|
im->native.mipmap = 0;
|
|
|
|
evas_gl_common_image_native_enable(im);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
# ifdef GLX_BIND_TO_TEXTURE_TARGETS_EXT
|
|
|
|
if (native)
|
|
|
|
{
|
|
|
|
int dummy;
|
|
|
|
unsigned int w, h, depth = 32, border;
|
|
|
|
Window wdummy;
|
|
|
|
|
|
|
|
// fixme: round trip :(
|
|
|
|
XGetGeometry(re->win->disp, pm, &wdummy, &dummy, &dummy,
|
|
|
|
&w, &h, &border, &depth);
|
|
|
|
n = calloc(1, sizeof(Native));
|
|
|
|
if (n)
|
|
|
|
{
|
|
|
|
int pixmap_att[20];
|
|
|
|
unsigned int target = 0;
|
|
|
|
unsigned int i = 0;
|
|
|
|
|
|
|
|
eina_hash_add(re->win->gl_context->shared->native_pm_hash, &pmid, im);
|
|
|
|
if ((re->win->depth_cfg[depth].tex_target &
|
|
|
|
GLX_TEXTURE_2D_BIT_EXT)
|
|
|
|
// && (1) // we assume npo2 for now
|
|
|
|
// size is pow2 || mnpo2 supported
|
|
|
|
)
|
|
|
|
target = GLX_TEXTURE_2D_EXT;
|
|
|
|
else if ((re->win->depth_cfg[depth].tex_target &
|
|
|
|
GLX_TEXTURE_RECTANGLE_BIT_EXT))
|
2010-02-14 07:12:39 -08:00
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ERR("rect!!! (not handled)");
|
|
|
|
target = GLX_TEXTURE_RECTANGLE_EXT;
|
2010-02-14 07:12:39 -08:00
|
|
|
}
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
if (!target)
|
2010-02-14 07:12:39 -08:00
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ERR("broken text-from-pixmap");
|
|
|
|
if (!(re->win->depth_cfg[depth].tex_target &
|
|
|
|
GLX_TEXTURE_2D_BIT_EXT))
|
|
|
|
target = GLX_TEXTURE_RECTANGLE_EXT;
|
|
|
|
else if (!(re->win->depth_cfg[depth].tex_target &
|
|
|
|
GLX_TEXTURE_RECTANGLE_BIT_EXT))
|
|
|
|
target = GLX_TEXTURE_2D_EXT;
|
2010-02-14 07:12:39 -08:00
|
|
|
}
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
|
|
|
|
|
|
|
|
pixmap_att[i++] = GLX_TEXTURE_FORMAT_EXT;
|
|
|
|
pixmap_att[i++] = re->win->depth_cfg[depth].tex_format;
|
|
|
|
pixmap_att[i++] = GLX_MIPMAP_TEXTURE_EXT;
|
|
|
|
pixmap_att[i++] = re->win->depth_cfg[depth].mipmap;
|
|
|
|
|
|
|
|
if (target)
|
2010-02-14 07:12:39 -08:00
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
pixmap_att[i++] = GLX_TEXTURE_TARGET_EXT;
|
|
|
|
pixmap_att[i++] = target;
|
2010-02-14 07:12:39 -08:00
|
|
|
}
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
|
|
|
|
pixmap_att[i++] = 0;
|
|
|
|
|
|
|
|
memcpy(&(n->ns), ns, sizeof(Evas_Native_Surface));
|
|
|
|
n->pixmap = pm;
|
|
|
|
n->visual = vis;
|
|
|
|
n->fbc = re->win->depth_cfg[depth].fbc;
|
|
|
|
if (glsym_glXCreatePixmap)
|
|
|
|
n->glx_pixmap = glsym_glXCreatePixmap(re->win->disp,
|
|
|
|
n->fbc,
|
|
|
|
n->pixmap,
|
|
|
|
pixmap_att);
|
2010-02-14 07:12:39 -08:00
|
|
|
else
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ERR("Try glXCreatePixmap on GLX with no support");
|
|
|
|
if (n->glx_pixmap)
|
2010-02-14 07:12:39 -08:00
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// printf("%p: new native texture for %x | %4i x %4i @ %2i = %p\n",
|
|
|
|
// n, pm, w, h, depth, n->glx_pixmap);
|
|
|
|
if (!target)
|
|
|
|
{
|
|
|
|
ERR("no target :(");
|
|
|
|
if (glsym_glXQueryDrawable)
|
|
|
|
glsym_glXQueryDrawable(re->win->disp,
|
|
|
|
n->pixmap,
|
|
|
|
GLX_TEXTURE_TARGET_EXT,
|
|
|
|
&target);
|
|
|
|
}
|
|
|
|
if (target == GLX_TEXTURE_2D_EXT)
|
|
|
|
{
|
|
|
|
im->native.target = GL_TEXTURE_2D;
|
|
|
|
im->native.mipmap = re->win->depth_cfg[depth].mipmap;
|
|
|
|
}
|
|
|
|
# ifdef GL_TEXTURE_RECTANGLE_ARB
|
|
|
|
else if (target == GLX_TEXTURE_RECTANGLE_EXT)
|
|
|
|
{
|
|
|
|
im->native.target = GL_TEXTURE_RECTANGLE_ARB;
|
|
|
|
im->native.mipmap = 0;
|
|
|
|
}
|
|
|
|
# endif
|
|
|
|
else
|
|
|
|
{
|
|
|
|
im->native.target = GL_TEXTURE_2D;
|
|
|
|
im->native.mipmap = 0;
|
|
|
|
ERR("still unknown target");
|
|
|
|
}
|
2010-02-14 07:12:39 -08:00
|
|
|
}
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
else
|
|
|
|
ERR("GLX Pixmap create fail");
|
|
|
|
im->native.yinvert = re->win->depth_cfg[depth].yinvert;
|
|
|
|
im->native.loose = re->win->detected.loose_binding;
|
|
|
|
im->native.data = n;
|
|
|
|
im->native.func.data = re;
|
|
|
|
im->native.func.bind = _native_bind_cb;
|
|
|
|
im->native.func.unbind = _native_unbind_cb;
|
|
|
|
im->native.func.free = _native_free_cb;
|
|
|
|
|
|
|
|
evas_gl_common_image_native_enable(im);
|
|
|
|
}
|
|
|
|
}
|
2011-06-17 00:47:28 -07:00
|
|
|
# endif
|
2010-01-21 00:44:11 -08:00
|
|
|
#endif
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
}
|
|
|
|
else if (ns->type == EVAS_NATIVE_SURFACE_OPENGL)
|
|
|
|
{
|
|
|
|
if (native)
|
|
|
|
{
|
|
|
|
n = calloc(1, sizeof(Native));
|
|
|
|
if (n)
|
|
|
|
{
|
|
|
|
memcpy(&(n->ns), ns, sizeof(Evas_Native_Surface));
|
|
|
|
|
|
|
|
eina_hash_add(re->win->gl_context->shared->native_tex_hash, &texid, im);
|
|
|
|
|
|
|
|
n->pixmap = 0;
|
|
|
|
n->visual = 0;
|
2011-04-04 03:23:12 -07:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
n->egl_surface = 0;
|
2011-04-04 03:23:12 -07:00
|
|
|
#else
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
n->fbc = 0;
|
|
|
|
n->glx_pixmap = 0;
|
2011-04-04 03:23:12 -07:00
|
|
|
#endif
|
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
im->native.yinvert = 0;
|
|
|
|
im->native.loose = 0;
|
|
|
|
im->native.data = n;
|
|
|
|
im->native.func.data = re;
|
|
|
|
im->native.func.bind = _native_bind_cb;
|
|
|
|
im->native.func.unbind = _native_unbind_cb;
|
|
|
|
im->native.func.free = _native_free_cb;
|
|
|
|
im->native.target = GL_TEXTURE_2D;
|
|
|
|
im->native.mipmap = 0;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// FIXME: need to implement mapping sub texture regions
|
|
|
|
// x, y, w, h for possible texture atlasing
|
2011-04-04 03:23:12 -07:00
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
evas_gl_common_image_native_enable(im);
|
|
|
|
}
|
|
|
|
}
|
2011-04-04 03:23:12 -07:00
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
}
|
2010-08-02 23:09:53 -07:00
|
|
|
return im;
|
2006-12-17 07:48:52 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void *
|
cleanup: fix some "unused" errors from -Wextra.
As we're heading for a release we better remove as much errors as
possible and as the first step I'm removing warnings due unused
parameters, variables and functions. These tend to pollute real errors
spotted by -Wall and clang/llvm.
This does not fixes all, just the clear that could be set to
__UNUSED__, particularly to do (and I'd like some help from the
authors):
* src/lib/engines/common/evas_font_{draw,query}.c (tasn):
intl_props is just used while doing BIDI, but also used in other
#ifdef blocks :-/
* evas_map_* (raster):
huge amount of warnings, code is quite confusing and thus I'm not
touching it. I have no idea whenever the commented blocks or extra
parameters are intended to be used or no.
* src/modules/engines/fbevas_fb_main.c (raster?):
is fb_setvt() to be used? If not do you mind removing it?
* src/modules/engines/gl_{common,x11} (raster):
huge amount of warnings, code is quite nested and full of #ifdefs
that does not help to give a clear picture of what's going on.
* src/bin/evas_cserve_main.c (raster):
I could have ignored most of the errors, but is the code correct? I
mean, there is no unload of images being applied. If you confirm
none of those warnings are harmful I can flag them as unused.
* src/lib/engines/common_8 (dottedmag):
lots of unused functions that were acquired from common_16, they
are unused and if they will not, then they should be removed.
SVN revision: 52421
2010-09-18 12:17:41 -07:00
|
|
|
eng_image_native_get(void *data __UNUSED__, void *image)
|
2006-12-17 07:48:52 -08:00
|
|
|
{
|
2010-01-21 00:44:11 -08:00
|
|
|
Evas_GL_Image *im = image;
|
|
|
|
Native *n;
|
|
|
|
if (!im) return NULL;
|
|
|
|
n = im->native.data;
|
|
|
|
if (!n) return NULL;
|
|
|
|
return &(n->ns);
|
2006-12-17 07:48:52 -08:00
|
|
|
}
|
|
|
|
|
2011-06-02 03:40:43 -07:00
|
|
|
#if 0 // filtering disabled
|
2011-04-18 22:47:56 -07:00
|
|
|
static void
|
|
|
|
eng_image_draw_filtered(void *data, void *context, void *surface,
|
2011-04-20 01:05:23 -07:00
|
|
|
void *image, Evas_Filter_Info *filter)
|
2011-04-18 22:47:56 -07:00
|
|
|
{
|
|
|
|
Render_Engine *re = data;
|
|
|
|
|
|
|
|
if (!image) return;
|
|
|
|
eng_window_use(re->win);
|
|
|
|
evas_gl_common_context_target_surface_set(re->win->gl_context, surface);
|
|
|
|
re->win->gl_context->dc = context;
|
|
|
|
|
2011-04-20 01:05:23 -07:00
|
|
|
evas_gl_common_filter_draw(re->win->gl_context, image, filter);
|
2011-04-18 22:47:56 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static Filtered_Image *
|
|
|
|
eng_image_filtered_get(void *im, uint8_t *key, size_t keylen)
|
|
|
|
{
|
|
|
|
return evas_gl_common_image_filtered_get(im, key, keylen);
|
|
|
|
}
|
|
|
|
|
|
|
|
static Filtered_Image *
|
|
|
|
eng_image_filtered_save(void *im, void *fim, uint8_t *key, size_t keylen)
|
|
|
|
{
|
|
|
|
return evas_gl_common_image_filtered_save(im, fim, key, keylen);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
eng_image_filtered_free(void *im, Filtered_Image *fim)
|
|
|
|
{
|
|
|
|
evas_gl_common_image_filtered_free(im, fim);
|
|
|
|
}
|
2011-06-02 03:40:43 -07:00
|
|
|
#endif
|
2011-04-18 22:47:56 -07:00
|
|
|
|
|
|
|
|
2010-01-21 00:44:11 -08:00
|
|
|
//
|
|
|
|
//
|
|
|
|
/////////////////////////////////////////////////////////////////////////
|
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
static void *
|
2007-03-04 08:19:32 -08:00
|
|
|
eng_image_load(void *data, const char *file, const char *key, int *error, Evas_Image_Load_Opts *lo)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
|
|
|
|
|
|
|
re = (Render_Engine *)data;
|
2009-12-22 15:11:57 -08:00
|
|
|
*error = EVAS_LOAD_ERROR_NONE;
|
2006-03-06 18:44:16 -08:00
|
|
|
eng_window_use(re->win);
|
2009-12-22 15:11:57 -08:00
|
|
|
return evas_gl_common_image_load(re->win->gl_context, file, key, lo, error);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void *
|
2006-12-17 07:48:52 -08:00
|
|
|
eng_image_new_from_data(void *data, int w, int h, DATA32 *image_data, int alpha, int cspace)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2006-03-06 18:44:16 -08:00
|
|
|
eng_window_use(re->win);
|
2006-12-17 07:48:52 -08:00
|
|
|
return evas_gl_common_image_new_from_data(re->win->gl_context, w, h, image_data, alpha, cspace);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void *
|
2006-12-17 07:48:52 -08:00
|
|
|
eng_image_new_from_copied_data(void *data, int w, int h, DATA32 *image_data, int alpha, int cspace)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2006-03-06 18:44:16 -08:00
|
|
|
eng_window_use(re->win);
|
2006-12-17 07:48:52 -08:00
|
|
|
return evas_gl_common_image_new_from_copied_data(re->win->gl_context, w, h, image_data, alpha, cspace);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2006-02-27 20:07:49 -08:00
|
|
|
eng_image_free(void *data, void *image)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
|
|
|
|
|
|
|
re = (Render_Engine *)data;
|
2006-12-19 06:12:40 -08:00
|
|
|
if (!image) return;
|
2006-03-06 18:44:16 -08:00
|
|
|
eng_window_use(re->win);
|
2003-09-04 00:40:34 -07:00
|
|
|
evas_gl_common_image_free(image);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
cleanup: fix some "unused" errors from -Wextra.
As we're heading for a release we better remove as much errors as
possible and as the first step I'm removing warnings due unused
parameters, variables and functions. These tend to pollute real errors
spotted by -Wall and clang/llvm.
This does not fixes all, just the clear that could be set to
__UNUSED__, particularly to do (and I'd like some help from the
authors):
* src/lib/engines/common/evas_font_{draw,query}.c (tasn):
intl_props is just used while doing BIDI, but also used in other
#ifdef blocks :-/
* evas_map_* (raster):
huge amount of warnings, code is quite confusing and thus I'm not
touching it. I have no idea whenever the commented blocks or extra
parameters are intended to be used or no.
* src/modules/engines/fbevas_fb_main.c (raster?):
is fb_setvt() to be used? If not do you mind removing it?
* src/modules/engines/gl_{common,x11} (raster):
huge amount of warnings, code is quite nested and full of #ifdefs
that does not help to give a clear picture of what's going on.
* src/bin/evas_cserve_main.c (raster):
I could have ignored most of the errors, but is the code correct? I
mean, there is no unload of images being applied. If you confirm
none of those warnings are harmful I can flag them as unused.
* src/lib/engines/common_8 (dottedmag):
lots of unused functions that were acquired from common_16, they
are unused and if they will not, then they should be removed.
SVN revision: 52421
2010-09-18 12:17:41 -07:00
|
|
|
eng_image_size_get(void *data __UNUSED__, void *image, int *w, int *h)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
2006-12-19 06:12:40 -08:00
|
|
|
if (!image)
|
|
|
|
{
|
2011-11-10 00:59:09 -08:00
|
|
|
*w = 0;
|
|
|
|
*h = 0;
|
|
|
|
return;
|
2006-12-19 06:12:40 -08:00
|
|
|
}
|
2010-01-21 01:42:26 -08:00
|
|
|
if (w) *w = ((Evas_GL_Image *)image)->w;
|
|
|
|
if (h) *h = ((Evas_GL_Image *)image)->h;
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void *
|
2006-02-27 20:07:49 -08:00
|
|
|
eng_image_size_set(void *data, void *image, int w, int h)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2010-01-21 01:42:26 -08:00
|
|
|
Evas_GL_Image *im = image;
|
|
|
|
Evas_GL_Image *im_old;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2010-01-21 01:42:26 -08:00
|
|
|
if (!im) return NULL;
|
|
|
|
if (im->native.data)
|
|
|
|
{
|
|
|
|
im->w = w;
|
|
|
|
im->h = h;
|
|
|
|
return image;
|
|
|
|
}
|
2006-12-19 06:12:40 -08:00
|
|
|
eng_window_use(re->win);
|
2010-08-18 20:30:47 -07:00
|
|
|
if ((im->tex) && (im->tex->pt->dyn.img))
|
|
|
|
{
|
|
|
|
evas_gl_common_texture_free(im->tex);
|
|
|
|
im->tex = NULL;
|
2010-10-07 22:11:32 -07:00
|
|
|
im->w = w;
|
|
|
|
im->h = h;
|
2010-08-18 20:30:47 -07:00
|
|
|
im->tex = evas_gl_common_texture_dynamic_new(im->gc, im);
|
|
|
|
return image;
|
|
|
|
}
|
2003-09-04 00:40:34 -07:00
|
|
|
im_old = image;
|
2011-08-29 13:56:48 -07:00
|
|
|
|
|
|
|
switch (eng_image_colorspace_get(data, image))
|
|
|
|
{
|
|
|
|
case EVAS_COLORSPACE_YCBCR422P601_PL:
|
|
|
|
case EVAS_COLORSPACE_YCBCR422P709_PL:
|
|
|
|
case EVAS_COLORSPACE_YCBCR422601_PL:
|
|
|
|
case EVAS_COLORSPACE_YCBCR420NV12601_PL:
|
|
|
|
case EVAS_COLORSPACE_YCBCR420TM12601_PL:
|
|
|
|
w &= ~0x1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2010-09-18 16:16:25 -07:00
|
|
|
if ((im_old) &&
|
|
|
|
((int)im_old->im->cache_entry.w == w) &&
|
|
|
|
((int)im_old->im->cache_entry.h == h))
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
return image;
|
2003-09-04 00:40:34 -07:00
|
|
|
if (im_old)
|
|
|
|
{
|
2011-11-10 00:59:09 -08:00
|
|
|
im = evas_gl_common_image_new(re->win->gl_context, w, h,
|
|
|
|
eng_image_alpha_get(data, image),
|
|
|
|
eng_image_colorspace_get(data, image));
|
|
|
|
/*
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
evas_common_load_image_data_from_file(im_old->im);
|
|
|
|
if (im_old->im->image->data)
|
|
|
|
{
|
|
|
|
evas_common_blit_rectangle(im_old->im, im->im, 0, 0, w, h, 0, 0);
|
|
|
|
evas_common_cpu_end_opt();
|
|
|
|
}
|
|
|
|
*/
|
2009-10-09 05:10:27 -07:00
|
|
|
evas_gl_common_image_free(im_old);
|
2003-09-04 00:40:34 -07:00
|
|
|
}
|
2006-12-17 07:48:52 -08:00
|
|
|
else
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
im = evas_gl_common_image_new(re->win->gl_context, w, h, 1, EVAS_COLORSPACE_ARGB8888);
|
2003-09-04 00:40:34 -07:00
|
|
|
return im;
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void *
|
2009-12-19 22:23:13 -08:00
|
|
|
eng_image_dirty_region(void *data, void *image, int x, int y, int w, int h)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2010-01-21 01:42:26 -08:00
|
|
|
Evas_GL_Image *im = image;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2006-12-19 06:12:40 -08:00
|
|
|
if (!image) return NULL;
|
2010-01-21 01:42:26 -08:00
|
|
|
if (im->native.data) return image;
|
2010-01-21 04:43:53 -08:00
|
|
|
eng_window_use(re->win);
|
2009-12-19 22:23:13 -08:00
|
|
|
evas_gl_common_image_dirty(image, x, y, w, h);
|
2003-09-04 00:40:34 -07:00
|
|
|
return image;
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void *
|
2011-05-19 04:19:22 -07:00
|
|
|
eng_image_data_get(void *data, void *image, int to_write, DATA32 **image_data, int *err)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2003-09-04 00:40:34 -07:00
|
|
|
Evas_GL_Image *im;
|
2011-05-19 04:19:22 -07:00
|
|
|
int error;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2006-12-19 06:12:40 -08:00
|
|
|
if (!image)
|
|
|
|
{
|
2011-11-10 00:59:09 -08:00
|
|
|
*image_data = NULL;
|
2011-05-19 04:19:22 -07:00
|
|
|
if (err) *err = EVAS_LOAD_ERROR_GENERIC;
|
2011-11-10 00:59:09 -08:00
|
|
|
return NULL;
|
2006-12-19 06:12:40 -08:00
|
|
|
}
|
2003-09-04 00:40:34 -07:00
|
|
|
im = image;
|
2010-01-21 01:42:26 -08:00
|
|
|
if (im->native.data)
|
|
|
|
{
|
|
|
|
*image_data = NULL;
|
2011-05-19 04:19:22 -07:00
|
|
|
if (err) *err = EVAS_LOAD_ERROR_NONE;
|
2010-01-21 01:42:26 -08:00
|
|
|
return im;
|
|
|
|
}
|
2011-08-16 00:06:36 -07:00
|
|
|
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
|
|
|
eng_window_use(re->win);
|
|
|
|
|
2011-09-30 08:43:51 -07:00
|
|
|
if ((im->tex) && (im->tex->pt) && (im->tex->pt->dyn.img) && (im->cs.space == EVAS_COLORSPACE_ARGB8888))
|
2011-08-16 00:06:36 -07:00
|
|
|
{
|
2011-11-10 23:47:25 -08:00
|
|
|
if (im->tex->pt->dyn.checked_out > 0)
|
|
|
|
{
|
|
|
|
im->tex->pt->dyn.checked_out++;
|
|
|
|
*image_data = im->tex->pt->dyn.data;
|
|
|
|
if (err) *err = EVAS_LOAD_ERROR_NONE;
|
|
|
|
return im;
|
|
|
|
}
|
2011-08-16 00:06:36 -07:00
|
|
|
*image_data = im->tex->pt->dyn.data = glsym_eglMapImageSEC(re->win->egl_disp, im->tex->pt->dyn.img);
|
|
|
|
|
|
|
|
if (!im->tex->pt->dyn.data)
|
|
|
|
{
|
2011-11-14 01:27:29 -08:00
|
|
|
if (err) *err = EVAS_LOAD_ERROR_RESOURCE_ALLOCATION_FAILED;
|
2011-08-16 00:06:36 -07:00
|
|
|
GLERR(__FUNCTION__, __FILE__, __LINE__, "");
|
2011-11-14 01:27:29 -08:00
|
|
|
return im;
|
2011-08-16 00:06:36 -07:00
|
|
|
}
|
2011-11-10 23:47:25 -08:00
|
|
|
im->tex->pt->dyn.checked_out++;
|
2011-08-16 00:06:36 -07:00
|
|
|
|
|
|
|
if (err) *err = EVAS_LOAD_ERROR_NONE;
|
|
|
|
return im;
|
|
|
|
}
|
|
|
|
#else
|
2010-08-13 03:39:41 -07:00
|
|
|
if ((im->tex) && (im->tex->pt) && (im->tex->pt->dyn.data))
|
2010-08-13 03:34:51 -07:00
|
|
|
{
|
|
|
|
*image_data = im->tex->pt->dyn.data;
|
2011-05-19 04:19:22 -07:00
|
|
|
if (err) *err = EVAS_LOAD_ERROR_NONE;
|
2010-08-13 03:34:51 -07:00
|
|
|
return im;
|
|
|
|
}
|
2011-08-16 00:06:36 -07:00
|
|
|
|
2006-03-06 18:44:16 -08:00
|
|
|
eng_window_use(re->win);
|
2011-08-16 00:06:36 -07:00
|
|
|
#endif
|
|
|
|
|
From: Jiyoun Park <jy0703.park@samsung.com>
Subject: [E-devel] [Patch] evas gl engine's texture creation
Hello.
1. _pool_tex_dynamic_new function, it didnt set pt to NULL when secsym_eglCreateImage function failed.
In this case, it returns wrong pt pointer and it has possibility to make crash.
So I add free pt code and return NULL code into _pool_tex_dynamic_new function.
2. I modified eng_image_data_get of gl engine.
If Evas_GL_Image's texture creation failed and evas_gl_image's cache image was droped,
Im->im can be NULL. So I add check code.
Example: evas_gl_common_image_content_hint_set
1) EVAS_IMAGE_CONTENT_HINT_DYNAMIC , it drop cache image
2) if evas_gl_common_texture_dynamic_new failed
3) then, im->im =NULL, im->tex=NULL
In this situation, if application call's evas_object_image_data_get function,
It make crash in evas_cache_image_load_data function.
3. I think function's related with evas_object's engine data have to be return NULL if it failed.
If function's returns null, evas object code can handle error more easily.
But evas object's code was implemented differently each case. Does my suggestion right?
I add engine data null check code to evas_object_image based on upper consumtion.
If it is wrong , the patch code related with evas object image have to be removed.
If it is right , I will survey other evas object type also.
SVN revision: 62775
2011-08-24 21:48:45 -07:00
|
|
|
/* Engine can be fail to create texture after cache drop like eng_image_content_hint_set function,
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
so it is need to add code which check im->im's NULL value*/
|
From: Jiyoun Park <jy0703.park@samsung.com>
Subject: [E-devel] [Patch] evas gl engine's texture creation
Hello.
1. _pool_tex_dynamic_new function, it didnt set pt to NULL when secsym_eglCreateImage function failed.
In this case, it returns wrong pt pointer and it has possibility to make crash.
So I add free pt code and return NULL code into _pool_tex_dynamic_new function.
2. I modified eng_image_data_get of gl engine.
If Evas_GL_Image's texture creation failed and evas_gl_image's cache image was droped,
Im->im can be NULL. So I add check code.
Example: evas_gl_common_image_content_hint_set
1) EVAS_IMAGE_CONTENT_HINT_DYNAMIC , it drop cache image
2) if evas_gl_common_texture_dynamic_new failed
3) then, im->im =NULL, im->tex=NULL
In this situation, if application call's evas_object_image_data_get function,
It make crash in evas_cache_image_load_data function.
3. I think function's related with evas_object's engine data have to be return NULL if it failed.
If function's returns null, evas object code can handle error more easily.
But evas object's code was implemented differently each case. Does my suggestion right?
I add engine data null check code to evas_object_image based on upper consumtion.
If it is wrong , the patch code related with evas object image have to be removed.
If it is right , I will survey other evas object type also.
SVN revision: 62775
2011-08-24 21:48:45 -07:00
|
|
|
|
|
|
|
if (!im->im)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
{
|
|
|
|
*image_data = NULL;
|
|
|
|
if (err) *err = EVAS_LOAD_ERROR_RESOURCE_ALLOCATION_FAILED;
|
|
|
|
return NULL;
|
|
|
|
}
|
From: Jiyoun Park <jy0703.park@samsung.com>
Subject: [E-devel] [Patch] evas gl engine's texture creation
Hello.
1. _pool_tex_dynamic_new function, it didnt set pt to NULL when secsym_eglCreateImage function failed.
In this case, it returns wrong pt pointer and it has possibility to make crash.
So I add free pt code and return NULL code into _pool_tex_dynamic_new function.
2. I modified eng_image_data_get of gl engine.
If Evas_GL_Image's texture creation failed and evas_gl_image's cache image was droped,
Im->im can be NULL. So I add check code.
Example: evas_gl_common_image_content_hint_set
1) EVAS_IMAGE_CONTENT_HINT_DYNAMIC , it drop cache image
2) if evas_gl_common_texture_dynamic_new failed
3) then, im->im =NULL, im->tex=NULL
In this situation, if application call's evas_object_image_data_get function,
It make crash in evas_cache_image_load_data function.
3. I think function's related with evas_object's engine data have to be return NULL if it failed.
If function's returns null, evas object code can handle error more easily.
But evas object's code was implemented differently each case. Does my suggestion right?
I add engine data null check code to evas_object_image based on upper consumtion.
If it is wrong , the patch code related with evas object image have to be removed.
If it is right , I will survey other evas object type also.
SVN revision: 62775
2011-08-24 21:48:45 -07:00
|
|
|
|
2011-05-19 04:19:22 -07:00
|
|
|
error = evas_cache_image_load_data(&im->im->cache_entry);
|
2006-12-17 07:48:52 -08:00
|
|
|
switch (im->cs.space)
|
2003-09-04 00:40:34 -07:00
|
|
|
{
|
2006-12-17 07:48:52 -08:00
|
|
|
case EVAS_COLORSPACE_ARGB8888:
|
2011-11-10 00:59:09 -08:00
|
|
|
if (to_write)
|
|
|
|
{
|
|
|
|
if (im->references > 1)
|
|
|
|
{
|
|
|
|
Evas_GL_Image *im_new;
|
|
|
|
|
|
|
|
im_new = evas_gl_common_image_new_from_copied_data
|
|
|
|
(im->gc, im->im->cache_entry.w, im->im->cache_entry.h,
|
|
|
|
im->im->image.data,
|
|
|
|
eng_image_alpha_get(data, image),
|
|
|
|
eng_image_colorspace_get(data, image));
|
|
|
|
if (!im_new)
|
|
|
|
{
|
|
|
|
*image_data = NULL;
|
|
|
|
if (err) *err = EVAS_LOAD_ERROR_RESOURCE_ALLOCATION_FAILED;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
evas_gl_common_image_free(im);
|
|
|
|
im = im_new;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
evas_gl_common_image_dirty(im, 0, 0, 0, 0);
|
|
|
|
}
|
|
|
|
*image_data = im->im->image.data;
|
|
|
|
break;
|
2006-12-17 07:48:52 -08:00
|
|
|
case EVAS_COLORSPACE_YCBCR422P601_PL:
|
|
|
|
case EVAS_COLORSPACE_YCBCR422P709_PL:
|
2011-08-23 08:13:40 -07:00
|
|
|
case EVAS_COLORSPACE_YCBCR422601_PL:
|
2011-08-29 13:56:48 -07:00
|
|
|
case EVAS_COLORSPACE_YCBCR420NV12601_PL:
|
|
|
|
case EVAS_COLORSPACE_YCBCR420TM12601_PL:
|
2011-11-10 00:59:09 -08:00
|
|
|
*image_data = im->cs.data;
|
|
|
|
break;
|
2006-12-17 07:48:52 -08:00
|
|
|
default:
|
2011-11-10 00:59:09 -08:00
|
|
|
abort();
|
|
|
|
break;
|
2003-09-04 00:40:34 -07:00
|
|
|
}
|
2011-05-19 04:19:22 -07:00
|
|
|
if (err) *err = error;
|
2003-09-04 00:40:34 -07:00
|
|
|
return im;
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void *
|
2006-02-27 20:07:49 -08:00
|
|
|
eng_image_data_put(void *data, void *image, DATA32 *image_data)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2006-12-17 08:46:30 -08:00
|
|
|
Evas_GL_Image *im, *im2;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2006-12-19 06:12:40 -08:00
|
|
|
if (!image) return NULL;
|
2003-09-04 00:40:34 -07:00
|
|
|
im = image;
|
2010-01-21 01:42:26 -08:00
|
|
|
if (im->native.data) return image;
|
2006-03-06 18:44:16 -08:00
|
|
|
eng_window_use(re->win);
|
2011-09-30 08:43:51 -07:00
|
|
|
if ((im->tex) && (im->tex->pt)
|
|
|
|
&& (im->tex->pt->dyn.data)
|
|
|
|
&& (im->cs.space == EVAS_COLORSPACE_ARGB8888))
|
2010-08-13 03:34:51 -07:00
|
|
|
{
|
2011-10-19 02:04:18 -07:00
|
|
|
int w, h;
|
|
|
|
|
2011-11-10 23:47:25 -08:00
|
|
|
if (im->tex->pt->dyn.data == image_data)
|
|
|
|
{
|
|
|
|
im->tex->pt->dyn.checked_out--;
|
2011-08-16 00:06:36 -07:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
2011-11-10 23:47:25 -08:00
|
|
|
if (im->tex->pt->dyn.checked_out == 0)
|
|
|
|
glsym_eglUnmapImageSEC(re->win->egl_disp, im->tex->pt->dyn.img);
|
2011-08-16 00:06:36 -07:00
|
|
|
#endif
|
2011-11-10 23:47:25 -08:00
|
|
|
return image;
|
|
|
|
}
|
2011-10-19 02:04:18 -07:00
|
|
|
|
|
|
|
w = im->im->cache_entry.w;
|
|
|
|
h = im->im->cache_entry.h;
|
|
|
|
im2 = eng_image_new_from_data(data, w, h, image_data,
|
|
|
|
eng_image_alpha_get(data, image),
|
|
|
|
eng_image_colorspace_get(data, image));
|
|
|
|
if (!im2) return im;
|
|
|
|
evas_gl_common_image_free(im);
|
|
|
|
im = im2;
|
|
|
|
evas_gl_common_image_dirty(im, 0, 0, 0, 0);
|
|
|
|
return im;
|
2010-08-13 03:34:51 -07:00
|
|
|
}
|
2006-12-17 07:48:52 -08:00
|
|
|
switch (im->cs.space)
|
2003-09-04 00:40:34 -07:00
|
|
|
{
|
2006-12-17 07:48:52 -08:00
|
|
|
case EVAS_COLORSPACE_ARGB8888:
|
2011-11-10 00:59:09 -08:00
|
|
|
if (image_data != im->im->image.data)
|
|
|
|
{
|
|
|
|
int w, h;
|
|
|
|
|
|
|
|
w = im->im->cache_entry.w;
|
|
|
|
h = im->im->cache_entry.h;
|
|
|
|
im2 = eng_image_new_from_data(data, w, h, image_data,
|
|
|
|
eng_image_alpha_get(data, image),
|
|
|
|
eng_image_colorspace_get(data, image));
|
|
|
|
if (!im2) return im;
|
|
|
|
evas_gl_common_image_free(im);
|
|
|
|
im = im2;
|
|
|
|
}
|
|
|
|
break;
|
2006-12-17 07:48:52 -08:00
|
|
|
case EVAS_COLORSPACE_YCBCR422P601_PL:
|
|
|
|
case EVAS_COLORSPACE_YCBCR422P709_PL:
|
2011-08-23 08:13:40 -07:00
|
|
|
case EVAS_COLORSPACE_YCBCR422601_PL:
|
2011-08-29 13:56:48 -07:00
|
|
|
case EVAS_COLORSPACE_YCBCR420NV12601_PL:
|
|
|
|
case EVAS_COLORSPACE_YCBCR420TM12601_PL:
|
2011-11-10 00:59:09 -08:00
|
|
|
if (image_data != im->cs.data)
|
|
|
|
{
|
|
|
|
if (im->cs.data)
|
|
|
|
{
|
|
|
|
if (!im->cs.no_free) free(im->cs.data);
|
|
|
|
}
|
|
|
|
im->cs.data = image_data;
|
|
|
|
}
|
|
|
|
evas_gl_common_image_dirty(im, 0, 0, 0, 0);
|
|
|
|
break;
|
2006-12-17 07:48:52 -08:00
|
|
|
default:
|
2011-11-10 00:59:09 -08:00
|
|
|
abort();
|
|
|
|
break;
|
2003-09-04 00:40:34 -07:00
|
|
|
}
|
|
|
|
return im;
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
2008-09-16 07:52:57 -07:00
|
|
|
static void
|
2009-02-28 02:08:45 -08:00
|
|
|
eng_image_data_preload_request(void *data __UNUSED__, void *image, const void *target)
|
2008-09-16 07:52:57 -07:00
|
|
|
{
|
|
|
|
Evas_GL_Image *gim = image;
|
|
|
|
RGBA_Image *im;
|
|
|
|
|
2010-01-21 01:42:26 -08:00
|
|
|
if (!gim) return;
|
|
|
|
if (gim->native.data) return;
|
|
|
|
im = (RGBA_Image *)gim->im;
|
|
|
|
if (!im) return;
|
2008-09-16 07:52:57 -07:00
|
|
|
evas_cache_image_preload_data(&im->cache_entry, target);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2009-02-28 02:08:45 -08:00
|
|
|
eng_image_data_preload_cancel(void *data __UNUSED__, void *image, const void *target)
|
2008-09-16 07:52:57 -07:00
|
|
|
{
|
|
|
|
Evas_GL_Image *gim = image;
|
|
|
|
RGBA_Image *im;
|
|
|
|
|
2010-01-21 01:42:26 -08:00
|
|
|
if (!gim) return;
|
|
|
|
if (gim->native.data) return;
|
|
|
|
im = (RGBA_Image *)gim->im;
|
|
|
|
if (!im) return;
|
2009-01-20 06:56:37 -08:00
|
|
|
evas_cache_image_preload_cancel(&im->cache_entry, target);
|
2008-09-16 07:52:57 -07:00
|
|
|
}
|
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
static void
|
2009-11-12 23:22:31 -08:00
|
|
|
eng_image_draw(void *data, void *context, void *surface, void *image, int src_x, int src_y, int src_w, int src_h, int dst_x, int dst_y, int dst_w, int dst_h, int smooth)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2005-05-21 19:49:50 -07:00
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
re = (Render_Engine *)data;
|
2006-12-19 06:12:40 -08:00
|
|
|
if (!image) return;
|
2006-03-06 18:44:16 -08:00
|
|
|
eng_window_use(re->win);
|
2009-11-12 23:22:31 -08:00
|
|
|
evas_gl_common_context_target_surface_set(re->win->gl_context, surface);
|
2006-09-30 03:18:37 -07:00
|
|
|
re->win->gl_context->dc = context;
|
|
|
|
evas_gl_common_image_draw(re->win->gl_context, image,
|
2009-10-09 05:10:27 -07:00
|
|
|
src_x, src_y, src_w, src_h,
|
|
|
|
dst_x, dst_y, dst_w, dst_h,
|
|
|
|
smooth);
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
2009-05-07 06:29:56 -07:00
|
|
|
static void
|
|
|
|
eng_image_scale_hint_set(void *data __UNUSED__, void *image, int hint)
|
|
|
|
{
|
2010-08-11 23:11:13 -07:00
|
|
|
if (image) evas_gl_common_image_scale_hint_set(image, hint);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
eng_image_scale_hint_get(void *data __UNUSED__, void *image)
|
|
|
|
{
|
|
|
|
Evas_GL_Image *gim = image;
|
|
|
|
if (!gim) return EVAS_IMAGE_SCALE_HINT_NONE;
|
|
|
|
return gim->scale_hint;
|
2009-05-07 06:29:56 -07:00
|
|
|
}
|
|
|
|
|
2009-11-06 03:32:23 -08:00
|
|
|
static void
|
2011-06-09 12:25:21 -07:00
|
|
|
eng_image_map_draw(void *data, void *context, void *surface, void *image, int npoints, RGBA_Map_Point *p, int smooth, int level)
|
2009-11-06 03:32:23 -08:00
|
|
|
{
|
2010-09-18 07:23:20 -07:00
|
|
|
Evas_GL_Image *gim = image;
|
2009-11-11 03:39:25 -08:00
|
|
|
Render_Engine *re;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2009-11-11 03:39:25 -08:00
|
|
|
re = (Render_Engine *)data;
|
2010-09-18 07:23:20 -07:00
|
|
|
if (!image) return;
|
2009-11-12 23:22:31 -08:00
|
|
|
eng_window_use(re->win);
|
|
|
|
evas_gl_common_context_target_surface_set(re->win->gl_context, surface);
|
|
|
|
re->win->gl_context->dc = context;
|
2011-02-09 22:52:53 -08:00
|
|
|
if (npoints != 4)
|
|
|
|
{
|
2011-05-30 09:45:08 -07:00
|
|
|
// FIXME: nash - you didn't fix this
|
2011-02-09 22:52:53 -08:00
|
|
|
abort();
|
|
|
|
}
|
2010-09-18 07:23:20 -07:00
|
|
|
if ((p[0].x == p[3].x) &&
|
|
|
|
(p[1].x == p[2].x) &&
|
|
|
|
(p[0].y == p[1].y) &&
|
|
|
|
(p[3].y == p[2].y) &&
|
|
|
|
(p[0].x <= p[1].x) &&
|
|
|
|
(p[0].y <= p[2].y) &&
|
|
|
|
(p[0].u == 0) &&
|
|
|
|
(p[0].v == 0) &&
|
|
|
|
(p[1].u == (gim->w << FP)) &&
|
|
|
|
(p[1].v == 0) &&
|
|
|
|
(p[2].u == (gim->w << FP)) &&
|
|
|
|
(p[2].v == (gim->h << FP)) &&
|
|
|
|
(p[3].u == 0) &&
|
|
|
|
(p[3].v == (gim->h << FP)) &&
|
|
|
|
(p[0].col == 0xffffffff) &&
|
|
|
|
(p[1].col == 0xffffffff) &&
|
|
|
|
(p[2].col == 0xffffffff) &&
|
|
|
|
(p[3].col == 0xffffffff))
|
|
|
|
{
|
|
|
|
int dx, dy, dw, dh;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-09-18 07:23:20 -07:00
|
|
|
dx = p[0].x >> FP;
|
|
|
|
dy = p[0].y >> FP;
|
|
|
|
dw = (p[2].x >> FP) - dx;
|
|
|
|
dh = (p[2].y >> FP) - dy;
|
2011-02-09 10:39:54 -08:00
|
|
|
eng_image_draw(data, context, surface, image,
|
|
|
|
0, 0, gim->w, gim->h, dx, dy, dw, dh, smooth);
|
2010-09-18 07:23:20 -07:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2011-02-09 22:52:53 -08:00
|
|
|
evas_gl_common_image_map_draw(re->win->gl_context, image, npoints, p,
|
|
|
|
smooth, level);
|
2010-09-18 07:23:20 -07:00
|
|
|
}
|
2009-11-06 03:32:23 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void *
|
2011-06-09 12:25:21 -07:00
|
|
|
eng_image_map_surface_new(void *data, int w, int h, int alpha)
|
2009-11-06 03:32:23 -08:00
|
|
|
{
|
2009-11-12 23:22:31 -08:00
|
|
|
Render_Engine *re;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2009-11-12 23:22:31 -08:00
|
|
|
re = (Render_Engine *)data;
|
|
|
|
return evas_gl_common_image_surface_new(re->win->gl_context, w, h, alpha);
|
2009-11-06 03:32:23 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
eng_image_map_surface_free(void *data __UNUSED__, void *surface)
|
|
|
|
{
|
2009-11-12 23:22:31 -08:00
|
|
|
evas_gl_common_image_free(surface);
|
2009-11-06 03:32:23 -08:00
|
|
|
}
|
|
|
|
|
2010-08-11 23:11:13 -07:00
|
|
|
static void
|
|
|
|
eng_image_content_hint_set(void *data __UNUSED__, void *image, int hint)
|
|
|
|
{
|
|
|
|
if (image) evas_gl_common_image_content_hint_set(image, hint);
|
|
|
|
}
|
|
|
|
|
2009-05-07 06:29:56 -07:00
|
|
|
static int
|
2010-08-11 23:11:13 -07:00
|
|
|
eng_image_content_hint_get(void *data __UNUSED__, void *image)
|
2009-05-07 06:29:56 -07:00
|
|
|
{
|
2010-08-11 23:11:13 -07:00
|
|
|
Evas_GL_Image *gim = image;
|
|
|
|
if (!gim) return EVAS_IMAGE_CONTENT_HINT_NONE;
|
|
|
|
return gim->content_hint;
|
2009-05-07 06:29:56 -07:00
|
|
|
}
|
|
|
|
|
2011-02-08 03:41:38 -08:00
|
|
|
static void
|
2011-06-09 12:25:21 -07:00
|
|
|
eng_image_cache_flush(void *data)
|
2011-02-08 03:41:38 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
|
|
|
int tmp_size;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-02-08 03:41:38 -08:00
|
|
|
re = (Render_Engine *)data;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-02-08 03:41:38 -08:00
|
|
|
tmp_size = evas_common_image_get_cache();
|
|
|
|
evas_common_image_set_cache(0);
|
|
|
|
evas_common_rgba_image_scalecache_flush();
|
|
|
|
evas_gl_common_image_cache_flush(re->win->gl_context);
|
|
|
|
evas_common_image_set_cache(tmp_size);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2011-06-09 12:25:21 -07:00
|
|
|
eng_image_cache_set(void *data, int bytes)
|
2011-02-08 03:41:38 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-02-08 03:41:38 -08:00
|
|
|
re = (Render_Engine *)data;
|
|
|
|
evas_common_image_set_cache(bytes);
|
|
|
|
evas_common_rgba_image_scalecache_size_set(bytes);
|
|
|
|
evas_gl_common_image_cache_flush(re->win->gl_context);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
eng_image_cache_get(void *data __UNUSED__)
|
|
|
|
{
|
|
|
|
return evas_common_image_get_cache();
|
|
|
|
}
|
|
|
|
|
2010-08-18 22:18:17 -07:00
|
|
|
static void
|
cleanup: fix some "unused" errors from -Wextra.
As we're heading for a release we better remove as much errors as
possible and as the first step I'm removing warnings due unused
parameters, variables and functions. These tend to pollute real errors
spotted by -Wall and clang/llvm.
This does not fixes all, just the clear that could be set to
__UNUSED__, particularly to do (and I'd like some help from the
authors):
* src/lib/engines/common/evas_font_{draw,query}.c (tasn):
intl_props is just used while doing BIDI, but also used in other
#ifdef blocks :-/
* evas_map_* (raster):
huge amount of warnings, code is quite confusing and thus I'm not
touching it. I have no idea whenever the commented blocks or extra
parameters are intended to be used or no.
* src/modules/engines/fbevas_fb_main.c (raster?):
is fb_setvt() to be used? If not do you mind removing it?
* src/modules/engines/gl_{common,x11} (raster):
huge amount of warnings, code is quite nested and full of #ifdefs
that does not help to give a clear picture of what's going on.
* src/bin/evas_cserve_main.c (raster):
I could have ignored most of the errors, but is the code correct? I
mean, there is no unload of images being applied. If you confirm
none of those warnings are harmful I can flag them as unused.
* src/lib/engines/common_8 (dottedmag):
lots of unused functions that were acquired from common_16, they
are unused and if they will not, then they should be removed.
SVN revision: 52421
2010-09-18 12:17:41 -07:00
|
|
|
eng_image_stride_get(void *data __UNUSED__, void *image, int *stride)
|
2010-08-18 20:30:47 -07:00
|
|
|
{
|
|
|
|
Evas_GL_Image *im = image;
|
2011-06-09 12:25:21 -07:00
|
|
|
|
2010-09-18 17:28:58 -07:00
|
|
|
if ((im->tex) && (im->tex->pt->dyn.img))
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
*stride = im->tex->pt->dyn.stride;
|
2011-07-17 22:32:06 -07:00
|
|
|
else
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
*stride = im->w * 4;
|
2010-08-18 20:30:47 -07:00
|
|
|
}
|
|
|
|
|
2002-11-08 00:02:15 -08:00
|
|
|
static void
|
2011-05-29 06:56:23 -07:00
|
|
|
eng_font_draw(void *data, void *context, void *surface, Evas_Font_Set *font, int x, int y, int w __UNUSED__, int h __UNUSED__, int ow __UNUSED__, int oh __UNUSED__, const Evas_Text_Props *intl_props)
|
2002-11-08 00:02:15 -08:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
|
|
|
|
|
|
|
re = (Render_Engine *)data;
|
2009-10-09 05:10:27 -07:00
|
|
|
eng_window_use(re->win);
|
2009-11-12 23:22:31 -08:00
|
|
|
evas_gl_common_context_target_surface_set(re->win->gl_context, surface);
|
|
|
|
re->win->gl_context->dc = context;
|
2003-09-04 00:40:34 -07:00
|
|
|
{
|
2009-10-09 05:10:27 -07:00
|
|
|
// FIXME: put im into context so we can free it
|
2011-11-10 00:59:09 -08:00
|
|
|
static RGBA_Image *im = NULL;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2009-10-09 05:10:27 -07:00
|
|
|
if (!im)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
im = (RGBA_Image *)evas_cache_image_empty(evas_common_image_cache_get());
|
2009-10-09 05:10:27 -07:00
|
|
|
im->cache_entry.w = re->win->w;
|
|
|
|
im->cache_entry.h = re->win->h;
|
|
|
|
evas_common_draw_context_font_ext_set(context,
|
2011-11-10 00:59:09 -08:00
|
|
|
re->win->gl_context,
|
|
|
|
evas_gl_font_texture_new,
|
|
|
|
evas_gl_font_texture_free,
|
|
|
|
evas_gl_font_texture_draw);
|
|
|
|
evas_common_font_draw(im, context, (RGBA_Font *) font, x, y,
|
2011-05-29 06:56:23 -07:00
|
|
|
intl_props);
|
2011-11-10 00:59:09 -08:00
|
|
|
evas_common_draw_context_font_ext_set(context,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
NULL);
|
2003-09-04 00:40:34 -07:00
|
|
|
}
|
2002-11-08 00:02:15 -08:00
|
|
|
}
|
|
|
|
|
2009-08-14 10:11:08 -07:00
|
|
|
static Eina_Bool
|
2011-06-28 01:11:07 -07:00
|
|
|
eng_canvas_alpha_get(void *data, void *info __UNUSED__)
|
2009-08-14 10:11:08 -07:00
|
|
|
{
|
2011-06-28 01:11:07 -07:00
|
|
|
Render_Engine *re = (Render_Engine *)data;
|
|
|
|
return re->win->alpha;
|
2009-08-14 10:11:08 -07:00
|
|
|
}
|
|
|
|
|
2011-04-04 03:23:12 -07:00
|
|
|
static int
|
|
|
|
_set_internal_config(Render_Engine_GL_Surface *sfc, Evas_GL_Config *cfg)
|
|
|
|
{
|
|
|
|
// Also initialize pixel format here as well...
|
|
|
|
switch(cfg->color_format)
|
2011-06-17 00:47:28 -07:00
|
|
|
{
|
2011-10-28 04:08:23 -07:00
|
|
|
case EVAS_GL_RGB_888:
|
2011-04-04 03:23:12 -07:00
|
|
|
sfc->rt_fmt = GL_RGB;
|
|
|
|
sfc->rt_internal_fmt = GL_RGB;
|
|
|
|
break;
|
2011-10-28 04:08:23 -07:00
|
|
|
case EVAS_GL_RGBA_8888:
|
2011-04-04 03:23:12 -07:00
|
|
|
sfc->rt_fmt = GL_RGBA;
|
|
|
|
sfc->rt_internal_fmt = GL_RGBA;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
ERR("Invalid Color Format!");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch(cfg->depth_bits)
|
2011-06-17 00:47:28 -07:00
|
|
|
{
|
2011-04-04 03:23:12 -07:00
|
|
|
case EVAS_GL_DEPTH_NONE:
|
|
|
|
break;
|
|
|
|
case EVAS_GL_DEPTH_BIT_8:
|
|
|
|
case EVAS_GL_DEPTH_BIT_16:
|
|
|
|
case EVAS_GL_DEPTH_BIT_24:
|
2011-05-18 02:49:58 -07:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
|
|
|
// 24 bit doesn't work... just cover it with 16 for now..
|
|
|
|
sfc->rb_depth_fmt = GL_DEPTH_COMPONENT16;
|
|
|
|
#else
|
2011-04-04 03:23:12 -07:00
|
|
|
sfc->rb_depth_fmt = GL_DEPTH_COMPONENT;
|
2011-05-18 02:49:58 -07:00
|
|
|
#endif
|
2011-04-04 03:23:12 -07:00
|
|
|
break;
|
|
|
|
case EVAS_GL_DEPTH_BIT_32:
|
|
|
|
default:
|
|
|
|
ERR("Unsupported Depth Bits Format!");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch(cfg->stencil_bits)
|
2011-06-17 00:47:28 -07:00
|
|
|
{
|
2011-04-04 03:23:12 -07:00
|
|
|
case EVAS_GL_STENCIL_NONE:
|
|
|
|
break;
|
|
|
|
case EVAS_GL_STENCIL_BIT_1:
|
|
|
|
case EVAS_GL_STENCIL_BIT_2:
|
|
|
|
case EVAS_GL_STENCIL_BIT_4:
|
|
|
|
case EVAS_GL_STENCIL_BIT_8:
|
2011-05-18 02:49:58 -07:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
|
|
|
sfc->rb_stencil_fmt = GL_STENCIL_INDEX8;
|
|
|
|
#else
|
2011-04-04 03:23:12 -07:00
|
|
|
sfc->rb_stencil_fmt = GL_STENCIL_INDEX;
|
2011-05-18 02:49:58 -07:00
|
|
|
#endif
|
2011-04-04 03:23:12 -07:00
|
|
|
break;
|
|
|
|
case EVAS_GL_STENCIL_BIT_16:
|
|
|
|
default:
|
|
|
|
ERR("Unsupported Stencil Bits Format!");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-06-17 00:47:28 -07:00
|
|
|
// Do Packed Depth24_Stencil8 Later...
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2011-06-17 00:47:28 -07:00
|
|
|
_create_rt_buffers(Render_Engine *data __UNUSED__,
|
2011-04-04 03:23:12 -07:00
|
|
|
Render_Engine_GL_Surface *sfc)
|
|
|
|
{
|
|
|
|
// Render Target texture
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glGenTextures(1, &sfc->rt_tex );
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
// Depth RenderBuffer - Create storage here...
|
|
|
|
if (sfc->depth_bits != EVAS_GL_DEPTH_NONE)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glGenRenderbuffers(1, &sfc->rb_depth);
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
// Stencil RenderBuffer - Create Storage here...
|
|
|
|
if (sfc->stencil_bits != EVAS_GL_STENCIL_NONE)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glGenRenderbuffers(1, &sfc->rb_stencil);
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2011-06-17 00:47:28 -07:00
|
|
|
_attach_fbo_surface(Render_Engine *data __UNUSED__,
|
|
|
|
Render_Engine_GL_Surface *sfc,
|
2011-04-04 03:23:12 -07:00
|
|
|
Render_Engine_GL_Context *ctx)
|
|
|
|
{
|
|
|
|
int fb_status;
|
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
// Initialize Texture
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glBindTexture(GL_TEXTURE_2D, sfc->rt_tex );
|
|
|
|
glsym_glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
|
|
|
|
glsym_glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
|
|
|
|
glsym_glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
|
|
|
|
glsym_glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
|
|
|
|
glsym_glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, sfc->w, sfc->h, 0,
|
|
|
|
GL_RGBA, GL_UNSIGNED_BYTE, NULL);
|
|
|
|
glsym_glBindTexture(GL_TEXTURE_2D, 0);
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
|
|
|
|
|
|
|
|
// Attach texture to FBO
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glBindFramebuffer(GL_FRAMEBUFFER, ctx->context_fbo);
|
|
|
|
glsym_glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0,
|
|
|
|
GL_TEXTURE_2D, sfc->rt_tex, 0);
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-04-04 03:23:12 -07:00
|
|
|
// Depth RenderBuffer - Attach it to FBO
|
|
|
|
if (sfc->depth_bits != EVAS_GL_DEPTH_NONE)
|
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glBindRenderbuffer(GL_RENDERBUFFER, sfc->rb_depth);
|
|
|
|
glsym_glRenderbufferStorage(GL_RENDERBUFFER, sfc->rb_depth_fmt,
|
|
|
|
sfc->w, sfc->h);
|
|
|
|
glsym_glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT,
|
|
|
|
GL_RENDERBUFFER, sfc->rb_depth);
|
|
|
|
glsym_glBindRenderbuffer(GL_RENDERBUFFER, 0);
|
2011-04-04 03:23:12 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
// Stencil RenderBuffer - Attach it to FBO
|
|
|
|
if (sfc->stencil_bits != EVAS_GL_STENCIL_NONE)
|
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glBindRenderbuffer(GL_RENDERBUFFER, sfc->rb_stencil);
|
|
|
|
glsym_glRenderbufferStorage(GL_RENDERBUFFER, sfc->rb_stencil_fmt,
|
|
|
|
sfc->w, sfc->h);
|
|
|
|
glsym_glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_STENCIL_ATTACHMENT,
|
|
|
|
GL_RENDERBUFFER, sfc->rb_stencil);
|
|
|
|
glsym_glBindRenderbuffer(GL_RENDERBUFFER, 0);
|
2011-04-04 03:23:12 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
// Check FBO for completeness
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
fb_status = glsym_glCheckFramebufferStatus(GL_FRAMEBUFFER);
|
2011-06-17 00:47:28 -07:00
|
|
|
if (fb_status != GL_FRAMEBUFFER_COMPLETE)
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
|
|
|
ERR("FBO not complete!");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
|
2011-04-04 03:23:12 -07:00
|
|
|
static void *
|
|
|
|
eng_gl_surface_create(void *data, void *config, int w, int h)
|
|
|
|
{
|
|
|
|
Render_Engine *re;
|
|
|
|
Render_Engine_GL_Surface *sfc;
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
Render_Engine_GL_Resource *rsc;
|
2011-06-17 00:47:28 -07:00
|
|
|
Evas_GL_Config *cfg;
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: [E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface
texture creation patch
I'm attaching a patch that addresses the awkward usage case. It's something
that didn't bother me initially but the more I look at it, i think
it's a little off. :-)
The initial version of the evas_gl that I've submitted had the
following use case.
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
// Make current triggers surface texture and FBO to be created
evas_gl_make_current(evasgl, sfc, ctx);
// Then you can do a surface_get to retrieve the proper texture and set it
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The unnatural thing about this use case is that you have to call the make_current
one time in order for evas_gl to generate a surface texture. This is because
you need a context to create a texture. Unfortunately, this makes the usage
case really awkward.
So, instead, I've decided to get rid of the need for calling the make_current
by generating a surface texture when evas_gl_surface_create() is called
by using the evas' gl context. This works because the newly created context
shares resources with evas. in fact, this is what i'm currently doing with surface
deletion anyway so I thought this solution was reasonable.
Here's how it looks after you get rid of the make_current:
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The patch is pretty small and straightforward.
SVN revision: 58892
2011-04-25 01:41:36 -07:00
|
|
|
int ret;
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
sfc = calloc(1, sizeof(Render_Engine_GL_Surface));
|
|
|
|
if (!sfc) return NULL;
|
|
|
|
|
|
|
|
re = (Render_Engine *)data;
|
|
|
|
cfg = (Evas_GL_Config *)config;
|
|
|
|
|
|
|
|
sfc->initialized = 0;
|
2011-05-18 02:49:58 -07:00
|
|
|
sfc->fbo_attached = 0;
|
2011-04-04 03:23:12 -07:00
|
|
|
sfc->w = w;
|
|
|
|
sfc->h = h;
|
|
|
|
sfc->depth_bits = cfg->depth_bits;
|
|
|
|
sfc->stencil_bits = cfg->stencil_bits;
|
|
|
|
sfc->rt_tex = 0;
|
|
|
|
sfc->rb_depth = 0;
|
|
|
|
sfc->rb_stencil = 0;
|
|
|
|
|
|
|
|
// Set the internal format based on the config
|
|
|
|
if (!_set_internal_config(sfc, cfg))
|
|
|
|
{
|
|
|
|
ERR("Unsupported Format!");
|
|
|
|
free(sfc);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
// Create internal resource context if it hasn't been created already
|
|
|
|
if ((rsc = eina_tls_get(resource_key)) == NULL)
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: [E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface
texture creation patch
I'm attaching a patch that addresses the awkward usage case. It's something
that didn't bother me initially but the more I look at it, i think
it's a little off. :-)
The initial version of the evas_gl that I've submitted had the
following use case.
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
// Make current triggers surface texture and FBO to be created
evas_gl_make_current(evasgl, sfc, ctx);
// Then you can do a surface_get to retrieve the proper texture and set it
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The unnatural thing about this use case is that you have to call the make_current
one time in order for evas_gl to generate a surface texture. This is because
you need a context to create a texture. Unfortunately, this makes the usage
case really awkward.
So, instead, I've decided to get rid of the need for calling the make_current
by generating a surface texture when evas_gl_surface_create() is called
by using the evas' gl context. This works because the newly created context
shares resources with evas. in fact, this is what i'm currently doing with surface
deletion anyway so I thought this solution was reasonable.
Here's how it looks after you get rid of the make_current:
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The patch is pretty small and straightforward.
SVN revision: 58892
2011-04-25 01:41:36 -07:00
|
|
|
{
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
if ((rsc = _create_internal_glue_resources(re)) == NULL)
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: [E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface
texture creation patch
I'm attaching a patch that addresses the awkward usage case. It's something
that didn't bother me initially but the more I look at it, i think
it's a little off. :-)
The initial version of the evas_gl that I've submitted had the
following use case.
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
// Make current triggers surface texture and FBO to be created
evas_gl_make_current(evasgl, sfc, ctx);
// Then you can do a surface_get to retrieve the proper texture and set it
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The unnatural thing about this use case is that you have to call the make_current
one time in order for evas_gl to generate a surface texture. This is because
you need a context to create a texture. Unfortunately, this makes the usage
case really awkward.
So, instead, I've decided to get rid of the need for calling the make_current
by generating a surface texture when evas_gl_surface_create() is called
by using the evas' gl context. This works because the newly created context
shares resources with evas. in fact, this is what i'm currently doing with surface
deletion anyway so I thought this solution was reasonable.
Here's how it looks after you get rid of the make_current:
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The patch is pretty small and straightforward.
SVN revision: 58892
2011-04-25 01:41:36 -07:00
|
|
|
{
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
ERR("Error creating internal resources.");
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: [E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface
texture creation patch
I'm attaching a patch that addresses the awkward usage case. It's something
that didn't bother me initially but the more I look at it, i think
it's a little off. :-)
The initial version of the evas_gl that I've submitted had the
following use case.
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
// Make current triggers surface texture and FBO to be created
evas_gl_make_current(evasgl, sfc, ctx);
// Then you can do a surface_get to retrieve the proper texture and set it
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The unnatural thing about this use case is that you have to call the make_current
one time in order for evas_gl to generate a surface texture. This is because
you need a context to create a texture. Unfortunately, this makes the usage
case really awkward.
So, instead, I've decided to get rid of the need for calling the make_current
by generating a surface texture when evas_gl_surface_create() is called
by using the evas' gl context. This works because the newly created context
shares resources with evas. in fact, this is what i'm currently doing with surface
deletion anyway so I thought this solution was reasonable.
Here's how it looks after you get rid of the make_current:
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The patch is pretty small and straightforward.
SVN revision: 58892
2011-04-25 01:41:36 -07:00
|
|
|
free(sfc);
|
|
|
|
return NULL;
|
|
|
|
}
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
}
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: [E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface
texture creation patch
I'm attaching a patch that addresses the awkward usage case. It's something
that didn't bother me initially but the more I look at it, i think
it's a little off. :-)
The initial version of the evas_gl that I've submitted had the
following use case.
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
// Make current triggers surface texture and FBO to be created
evas_gl_make_current(evasgl, sfc, ctx);
// Then you can do a surface_get to retrieve the proper texture and set it
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The unnatural thing about this use case is that you have to call the make_current
one time in order for evas_gl to generate a surface texture. This is because
you need a context to create a texture. Unfortunately, this makes the usage
case really awkward.
So, instead, I've decided to get rid of the need for calling the make_current
by generating a surface texture when evas_gl_surface_create() is called
by using the evas' gl context. This works because the newly created context
shares resources with evas. in fact, this is what i'm currently doing with surface
deletion anyway so I thought this solution was reasonable.
Here's how it looks after you get rid of the make_current:
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The patch is pretty small and straightforward.
SVN revision: 58892
2011-04-25 01:41:36 -07:00
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
// I'm using evas's original context to create the render target texture
|
|
|
|
// This is to prevent awkwardness in using native_surface_get() function
|
|
|
|
// If the rt texture creation is deferred till the context is created and
|
|
|
|
// make_current called, the user can't call native_surface_get() right
|
|
|
|
// after the surface is created. hence this is done here using evas' context.
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ret = glsym_eglMakeCurrent(re->win->egl_disp, rsc->surface, rsc->surface, rsc->context);
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
#else
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ret = glsym_glXMakeCurrent(re->info->info.display, re->win->win, rsc->context);
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
#endif
|
|
|
|
if (!ret)
|
|
|
|
{
|
|
|
|
ERR("xxxMakeCurrent() failed!");
|
|
|
|
free(sfc);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Create Render texture
|
|
|
|
if (!_create_rt_buffers(re, sfc))
|
|
|
|
{
|
|
|
|
ERR("_create_rt_buffers() failed.");
|
|
|
|
free(sfc);
|
|
|
|
return NULL;
|
|
|
|
}
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: [E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface
texture creation patch
I'm attaching a patch that addresses the awkward usage case. It's something
that didn't bother me initially but the more I look at it, i think
it's a little off. :-)
The initial version of the evas_gl that I've submitted had the
following use case.
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
// Make current triggers surface texture and FBO to be created
evas_gl_make_current(evasgl, sfc, ctx);
// Then you can do a surface_get to retrieve the proper texture and set it
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The unnatural thing about this use case is that you have to call the make_current
one time in order for evas_gl to generate a surface texture. This is because
you need a context to create a texture. Unfortunately, this makes the usage
case really awkward.
So, instead, I've decided to get rid of the need for calling the make_current
by generating a surface texture when evas_gl_surface_create() is called
by using the evas' gl context. This works because the newly created context
shares resources with evas. in fact, this is what i'm currently doing with surface
deletion anyway so I thought this solution was reasonable.
Here's how it looks after you get rid of the make_current:
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The patch is pretty small and straightforward.
SVN revision: 58892
2011-04-25 01:41:36 -07:00
|
|
|
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ret = glsym_eglMakeCurrent(re->win->egl_disp, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: [E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface
texture creation patch
I'm attaching a patch that addresses the awkward usage case. It's something
that didn't bother me initially but the more I look at it, i think
it's a little off. :-)
The initial version of the evas_gl that I've submitted had the
following use case.
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
// Make current triggers surface texture and FBO to be created
evas_gl_make_current(evasgl, sfc, ctx);
// Then you can do a surface_get to retrieve the proper texture and set it
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The unnatural thing about this use case is that you have to call the make_current
one time in order for evas_gl to generate a surface texture. This is because
you need a context to create a texture. Unfortunately, this makes the usage
case really awkward.
So, instead, I've decided to get rid of the need for calling the make_current
by generating a surface texture when evas_gl_surface_create() is called
by using the evas' gl context. This works because the newly created context
shares resources with evas. in fact, this is what i'm currently doing with surface
deletion anyway so I thought this solution was reasonable.
Here's how it looks after you get rid of the make_current:
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The patch is pretty small and straightforward.
SVN revision: 58892
2011-04-25 01:41:36 -07:00
|
|
|
#else
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ret = glsym_glXMakeCurrent(re->info->info.display, None, NULL);
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: [E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface
texture creation patch
I'm attaching a patch that addresses the awkward usage case. It's something
that didn't bother me initially but the more I look at it, i think
it's a little off. :-)
The initial version of the evas_gl that I've submitted had the
following use case.
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
// Make current triggers surface texture and FBO to be created
evas_gl_make_current(evasgl, sfc, ctx);
// Then you can do a surface_get to retrieve the proper texture and set it
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The unnatural thing about this use case is that you have to call the make_current
one time in order for evas_gl to generate a surface texture. This is because
you need a context to create a texture. Unfortunately, this makes the usage
case really awkward.
So, instead, I've decided to get rid of the need for calling the make_current
by generating a surface texture when evas_gl_surface_create() is called
by using the evas' gl context. This works because the newly created context
shares resources with evas. in fact, this is what i'm currently doing with surface
deletion anyway so I thought this solution was reasonable.
Here's how it looks after you get rid of the make_current:
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The patch is pretty small and straightforward.
SVN revision: 58892
2011-04-25 01:41:36 -07:00
|
|
|
#endif
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
if (!ret)
|
|
|
|
{
|
|
|
|
ERR("xxxMakeCurrent() failed!");
|
|
|
|
free(sfc);
|
|
|
|
return NULL;
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: [E-devel] [Review] [Patch] Evas - OpenGL on Evas: surface
texture creation patch
I'm attaching a patch that addresses the awkward usage case. It's something
that didn't bother me initially but the more I look at it, i think
it's a little off. :-)
The initial version of the evas_gl that I've submitted had the
following use case.
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
// Make current triggers surface texture and FBO to be created
evas_gl_make_current(evasgl, sfc, ctx);
// Then you can do a surface_get to retrieve the proper texture and set it
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The unnatural thing about this use case is that you have to call the make_current
one time in order for evas_gl to generate a surface texture. This is because
you need a context to create a texture. Unfortunately, this makes the usage
case really awkward.
So, instead, I've decided to get rid of the need for calling the make_current
by generating a surface texture when evas_gl_surface_create() is called
by using the evas' gl context. This works because the newly created context
shares resources with evas. in fact, this is what i'm currently doing with surface
deletion anyway so I thought this solution was reasonable.
Here's how it looks after you get rid of the make_current:
evasgl = evas_gl_new(e);
sfc = evas_gl_surface_create(...);
ctx = evas_gl_context_create(...);
evas_gl_native_surface_get(evasgl, sfc, &ns);
evas_object_image_native_surface_set(img_obj, &ns);
The patch is pretty small and straightforward.
SVN revision: 58892
2011-04-25 01:41:36 -07:00
|
|
|
}
|
|
|
|
|
2011-04-04 03:23:12 -07:00
|
|
|
return sfc;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
eng_gl_surface_destroy(void *data, void *surface)
|
|
|
|
{
|
|
|
|
Render_Engine *re;
|
|
|
|
Render_Engine_GL_Surface *sfc;
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
Render_Engine_GL_Resource *rsc;
|
2011-04-04 03:23:12 -07:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
re = (Render_Engine *)data;
|
|
|
|
sfc = (Render_Engine_GL_Surface*)surface;
|
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
if (!sfc) return 0;
|
|
|
|
|
|
|
|
if ((rsc = eina_tls_get(resource_key)) == EINA_FALSE) return 0;
|
|
|
|
|
2011-04-04 03:23:12 -07:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ret = glsym_eglMakeCurrent(re->win->egl_disp, rsc->surface, rsc->surface, rsc->context);
|
2011-04-04 03:23:12 -07:00
|
|
|
#else
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ret = glsym_glXMakeCurrent(re->info->info.display, re->win->win, rsc->context);
|
2011-04-04 03:23:12 -07:00
|
|
|
#endif
|
2011-06-17 00:47:28 -07:00
|
|
|
if (!ret)
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
|
|
|
ERR("xxxMakeCurrent() failed!");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Delete FBO/RBO and Texture here
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
if (sfc->rt_tex)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glDeleteTextures(1, &sfc->rt_tex);
|
2011-04-04 03:23:12 -07:00
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
if (sfc->rb_depth)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glDeleteRenderbuffers(1, &sfc->rb_depth);
|
2011-04-04 03:23:12 -07:00
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
if (sfc->rb_stencil)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glDeleteRenderbuffers(1, &sfc->rb_stencil);
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ret = glsym_eglMakeCurrent(re->win->egl_disp, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);
|
2011-04-04 03:23:12 -07:00
|
|
|
#else
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ret = glsym_glXMakeCurrent(re->info->info.display, None, NULL);
|
2011-04-04 03:23:12 -07:00
|
|
|
#endif
|
2011-06-17 00:47:28 -07:00
|
|
|
if (!ret)
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
|
|
|
ERR("xxxMakeCurrent() failed!");
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
free(sfc);
|
2011-04-04 03:23:12 -07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
free(sfc);
|
|
|
|
surface = NULL;
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void *
|
|
|
|
eng_gl_context_create(void *data, void *share_context)
|
|
|
|
{
|
|
|
|
Render_Engine *re;
|
|
|
|
Render_Engine_GL_Context *ctx;
|
|
|
|
Render_Engine_GL_Context *share_ctx;
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
|
|
|
int context_attrs[3];
|
2011-06-17 00:47:28 -07:00
|
|
|
#endif
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
ctx = calloc(1, sizeof(Render_Engine_GL_Context));
|
|
|
|
|
|
|
|
if (!ctx) return NULL;
|
|
|
|
|
|
|
|
re = (Render_Engine *)data;
|
|
|
|
share_ctx = (Render_Engine_GL_Context *)share_context;
|
|
|
|
|
|
|
|
// Set the share context to Evas' GL context if share_context is NULL.
|
|
|
|
// Otherwise set it to the given share_context.
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
|
|
|
// EGL
|
|
|
|
context_attrs[0] = EGL_CONTEXT_CLIENT_VERSION;
|
|
|
|
context_attrs[1] = 2;
|
|
|
|
context_attrs[2] = EGL_NONE;
|
|
|
|
|
|
|
|
if (share_ctx)
|
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ctx->context = glsym_eglCreateContext(re->win->egl_disp,
|
|
|
|
re->win->egl_config,
|
|
|
|
share_ctx->context, // Share Context
|
|
|
|
context_attrs);
|
2011-04-04 03:23:12 -07:00
|
|
|
}
|
2011-06-17 00:47:28 -07:00
|
|
|
else
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ctx->context = glsym_eglCreateContext(re->win->egl_disp,
|
|
|
|
re->win->egl_config,
|
|
|
|
re->win->egl_context[0], // Evas' GL Context
|
|
|
|
context_attrs);
|
2011-04-04 03:23:12 -07:00
|
|
|
}
|
|
|
|
|
2011-06-17 00:47:28 -07:00
|
|
|
if (!ctx->context)
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ERR("glsym_eglCreateContext() fail. code=%#x", glsym_eglGetError());
|
2011-04-04 03:23:12 -07:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
// GLX
|
|
|
|
if (share_context)
|
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ctx->context = glsym_glXCreateContext(re->info->info.display,
|
|
|
|
re->win->visualinfo,
|
|
|
|
share_ctx->context, // Share Context
|
|
|
|
1);
|
2011-04-04 03:23:12 -07:00
|
|
|
}
|
2011-06-17 00:47:28 -07:00
|
|
|
else
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ctx->context = glsym_glXCreateContext(re->info->info.display,
|
|
|
|
re->win->visualinfo,
|
|
|
|
re->win->context, // Evas' GL Context
|
|
|
|
1);
|
2011-04-04 03:23:12 -07:00
|
|
|
}
|
|
|
|
|
2011-06-17 00:47:28 -07:00
|
|
|
if (!ctx->context)
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
|
|
|
ERR("glXCreateContext() fail.");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
ctx->initialized = 0;
|
2011-08-24 23:30:52 -07:00
|
|
|
ctx->context_fbo = 0;
|
2011-05-18 02:49:58 -07:00
|
|
|
ctx->current_sfc = NULL;
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
return ctx;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
eng_gl_context_destroy(void *data, void *context)
|
|
|
|
{
|
|
|
|
Render_Engine *re;
|
|
|
|
Render_Engine_GL_Context *ctx;
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
Render_Engine_GL_Resource *rsc;
|
2011-04-04 03:23:12 -07:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
re = (Render_Engine *)data;
|
|
|
|
ctx = (Render_Engine_GL_Context*)context;
|
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
if (!ctx) return 0;
|
|
|
|
|
|
|
|
if ((rsc = eina_tls_get(resource_key)) == EINA_FALSE) return 0;
|
|
|
|
|
2011-04-04 03:23:12 -07:00
|
|
|
// 1. Do a make current with the given context
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ret = glsym_eglMakeCurrent(re->win->egl_disp, rsc->surface,
|
|
|
|
rsc->surface, ctx->context);
|
2011-04-04 03:23:12 -07:00
|
|
|
#else
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ret = glsym_glXMakeCurrent(re->info->info.display, re->win->win,
|
|
|
|
ctx->context);
|
2011-04-04 03:23:12 -07:00
|
|
|
#endif
|
2011-06-17 00:47:28 -07:00
|
|
|
if (!ret)
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
|
|
|
ERR("xxxMakeCurrent() failed!");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
// 2. Delete the FBO
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
if (ctx->context_fbo)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glDeleteFramebuffers(1, &ctx->context_fbo);
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
// 3. Destroy the Context
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_eglDestroyContext(re->win->egl_disp, ctx->context);
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
ctx->context = EGL_NO_CONTEXT;
|
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ret = glsym_eglMakeCurrent(re->win->egl_disp, EGL_NO_SURFACE,
|
|
|
|
EGL_NO_SURFACE, EGL_NO_CONTEXT);
|
2011-04-04 03:23:12 -07:00
|
|
|
#else
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glXDestroyContext(re->info->info.display, ctx->context);
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
ctx->context = 0;
|
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ret = glsym_glXMakeCurrent(re->info->info.display, None, NULL);
|
2011-04-04 03:23:12 -07:00
|
|
|
#endif
|
2011-06-17 00:47:28 -07:00
|
|
|
if (!ret)
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
|
|
|
ERR("xxxMakeCurrent() failed!");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
free(ctx);
|
|
|
|
context = NULL;
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2011-10-25 05:07:56 -07:00
|
|
|
eng_gl_make_current(void *data __UNUSED__, void *surface, void *context)
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
|
|
|
Render_Engine *re;
|
|
|
|
Render_Engine_GL_Surface *sfc;
|
|
|
|
Render_Engine_GL_Context *ctx;
|
2011-05-19 04:19:22 -07:00
|
|
|
int ret = 0;
|
2011-10-29 22:02:05 -07:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
|
|
|
Render_Engine_GL_Resource *rsc;
|
|
|
|
#endif
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
re = (Render_Engine *)data;
|
|
|
|
sfc = (Render_Engine_GL_Surface*)surface;
|
|
|
|
ctx = (Render_Engine_GL_Context*)context;
|
|
|
|
|
2011-05-18 02:49:58 -07:00
|
|
|
// Unset surface/context
|
2011-04-04 03:23:12 -07:00
|
|
|
if ((!sfc) || (!ctx))
|
|
|
|
{
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ret = glsym_eglMakeCurrent(re->win->egl_disp, EGL_NO_SURFACE,
|
|
|
|
EGL_NO_SURFACE, EGL_NO_CONTEXT);
|
2011-04-04 03:23:12 -07:00
|
|
|
#else
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ret = glsym_glXMakeCurrent(re->info->info.display, None, NULL);
|
2011-04-04 03:23:12 -07:00
|
|
|
#endif
|
2011-06-17 00:47:28 -07:00
|
|
|
if (!ret)
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
|
|
|
ERR("xxxMakeCurrent() failed!");
|
|
|
|
return 0;
|
|
|
|
}
|
2011-08-24 23:30:52 -07:00
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
if (ctx) ctx->current_sfc = NULL;
|
|
|
|
if (sfc) sfc->current_ctx = NULL;
|
2011-08-24 23:30:52 -07:00
|
|
|
current_evgl_ctx = NULL;
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
return 1;
|
2011-04-04 03:23:12 -07:00
|
|
|
}
|
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
// Do a make current only if it's not already current
|
2011-04-04 03:23:12 -07:00
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
if ((rsc = eina_tls_get(resource_key)) == EINA_FALSE) return 0;
|
2011-08-24 23:30:52 -07:00
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
if ((glsym_eglGetCurrentContext() != ctx->context) ||
|
|
|
|
(glsym_eglGetCurrentSurface(EGL_READ) != rsc->surface) ||
|
|
|
|
(glsym_eglGetCurrentSurface(EGL_DRAW) != rsc->surface) )
|
2011-08-24 23:30:52 -07:00
|
|
|
{
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
// Flush remainder of what's in Evas' pipeline
|
|
|
|
if (re->win) eng_window_use(NULL);
|
2011-08-24 23:30:52 -07:00
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
// Do a make current
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ret = glsym_eglMakeCurrent(re->win->egl_disp, rsc->surface,
|
|
|
|
rsc->surface, ctx->context);
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
if (!ret)
|
|
|
|
{
|
|
|
|
ERR("xxxMakeCurrent() failed!");
|
|
|
|
return 0;
|
|
|
|
}
|
2011-04-04 03:23:12 -07:00
|
|
|
}
|
2011-08-24 23:30:52 -07:00
|
|
|
#else
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
if ((glsym_glXGetCurrentContext() != ctx->context) ||
|
|
|
|
(glsym_glXGetCurrentDrawable() != re->win->win) )
|
2011-08-24 23:30:52 -07:00
|
|
|
{
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
// Flush remainder of what's in Evas' pipeline
|
|
|
|
if (re->win) eng_window_use(NULL);
|
|
|
|
|
|
|
|
// Do a make current
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
ret = glsym_glXMakeCurrent(re->info->info.display, re->win->win, ctx->context);
|
2011-11-10 00:59:09 -08:00
|
|
|
if (!ret)
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
{
|
|
|
|
ERR("xxxMakeCurrent() failed!");
|
|
|
|
return 0;
|
|
|
|
}
|
2011-08-24 23:30:52 -07:00
|
|
|
}
|
|
|
|
#endif
|
2011-04-04 03:23:12 -07:00
|
|
|
|
2011-05-18 02:49:58 -07:00
|
|
|
// Create FBO if not already created
|
2011-06-17 00:47:28 -07:00
|
|
|
if (!ctx->initialized)
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glGenFramebuffers(1, &ctx->context_fbo);
|
2011-05-18 02:49:58 -07:00
|
|
|
ctx->initialized = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Attach FBO if it hasn't been attached or if surface changed
|
2011-08-24 23:30:52 -07:00
|
|
|
if ((!sfc->fbo_attached) || (ctx->current_sfc != sfc))
|
2011-05-18 02:49:58 -07:00
|
|
|
{
|
2011-06-17 00:47:28 -07:00
|
|
|
if (!_attach_fbo_surface(re, sfc, ctx))
|
2011-04-04 03:23:12 -07:00
|
|
|
{
|
2011-05-18 02:49:58 -07:00
|
|
|
ERR("_attach_fbo_surface() failed.");
|
2011-04-04 03:23:12 -07:00
|
|
|
return 0;
|
|
|
|
}
|
2011-08-24 23:30:52 -07:00
|
|
|
|
|
|
|
if (ctx->current_fbo)
|
|
|
|
// Bind to the previously bound buffer
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glBindFramebuffer(GL_FRAMEBUFFER, ctx->current_fbo);
|
2011-08-24 23:30:52 -07:00
|
|
|
else
|
|
|
|
// Bind FBO
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glBindFramebuffer(GL_FRAMEBUFFER, ctx->context_fbo);
|
2011-08-24 23:30:52 -07:00
|
|
|
|
2011-05-18 02:49:58 -07:00
|
|
|
sfc->fbo_attached = 1;
|
2011-04-04 03:23:12 -07:00
|
|
|
}
|
|
|
|
|
2011-06-17 00:47:28 -07:00
|
|
|
// Set the current surface/context
|
2011-04-04 03:23:12 -07:00
|
|
|
ctx->current_sfc = sfc;
|
|
|
|
sfc->current_ctx = ctx;
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
current_evgl_ctx = ctx;
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
static void *
|
2011-10-25 05:07:56 -07:00
|
|
|
eng_gl_string_query(void *data __UNUSED__, int name)
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
{
|
|
|
|
switch(name)
|
|
|
|
{
|
|
|
|
case EVAS_GL_EXTENSIONS:
|
|
|
|
return (void*)_evasgl_ext_string;
|
|
|
|
default:
|
|
|
|
return NULL;
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2011-04-04 03:23:12 -07:00
|
|
|
static void *
|
|
|
|
eng_gl_proc_address_get(void *data __UNUSED__, const char *name)
|
|
|
|
{
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
|
|
|
if (glsym_eglGetProcAddress) return glsym_eglGetProcAddress(name);
|
|
|
|
return dlsym(RTLD_DEFAULT, name);
|
|
|
|
#else
|
|
|
|
if (glsym_glXGetProcAddress) return glsym_glXGetProcAddress(name);
|
|
|
|
return dlsym(RTLD_DEFAULT, name);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2011-06-17 00:47:28 -07:00
|
|
|
static int
|
2011-04-04 03:23:12 -07:00
|
|
|
eng_gl_native_surface_get(void *data, void *surface, void *native_surface)
|
|
|
|
{
|
|
|
|
Render_Engine *re;
|
|
|
|
Render_Engine_GL_Surface *sfc;
|
|
|
|
Evas_Native_Surface *ns;
|
|
|
|
|
|
|
|
re = (Render_Engine *)data;
|
|
|
|
sfc = (Render_Engine_GL_Surface*)surface;
|
|
|
|
ns = (Evas_Native_Surface*)native_surface;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-04-04 03:23:12 -07:00
|
|
|
ns->type = EVAS_NATIVE_SURFACE_OPENGL;
|
|
|
|
ns->version = EVAS_NATIVE_SURFACE_VERSION;
|
|
|
|
ns->data.opengl.texture_id = sfc->rt_tex;
|
|
|
|
ns->data.opengl.x = 0;
|
|
|
|
ns->data.opengl.y = 0;
|
|
|
|
ns->data.opengl.w = sfc->w;
|
|
|
|
ns->data.opengl.h = sfc->h;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-04-04 03:23:12 -07:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
|
|
|
|
static const GLubyte *
|
|
|
|
evgl_glGetString(GLenum name)
|
|
|
|
{
|
|
|
|
if (name == GL_EXTENSIONS)
|
|
|
|
return (GLubyte *)_gl_ext_string; //glGetString(GL_EXTENSIONS);
|
|
|
|
else
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
return glsym_glGetString(name);
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
}
|
|
|
|
|
2011-05-01 19:14:00 -07:00
|
|
|
static void
|
|
|
|
evgl_glBindFramebuffer(GLenum target, GLuint framebuffer)
|
|
|
|
{
|
2011-08-24 23:30:52 -07:00
|
|
|
Render_Engine_GL_Context *ctx = current_evgl_ctx;
|
|
|
|
|
|
|
|
// Take care of BindFramebuffer 0 issue
|
|
|
|
if (framebuffer==0)
|
|
|
|
{
|
|
|
|
if (ctx)
|
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glBindFramebuffer(target, ctx->context_fbo);
|
2011-08-24 23:30:52 -07:00
|
|
|
ctx->current_fbo = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glBindFramebuffer(target, framebuffer);
|
2011-08-24 23:30:52 -07:00
|
|
|
|
|
|
|
// Save this for restore when doing make current
|
|
|
|
if (ctx)
|
|
|
|
ctx->current_fbo = framebuffer;
|
|
|
|
}
|
2011-05-01 19:14:00 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
evgl_glBindRenderbuffer(GLenum target, GLuint renderbuffer)
|
|
|
|
{
|
|
|
|
// Add logic to take care when renderbuffer=0
|
2011-08-24 23:30:52 -07:00
|
|
|
// On a second thought we don't need this
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glBindRenderbuffer(target, renderbuffer);
|
2011-05-01 19:14:00 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
evgl_glClearDepthf(GLclampf depth)
|
|
|
|
{
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glClearDepthf(depth);
|
2011-05-01 19:14:00 -07:00
|
|
|
#else
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glClearDepthf(depth);
|
2011-05-01 19:14:00 -07:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
evgl_glDepthRangef(GLclampf zNear, GLclampf zFar)
|
|
|
|
{
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glDepthRangef(zNear, zFar);
|
2011-05-01 19:14:00 -07:00
|
|
|
#else
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glDepthRangef(zNear, zFar);
|
2011-05-01 19:14:00 -07:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
evgl_glGetShaderPrecisionFormat(GLenum shadertype, GLenum precisiontype, GLint* range, GLint* precision)
|
|
|
|
{
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glGetShaderPrecisionFormat(shadertype, precisiontype, range, precision);
|
2011-05-01 19:14:00 -07:00
|
|
|
#else
|
|
|
|
if (range)
|
|
|
|
{
|
|
|
|
range[0] = -126; // floor(log2(FLT_MIN))
|
|
|
|
range[1] = 127; // floor(log2(FLT_MAX))
|
|
|
|
}
|
|
|
|
if (precision)
|
|
|
|
{
|
|
|
|
precision[0] = 24; // floor(-log2((1.0/16777218.0)));
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
shadertype = precisiontype = 0;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
evgl_glReleaseShaderCompiler(void)
|
|
|
|
{
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glReleaseShaderCompiler();
|
2011-05-01 19:14:00 -07:00
|
|
|
#else
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
evgl_glShaderBinary(GLsizei n, const GLuint* shaders, GLenum binaryformat, const void* binary, GLsizei length)
|
|
|
|
{
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_glShaderBinary(n, shaders, binaryformat, binary, length);
|
2011-05-01 19:14:00 -07:00
|
|
|
#else
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// FIXME: need to dlsym/getprocaddress for this
|
2011-05-01 19:14:00 -07:00
|
|
|
return;
|
|
|
|
n = binaryformat = length = 0;
|
|
|
|
shaders = binary = 0;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
//--------------------------------//
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
|
|
|
// EGL Extensions
|
|
|
|
static void *
|
|
|
|
evgl_evasglCreateImage(int target, void* buffer, int *attrib_list)
|
|
|
|
{
|
|
|
|
if (current_engine)
|
|
|
|
{
|
|
|
|
return glsym_eglCreateImage(current_engine->win->egl_disp,
|
|
|
|
EGL_NO_CONTEXT,
|
|
|
|
target,
|
|
|
|
buffer,
|
|
|
|
attrib_list);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
ERR("Invalid Engine... (Can't acccess EGL Display)\n");
|
|
|
|
}
|
|
|
|
|
2011-11-10 00:59:09 -08:00
|
|
|
static void
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
evgl_evasglDestroyImage(EvasGLImage image)
|
|
|
|
{
|
|
|
|
if (current_engine)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
glsym_eglDestroyImage(current_engine->win->egl_disp, image);
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
else
|
|
|
|
ERR("Invalid Engine... (Can't acccess EGL Display)\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
evgl_glEvasGLImageTargetTexture2DOES(GLenum target, EvasGLImage image)
|
|
|
|
{
|
|
|
|
glsym_glEGLImageTargetTexture2DOES(target, image);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
evgl_glEvasGLImageTargetRenderbufferStorageOES(GLenum target, EvasGLImage image)
|
|
|
|
{
|
|
|
|
glsym_glEGLImageTargetTexture2DOES(target, image);
|
|
|
|
}
|
|
|
|
#else
|
2011-06-17 00:47:28 -07:00
|
|
|
#endif
|
2011-05-01 19:14:00 -07:00
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
//--------------------------------//
|
|
|
|
|
|
|
|
|
2011-05-01 19:14:00 -07:00
|
|
|
static void *
|
|
|
|
eng_gl_api_get(void *data)
|
|
|
|
{
|
|
|
|
Render_Engine *re;
|
|
|
|
|
|
|
|
re = (Render_Engine *)data;
|
|
|
|
|
|
|
|
gl_funcs.version = EVAS_GL_API_VERSION;
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
#define ORD(f) EVAS_API_OVERRIDE(f, &gl_funcs, glsym_)
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
// GLES 2.0
|
2011-05-01 19:14:00 -07:00
|
|
|
ORD(glActiveTexture);
|
|
|
|
ORD(glAttachShader);
|
|
|
|
ORD(glBindAttribLocation);
|
|
|
|
ORD(glBindBuffer);
|
|
|
|
ORD(glBindTexture);
|
|
|
|
ORD(glBlendColor);
|
|
|
|
ORD(glBlendEquation);
|
|
|
|
ORD(glBlendEquationSeparate);
|
|
|
|
ORD(glBlendFunc);
|
|
|
|
ORD(glBlendFuncSeparate);
|
|
|
|
ORD(glBufferData);
|
|
|
|
ORD(glBufferSubData);
|
|
|
|
ORD(glCheckFramebufferStatus);
|
|
|
|
ORD(glClear);
|
|
|
|
ORD(glClearColor);
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// ORD(glClearDepthf);
|
2011-05-01 19:14:00 -07:00
|
|
|
ORD(glClearStencil);
|
|
|
|
ORD(glColorMask);
|
|
|
|
ORD(glCompileShader);
|
|
|
|
ORD(glCompressedTexImage2D);
|
|
|
|
ORD(glCompressedTexSubImage2D);
|
|
|
|
ORD(glCopyTexImage2D);
|
|
|
|
ORD(glCopyTexSubImage2D);
|
|
|
|
ORD(glCreateProgram);
|
|
|
|
ORD(glCreateShader);
|
|
|
|
ORD(glCullFace);
|
|
|
|
ORD(glDeleteBuffers);
|
|
|
|
ORD(glDeleteFramebuffers);
|
|
|
|
ORD(glDeleteProgram);
|
|
|
|
ORD(glDeleteRenderbuffers);
|
|
|
|
ORD(glDeleteShader);
|
|
|
|
ORD(glDeleteTextures);
|
|
|
|
ORD(glDepthFunc);
|
|
|
|
ORD(glDepthMask);
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// ORD(glDepthRangef);
|
2011-05-01 19:14:00 -07:00
|
|
|
ORD(glDetachShader);
|
|
|
|
ORD(glDisable);
|
|
|
|
ORD(glDisableVertexAttribArray);
|
|
|
|
ORD(glDrawArrays);
|
|
|
|
ORD(glDrawElements);
|
|
|
|
ORD(glEnable);
|
|
|
|
ORD(glEnableVertexAttribArray);
|
|
|
|
ORD(glFinish);
|
|
|
|
ORD(glFlush);
|
|
|
|
ORD(glFramebufferRenderbuffer);
|
|
|
|
ORD(glFramebufferTexture2D);
|
|
|
|
ORD(glFrontFace);
|
|
|
|
ORD(glGenBuffers);
|
|
|
|
ORD(glGenerateMipmap);
|
|
|
|
ORD(glGenFramebuffers);
|
|
|
|
ORD(glGenRenderbuffers);
|
|
|
|
ORD(glGenTextures);
|
|
|
|
ORD(glGetActiveAttrib);
|
|
|
|
ORD(glGetActiveUniform);
|
|
|
|
ORD(glGetAttachedShaders);
|
|
|
|
ORD(glGetAttribLocation);
|
|
|
|
ORD(glGetBooleanv);
|
|
|
|
ORD(glGetBufferParameteriv);
|
|
|
|
ORD(glGetError);
|
|
|
|
ORD(glGetFloatv);
|
|
|
|
ORD(glGetFramebufferAttachmentParameteriv);
|
|
|
|
ORD(glGetIntegerv);
|
|
|
|
ORD(glGetProgramiv);
|
|
|
|
ORD(glGetProgramInfoLog);
|
|
|
|
ORD(glGetRenderbufferParameteriv);
|
|
|
|
ORD(glGetShaderiv);
|
|
|
|
ORD(glGetShaderInfoLog);
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// ORD(glGetShaderPrecisionFormat);
|
2011-05-01 19:14:00 -07:00
|
|
|
ORD(glGetShaderSource);
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// ORD(glGetString);
|
2011-05-01 19:14:00 -07:00
|
|
|
ORD(glGetTexParameterfv);
|
|
|
|
ORD(glGetTexParameteriv);
|
|
|
|
ORD(glGetUniformfv);
|
|
|
|
ORD(glGetUniformiv);
|
|
|
|
ORD(glGetUniformLocation);
|
|
|
|
ORD(glGetVertexAttribfv);
|
|
|
|
ORD(glGetVertexAttribiv);
|
|
|
|
ORD(glGetVertexAttribPointerv);
|
|
|
|
ORD(glHint);
|
|
|
|
ORD(glIsBuffer);
|
|
|
|
ORD(glIsEnabled);
|
|
|
|
ORD(glIsFramebuffer);
|
|
|
|
ORD(glIsProgram);
|
|
|
|
ORD(glIsRenderbuffer);
|
|
|
|
ORD(glIsShader);
|
|
|
|
ORD(glIsTexture);
|
|
|
|
ORD(glLineWidth);
|
|
|
|
ORD(glLinkProgram);
|
|
|
|
ORD(glPixelStorei);
|
|
|
|
ORD(glPolygonOffset);
|
|
|
|
ORD(glReadPixels);
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// ORD(glReleaseShaderCompiler);
|
2011-05-01 19:14:00 -07:00
|
|
|
ORD(glRenderbufferStorage);
|
|
|
|
ORD(glSampleCoverage);
|
|
|
|
ORD(glScissor);
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// ORD(glShaderBinary);
|
2011-05-01 19:14:00 -07:00
|
|
|
ORD(glShaderSource);
|
|
|
|
ORD(glStencilFunc);
|
|
|
|
ORD(glStencilFuncSeparate);
|
|
|
|
ORD(glStencilMask);
|
|
|
|
ORD(glStencilMaskSeparate);
|
|
|
|
ORD(glStencilOp);
|
|
|
|
ORD(glStencilOpSeparate);
|
|
|
|
ORD(glTexImage2D);
|
|
|
|
ORD(glTexParameterf);
|
|
|
|
ORD(glTexParameterfv);
|
|
|
|
ORD(glTexParameteri);
|
|
|
|
ORD(glTexParameteriv);
|
|
|
|
ORD(glTexSubImage2D);
|
|
|
|
ORD(glUniform1f);
|
|
|
|
ORD(glUniform1fv);
|
|
|
|
ORD(glUniform1i);
|
|
|
|
ORD(glUniform1iv);
|
|
|
|
ORD(glUniform2f);
|
|
|
|
ORD(glUniform2fv);
|
|
|
|
ORD(glUniform2i);
|
|
|
|
ORD(glUniform2iv);
|
|
|
|
ORD(glUniform3f);
|
|
|
|
ORD(glUniform3fv);
|
|
|
|
ORD(glUniform3i);
|
|
|
|
ORD(glUniform3iv);
|
|
|
|
ORD(glUniform4f);
|
|
|
|
ORD(glUniform4fv);
|
|
|
|
ORD(glUniform4i);
|
|
|
|
ORD(glUniform4iv);
|
|
|
|
ORD(glUniformMatrix2fv);
|
|
|
|
ORD(glUniformMatrix3fv);
|
|
|
|
ORD(glUniformMatrix4fv);
|
|
|
|
ORD(glUseProgram);
|
|
|
|
ORD(glValidateProgram);
|
|
|
|
ORD(glVertexAttrib1f);
|
|
|
|
ORD(glVertexAttrib1fv);
|
|
|
|
ORD(glVertexAttrib2f);
|
|
|
|
ORD(glVertexAttrib2fv);
|
|
|
|
ORD(glVertexAttrib3f);
|
|
|
|
ORD(glVertexAttrib3fv);
|
|
|
|
ORD(glVertexAttrib4f);
|
|
|
|
ORD(glVertexAttrib4fv);
|
|
|
|
ORD(glVertexAttribPointer);
|
|
|
|
ORD(glViewport);
|
|
|
|
#undef ORD
|
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
#define ORD(f) EVAS_API_OVERRIDE(f, &gl_funcs, glsym_)
|
|
|
|
// Extensions
|
2011-11-10 00:59:09 -08:00
|
|
|
ORD(glGetProgramBinaryOES);
|
|
|
|
ORD(glProgramBinaryOES);
|
|
|
|
ORD(glMapBufferOES);
|
|
|
|
ORD(glUnmapBufferOES);
|
|
|
|
ORD(glGetBufferPointervOES);
|
|
|
|
ORD(glTexImage3DOES);
|
|
|
|
ORD(glTexSubImage3DOES);
|
|
|
|
ORD(glCopyTexSubImage3DOES);
|
|
|
|
ORD(glCompressedTexImage3DOES);
|
|
|
|
ORD(glCompressedTexSubImage3DOES);
|
|
|
|
ORD(glFramebufferTexture3DOES);
|
|
|
|
ORD(glGetPerfMonitorGroupsAMD);
|
|
|
|
ORD(glGetPerfMonitorCountersAMD);
|
|
|
|
ORD(glGetPerfMonitorGroupStringAMD);
|
|
|
|
ORD(glGetPerfMonitorCounterStringAMD);
|
|
|
|
ORD(glGetPerfMonitorCounterInfoAMD);
|
|
|
|
ORD(glGenPerfMonitorsAMD);
|
|
|
|
ORD(glDeletePerfMonitorsAMD);
|
|
|
|
ORD(glSelectPerfMonitorCountersAMD);
|
|
|
|
ORD(glBeginPerfMonitorAMD);
|
|
|
|
ORD(glEndPerfMonitorAMD);
|
|
|
|
ORD(glGetPerfMonitorCounterDataAMD);
|
|
|
|
ORD(glDiscardFramebufferEXT);
|
|
|
|
ORD(glMultiDrawArraysEXT);
|
|
|
|
ORD(glMultiDrawElementsEXT);
|
|
|
|
ORD(glDeleteFencesNV);
|
|
|
|
ORD(glGenFencesNV);
|
|
|
|
ORD(glIsFenceNV);
|
|
|
|
ORD(glTestFenceNV);
|
|
|
|
ORD(glGetFenceivNV);
|
|
|
|
ORD(glFinishFenceNV);
|
|
|
|
ORD(glSetFenceNV);
|
|
|
|
ORD(glGetDriverControlsQCOM);
|
|
|
|
ORD(glGetDriverControlStringQCOM);
|
|
|
|
ORD(glEnableDriverControlQCOM);
|
|
|
|
ORD(glDisableDriverControlQCOM);
|
|
|
|
ORD(glExtGetTexturesQCOM);
|
|
|
|
ORD(glExtGetBuffersQCOM);
|
|
|
|
ORD(glExtGetRenderbuffersQCOM);
|
|
|
|
ORD(glExtGetFramebuffersQCOM);
|
|
|
|
ORD(glExtGetTexLevelParameterivQCOM);
|
|
|
|
ORD(glExtTexObjectStateOverrideiQCOM);
|
|
|
|
ORD(glExtGetTexSubImageQCOM);
|
|
|
|
ORD(glExtGetBufferPointervQCOM);
|
|
|
|
ORD(glExtGetShadersQCOM);
|
|
|
|
ORD(glExtGetProgramsQCOM);
|
|
|
|
ORD(glExtIsProgramBinaryQCOM);
|
|
|
|
ORD(glExtGetProgramBinarySourceQCOM);
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
#undef ORD
|
|
|
|
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
// Override functions wrapped by Evas_GL
|
2011-05-01 19:14:00 -07:00
|
|
|
#define ORD(f) EVAS_API_OVERRIDE(f, &gl_funcs, evgl_)
|
2011-06-17 00:47:28 -07:00
|
|
|
ORD(glBindFramebuffer);
|
|
|
|
ORD(glBindRenderbuffer);
|
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
// GLES2.0 API compat on top of desktop gl
|
2011-05-01 19:14:00 -07:00
|
|
|
ORD(glClearDepthf);
|
|
|
|
ORD(glDepthRangef);
|
|
|
|
ORD(glGetShaderPrecisionFormat);
|
|
|
|
ORD(glReleaseShaderCompiler);
|
|
|
|
ORD(glShaderBinary);
|
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
ORD(glGetString);
|
|
|
|
|
|
|
|
#if defined (GLES_VARIETY_S3C6410) || defined (GLES_VARIETY_SGX)
|
|
|
|
// GLES 2.0 Extensions that needs wrapping
|
|
|
|
ORD(evasglCreateImage);
|
|
|
|
ORD(evasglDestroyImage);
|
|
|
|
ORD(glEvasGLImageTargetTexture2DOES);
|
|
|
|
ORD(glEvasGLImageTargetRenderbufferStorageOES);
|
2011-06-17 00:47:28 -07:00
|
|
|
#endif
|
2011-05-01 19:14:00 -07:00
|
|
|
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
#undef ORD
|
|
|
|
|
2011-05-01 19:14:00 -07:00
|
|
|
return &gl_funcs;
|
|
|
|
}
|
|
|
|
|
2011-05-19 04:19:22 -07:00
|
|
|
static int
|
|
|
|
eng_image_load_error_get(void *data __UNUSED__, void *image)
|
|
|
|
{
|
|
|
|
Evas_GL_Image *im;
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-05-19 04:19:22 -07:00
|
|
|
if (!image) return EVAS_LOAD_ERROR_NONE;
|
|
|
|
im = image;
|
|
|
|
return im->im->cache_entry.load_error;
|
|
|
|
}
|
2011-05-01 19:14:00 -07:00
|
|
|
|
2011-08-10 23:04:08 -07:00
|
|
|
static Eina_Bool
|
|
|
|
eng_image_animated_get(void *data __UNUSED__, void *image)
|
|
|
|
{
|
2011-10-18 02:10:26 -07:00
|
|
|
Evas_GL_Image *gim = image;
|
2011-08-10 23:04:08 -07:00
|
|
|
Image_Entry *im;
|
|
|
|
|
2011-10-18 02:10:26 -07:00
|
|
|
if (!gim) return EINA_FALSE;
|
|
|
|
im = (Image_Entry *)gim->im;
|
|
|
|
if (!im) return EINA_FALSE;
|
|
|
|
|
2011-08-10 23:04:08 -07:00
|
|
|
return im->flags.animated;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
eng_image_animated_frame_count_get(void *data __UNUSED__, void *image)
|
|
|
|
{
|
2011-10-18 02:10:26 -07:00
|
|
|
Evas_GL_Image *gim = image;
|
2011-08-10 23:04:08 -07:00
|
|
|
Image_Entry *im;
|
|
|
|
|
2011-10-18 02:10:26 -07:00
|
|
|
if (!gim) return -1;
|
|
|
|
im = (Image_Entry *)gim->im;
|
|
|
|
if (!im) return -1;
|
|
|
|
|
2011-08-10 23:04:08 -07:00
|
|
|
if (!im->flags.animated) return -1;
|
|
|
|
return im->frame_count;
|
|
|
|
}
|
|
|
|
|
|
|
|
static Evas_Image_Animated_Loop_Hint
|
|
|
|
eng_image_animated_loop_type_get(void *data __UNUSED__, void *image)
|
|
|
|
{
|
2011-10-18 02:10:26 -07:00
|
|
|
Evas_GL_Image *gim = image;
|
2011-08-10 23:04:08 -07:00
|
|
|
Image_Entry *im;
|
|
|
|
|
2011-10-18 02:10:26 -07:00
|
|
|
if (!gim) return EVAS_IMAGE_ANIMATED_HINT_NONE;
|
|
|
|
im = (Image_Entry *)gim->im;
|
|
|
|
if (!im) return EVAS_IMAGE_ANIMATED_HINT_NONE;
|
|
|
|
|
2011-08-10 23:04:08 -07:00
|
|
|
if (!im->flags.animated) return EVAS_IMAGE_ANIMATED_HINT_NONE;
|
|
|
|
return im->loop_hint;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
eng_image_animated_loop_count_get(void *data __UNUSED__, void *image)
|
|
|
|
{
|
2011-10-18 02:10:26 -07:00
|
|
|
Evas_GL_Image *gim = image;
|
2011-08-10 23:04:08 -07:00
|
|
|
Image_Entry *im;
|
|
|
|
|
2011-10-18 02:10:26 -07:00
|
|
|
if (!gim) return -1;
|
|
|
|
im = (Image_Entry *)gim->im;
|
|
|
|
if (!im) return -1;
|
|
|
|
|
2011-08-10 23:04:08 -07:00
|
|
|
if (!im->flags.animated) return -1;
|
|
|
|
return im->loop_count;
|
|
|
|
}
|
|
|
|
|
|
|
|
static double
|
|
|
|
eng_image_animated_frame_duration_get(void *data __UNUSED__, void *image, int start_frame, int frame_num)
|
|
|
|
{
|
2011-10-18 02:10:26 -07:00
|
|
|
Evas_GL_Image *gim = image;
|
2011-08-10 23:04:08 -07:00
|
|
|
Image_Entry *im;
|
|
|
|
|
2011-10-18 02:10:26 -07:00
|
|
|
if (!gim) return -1;
|
|
|
|
im = (Image_Entry *)gim->im;
|
|
|
|
if (!im) return -1;
|
|
|
|
|
2011-08-10 23:04:08 -07:00
|
|
|
if (!im->flags.animated) return -1;
|
|
|
|
return evas_common_load_rgba_image_frame_duration_from_file(im, start_frame, frame_num);
|
|
|
|
}
|
|
|
|
|
|
|
|
static Eina_Bool
|
|
|
|
eng_image_animated_frame_set(void *data __UNUSED__, void *image, int frame_index)
|
|
|
|
{
|
2011-10-18 02:10:26 -07:00
|
|
|
Evas_GL_Image *gim = image;
|
2011-08-10 23:04:08 -07:00
|
|
|
Image_Entry *im;
|
|
|
|
|
2011-10-18 02:10:26 -07:00
|
|
|
if (!gim) return EINA_FALSE;
|
|
|
|
im = (Image_Entry *)gim->im;
|
|
|
|
if (!im) return EINA_FALSE;
|
|
|
|
|
2011-08-10 23:04:08 -07:00
|
|
|
if (!im->flags.animated) return EINA_FALSE;
|
|
|
|
if (im->cur_frame == frame_index) return EINA_FALSE;
|
|
|
|
|
|
|
|
im->cur_frame = frame_index;
|
|
|
|
return EINA_TRUE;
|
|
|
|
}
|
|
|
|
|
2011-12-13 08:58:20 -08:00
|
|
|
static Eina_Bool
|
|
|
|
eng_image_can_region_get(void *data__UNUSED__, void *image)
|
|
|
|
{
|
|
|
|
Evas_GL_Image *gim = image;
|
|
|
|
Image_Entry *im;
|
|
|
|
if (!gim) return EINA_FALSE;
|
|
|
|
im = (Image_Entry *)gim->im;
|
|
|
|
if (!im) return EINA_FALSE;
|
|
|
|
return ((Evas_Image_Load_Func*) im->info.loader)->do_region;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-10-21 01:17:14 -07:00
|
|
|
static void
|
|
|
|
eng_image_max_size_get(void *data, int *maxw, int *maxh)
|
|
|
|
{
|
|
|
|
Render_Engine *re = (Render_Engine *)data;
|
|
|
|
if (maxw) *maxw = re->win->gl_context->shared->info.max_texture_size;
|
|
|
|
if (maxh) *maxh = re->win->gl_context->shared->info.max_texture_size;
|
|
|
|
}
|
|
|
|
|
2009-06-16 06:01:36 -07:00
|
|
|
static int
|
2006-09-06 00:28:46 -07:00
|
|
|
module_open(Evas_Module *em)
|
2006-01-14 04:13:38 -08:00
|
|
|
{
|
2010-04-29 08:32:47 -07:00
|
|
|
static Eina_Bool xrm_inited = EINA_FALSE;
|
|
|
|
if (!xrm_inited)
|
|
|
|
{
|
2011-11-10 00:59:09 -08:00
|
|
|
xrm_inited = EINA_TRUE;
|
|
|
|
XrmInitialize();
|
2010-04-29 08:32:47 -07:00
|
|
|
}
|
|
|
|
|
2006-01-14 04:13:38 -08:00
|
|
|
if (!em) return 0;
|
2010-10-07 16:46:42 -07:00
|
|
|
if (!evas_gl_common_module_open()) return 0;
|
2006-12-09 00:52:08 -08:00
|
|
|
/* get whatever engine module we inherit from */
|
|
|
|
if (!_evas_module_engine_inherit(&pfunc, "software_generic")) return 0;
|
2009-11-13 00:28:47 -08:00
|
|
|
if (_evas_engine_GL_X11_log_dom < 0)
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
_evas_engine_GL_X11_log_dom = eina_log_domain_register
|
|
|
|
("evas-gl_x11", EVAS_DEFAULT_LOG_COLOR);
|
2009-11-13 00:28:47 -08:00
|
|
|
if (_evas_engine_GL_X11_log_dom < 0)
|
2009-10-22 08:22:22 -07:00
|
|
|
{
|
2010-10-07 16:46:42 -07:00
|
|
|
EINA_LOG_ERR("Can not create a module log domain.");
|
2009-11-13 00:28:47 -08:00
|
|
|
return 0;
|
2009-10-22 08:22:22 -07:00
|
|
|
}
|
2006-12-09 00:52:08 -08:00
|
|
|
/* store it for later use */
|
|
|
|
func = pfunc;
|
|
|
|
/* now to override methods */
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
#define ORD(f) EVAS_API_OVERRIDE(f, &func, eng_)
|
2006-12-09 00:52:08 -08:00
|
|
|
ORD(info);
|
|
|
|
ORD(info_free);
|
|
|
|
ORD(setup);
|
2009-08-14 10:11:08 -07:00
|
|
|
ORD(canvas_alpha_get);
|
2006-12-09 00:52:08 -08:00
|
|
|
ORD(output_free);
|
|
|
|
ORD(output_resize);
|
|
|
|
ORD(output_tile_size_set);
|
|
|
|
ORD(output_redraws_rect_add);
|
|
|
|
ORD(output_redraws_rect_del);
|
|
|
|
ORD(output_redraws_clear);
|
|
|
|
ORD(output_redraws_next_update_get);
|
|
|
|
ORD(output_redraws_next_update_push);
|
|
|
|
ORD(context_cutout_add);
|
|
|
|
ORD(context_cutout_clear);
|
|
|
|
ORD(output_flush);
|
2007-06-16 19:56:59 -07:00
|
|
|
ORD(output_idle_flush);
|
2010-04-12 01:23:53 -07:00
|
|
|
ORD(output_dump);
|
2006-12-09 00:52:08 -08:00
|
|
|
ORD(rectangle_draw);
|
|
|
|
ORD(line_draw);
|
|
|
|
ORD(polygon_point_add);
|
|
|
|
ORD(polygon_points_clear);
|
|
|
|
ORD(polygon_draw);
|
2008-08-25 22:45:04 -07:00
|
|
|
|
2006-12-09 00:52:08 -08:00
|
|
|
ORD(image_load);
|
|
|
|
ORD(image_new_from_data);
|
|
|
|
ORD(image_new_from_copied_data);
|
|
|
|
ORD(image_free);
|
|
|
|
ORD(image_size_get);
|
|
|
|
ORD(image_size_set);
|
|
|
|
ORD(image_dirty_region);
|
|
|
|
ORD(image_data_get);
|
|
|
|
ORD(image_data_put);
|
2008-09-16 07:52:57 -07:00
|
|
|
ORD(image_data_preload_request);
|
|
|
|
ORD(image_data_preload_cancel);
|
2006-12-09 00:52:08 -08:00
|
|
|
ORD(image_alpha_set);
|
|
|
|
ORD(image_alpha_get);
|
2008-11-04 01:19:35 -08:00
|
|
|
ORD(image_border_set);
|
|
|
|
ORD(image_border_get);
|
2006-12-09 00:52:08 -08:00
|
|
|
ORD(image_draw);
|
|
|
|
ORD(image_comment_get);
|
|
|
|
ORD(image_format_get);
|
|
|
|
ORD(image_colorspace_set);
|
|
|
|
ORD(image_colorspace_get);
|
2011-04-05 22:38:38 -07:00
|
|
|
ORD(image_mask_create);
|
2006-12-09 00:52:08 -08:00
|
|
|
ORD(image_native_set);
|
|
|
|
ORD(image_native_get);
|
2011-06-02 03:40:43 -07:00
|
|
|
#if 0 // filtering disabled
|
2011-04-18 22:47:56 -07:00
|
|
|
ORD(image_draw_filtered);
|
|
|
|
ORD(image_filtered_get);
|
|
|
|
ORD(image_filtered_save);
|
|
|
|
ORD(image_filtered_free);
|
2011-06-02 03:40:43 -07:00
|
|
|
#endif
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2006-12-09 00:52:08 -08:00
|
|
|
ORD(font_draw);
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2009-05-07 06:29:56 -07:00
|
|
|
ORD(image_scale_hint_set);
|
|
|
|
ORD(image_scale_hint_get);
|
2010-08-18 20:30:47 -07:00
|
|
|
ORD(image_stride_get);
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-02-06 15:52:17 -08:00
|
|
|
ORD(image_map_draw);
|
2009-11-06 03:32:23 -08:00
|
|
|
ORD(image_map_surface_new);
|
|
|
|
ORD(image_map_surface_free);
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2010-08-11 23:11:13 -07:00
|
|
|
ORD(image_content_hint_set);
|
|
|
|
ORD(image_content_hint_get);
|
2011-02-08 03:41:38 -08:00
|
|
|
|
|
|
|
ORD(image_cache_flush);
|
|
|
|
ORD(image_cache_set);
|
|
|
|
ORD(image_cache_get);
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
ORD(gl_surface_create);
|
|
|
|
ORD(gl_surface_destroy);
|
|
|
|
ORD(gl_context_create);
|
|
|
|
ORD(gl_context_destroy);
|
|
|
|
ORD(gl_make_current);
|
From: "Sung W. Park" <sungwoo@gmail.com>
Subject: Re: [E-devel] [E-Devel][Review][Patch] Evas GL Extensions + a
bug fix
Here's an initial attempt at the GL extensions issue for Evas GL.
I have been in discussion with a few EFL developers regarding how we should
provide extensions. Essentially, there are two ways to go about doing this.
1. provide evas_gl_proc_address_get() function as it is done in other
glue layers
2. provide all the extension functions in the EVAS_GL_API struct.
#1 approach is how it's done in other glue layers and the driver implementor can
provide new extensions easily. It is however pretty annoying to get the
function prototypes right and use the function pointers and etc.
#2 approach provides all the extension functions in the struct so it's
definitely easier to use. Adding new extensions can be a pain as people may
have to wait for new version releases.
For now, we thought it was OK to just throw them in the struct as in
#2 and try it out. So, I've implemented this approach. As for the extensions,
I've basically included all the extensions in gl2ext.h as EvasGL currently
provides all the GLES 2.0 functions. In order to display the right
information, I had to override glGetString() with GL_EXTENSIONS as parameter to properly
display the supported extensions.
Also, I've added a few EGL extensions that have been
modified for EvasGL use. For example, eglCreateImage/eglDestroyImage has been
defined as folllows.
EvasGLImage (*evasglCreateImage) (int target, void* buffer, int*
attrib_list); void
(*evasglDestroyImage)
(EvasGLImage image);
const char *evas_gl_string_query() function was added to return a string of
supported EvasGL extensions. So essentially, a user can search this string to see
if the desired extension is supported. if it is, he can use the functions. He can
always check if the function pointers are NULL as well.
Take a look at the pach and let me know what you think.
______________
While I was adding the extension code, I've added a few fixes/ changes
to the EvasGL.
1. glDeletBuffers bug
- When I wad destroying evasgl context, I was deleting the context FBO with
glDeleteBuffers instead of glDeleteFramebuffers. This code in effect was
deleting BOs in other contexts and we had some funky behaviors as a
result. The
bug has been fixed.
2. make_current
- I've made some changes to the make current code and also added a resource
context to the engine data. the resource context is used for creating surface
texture/ fbos when surface/ context is created. Before, i was using evas'
context but thought it'd be a good idea to use a separate context.
SVN revision: 64139
2011-10-18 01:13:23 -07:00
|
|
|
ORD(gl_string_query);
|
2011-04-04 03:23:12 -07:00
|
|
|
ORD(gl_proc_address_get);
|
|
|
|
ORD(gl_native_surface_get);
|
2011-05-01 19:14:00 -07:00
|
|
|
ORD(gl_api_get);
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-05-19 04:19:22 -07:00
|
|
|
ORD(image_load_error_get);
|
2011-06-17 00:47:28 -07:00
|
|
|
|
2011-08-10 23:04:08 -07:00
|
|
|
/* now advertise out own api */
|
|
|
|
ORD(image_animated_get);
|
|
|
|
ORD(image_animated_frame_count_get);
|
|
|
|
ORD(image_animated_loop_type_get);
|
|
|
|
ORD(image_animated_loop_count_get);
|
|
|
|
ORD(image_animated_frame_duration_get);
|
|
|
|
ORD(image_animated_frame_set);
|
|
|
|
|
2011-10-21 01:17:14 -07:00
|
|
|
ORD(image_max_size_get);
|
2011-11-10 00:59:09 -08:00
|
|
|
|
2006-12-09 00:52:08 -08:00
|
|
|
/* now advertise out own api */
|
|
|
|
em->functions = (void *)(&func);
|
2006-01-14 04:13:38 -08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2009-06-16 06:01:36 -07:00
|
|
|
static void
|
cleanup: fix some "unused" errors from -Wextra.
As we're heading for a release we better remove as much errors as
possible and as the first step I'm removing warnings due unused
parameters, variables and functions. These tend to pollute real errors
spotted by -Wall and clang/llvm.
This does not fixes all, just the clear that could be set to
__UNUSED__, particularly to do (and I'd like some help from the
authors):
* src/lib/engines/common/evas_font_{draw,query}.c (tasn):
intl_props is just used while doing BIDI, but also used in other
#ifdef blocks :-/
* evas_map_* (raster):
huge amount of warnings, code is quite confusing and thus I'm not
touching it. I have no idea whenever the commented blocks or extra
parameters are intended to be used or no.
* src/modules/engines/fbevas_fb_main.c (raster?):
is fb_setvt() to be used? If not do you mind removing it?
* src/modules/engines/gl_{common,x11} (raster):
huge amount of warnings, code is quite nested and full of #ifdefs
that does not help to give a clear picture of what's going on.
* src/bin/evas_cserve_main.c (raster):
I could have ignored most of the errors, but is the code correct? I
mean, there is no unload of images being applied. If you confirm
none of those warnings are harmful I can flag them as unused.
* src/lib/engines/common_8 (dottedmag):
lots of unused functions that were acquired from common_16, they
are unused and if they will not, then they should be removed.
SVN revision: 52421
2010-09-18 12:17:41 -07:00
|
|
|
module_close(Evas_Module *em __UNUSED__)
|
2006-01-14 04:13:38 -08:00
|
|
|
{
|
2009-10-22 08:22:22 -07:00
|
|
|
eina_log_domain_unregister(_evas_engine_GL_X11_log_dom);
|
2011-10-25 05:01:44 -07:00
|
|
|
/*
|
2010-04-29 08:32:47 -07:00
|
|
|
if (xrdb_user.db)
|
|
|
|
{
|
|
|
|
XrmDestroyDatabase(xrdb_user.db);
|
|
|
|
xrdb_user.last_stat = 0;
|
|
|
|
xrdb_user.last_mtime = 0;
|
|
|
|
xrdb_user.db = NULL;
|
|
|
|
}
|
2011-10-25 05:01:44 -07:00
|
|
|
*/
|
2010-10-07 16:46:42 -07:00
|
|
|
evas_gl_common_module_close();
|
2006-01-14 04:13:38 -08:00
|
|
|
}
|
|
|
|
|
2009-06-16 06:01:36 -07:00
|
|
|
static Evas_Module_Api evas_modapi =
|
2006-01-14 04:13:38 -08:00
|
|
|
{
|
|
|
|
EVAS_MODULE_API_VERSION,
|
2009-06-16 06:01:36 -07:00
|
|
|
"gl_x11",
|
|
|
|
"none",
|
|
|
|
{
|
I'm attaching a patch for the initial version of the GL Fastpath
addition to evas gl backend.
Working on different mobile devices, we've noticed that the cost of context
switch (MakeCurrent) in GL can be very expensive depending on the driver
implementation. To minimize the poorly written driver's context switch
overhead, I've implemented a state tracking layer on top of the driver
implemented GL.
Essentially, this layer wraps all the GL/Glue(GLX/EGL) APIs and manages its own
state changes. Internally, only one real GL context is created and logical
contexts are created every time a user requests context creation. The logical
contexts keep track of its states and sets only the necessary states
(the ones that are different than the current ones)
when there is a MakeCurrent request. The real MakeCurrent gets called when
there is a Surface/Window change request.
The GL library is dlopened and all the APIs are dlsym'ed and wrapped
accordingly. All the GL functions are in evas_gl_core.{h,c}.
Here's a very simply flow of the code.
- all the APIs are exported as function pointers (*glsym_glBegin),
(*glsm_eglCreatContext), and etc.
- all the native GL/Glue(GLX/EGL) APIs are dlsym'ed as _sym_glBegin,
_sym_eglCreateContext, and etc.
- all the fastpath APIs are implmemnted as fpgl_glBegin,
fpgl_eglCreateContext, and etc.
- if faspath is seletected, the exported APIs are set accordingly
ie. glsym_glBegin = fpgl_glBegin;
- default mode is the regular gl symbols are directly set.
ie. glsym_glBegin = _sym_glBegin;
I have an Environment variable where you can set it to three different Modes
EVAS_GL_FASTPATH = 0 // Default mode. Regular GL symbols are directly loaded
EVAS_GL_FASTPATH = 1 // Fastpath mode. Takes the path described above.
EVAS_GL_FASTPATH = 2 // Wrapped mode. All the regular GL functions are
wrapped once. This can be used for various
purposes
Since all the GL symbols are now loaded in this library, I took out all
the gl symbol loading parts in the evas gl backend as you'll see in the patch.
The changes to the engine and the backend itself is pretty minor.
There are still some known issues to hammer out but I thought we're at a good
place for an initial version so that my source doesn't diverge too much.
Known Issues and To Do's
* Current GL Fastpath version doesn't support multiple threads. Instead of
having one global real context, I would need to do it for each thread. I'll
get on this soon.
* Issues running Evas GL on certain conditions. When running the elementary
test (with gl engine), if you run ELMGLview test that runs in ON_DEMAND mode,
everything works fine. BUT, when you run the ELMGLView test in ALWAYS
mode, the subsequent elm tests shows blank screen. When you destroy the
GLView window, everything else comes on fine.
* Resource protection code. This actually applies to Evas GL code in general
as well. Since all the resources are shared among all the contexts that get
created, I would like to eventually have a resource protecting mechanism that
prevents access to resources outside of its context unless specifically
specified.
I'm attaching three files
- evas_gl_core.h, evas_gl_core.c, fastpath.patch
To get the code running...
- copy evas_gl_core.{c,h} to src/modules/engine/gl_common/
- apply the fastpath.patch
- compile/install evas
- to run with fastpath GL (ie. % EVAS_GL_FASTPATH=1 ./evasgl_sample1)
SVN revision: 65891
2011-12-05 00:54:14 -08:00
|
|
|
module_open,
|
|
|
|
module_close
|
2009-06-16 06:01:36 -07:00
|
|
|
}
|
2006-01-14 04:13:38 -08:00
|
|
|
};
|
2009-06-16 06:01:36 -07:00
|
|
|
|
|
|
|
EVAS_MODULE_DEFINE(EVAS_MODULE_TYPE_ENGINE, engine, gl_x11);
|
|
|
|
|
2011-07-08 18:47:01 -07:00
|
|
|
#ifndef EVAS_STATIC_BUILD_GL_XLIB
|
2009-06-16 06:01:36 -07:00
|
|
|
EVAS_EINA_MODULE_DEFINE(engine, gl_x11);
|
|
|
|
#endif
|
2011-04-04 03:23:12 -07:00
|
|
|
|
|
|
|
/* vim:set ts=8 sw=3 sts=3 expandtab cino=>5n-2f0^-2{2(0W1st0 :*/
|