Re: [E-devel] [EGIT] [core/efl] master 01/02: gl_drm: Move the gl symbol check to immediately after display init
On Thu, 8 Mar 2018 10:05:30 -0600 Derek Foremansaid: > On 2018-03-07 11:26 PM, Carsten Haitzler (The Rasterman) wrote: > > On Wed, 07 Mar 2018 13:25:27 -0800 Derek Foreman > > 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. h 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 > >> 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 == 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
Re: [E-devel] [EGIT] [core/efl] master 01/02: gl_drm: Move the gl symbol check to immediately after display init
On 2018-03-07 11:26 PM, Carsten Haitzler (The Rasterman) wrote: On Wed, 07 Mar 2018 13:25:27 -0800 Derek Foremansaid: 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. 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 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 == 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
Re: [E-devel] [EGIT] [core/efl] master 01/02: gl_drm: Move the gl symbol check to immediately after display init
On Wed, 07 Mar 2018 13:25:27 -0800 Derek Foremansaid: 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? > derekf pushed a commit to branch master. > > http://git.enlightenment.org/core/efl.git/commit/?id=f8658d25fa604f885ee23b20e94a2892d340bceb > > commit f8658d25fa604f885ee23b20e94a2892d340bceb > Author: Derek Foreman > 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 == 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; > > > -- > > -- - 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