Thread: [PyOpenGL-Users] PyOpenGL Release 3.0.0 (final)
Brought to you by:
mcfletch
Menu
▾
▴
pyopengl-users
|
From: Mike C. F. <mcf...@vr...> - 2009-04-01 21:48:31
|
PyOpenGL is the traditional OpenGL binding for the Python language
(Python 2.x series). This release is the first major release of the
package in more than 4 years. PyOpenGL 3.x is a complete rewrite of the
PyOpenGL project which attempts to retain compatibility with the
original PyOpenGL 2.x API while providing support for many more
data-formats and extensions than were wrapped by the previous
code-base. It attempts to retain the "easy" approachable API of the
original PyOpenGL bindings, focusing more on ease of development (both
for client code and the library itself) than speed.
Build and installation has been dramatically simplified. It is possible
to work directly from a PyOpenGL bzr branch or to merely unpack the
package into your PYTHONPATH. To install from source and/or participate
in development:
bzr branch lp:pyopengl
bzr branch lp:pyopengl-demo
then add the pyopengl/OpenGL directory to your PYTHONPATH. You can also
download the source distributions from:
http://pyopengl.sourceforge.net
and use standard distutils commands to install. PyOpenGL 3.x is already
supported by the PyInstaller "exe" packaging utility, and can be made to
work with Py2exe with inclusion statements.
PyOpenGL may be installed using the easy_install script if desired.
There are no setuptools/package-resources dependencies in PyOpenGL 3.0.0
final. You can install PyOpenGL on supported platforms (currently
Linux, Win32 and OSX) with the following if you have setuptools, PIL and
Numpy installed:
easy_install PyOpenGL
easy_install PyOpenGL-Demo
You can then run the scripts in the PyOpenGL-Demo package.
PyOpenGL 3.x introduces package-level configuration flags which allow
you to modify the behavior of the entire PyOpenGL package, e.g. by
introducing extremely verbose logging, or turning off all error-checking
to improve performance. Of particular note is a flag which allows you
to disable APIs which have been deprecated by the ARB in OpenGL 3.0.
Other flags allow you to control the trade-off between ease-of-use and
performance during the development and release process.
PyOpenGL 3.x provides access to the entire OpenGL 3.0 API, as well as
most extensions which have been entered in the OpenGL extension
registry. Commonly used extensions can have "Pythonic" wrappers written
easily, and many of the commonly used extensions already have simplified
APIs provided. It also provides wrappers for the GLUT, GLE and GLX
libraries. The AGL and WGL modules are not provided with PyOpenGL 3.x,
as most devs are using window-manager-based GL operations.
PyOpenGL 3.x provides a simple plug-in API that allows you to write
data-format or platform plugins. These can be used to easily add
"native" support for your array-friendly data-formats (vector classes
and the like). There is a sample data-format plug-in which wraps the
"Vertex Buffer Objects" extensions (in the OpenGL/arrays/vbo.py module).
PyOpenGL 3.x's documentation has been regenerated and the build process
for the documentation has been updated so that it can be easily
regenerated to include pointers to other Open Source PyOpenGL project's
online code viewers. If you would like to add your project to the list
of referenced projects, please contact the author with details of your
code viewer's url, code license and project name.
Notes in the reference documentation indicates the deprecated entry
points for OpenGL 3.0. If you have a PyOpenGL code-base you should be
looking at reworking the code in order to eliminate the use of "legacy"
APIs before OpenGL 3.1 drivers become mainstream. At minimum you should
be converting away from per-vertex operations and the use of display
lists toward using array-based geometry.
You should expect a performance decline with the use of PyOpenGL 3.x
versus PyOpenGL 2.x! PyOpenGL 3.x will have an accelerator module
released in time to provide better performance, but the development
method (ctypes) is inherently slower than the C (SWIG) method previously
used. If your code is performance critical you should likely use the
accelerator module when it becomes available. Also consider using the
package-level configuration flags to remove "support" functionality as
you near release, use of these flags can provide more than 2x speedup in
most cases.
The 3.0.0 final release has a few bugs fixed from the previous 3.0.0c1
release. Users of the release candidate should upgrade. PyOpenGL 3.0.0
is intended for use with the Python 2.x series, porting to Python 3.x is
not currently on the roadmap. There will likely be a PyOpenGL 3.0.1
release in the near future which will introduce a few more optimizations
and likely will be synchronized with the first public release of the
accelerator modules.
Since the release of PyOpenGL 2.x another common OpenGL binding for
Python has become popular and may be an appropriate choice for your
projects. The Pyglet project (http://www.pyglet.org) has a full OpenGL
binding in "raw" C style, along with many higher-level utilities to aid
in the development of games, all of which can be easily installed on
common platforms.
Enjoy yourselves,
Mike
--
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com
|
|
From: Lorenzo M. <lma...@de...> - 2009-04-02 08:57:00
|
Hello Mike, this really is great news! Congratulations! > You should expect a performance decline with the use of PyOpenGL 3.x > versus PyOpenGL 2.x! PyOpenGL 3.x will have an accelerator module > released in time to provide better performance, but the development > method (ctypes) is inherently slower than the C (SWIG) method previously > used. In the past days I've tried OpenGL_accelerate on some code of mine that suffers an expected 50% performance loss switching from pyopengl 2.x to 3.x, and it already yields a little speedup; since you are speaking in future tense, does this mean that more consistent improvements on OpenGL_accelerate are planned? [[Note: the code I'm talking about is heavily display-lists and other OpenGL legaciness based, so probably it doesn't represent a valid test bench for pyopengl 3.x performance measurements.]] > Also consider using the > package-level configuration flags to remove "support" functionality as > you near release, use of these flags can provide more than 2x speedup in > most cases. Are you talking about OpenGL.FORWARD_COMPATIBLE_ONLY? To do that, the OpenGL code in the application must be legacy-free, correct? > Since the release of PyOpenGL 2.x another common OpenGL binding for > Python has become popular and may be an appropriate choice for your > projects. The Pyglet project (http://www.pyglet.org) has a full OpenGL > binding in "raw" C style, along with many higher-level utilities to aid > in the development of games, all of which can be easily installed on > common platforms. As I wrote in a previous message, such a "raw" C style wrapper is also hidden in PyOpenGL, you just have to import from OpenGL.raw.GL instead of OpenGL.GL, and switch OpenGL.ERROR_CHECKING to False. This can improve performance (I get a 100% speedup with the codebase mentioned above) and bring it to the levels of 2.x, at the cost of some ctypes pollution in the code - raw wrappers of pyopengl and pyglet are almost indistinguishable both performance and code appearance wise. Talking about pyglet, some time ago I happened to read their automatic wrapper generator: I found it nice and easily pluggable in a toy project of mine. Since it uses the same ctypes technology and I remember you praising it yourself in a past presentation of yours, are you planning to merge it into pyopengl3.x to avoid duplicating efforts? Thanks, and keep up the great work! -- Lorenzo Mancini |
|
From: Mike C. F. <mcf...@vr...> - 2009-04-02 15:12:05
|
Lorenzo Mancini wrote:
> Hello Mike, this really is great news! Congratulations!
>
>
>> You should expect a performance decline with the use of PyOpenGL 3.x
>> versus PyOpenGL 2.x! PyOpenGL 3.x will have an accelerator module
>> released in time to provide better performance, but the development
>> method (ctypes) is inherently slower than the C (SWIG) method
>> previously used.
>
> In the past days I've tried OpenGL_accelerate on some code of mine
> that suffers an expected 50% performance loss switching from pyopengl
> 2.x to 3.x, and it already yields a little speedup; since you are
> speaking in future tense, does this mean that more consistent
> improvements on OpenGL_accelerate are planned?
>
> [[Note: the code I'm talking about is heavily display-lists and other
> OpenGL legaciness based, so probably it doesn't represent a valid test
> bench for pyopengl 3.x performance measurements.]]
I'm intending to get rather more (Cython) accelerator helpers in
OpenGL_accelerate, but no, it likely won't be focusing on the legacy
APIs. Basically I'm planning to focus on the array-handling APIs so
that we can reduce the overhead there to something reasonable. There
are a considerable number of performance improvements still lying on the
ground in the wrapper mechanism that could be fairly straightforwardly
fixed if I can find the time. I also want to look into whether we can
simplify some of the wrapper operations if you enable legacy-free behavior.
>
>> Also consider using the package-level configuration flags to remove
>> "support" functionality as you near release, use of these flags can
>> provide more than 2x speedup in most cases.
>
> Are you talking about OpenGL.FORWARD_COMPATIBLE_ONLY? To do that, the
> OpenGL code in the application must be legacy-free, correct?
Nope, FORWARD_COMPATIBLE_ONLY is part of the migration path machinery
(which is another of the areas I'm intending to focus on), it doesn't
give you any performance improvements, it just disables the old APIs and
lets you know which pieces are legacy by raising errors (though it
doesn't do this for GLUT/GLU). Code that is entirely forward compatible
(legacy free) is going to be reasonably fast, because it *must* use VBOs
and shaders and there's basically nothing going on within the Python
code[1]. I'll be looking at optimizing those paths fairly heavily as
well, as that's where we need to go. However, the flag itself doesn't
make your code any faster, it just disables the legacy stuff so you
can't use it.
The flags that impact performance are:
* ERROR_CHECKING -- huge performance win, but no error checking, use
at the end of the dev cycle when you know your code is handling
all cases properly and want a performance boost, often close to 2x
improvement, as it halves the number of OpenGL calls in many cases.
* ERROR_LOGGING -- less of a performance win, but removes a single
wrapper call from every OpenGL call, if you turn off error
checking then this is turned off as well, but you can disable just
this to remove the function-call overhead
* ERROR_ON_COPY -- if set, will tell you when you are passing
incompatible arrays to array-handling functions (thus requiring a
copy of the array). For large array-oriented code-bases array
copying can become a huge bottleneck, so you can set this flag to
True to be warned of the problem. By default it silently fixes
the problem at the cost of performance. Eventually this will
likely *also* reject list/tuple types as array values, as they
require a data-copy as well.
* ALLOW_NUMPY_SCALARS -- if set, works around a bug in older
Python's ctypes that disallowed use of numpy scalars as return
values, has a large negative performance penalty, so is currently
disabled by default
The new one I plan to introduce will likely have this effect:
* disable pointer-storage-for-safety behavior, currently PyOpenGL
stores the pointer objects you pass it in order to prevent
memory-access failures, this behavior becomes unnecessary when we
have full ERROR_ON_COPY behavior and you've fixed all of your code
to pass in objects which are compatible by default. The behavior
is also unneeded with legacy-free arrays, as data-copying happens
during the call in *all* cases, so there's no need for the GL to
access the data "later".
The idea being that by default the system will be as robust and friendly
as possible, but as you move your application toward release you'll
start peeling off the layers of "nets" to improve your performance.
>> Since the release of PyOpenGL 2.x another common OpenGL binding for
>> Python has become popular and may be an appropriate choice for your
>> projects. The Pyglet project (http://www.pyglet.org) has a full
>> OpenGL binding in "raw" C style, along with many higher-level
>> utilities to aid in the development of games, all of which can be
>> easily installed on common platforms.
>
> As I wrote in a previous message, such a "raw" C style wrapper is also
> hidden in PyOpenGL, you just have to import from OpenGL.raw.GL instead
> of OpenGL.GL, and switch OpenGL.ERROR_CHECKING to False.
There's a few more differences (PyOpenGL's wrapper does more to each
function in order to be as friendly and safe as possible), but yes, that
is the basic idea of the "raw" hierarchy.
> This can improve performance (I get a 100% speedup with the codebase
> mentioned above) and bring it to the levels of 2.x, at the cost of
> some ctypes pollution in the code - raw wrappers of pyopengl and
> pyglet are almost indistinguishable both performance and code
> appearance wise.
You should still see a performance win on Pyglet unless you're using
OpenGL_accelerate. It does far less per-call than PyOpenGL in most cases.
> Talking about pyglet, some time ago I happened to read their automatic
> wrapper generator: I found it nice and easily pluggable in a toy
> project of mine. Since it uses the same ctypes technology and I
> remember you praising it yourself in a past presentation of yours, are
> you planning to merge it into pyopengl3.x to avoid duplicating efforts?
Yup, my intention is to use Pyglet's generator to replace the PyOpenGL
generation mechanism. That was put on hold to focus on just getting the
library out the door. The proof of concept was able to generate
basically the same wrapper as PyOpenGL for the core, but there were some
subtle differences from the current raw wrappers that wound up making
the result unstable in my testing. That should all just be a matter of
time to fix... unfortunately, time is something I seem to have little of
these days :) .
Enjoy,
Mike
[1] The one big anti-pattern for legacy-free is the individual-quad
rendering pattern that a lot of people are using in current PyOpenGL.
You (including me) really need to switch to texture atlases for things
like rendering text/sprites and use a big buffer with a shader that
renders the sprites with a single pass.
--
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com
|
|
From: Mike C. F. <mcf...@vr...> - 2009-04-02 15:20:49
|
Peter Gebauer wrote: > Hi Mike! > > Will PyOpenGL 3.x be rewritten in the future to use SWIG, Pyrex or > Python extensions written in C to improve performance? Is there a possibility > of mixing ctypes with Python extensions in C for the more critical parts? > The OpenGL_accelerate module is written in Cython (~= Pyrex) to improve performance. Yes, you can fairly freely mix C/Cython/Pyrex coded OpenGL-using extensions with PyOpenGL code. The current GL context is used by all PyOpenGL calls (well, the ones that don't explicitly specify contexts, such as those in GLUT or GLX). As for rewriting the core library, I doubt *I* will do another rewrite. But the fact is that someone could easily generate a new Cython/Pyrex wrapper without breaking a sweat. They would just then need to do all the project management and maintenance on the code-base, and I quit working on the SWIG code-base because of the maintenance headaches, so it's not really something I want to go back to. The use of ctypes means that we should eventually be able to run on all of Jython, PyPy, IronPython, Unladen Swallow and CPython with the core Python+ctypes-only implementation. Interpreters that actually *use* the ctypes annotations (PyPy) may eventually be able to use the fact of using ctypes to generate almost-C-level performance from the code. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
|
From: René D. <re...@gm...> - 2009-04-02 22:58:03
|
On Fri, Apr 3, 2009 at 2:20 AM, Mike C. Fletcher <mcf...@vr...>wrote: > Peter Gebauer wrote: > >> Hi Mike! >> >> Will PyOpenGL 3.x be rewritten in the future to use SWIG, Pyrex or >> Python extensions written in C to improve performance? Is there a >> possibility >> of mixing ctypes with Python extensions in C for the more critical parts? >> >> > The OpenGL_accelerate module is written in Cython (~= Pyrex) to improve > performance. Yes, you can fairly freely mix C/Cython/Pyrex coded > OpenGL-using extensions with PyOpenGL code. The current GL context is used > by all PyOpenGL calls (well, the ones that don't explicitly specify > contexts, such as those in GLUT or GLX). > > As for rewriting the core library, I doubt *I* will do another rewrite. But > the fact is that someone could easily generate a new Cython/Pyrex wrapper > without breaking a sweat. They would just then need to do all the project > management and maintenance on the code-base, and I quit working on the SWIG > code-base because of the maintenance headaches, so it's not really something > I want to go back to. > > The use of ctypes means that we should eventually be able to run on all of > Jython, PyPy, IronPython, Unladen Swallow and CPython with the core > Python+ctypes-only implementation. Interpreters that actually *use* the > ctypes annotations (PyPy) may eventually be able to use the fact of using > ctypes to generate almost-C-level performance from the code. > A funny side note is that ironpython can more easily run CPython compiled extensions than ctypes code at the moment. This is done by emulating the CPython API. cu, |
|
From: Thomas H. <th...@ct...> - 2009-04-03 16:15:51
|
René Dudfield schrieb: > On Fri, Apr 3, 2009 at 2:20 AM, Mike C. Fletcher <mcf...@vr...>wrote: > >> Peter Gebauer wrote: >> >>> Hi Mike! >>> >>> Will PyOpenGL 3.x be rewritten in the future to use SWIG, Pyrex or >>> Python extensions written in C to improve performance? Is there a >>> possibility >>> of mixing ctypes with Python extensions in C for the more critical parts? >>> >>> >> The OpenGL_accelerate module is written in Cython (~= Pyrex) to improve >> performance. Yes, you can fairly freely mix C/Cython/Pyrex coded >> OpenGL-using extensions with PyOpenGL code. The current GL context is used >> by all PyOpenGL calls (well, the ones that don't explicitly specify >> contexts, such as those in GLUT or GLX). >> >> As for rewriting the core library, I doubt *I* will do another rewrite. But >> the fact is that someone could easily generate a new Cython/Pyrex wrapper >> without breaking a sweat. They would just then need to do all the project >> management and maintenance on the code-base, and I quit working on the SWIG >> code-base because of the maintenance headaches, so it's not really something >> I want to go back to. >> >> The use of ctypes means that we should eventually be able to run on all of >> Jython, PyPy, IronPython, Unladen Swallow and CPython with the core >> Python+ctypes-only implementation. Interpreters that actually *use* the >> ctypes annotations (PyPy) may eventually be able to use the fact of using >> ctypes to generate almost-C-level performance from the code. >> > > > A funny side note is that ironpython can more easily run CPython compiled > extensions than ctypes code at the moment. This is done by emulating the > CPython API. But this means that it should be possible to run ctypes code on IronPython; just load _ctypes.pyd via the emulated CPython api. -- Thanks, Thomas |
|
From: Lorenzo M. <lma...@de...> - 2009-04-24 12:46:47
|
Mike C. Fletcher wrote: > If you have a PyOpenGL code-base you should be > looking at reworking the code in order to eliminate the use of "legacy" > APIs before OpenGL 3.1 drivers become mainstream. This seems to be OpenGL's direction indeed: Appendix F "Version 3.0 and Before", page 301 Appendix G "Version 3.1", page 308 http://www.opengl.org/registry/doc/glspec31.20090324.pdf But it was my understanding that even when OpenGL 3.1 drivers become mainstream, to obtain a "forward-compatible" 3.x context you will have to explicitly request it, otherwise you will get a 2.x legacy context. See for example this patch to allow an application to choose between 2.x and 3.x context creation, recently committed in SDL trunk: http://www.nabble.com/OpenGL-3.0-Context-Creation-td22645797.html Also, when you are using a 3.x context and your vendor chose to implement the GL_ARB_compatibility extension, you can find there all the constants and functions deprecated in 3.0 and removed in 3.1. So it seems to me that allowing any existing PyOpenGL legacy app to continue running on OpenGL 3.1 is unlikely to require changes to the code-base, because: * if your driver still supports creating a 2.x context, nothing changes; * if your driver only supports creating a 3.x context, but implements the GL_ARB_compatibility, PyOpenGL extension mechanisms will automatically detect it and expose all constants and functions which it declares. To sum it up, it looks like legacy PyOpenGL apps will be out of luck only if a vendor releases a driver which doesn't allow 2.x contexts creation *and* doesn't implement GL_ARB_compatibility extension. Does any of this make sense? Also see this document from nVidia about how they chose to implement OpenGL 3.x: http://developer.nvidia.com/object/opengl_3_driver.html -- Lorenzo Mancini |
|
From: Mike C. F. <mcf...@vr...> - 2009-04-24 15:01:09
|
Lorenzo Mancini wrote: > Mike C. Fletcher wrote: > >> If you have a PyOpenGL code-base you should be looking at reworking >> the code in order to eliminate the use of "legacy" APIs before OpenGL >> 3.1 drivers become mainstream. > > This seems to be OpenGL's direction indeed: > > Appendix F "Version 3.0 and Before", page 301 > Appendix G "Version 3.1", page 308 > http://www.opengl.org/registry/doc/glspec31.20090324.pdf > > > But it was my understanding that even when OpenGL 3.1 drivers become > mainstream, to obtain a "forward-compatible" 3.x context you will have > to explicitly request it, otherwise you will get a 2.x legacy context. That assumes that your driver has the ability to create a legacy context. While nVidia might be committing to always have a legacy context available, the OpenGL 3.1 spec doesn't require having a legacy context available. > Also, when you are using a 3.x context and your vendor chose to > implement the GL_ARB_compatibility extension, you can find there all > the constants and functions deprecated in 3.0 and removed in 3.1. Yes, again, with the assumption that your vendor is supporting that extension. With nVidia supporting it we can assume ATI/AMD will likely support it as well... which just eliminated any significant benefits from the OpenGL 3.1 rewrite :) . > So it seems to me that allowing any existing PyOpenGL legacy app to > continue running on OpenGL 3.1 is unlikely to require changes to the > code-base, because: > > * if your driver still supports creating a 2.x context, nothing changes; > * if your driver only supports creating a 3.x context, but implements > the GL_ARB_compatibility, PyOpenGL extension mechanisms will > automatically detect it and expose all constants and functions which > it declares. > > > To sum it up, it looks like legacy PyOpenGL apps will be out of luck > only if a vendor releases a driver which doesn't allow 2.x contexts > creation *and* doesn't implement GL_ARB_compatibility extension. Does > any of this make sense? No, that's the scope of it, but the question arises: why define deprecations at all if no-one is intending to drop the deprecated features? That is, the whole point of the deprecations was to create a smaller, lighter, more flexible API that could be more readily maintained and extended; something that could compete with DirectX head-to-head in games (where there's some really big money). In the OpenGL 3.0 era, we were basically told, "it's changing suck it up", but there was a heck of a lot of blow-back from CAD and similar users, while the Game users considered it too little too late. So now we have an extension which re-enables all of the legacy paths, so requires all of the complexity 3.1 was supposed to eliminate to be present... great for people with legacy code, but unlikely to let OpenGL "win" in the games sphere. Then again, there's not a lot of OpenGL games left, so maybe that's not really a concern and the ARB is effectively just acknowledging that their remaining community values compatibility far more than gaming competitiveness. Hopefully nVidia will implement with the switch with something like a separate legacy driver that will let them do a Longs-Peak-style driver for game competitiveness while swapping in a (separate) legacy driver only when requested. Anyway, yes, PyOpenGL will be supporting GL_ARB_compatibility, so if your driver supports it, you should be able to use the legacy APIs. So the advice that you will need to recode is probably invalid for most users. (And I apologize, while the 3.1 spec came out a few days before PyOpenGL 3.0.0 I hadn't had a chance to read it at the time I wrote the release notes). Have fun, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X