Re: [E-devel] [E-Devel][Review][Patch] Evas GL Fastpath
On Fri, 25 Nov 2011 17:06:12 +0900 Sung W. Park sung...@gmail.com said:
ok - took a look. i can put this in. but it needs some more work. the gl
engines still link to lib gl (-lGL, -lGLESv2, -lEGL ...). AND they dlopen too.
kind of unnecessary. in fact once the linking is removed
(evas_check_engine.m4), they shouldnt actually check for libgl anymore to work
- they should always compile (if x11 or sdl dependencies are met) anyway. as
they have no compile-time gl dependencies.
the other issue is we still have a gles vs gl flavor define. we want to remove
that now and have it checked at runtime - try load efl and glesv2 - if that
fails fall back to libGL... or vice-versa. :)
Hi Carsten,
As we've discussed on IRC/offline, the issue was the location of libGL.so.
Anyway, I've modified the code to check the libGL.so.1 first and then check
for
libGL.so.
I'm attaching the patch and the files again.
The instructions are same as before.
Let me know if you have questions
cheers,
Sung
On Tue, Nov 8, 2011 at 12:01 PM, Carsten Haitzler ras...@rasterman.comwrote:
On Tue, 8 Nov 2011 11:06:14 +0900 Sung W. Park sung...@gmail.com said:
Hi Carsten,
That's really weird. I've tested elementary_test before I submitted the
patch.
I'm wondering if there were changes that I made that would require
elementary recompile... i can't think of one at the moment.
Just curious, are you using evas with NEWGL enabled? If that's the
case, it
explains the breakage. My understanding was that NEWGL was broken and it
wasn't turned on by default so I didn't bother with it for now.
nup. NEWGL off. :( yes it's broken - even though it SHOULD work... theres
some
odd things around there but it's off here. :) and this was just running
elementary_test - didnt even just evas_gl... so basic stuff didnt work :(
I'll try to track down the issue.
cheers,
Sung
On Sun, Nov 6, 2011 at 2:48 PM, Carsten Haitzler ras...@rasterman.com
wrote:
On Wed, 26 Oct 2011 14:08:47 +0900 Sung W. Park sung...@gmail.com
said:
Hi all,
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.
this is.. unfortunately... important :(
Re: [E-devel] [E-Devel][Review][Patch] Evas GL Fastpath
Hi Carsten,
That's really weird. I've tested elementary_test before I submitted the
patch.
I'm wondering if there were changes that I made that would require
elementary recompile... i can't think of one at the moment.
Just curious, are you using evas with NEWGL enabled? If that's the case, it
explains the breakage. My understanding was that NEWGL was broken and it
wasn't turned on by default so I didn't bother with it for now.
I'll try to track down the issue.
cheers,
Sung
On Sun, Nov 6, 2011 at 2:48 PM, Carsten Haitzler ras...@rasterman.comwrote:
On Wed, 26 Oct 2011 14:08:47 +0900 Sung W. Park sung...@gmail.com
said:
Hi all,
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.
this is.. unfortunately... important :( not currently, but in future it
will be.
* 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.
smells of a context tracking bug to me.
* 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.
how do you know which context a resource belongs to? eg a texture. afre you
going to forbid 2 ctx's to set the same texture id as src texture for ops?
sounds silly.
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)
Let me know if you have questions or comments.
big problem. it breaks the gl engine as-is:
2:46PM ~ ELM_ENGINE=gl elementary_test
Initializing OpenGL APIs...
API OPT: 0 Default API path enabled...
ERR16397:evas-gl_x11 evas_x_main.c:802 eng_best_visual_get()
glsym_glXChooseFBConfig returned no configs ERR16397:evas-gl_x11
evas_x_main.c:802 eng_best_visual_get() glsym_glXChooseFBConfig returned no
configs
Re: [E-devel] [E-Devel][Review][Patch] Evas GL Fastpath
On Tue, 8 Nov 2011 11:06:14 +0900 Sung W. Park sung...@gmail.com said:
Hi Carsten,
That's really weird. I've tested elementary_test before I submitted the
patch.
I'm wondering if there were changes that I made that would require
elementary recompile... i can't think of one at the moment.
Just curious, are you using evas with NEWGL enabled? If that's the case, it
explains the breakage. My understanding was that NEWGL was broken and it
wasn't turned on by default so I didn't bother with it for now.
nup. NEWGL off. :( yes it's broken - even though it SHOULD work... theres some
odd things around there but it's off here. :) and this was just running
elementary_test - didnt even just evas_gl... so basic stuff didnt work :(
I'll try to track down the issue.
cheers,
Sung
On Sun, Nov 6, 2011 at 2:48 PM, Carsten Haitzler ras...@rasterman.comwrote:
On Wed, 26 Oct 2011 14:08:47 +0900 Sung W. Park sung...@gmail.com
said:
Hi all,
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.
this is.. unfortunately... important :( not currently, but in future it
will be.
* 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.
smells of a context tracking bug to me.
* 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.
how do you know which context a resource belongs to? eg a texture. afre you
going to forbid 2 ctx's to set the same texture id as src texture for ops?
sounds silly.
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)
Let me
Re: [E-devel] [E-Devel][Review][Patch] Evas GL Fastpath
On Wed, 26 Oct 2011 14:08:47 +0900 Sung W. Park sung...@gmail.com said:
Hi all,
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.
this is.. unfortunately... important :( not currently, but in future it will be.
* 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.
smells of a context tracking bug to me.
* 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.
how do you know which context a resource belongs to? eg a texture. afre you
going to forbid 2 ctx's to set the same texture id as src texture for ops?
sounds silly.
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)
Let me know if you have questions or comments.
big problem. it breaks the gl engine as-is:
2:46PM ~ ELM_ENGINE=gl elementary_test
Initializing OpenGL APIs...
API OPT: 0 Default API path enabled...
ERR16397:evas-gl_x11 evas_x_main.c:802 eng_best_visual_get()
glsym_glXChooseFBConfig returned no configs ERR16397:evas-gl_x11
evas_x_main.c:802 eng_best_visual_get() glsym_glXChooseFBConfig returned no
configs ERR16397:evas-gl_x11 evas_x_main.c:802 eng_best_visual_get()
glsym_glXChooseFBConfig returned no configs ERR16397:ecore_evas
ecore_evas_x.c:176 _ecore_evas_x_gl_window_new() evas_engine_info_set() for
engine 'opengl_x11' failed. ERR16397:ecore_evas ecore_evas_x.c:3197
ecore_evas_gl_x11_options_new() evas_engine_info_set() init engine 'opengl_x11'
failed. CRI16397:elementary elm_win.c:1461 elm_win_add() OpenGL engine
creation failed. Trying default.
:(
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
