On Thu, 8 Mar 2018 10:05:30 -0600 Derek Foreman <der...@osg.samsung.com> said:
> On 2018-03-07 11:26 PM, Carsten Haitzler (The Rasterman) wrote: > > On Wed, 07 Mar 2018 13:25:27 -0800 Derek Foreman <der...@osg.samsung.com> > > said: > > > > this brings back memories of problems with checking for extension symbols > > before a context is set up. the context may change the symbols (procaddress > > returned functions) as for example the same symbol for gles1.1 might vary > > for 2.0 and then 3.0 ... > > > > i know we've had these issue because that that's why the checks happen after > > context init. > > > > are you sure this is right? > > I think so, but I'm not sure all of this stuff is working as intended. > > As far as I can tell from the spec, we need an initialized display to > query these strings (or NO_DISPLAY to query client extensions, which we > really should be doing too). It's the GL_EXTENSIONS, not EGL that need a > bound context. aaaah it only gets egl stuff. ok. that's probably fine. the gl stuff though does depend on a context... that's what tweaked my interest when i saw the diff.. never mind then. i see in another commit you renamed to make it clear. > It was my commit that split up and moved the gl symbols for this engine > in commit eda81c6dffd84f so I think I was overly zealous there. I think > before that maybe were were using an invalid/no display and getting just > the client strings, which are quite different. (We actually should be > using client strings to determine if we can use eglGetPlatformDisplay) > > I've tested here and I get exactly the same string before and after the > recent change on my intel hardware. Haven't checked all the procaddress > pointers. > > Other compositors do the same thing (weston), so I think it's right this > way. > > What we probably should be doing is: > query egl client extensions > create display (with platform base if it's in client exts) > init display > query egl extensions > create context (perhaps using IMG's priority ext) > makecurrent > query gl extensions > > but I'm having a really hard time understanding the guts of > evas_gl_symbols() as it seems to expect the EGL_EXTENSIONS string to be > passed in (it looks for EGL_KHR_image_base), but it also looks for stuff > like GL_OES_mapbuffer which would be in the gl extension string you > can't get until you have a context bound. > > So am I supposed to call this function twice, once with EGL extensions > and once with GL extensions? or strcat the strings (which means I have > to call after my context is bound?) or ?? > > Thanks, > Derek > > >> derekf pushed a commit to branch master. > >> > >> http://git.enlightenment.org/core/efl.git/commit/?id=f8658d25fa604f885ee23b20e94a2892d340bceb > >> > >> commit f8658d25fa604f885ee23b20e94a2892d340bceb > >> Author: Derek Foreman <der...@osg.samsung.com> > >> Date: Wed Mar 7 13:11:45 2018 -0600 > >> > >> gl_drm: Move the gl symbol check to immediately after display init > >> > >> We don't actually need a context first, just an initialized display. > >> --- > >> src/modules/evas/engines/gl_drm/evas_outbuf.c | 4 ++-- > >> 1 file changed, 2 insertions(+), 2 deletions(-) > >> > >> diff --git a/src/modules/evas/engines/gl_drm/evas_outbuf.c > >> b/src/modules/evas/engines/gl_drm/evas_outbuf.c index > >> aff5de87bf..b1235355cc 100644 > >> --- a/src/modules/evas/engines/gl_drm/evas_outbuf.c > >> +++ b/src/modules/evas/engines/gl_drm/evas_outbuf.c > >> @@ -226,6 +226,8 @@ _evas_outbuf_egl_setup(Outbuf *ob) > >> return EINA_FALSE; > >> } > >> > >> + eng_gl_symbols(ob->egl.disp); > >> + > >> if (!eglGetConfigs(ob->egl.disp, NULL, 0, &ncfg) || (ncfg == 0)) > >> { > >> ERR("eglGetConfigs() fail. code=%#x", eglGetError()); > >> @@ -334,8 +336,6 @@ _evas_outbuf_egl_setup(Outbuf *ob) > >> goto err; > >> } > >> > >> - eng_gl_symbols(ob->egl.disp); > >> - > >> ob->gl_context = glsym_evas_gl_common_context_new(); > >> if (!ob->gl_context) goto err; > >> > >> > >> -- > >> > >> > > > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
