Re: pyopengl extension detection.
"Mike C. Fletcher" <[email protected]> Tue, 19 Nov 2013 21:36:40 -0500
| Newsgroups | gmane.comp.python.opengl.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============7424634006380568775==
Content-Type: multipart/alternative;
boundary="------------040800030308060306000102"
This is a multi-part message in MIME format.
--------------040800030308060306000102
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
> <[email protected] <mailto:[email protected]>> 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
--------------040800030308060306000102
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 11/08/2013 09:13 AM, Roman Valov
wrote:<br>
</div>
<blockquote
cite="mid:CAELN+SS6CitxxQf0-crx0Ea-h9mppR8YSgAPvSZtSUzwLxQXxQ@mail.gmail.com"
type="cite">
<div dir="ltr">Hello, Mike.</div>
</blockquote>
<br>
Hi Roman,<br>
<br>
I'm afraid I've rather hacked up your patch as I made it fit into
the xml generation branch. The biggest changes made:<br>
<ul>
<li>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)</li>
<li>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</li>
<li>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]</li>
<li>I tried to provide a fallback for glXGetCurrentDisplay()
(basically using raw X11)</li>
<li>I added an EGL version</li>
<li>I started on a WGL version of the plugin, but I haven't
actually booted into Windows to work on it<br>
</li>
</ul>
<p>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).<br>
</p>
<blockquote
cite="mid:CAELN+SS6CitxxQf0-crx0Ea-h9mppR8YSgAPvSZtSUzwLxQXxQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>In addition, I've removed one of calls to 'checkExtension'
in 'constructFunction' method,</div>
<div>because it seems redundant for me. Fix me, if I wrong.</div>
</div>
</blockquote>
<br>
You were correct, there was an extraneous call in there.<br>
<br>
Thanks, and enjoy,<br>
Mike<br>
<br>
<blockquote
cite="mid:CAELN+SS6CitxxQf0-crx0Ea-h9mppR8YSgAPvSZtSUzwLxQXxQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Nov 4, 2013 at 8:46 PM, Mike
C. Fletcher <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:[email protected]" target="_blank">[email protected]</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb">
<div class="h5">On 11/02/2013 10:11 AM, Roman Valov
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Ok, Mike.. the actual question to you is in last
paragraph.<br>
<br>
<br>
Here is update with my review of the problem with
wglSwapIntervalEXT and wglGetSwapIntervalEXT.<br>
Seems that problem is driven by two diffrent
factors:<br>
<br>
1) Wrapper code generator (gengl.py) doesn't set
'extension' parameter for 'createBaseFunction'.<br>
<br>
Thus OpenGL/platform/baseplatform.py code tries to
load extension functions from platform.GL library<br>
which actually doesn't have them in common case and
as a result I've got these functions unresolved.<br>
<br>
2) BasePlatform.checkExtension code relies only on
glGetString(GL_EXTENSIONS).<br>
<br>
I've tested extension WGL_EXT_swap_control on NV and
Intel gpu platforms. In fact only<br>
on NV platform this extension was listed in
glGetString(GL_EXTENSIONS) result. According<br>
to specs:<br>
<br>
<a moz-do-not-send="true"
href="http://www.opengl.org/registry/specs/EXT/wgl_extensions_string.txt"
target="_blank">http://www.opengl.org/registry/specs/EXT/wgl_extensions_string.txt</a><br>
<a moz-do-not-send="true"
href="http://www.opengl.org/registry/specs/ARB/wgl_extensions_string.txt"
target="_blank">http://www.opengl.org/registry/specs/ARB/wgl_extensions_string.txt</a><br>
<a moz-do-not-send="true"
href="http://www.opengl.org/wiki/Load_OpenGL_Functions#Platform-specific_Extensions"
target="_blank">http://www.opengl.org/wiki/Load_OpenGL_Functions#Platform-specific_Extensions</a><br>
<br>
one would to use wglGetExtensionsStringXXX to check
for WGL extensions. On both platforms I've used<br>
required extension was listed in
wglGetGetExtensionsString output. As I see on GLX
there is similar<br>
functionality provided by glXQueryExtensionsString.
Which also aren't taken into account in PyOpenGL.<br>
<br>
<br>
<br>
So, my plan is firstly to fix gengl.py and later add
method for platform-specific extensions check.<br>
But now I'm stuck with gengl.py doesn't produce the
same _WGL_NV.py that is commited to bzr.<br>
Besides header file path in comments (which is minor
issue), I see whitespaces differences and<br>
moreover, in myself-generated _WGL_NV.py there are
no 'GLAPI' symbol. Could you say anything<br>
about that symbol? Was it added by hand or was it
included in previous versions of wglext.h?<br>
</blockquote>
<br>
<br>
</div>
</div>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Hope that helps,<br>
Mike<br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
<a class="moz-txt-link-freetext" href="http://www.vrplumber.com">http://www.vrplumber.com</a>
<a class="moz-txt-link-freetext" href="http://blog.vrplumber.com">http://blog.vrplumber.com</a>
</pre>
</body>
</html>
--------------040800030308060306000102--
--===============7424634006380568775==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
--===============7424634006380568775==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net
_______________________________________________
PyOpenGL-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyopengl-devel
--===============7424634006380568775==--