Thread: Re: [PyOpenGL-Devel] pyopengl extension detection.
Brought to you by:
mcfletch
From: Roman V. <red...@gm...> - 2013-11-02 14:12:27
|
Ok, Mike.. the actual question to you is in last paragraph. Here is update with my review of the problem with wglSwapIntervalEXT and wglGetSwapIntervalEXT. Seems that problem is driven by two diffrent factors: 1) Wrapper code generator (gengl.py) doesn't set 'extension' parameter for 'createBaseFunction'. Thus OpenGL/platform/baseplatform.py code tries to load extension functions from platform.GL library which actually doesn't have them in common case and as a result I've got these functions unresolved. 2) BasePlatform.checkExtension code relies only on glGetString(GL_EXTENSIONS). I've tested extension WGL_EXT_swap_control on NV and Intel gpu platforms. In fact only on NV platform this extension was listed in glGetString(GL_EXTENSIONS) result. According to specs: http://www.opengl.org/registry/specs/EXT/wgl_extensions_string.txt http://www.opengl.org/registry/specs/ARB/wgl_extensions_string.txt http://www.opengl.org/wiki/Load_OpenGL_Functions#Platform-specific_Extensions one would to use wglGetExtensionsStringXXX to check for WGL extensions. On both platforms I've used required extension was listed in wglGetGetExtensionsString output. As I see on GLX there is similar functionality provided by glXQueryExtensionsString. Which also aren't taken into account in PyOpenGL. So, my plan is firstly to fix gengl.py and later add method for platform-specific extensions check. But now I'm stuck with gengl.py doesn't produce the same _WGL_NV.py that is commited to bzr. Besides header file path in comments (which is minor issue), I see whitespaces differences and moreover, in myself-generated _WGL_NV.py there are no 'GLAPI' symbol. Could you say anything about that symbol? Was it added by hand or was it included in previous versions of wglext.h? Regards, Roman. |
From: Mike C. F. <mcf...@vr...> - 2013-11-04 17:05:10
|
On 11/02/2013 10:11 AM, Roman Valov wrote: > Ok, Mike.. the actual question to you is in last paragraph. > > > Here is update with my review of the problem with wglSwapIntervalEXT > and wglGetSwapIntervalEXT. > Seems that problem is driven by two diffrent factors: > > 1) Wrapper code generator (gengl.py) doesn't set 'extension' parameter > for 'createBaseFunction'. > > Thus OpenGL/platform/baseplatform.py code tries to load extension > functions from platform.GL library > which actually doesn't have them in common case and as a result I've > got these functions unresolved. > > 2) BasePlatform.checkExtension code relies only on > glGetString(GL_EXTENSIONS). > > I've tested extension WGL_EXT_swap_control on NV and Intel gpu > platforms. In fact only > on NV platform this extension was listed in glGetString(GL_EXTENSIONS) > result. According > to specs: > > http://www.opengl.org/registry/specs/EXT/wgl_extensions_string.txt > http://www.opengl.org/registry/specs/ARB/wgl_extensions_string.txt > http://www.opengl.org/wiki/Load_OpenGL_Functions#Platform-specific_Extensions > > one would to use wglGetExtensionsStringXXX to check for WGL > extensions. On both platforms I've used > required extension was listed in wglGetGetExtensionsString output. As > I see on GLX there is similar > functionality provided by glXQueryExtensionsString. Which also aren't > taken into account in PyOpenGL. > > > > So, my plan is firstly to fix gengl.py and later add method for > platform-specific extensions check. > But now I'm stuck with gengl.py doesn't produce the same _WGL_NV.py > that is commited to bzr. > Besides header file path in comments (which is minor issue), I see > whitespaces differences and > moreover, in myself-generated _WGL_NV.py there are no 'GLAPI' symbol. > Could you say anything > about that symbol? Was it added by hand or was it included in previous > versions of wglext.h? gengl.py was probably last run many years ago now, and the versions of the underlying libraries you're using (basically pyglet) are likely different than the ones I used way back then. GLAPI is basically a macro that marks a function for DLL export, it *shouldn't* affect anything in our wrappers. Note that I'm about 50% of the way through an API generator based on the Khronos XML API spec, i.e. generating the wrappers from the thing that defines these APIs formally (and which is used to generate the headers that gengl and get_gl_extensions are parsing). That *should* generate all of WGL, GLX, EGL, GL, and GLES in full, and should keep them up-to-date going forward in a robust and maintainable fashion. I'll integrate your changes for wglGetExtensionsString and glXQueryExtensionsString when I get to the point of generating the WGL, GLX and EGL wrappers from the specs. The new generators won't actually alter the support code (e.g. platform), so a patch to those *should* carry across. I *wouldn't* suggest spending much time on fixing gengl.py based generation, because it has always proven rather fragile (which is why I don't use it for the core), even if it were working today, I'm unlikely to keep using it if I can use the XML registry to generate the functions. The WGL, GLX and the like extensions will be declared in the same manner as the GL ones, so you'll get the "extension" parameter set properly when regenerated. Hope that helps, Mike |
From: Roman V. <red...@gm...> - 2013-11-08 14:14:22
Attachments:
pyopengl-platform-specific-extensions.r00.diff
|
Hello, Mike. Here is a preview of patch for platform-specific extensions. It supports only GLX platform, since I want to get your review of my design decisions. Once it will be done, I will update the patch with WGL support and put stubs for other platforms. So, each platform implementation should provide 'getExtensionsString' method to list available platform-specific extensions in space-separated string. Both, GLX and WGL ways provide this list in this form. In case of GLX implementation definition of method is surrounded with try-except block, because code tries to import 'glXQueryExtensionsString' and 'glXGetCurrentDisplay' functions from GL-dll and according to spec these functions are defined in version 1.1 and 1.2 of GLX-spec respectively. Thus in case GLX implementation doesn't provide a method for querying extensions, code will define a method returning empty string. Non-extensible and stub platforms should do the same. Next, base platform implementation defines 'hasPlatformExtension' method which acts like 'extensions.hasGLExtension' function except it won't perform logging. I was trying to avoid platform-specific code and circular dependencies with 'OpenGL.platform' in 'OpenGL.extensions' module, thus all code resides in 'OpenGL.platform' sub-package. However, cached 'contextdata' for 'GL_EXTENSIONS' will also be used for platform-specific extensions. Once notable difference between 'hasGLExtension' and 'hasPlatformExtension' is that buffer for extensions list is by default initialized with 'None' to distinguish with '[]' which means no extensions available. In addition, I've removed one of calls to 'checkExtension' in 'constructFunction' method, because it seems redundant for me. Fix me, if I wrong. Best Regards, Roman. On Mon, Nov 4, 2013 at 8:46 PM, Mike C. Fletcher <mcf...@vr...>wrote: > On 11/02/2013 10:11 AM, Roman Valov wrote: > >> Ok, Mike.. the actual question to you is in last paragraph. >> >> >> Here is update with my review of the problem with wglSwapIntervalEXT and >> wglGetSwapIntervalEXT. >> Seems that problem is driven by two diffrent factors: >> >> 1) Wrapper code generator (gengl.py) doesn't set 'extension' parameter >> for 'createBaseFunction'. >> >> Thus OpenGL/platform/baseplatform.py code tries to load extension >> functions from platform.GL library >> which actually doesn't have them in common case and as a result I've got >> these functions unresolved. >> >> 2) BasePlatform.checkExtension code relies only on >> glGetString(GL_EXTENSIONS). >> >> I've tested extension WGL_EXT_swap_control on NV and Intel gpu platforms. >> In fact only >> on NV platform this extension was listed in glGetString(GL_EXTENSIONS) >> result. According >> to specs: >> >> http://www.opengl.org/registry/specs/EXT/wgl_extensions_string.txt >> http://www.opengl.org/registry/specs/ARB/wgl_extensions_string.txt >> http://www.opengl.org/wiki/Load_OpenGL_Functions# >> Platform-specific_Extensions >> >> one would to use wglGetExtensionsStringXXX to check for WGL extensions. >> On both platforms I've used >> required extension was listed in wglGetGetExtensionsString output. As I >> see on GLX there is similar >> functionality provided by glXQueryExtensionsString. Which also aren't >> taken into account in PyOpenGL. >> >> >> >> So, my plan is firstly to fix gengl.py and later add method for >> platform-specific extensions check. >> But now I'm stuck with gengl.py doesn't produce the same _WGL_NV.py that >> is commited to bzr. >> Besides header file path in comments (which is minor issue), I see >> whitespaces differences and >> moreover, in myself-generated _WGL_NV.py there are no 'GLAPI' symbol. >> Could you say anything >> about that symbol? Was it added by hand or was it included in previous >> versions of wglext.h? >> > > > gengl.py was probably last run many years ago now, and the versions of the > underlying libraries you're using (basically pyglet) are likely different > than the ones I used way back then. GLAPI is basically a macro that marks > a function for DLL export, it *shouldn't* affect anything in our wrappers. > > Note that I'm about 50% of the way through an API generator based on the > Khronos XML API spec, i.e. generating the wrappers from the thing that > defines these APIs formally (and which is used to generate the headers that > gengl and get_gl_extensions are parsing). That *should* generate all of > WGL, GLX, EGL, GL, and GLES in full, and should keep them up-to-date going > forward in a robust and maintainable fashion. I'll integrate your changes > for wglGetExtensionsString and glXQueryExtensionsString when I get to the > point of generating the WGL, GLX and EGL wrappers from the specs. The new > generators won't actually alter the support code (e.g. platform), so a > patch to those *should* carry across. > > I *wouldn't* suggest spending much time on fixing gengl.py based > generation, because it has always proven rather fragile (which is why I > don't use it for the core), even if it were working today, I'm unlikely to > keep using it if I can use the XML registry to generate the functions. > > The WGL, GLX and the like extensions will be declared in the same manner > as the GL ones, so you'll get the "extension" parameter set properly when > regenerated. > > Hope that helps, > Mike > > |
From: Mike C. F. <mcf...@vr...> - 2013-11-20 02:36:50
|
On 11/08/2013 09:13 AM, Roman Valov wrote: > Hello, Mike. Hi Roman, I'm afraid I've rather hacked up your patch as I made it fit into the xml generation branch. The biggest changes made: * I made the API-specific version/extension querying use a plug-in mechanism, with each API expected to provide the code in its own namespace (_types.py) * Currently this is *not* properly context/display/screen/HDC specific, but the idea is that each sub-class should be able to specify how to scope the caching * I added the concept of an assumed version for each plugin, so e.g. we assume at least glX [1,1] and gl [1,1] * I tried to provide a fallback for glXGetCurrentDisplay() (basically using raw X11) * I added an EGL version * I started on a WGL version of the plugin, but I haven't actually booted into Windows to work on it That's rather more changes than I was intending, but hopefully it makes the result cleaner (e.g. there's just one entry point to check for any extension being supported now, and all of the APIs use the same basic code for managing their extension/version querying). > In addition, I've removed one of calls to 'checkExtension' in > 'constructFunction' method, > because it seems redundant for me. Fix me, if I wrong. You were correct, there was an extraneous call in there. Thanks, and enjoy, Mike > > On Mon, Nov 4, 2013 at 8:46 PM, Mike C. Fletcher > <mcf...@vr... <mailto:mcf...@vr...>> wrote: > > On 11/02/2013 10:11 AM, Roman Valov wrote: > > Ok, Mike.. the actual question to you is in last paragraph. > > > Here is update with my review of the problem with > wglSwapIntervalEXT and wglGetSwapIntervalEXT. > Seems that problem is driven by two diffrent factors: > > 1) Wrapper code generator (gengl.py) doesn't set 'extension' > parameter for 'createBaseFunction'. > > Thus OpenGL/platform/baseplatform.py code tries to load > extension functions from platform.GL library > which actually doesn't have them in common case and as a > result I've got these functions unresolved. > > 2) BasePlatform.checkExtension code relies only on > glGetString(GL_EXTENSIONS). > > I've tested extension WGL_EXT_swap_control on NV and Intel gpu > platforms. In fact only > on NV platform this extension was listed in > glGetString(GL_EXTENSIONS) result. According > to specs: > > http://www.opengl.org/registry/specs/EXT/wgl_extensions_string.txt > http://www.opengl.org/registry/specs/ARB/wgl_extensions_string.txt > http://www.opengl.org/wiki/Load_OpenGL_Functions#Platform-specific_Extensions > > one would to use wglGetExtensionsStringXXX to check for WGL > extensions. On both platforms I've used > required extension was listed in wglGetGetExtensionsString > output. As I see on GLX there is similar > functionality provided by glXQueryExtensionsString. Which also > aren't taken into account in PyOpenGL. > > > > So, my plan is firstly to fix gengl.py and later add method > for platform-specific extensions check. > But now I'm stuck with gengl.py doesn't produce the same > _WGL_NV.py that is commited to bzr. > Besides header file path in comments (which is minor issue), I > see whitespaces differences and > moreover, in myself-generated _WGL_NV.py there are no 'GLAPI' > symbol. Could you say anything > about that symbol? Was it added by hand or was it included in > previous versions of wglext.h? > > > > gengl.py was probably last run many years ago now, and the > versions of the underlying libraries you're using (basically > pyglet) are likely different than the ones I used way back then. > GLAPI is basically a macro that marks a function for DLL export, > it *shouldn't* affect anything in our wrappers. > > Note that I'm about 50% of the way through an API generator based > on the Khronos XML API spec, i.e. generating the wrappers from the > thing that defines these APIs formally (and which is used to > generate the headers that gengl and get_gl_extensions are > parsing). That *should* generate all of WGL, GLX, EGL, GL, and > GLES in full, and should keep them up-to-date going forward in a > robust and maintainable fashion. I'll integrate your changes for > wglGetExtensionsString and glXQueryExtensionsString when I get to > the point of generating the WGL, GLX and EGL wrappers from the > specs. The new generators won't actually alter the support code > (e.g. platform), so a patch to those *should* carry across. > > I *wouldn't* suggest spending much time on fixing gengl.py based > generation, because it has always proven rather fragile (which is > why I don't use it for the core), even if it were working today, > I'm unlikely to keep using it if I can use the XML registry to > generate the functions. > > The WGL, GLX and the like extensions will be declared in the same > manner as the GL ones, so you'll get the "extension" parameter set > properly when regenerated. > > Hope that helps, > Mike > > -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |