From: Sylvain <be...@be...> - 2012-04-23 22:04:23
|
Hi, I've read some of the SDL2 source code today, and I found that it doesn't link with any OpenGL library, but detect and load it at run time, using dlopen/LoadLibrary. This means that *GetProcAddress is dynamically loaded through libGL.so.1/opengl32.dll, and then all internal OpenGL calls are like: rdata->glDrawArrays(...) rdata->glGetError(...) with rdata being populated with *GetProcAddress on startup. (Constants like GL_POINT are static though) This is similar to the GL2 loading we've recently implemented in fg_gl2.c, but more comprehensive because it also deals with *GetProcAddress. (Btw it already works this way in SDL1.) One interesting feature is that SDL2 can load GLESv1 or GLESv2 at run time, without the needed for triple compilation (glut/glut-gles1/glut-gles2). I guess that Apple does it that way to make both GLES1 and GLES2 available on application startup in EAGL. I'm contemplating implementing this technique in FreeGLUT, and replace all glXxx() calls accordindly. What do you think? -- Sylvain |
From: John F. F. <joh...@cy...> - 2012-04-24 03:31:03
|
Sylvain, My first question is, will this work with a decade-and-a-half-old C compiler? - John On 4/23/2012 5:04 PM, Sylvain wrote: > Hi, > > I've read some of the SDL2 source code today, and I found that it > doesn't link with any OpenGL library, but detect and load it at run > time, using dlopen/LoadLibrary. > > This means that *GetProcAddress is dynamically loaded through > libGL.so.1/opengl32.dll, and then all internal OpenGL calls are like: > > rdata->glDrawArrays(...) > rdata->glGetError(...) > > with rdata being populated with *GetProcAddress on startup. > (Constants like GL_POINT are static though) > > This is similar to the GL2 loading we've recently implemented in > fg_gl2.c, but more comprehensive because it also deals with > *GetProcAddress. > (Btw it already works this way in SDL1.) > > > One interesting feature is that SDL2 can load GLESv1 or GLESv2 at run > time, without the needed for triple compilation (glut/glut-gles1/glut-gles2). > I guess that Apple does it that way to make both GLES1 and GLES2 > available on application startup in EAGL. > > > I'm contemplating implementing this technique in FreeGLUT, and replace > all glXxx() calls accordindly. > > What do you think? > > |
From: Sylvain <be...@be...> - 2012-04-24 07:08:44
|
Hi John, I believe this works in VC++6 ;) For Win32 that'd be LoadLibrary and GetProcAddress calls AFAICS. We'd also need to provide a way to specify what kind of OpenGL the user wants to load. Btw, I just saw that some drivers currently cannot be included together in SDL: http://hg.libsdl.org/SDL/file/601b0e251822/src/video/x11/SDL_x11video.c#l217 There you can have GLX or MesaEGL, but not both :/ That sounds like an implementation choice rather than a technical limitation though. I'm not 100% sure about that idea, but at the same time I'm not satisfied with the multiple builds required to support OGL, GLES1 and GLES2 separately. - Sylvain On Mon, Apr 23, 2012 at 10:30:49PM -0500, John F. Fay wrote: > Sylvain, > > My first question is, will this work with a decade-and-a-half-old C > compiler? > > - John > > > On 4/23/2012 5:04 PM, Sylvain wrote: > > Hi, > > > > I've read some of the SDL2 source code today, and I found that it > > doesn't link with any OpenGL library, but detect and load it at run > > time, using dlopen/LoadLibrary. > > > > This means that *GetProcAddress is dynamically loaded through > > libGL.so.1/opengl32.dll, and then all internal OpenGL calls are like: > > > > rdata->glDrawArrays(...) > > rdata->glGetError(...) > > > > with rdata being populated with *GetProcAddress on startup. > > (Constants like GL_POINT are static though) > > > > This is similar to the GL2 loading we've recently implemented in > > fg_gl2.c, but more comprehensive because it also deals with > > *GetProcAddress. > > (Btw it already works this way in SDL1.) > > > > > > One interesting feature is that SDL2 can load GLESv1 or GLESv2 at run > > time, without the needed for triple compilation (glut/glut-gles1/glut-gles2). > > I guess that Apple does it that way to make both GLES1 and GLES2 > > available on application startup in EAGL. > > > > > > I'm contemplating implementing this technique in FreeGLUT, and replace > > all glXxx() calls accordindly. > > > > What do you think? |
From: Diederick C. N. <dc...@gm...> - 2012-04-24 08:52:00
|
Hi Syvain, On Tue, Apr 24, 2012 at 15:08, Sylvain <be...@be...> wrote: > I'm not 100% sure about that idea, but at the same time I'm not > satisfied with the multiple builds required to support OGL, GLES1 and > GLES2 separately. This is only an issue for X11 (where you can have all three) and the various mobile platforms, where you can have one of the latter two. The flexibility would be great. but i think this would boil down to how much impact the code changes will have, is it just a few isolated code files or would this be a system-wide overhaul? Best, Dee |
From: John F. F. <joh...@cy...> - 2012-04-24 11:57:29
|
(grin) The code snippet looked very C++-like. Will it work in MSVC 6 as a C-language file rather than a C++-language file? - John On 4/24/2012 2:08 AM, Sylvain wrote: > Hi John, > > I believe this works in VC++6 ;) > For Win32 that'd be LoadLibrary and GetProcAddress calls AFAICS. > > We'd also need to provide a way to specify what kind of OpenGL the > user wants to load. > > Btw, I just saw that some drivers currently cannot be included together in SDL: > http://hg.libsdl.org/SDL/file/601b0e251822/src/video/x11/SDL_x11video.c#l217 > There you can have GLX or MesaEGL, but not both :/ > That sounds like an implementation choice rather than a technical > limitation though. > > I'm not 100% sure about that idea, but at the same time I'm not > satisfied with the multiple builds required to support OGL, GLES1 and > GLES2 separately. > > - Sylvain > > On Mon, Apr 23, 2012 at 10:30:49PM -0500, John F. Fay wrote: > >> Sylvain, >> >> My first question is, will this work with a decade-and-a-half-old C >> compiler? >> >> - John >> >> >> On 4/23/2012 5:04 PM, Sylvain wrote: >> >>> Hi, >>> >>> I've read some of the SDL2 source code today, and I found that it >>> doesn't link with any OpenGL library, but detect and load it at run >>> time, using dlopen/LoadLibrary. >>> >>> This means that *GetProcAddress is dynamically loaded through >>> libGL.so.1/opengl32.dll, and then all internal OpenGL calls are like: >>> >>> rdata->glDrawArrays(...) >>> rdata->glGetError(...) >>> >>> with rdata being populated with *GetProcAddress on startup. >>> (Constants like GL_POINT are static though) >>> >>> This is similar to the GL2 loading we've recently implemented in >>> fg_gl2.c, but more comprehensive because it also deals with >>> *GetProcAddress. >>> (Btw it already works this way in SDL1.) >>> >>> >>> One interesting feature is that SDL2 can load GLESv1 or GLESv2 at run >>> time, without the needed for triple compilation (glut/glut-gles1/glut-gles2). >>> I guess that Apple does it that way to make both GLES1 and GLES2 >>> available on application startup in EAGL. >>> >>> >>> I'm contemplating implementing this technique in FreeGLUT, and replace >>> all glXxx() calls accordindly. >>> >>> What do you think? >>> > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > |
From: John T. <nu...@me...> - 2012-04-25 00:59:37
|
On Tue, Apr 24, 2012 at 06:57:12AM -0500, John F. Fay wrote: > (grin) The code snippet looked very C++-like. Will it work in MSVC 6 > as a C-language file rather than a C++-language file? It looks like C to me :) struct somestruct { int (*foo)(void); } mystruct; int bar(void) { return 42; } mystruct->foo = bar; int x = mystruct->foo(); -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: John F. F. <joh...@cy...> - 2012-04-24 11:58:11
|
(Actually, if you'll send me a sample file off the reflector I can try it out.) - John On 4/24/2012 6:57 AM, John F. Fay wrote: > (grin) The code snippet looked very C++-like. Will it work in MSVC 6 > as a C-language file rather than a C++-language file? > > - John > > > On 4/24/2012 2:08 AM, Sylvain wrote: >> Hi John, >> >> I believe this works in VC++6 ;) >> For Win32 that'd be LoadLibrary and GetProcAddress calls AFAICS. >> >> We'd also need to provide a way to specify what kind of OpenGL the >> user wants to load. >> >> Btw, I just saw that some drivers currently cannot be included >> together in SDL: >> http://hg.libsdl.org/SDL/file/601b0e251822/src/video/x11/SDL_x11video.c#l217 >> >> There you can have GLX or MesaEGL, but not both :/ >> That sounds like an implementation choice rather than a technical >> limitation though. >> >> I'm not 100% sure about that idea, but at the same time I'm not >> satisfied with the multiple builds required to support OGL, GLES1 and >> GLES2 separately. >> >> - Sylvain >> >> On Mon, Apr 23, 2012 at 10:30:49PM -0500, John F. Fay wrote: >>> Sylvain, >>> >>> My first question is, will this work with a >>> decade-and-a-half-old C >>> compiler? >>> >>> - John >>> >>> >>> On 4/23/2012 5:04 PM, Sylvain wrote: >>>> Hi, >>>> >>>> I've read some of the SDL2 source code today, and I found that it >>>> doesn't link with any OpenGL library, but detect and load it at run >>>> time, using dlopen/LoadLibrary. >>>> >>>> This means that *GetProcAddress is dynamically loaded through >>>> libGL.so.1/opengl32.dll, and then all internal OpenGL calls are like: >>>> >>>> rdata->glDrawArrays(...) >>>> rdata->glGetError(...) >>>> >>>> with rdata being populated with *GetProcAddress on startup. >>>> (Constants like GL_POINT are static though) >>>> >>>> This is similar to the GL2 loading we've recently implemented in >>>> fg_gl2.c, but more comprehensive because it also deals with >>>> *GetProcAddress. >>>> (Btw it already works this way in SDL1.) >>>> >>>> >>>> One interesting feature is that SDL2 can load GLESv1 or GLESv2 at run >>>> time, without the needed for triple compilation >>>> (glut/glut-gles1/glut-gles2). >>>> I guess that Apple does it that way to make both GLES1 and GLES2 >>>> available on application startup in EAGL. >>>> >>>> >>>> I'm contemplating implementing this technique in FreeGLUT, and replace >>>> all glXxx() calls accordindly. >>>> >>>> What do you think? >> ------------------------------------------------------------------------------ >> >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. >> Discussions >> will include endpoint security, mobile security and the latest in >> malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Freeglut-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> |
From: Sylvain <be...@be...> - 2012-04-24 13:04:02
|
Hi John, The sample is a C structure that stores pointers to the various GL functions. (It could be independent fields just as well.) Here's how it's done in SDL2 (which is written in C): http://hg.libsdl.org/SDL/file/601b0e251822/src/render/opengles2/SDL_render_gles2.c#l183 http://hg.libsdl.org/SDL/file/601b0e251822/src/render/opengles2/SDL_gles2funcs.h http://hg.libsdl.org/SDL/file/601b0e251822/src/video/x11/SDL_x11opengles.c Cheers! Sylvain On Tue, Apr 24, 2012 at 06:57:54AM -0500, John F. Fay wrote: > (Actually, if you'll send me a sample file off the reflector I can try > it out.) > > - John > > > On 4/24/2012 6:57 AM, John F. Fay wrote: > > (grin) The code snippet looked very C++-like. Will it work in MSVC 6 > > as a C-language file rather than a C++-language file? > > > > - John > > > > > > On 4/24/2012 2:08 AM, Sylvain wrote: > >> Hi John, > >> > >> I believe this works in VC++6 ;) > >> For Win32 that'd be LoadLibrary and GetProcAddress calls AFAICS. > >> > >> We'd also need to provide a way to specify what kind of OpenGL the > >> user wants to load. > >> > >> Btw, I just saw that some drivers currently cannot be included > >> together in SDL: > >> http://hg.libsdl.org/SDL/file/601b0e251822/src/video/x11/SDL_x11video.c#l217 > >> > >> There you can have GLX or MesaEGL, but not both :/ > >> That sounds like an implementation choice rather than a technical > >> limitation though. > >> > >> I'm not 100% sure about that idea, but at the same time I'm not > >> satisfied with the multiple builds required to support OGL, GLES1 and > >> GLES2 separately. > >> > >> - Sylvain > >> > >> On Mon, Apr 23, 2012 at 10:30:49PM -0500, John F. Fay wrote: > >>> Sylvain, > >>> > >>> My first question is, will this work with a > >>> decade-and-a-half-old C > >>> compiler? > >>> > >>> - John > >>> > >>> > >>> On 4/23/2012 5:04 PM, Sylvain wrote: > >>>> Hi, > >>>> > >>>> I've read some of the SDL2 source code today, and I found that it > >>>> doesn't link with any OpenGL library, but detect and load it at run > >>>> time, using dlopen/LoadLibrary. > >>>> > >>>> This means that *GetProcAddress is dynamically loaded through > >>>> libGL.so.1/opengl32.dll, and then all internal OpenGL calls are like: > >>>> > >>>> rdata->glDrawArrays(...) > >>>> rdata->glGetError(...) > >>>> > >>>> with rdata being populated with *GetProcAddress on startup. > >>>> (Constants like GL_POINT are static though) > >>>> > >>>> This is similar to the GL2 loading we've recently implemented in > >>>> fg_gl2.c, but more comprehensive because it also deals with > >>>> *GetProcAddress. > >>>> (Btw it already works this way in SDL1.) > >>>> > >>>> > >>>> One interesting feature is that SDL2 can load GLESv1 or GLESv2 at run > >>>> time, without the needed for triple compilation > >>>> (glut/glut-gles1/glut-gles2). > >>>> I guess that Apple does it that way to make both GLES1 and GLES2 > >>>> available on application startup in EAGL. > >>>> > >>>> > >>>> I'm contemplating implementing this technique in FreeGLUT, and replace > >>>> all glXxx() calls accordindly. > >>>> > >>>> What do you think? > >> ------------------------------------------------------------------------------ > >> > >> Live Security Virtual Conference > >> Exclusive live event will cover all the ways today's security and > >> threat landscape has changed and how IT managers can respond. > >> Discussions > >> will include endpoint security, mobile security and the latest in > >> malware > >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > >> _______________________________________________ > >> Freeglut-developer mailing list > >> Fre...@li... > >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer > >> > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Sylvain <be...@be...> - 2012-04-24 12:42:18
|
On Tue, Apr 24, 2012 at 04:51:49PM +0800, Diederick C. Niehorster wrote: > Hi Syvain, > > On Tue, Apr 24, 2012 at 15:08, Sylvain <be...@be...> wrote: > > I'm not 100% sure about that idea, but at the same time I'm not > > satisfied with the multiple builds required to support OGL, GLES1 and > > GLES2 separately. > > This is only an issue for X11 (where you can have all three) and the > various mobile platforms, where you can have one of the latter two. > The flexibility would be great. I see at: http://www.g-truc.net/post-0457.html that there is work in progress on windows as well. Interestingly the author mentions FreeGLUT, I'll send him a mail to tell about the current GLES support in . > but i think this would boil down to how much impact the code changes > will have, is it just a few isolated code files or would this be a > system-wide overhaul? Probably system-wide, since at least all glXxx calls will be converted to mystruct->glXxx. It may be possibly to statically link GLX/XGL/EGL and only dynamically load GL functions, I'm not sure yet. -- Sylvain |
From: Diederick C. N. <dc...@gm...> - 2012-04-24 13:27:01
|
Hi Sylvain, On Tue, Apr 24, 2012 at 20:42, Sylvain <be...@be...> wrote: > Probably system-wide, since at least all glXxx calls will be converted > to mystruct->glXxx. Thanks for the feedback. But the glxx calls are actually only in a few files, right? geometry, teapot, menu, font... anything else? So the change might not have such a big impact in the end. Yup, it might be good if entry points are checked on demand, and stored in a global struct so it only has to be done once for each function each run. I'd actually say, lets first rewrite the affected code files as is currently done for the gemeometry file by you and me. Once thats done, we can look into dynamic loading (of course side experiments so that by then we know whats best would be great!) Best, Dee |