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 :( 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
> >
> >
--
------------- 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
