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.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 :( 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...
> ERR<16397>:evas-gl_x11 evas_x_main.c:802 eng_best_visual_get()
> glsym_glXChooseFBConfig returned no configs ERR<16397>:evas-gl_x11
> evas_x_main.c:802 eng_best_visual_get() glsym_glXChooseFBConfig returned no
> configs ERR<16397>:evas-gl_x11 evas_x_main.c:802 eng_best_visual_get()
> glsym_glXChooseFBConfig returned no configs ERR<16397>:ecore_evas
> ecore_evas_x.c:176 _ecore_evas_x_gl_window_new() evas_engine_info_set() for
> engine 'opengl_x11' failed. ERR<16397>:ecore_evas ecore_evas_x.c:3197
> ecore_evas_gl_x11_options_new() evas_engine_info_set() init engine
> 'opengl_x11'
> failed. CRI<16397>: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
>
>
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
