Thread: [PyOpenGL-Devel] pyopengl and pypy
Brought to you by:
mcfletch
From: rndblnch <rnd...@gm...> - 2010-11-27 01:00:17
|
hello, i'm trying to make my pyopengl(3.0.1)-based code run with pypy (1.4). i ran into some issues: 1) the use of ctypes.pythonapi (for PyString_AsString in arrays/strings.py and PyBuffer_FromMemory in arrays/vbo.py) 2) an "AttributeError: type object 'ArrayDatatype' has no attribute '_CData_input'", trackback: ... File "/Users/Shared/src/pypy-1.4-osx/site-packages/OpenGL/latebind.py", line 45, in __call__ return self._finalCall( *args, **named ) File "/Users/Shared/src/pypy-1.4-osx/site-packages/OpenGL/wrapper.py", line 784, in wrapperCall result = self.wrappedOperation( *cArguments ) File "/Users/Shared/src/pypy-1.4-osx/site-packages/OpenGL/platform/baseplatform.py", line 335, in __call__ return self( *args, **named ) File "/Users/Shared/src/pypy-1.4-osx/lib_pypy/_ctypes/function.py", line 166, in __call__ argtypes, argsandobjs = self._wrap_args(argtypes, args) File "/Users/Shared/src/pypy-1.4-osx/lib_pypy/_ctypes/function.py", line 281, in _wrap_args wrapped = argtype._CData_input(arg) AttributeError: type object 'ArrayDatatype' has no attribute '_CData_input' i guess that for 1) it should be possible to write pure ctypes/python replacements for the needed functions (any hints welcome :) for 2) i didn't manage to understand enough the relationship between pyopengl and ctypes to get any clue about what's going on. anybody with some experience with/interested by such issues? thanks for your help, renaud |
From: Mike C. F. <mcf...@vr...> - 2010-11-29 19:00:21
|
On 10-11-26 07:54 PM, rndblnch wrote: > hello, > > i'm trying to make my pyopengl(3.0.1)-based code run with pypy (1.4). > i ran into some issues: > 1) the use of ctypes.pythonapi (for PyString_AsString in arrays/strings.py and > PyBuffer_FromMemory in arrays/vbo.py) > 2) an "AttributeError: type object 'ArrayDatatype' has no attribute > '_CData_input'", trackback: > ... > File "/Users/Shared/src/pypy-1.4-osx/site-packages/OpenGL/latebind.py", line > 45, in __call__ > return self._finalCall( *args, **named ) > File "/Users/Shared/src/pypy-1.4-osx/site-packages/OpenGL/wrapper.py", line > 784, in wrapperCall > result = self.wrappedOperation( *cArguments ) > File > "/Users/Shared/src/pypy-1.4-osx/site-packages/OpenGL/platform/baseplatform.py", > line 335, in __call__ > return self( *args, **named ) > File "/Users/Shared/src/pypy-1.4-osx/lib_pypy/_ctypes/function.py", line 166, > in __call__ > argtypes, argsandobjs = self._wrap_args(argtypes, args) > File "/Users/Shared/src/pypy-1.4-osx/lib_pypy/_ctypes/function.py", line 281, > in _wrap_args > wrapped = argtype._CData_input(arg) > AttributeError: type object 'ArrayDatatype' has no attribute '_CData_input' > > i guess that for 1) it should be possible to write pure ctypes/python > replacements for the needed functions (any hints welcome :) > for 2) i didn't manage to understand enough the relationship between pyopengl > and ctypes to get any clue about what's going on. > > anybody with some experience with/interested by such issues? > I'm definitely interested, but have very little time these days to play with PyOpenGL. There's a lot of machinery in PyOpenGL that produces the ctypes array-wrapper functionality (in the OpenGL/arrays package for the most part), but in the end, it's just doing standard ctypes calls about 95% of the time. Every once in a rare while I had to use an undocumented implementation feature of ctypes, but I don't think that's the problem here. _CData_input looks to be something pypy-specific which would be the equivalent of the from_param method on CPython ctypes? I'm guessing the pypy implementation assumes an inheritance relationship among all data-types and that _CData_input is a method on their _CData class. For whatever reason, the subclasses of ctypes.POINTER( <constant-type> ) are not picking up that method. For the first issue, those are going to require some reworking, in essence those are "C" implemented code that happens to use Python/ctypes as the implementation language and makes assumptions about the data-storage for the objects (e.g. that a string is internally a contiguous series of bytes, which is *not necessarily* true in PyPy). We'd need to find a mechanism in PyPy that would give us that direct memory-pointer access to be able to use it. Note: a compacting garbage collector (or anything else that can move memory locations) will cause problems there, so we may need to find a way to signal PyPy not to move a given object, and to use contiguous data-arrays for their storage. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: rndblnch <rnd...@gm...> - 2010-12-02 13:45:40
|
i'm back with some progress. got some help from pypy-dev: 1) the first issue (missing ctypes.pythonapi) was solved with the help of pypy-dev. they suggested to replace the c functions by a pure ctype implementation (and not worry and the memory layout, since their ctypes module does "the right thing"): PyString_asString can be avoided in OpenGL/array.string.py by using def dataPointer(value): return ctypes.cast(ctypes.create_string_buffer(value), ctypes.c_void_p).value or def dataPointer(value): return ctypes.cast(ctypes.c_char_p(value), ctypes.c_void_p).value PyBuffer_FromMemory can be implemented as (not tested though, since it's only used in experimental code for vbos): def PyBuffer_FromMemory(address, length): return buffer((ctypes.c_char * length).from_address(address)) if you want, i can provide a patch for those changes. in my tree of PyOpenGL i have totally removed the references to ctypes.pythonapi and it uses the ctypes version even for cpython. you might prefer to keep your implementation and just add a fallback if ctypes.pythonapi is None. the whole thread is there for reference: <http://codespeak.net/pipermail/pypy-dev/2010q4/006452.html> 2) the second issue (missing _CDada_intput) is from pypy. the good news is that it has already been fixed by Amaury Forgeot d'Arc in the fast-forward branch (aiming at cpython 2.7 compatibility). the patch (requires some adaptation to apply on pypy-1.4) can be found there: <http://codespeak.net/pipermail/pypy-svn/2010-November/045106.html> so far, i have managed to partially run the programs of my small opengl tutorial, i.e. a sample program that use most of the functionalities of the fixed pipeline and that is evolved step by step into a shader based implementation. what runs for the moment (with minor errors): - 01-direct.py (direct rendering, some geometry + 3d texture) - 02-displaylist.py - 03-array.py (use of Vertex/.../NormalPointer) - 04-vbo.py (idem + VBOs to pass the data) what does not run: the rest that uses shaders, but i'm pretty confident it's a minor issue (wrong types in glShaderSource arguments) the programs are based on pyopengl and can be found here: <http://bitbucket.org/rndblnch/opengl-programmable/> |
From: Mike C. F. <mcf...@vr...> - 2010-12-07 03:20:13
|
On 10-12-02 08:45 AM, rndblnch wrote: ... > def dataPointer(value): > return ctypes.cast(ctypes.c_char_p(value), ctypes.c_void_p).value > I don't see any documentation on this for CPython, for PyPy this apparently is going to create a copy of the data in value? My quick test says on CPython it doesn't copy the data, so I've swapped it into the code. > PyBuffer_FromMemory can be implemented as (not tested though, since it's > only used in experimental code for vbos): > def PyBuffer_FromMemory(address, length): > return buffer((ctypes.c_char * length).from_address(address)) > I've updated to use that one as well. > the whole thread is there for reference: > <http://codespeak.net/pipermail/pypy-dev/2010q4/006452.html> > > > 2) the second issue (missing _CDada_intput) is from pypy. the good news is that > it has already been fixed by Amaury Forgeot d'Arc in the fast-forward branch > (aiming at cpython 2.7 compatibility). the patch (requires some adaptation to > apply on pypy-1.4) can be found there: > <http://codespeak.net/pipermail/pypy-svn/2010-November/045106.html> > Hmm, that branch doesn't build on my machine, so I can't test the changes. > so far, i have managed to partially run the programs of my small opengl > tutorial, i.e. a sample program that use most of the functionalities of the > fixed pipeline and that is evolved step by step into a shader based > implementation. what runs for the moment (with minor errors): > - 01-direct.py (direct rendering, some geometry + 3d texture) > - 02-displaylist.py > - 03-array.py (use of Vertex/.../NormalPointer) > - 04-vbo.py (idem + VBOs to pass the data) > what does not run: the rest that uses shaders, but i'm pretty confident it's a > minor issue (wrong types in glShaderSource arguments) > > the programs are based on pyopengl and can be found here: > <http://bitbucket.org/rndblnch/opengl-programmable/> > I'll try to find some time to play with them. Good luck, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: rndblnch <rnd...@gm...> - 2010-11-30 17:39:35
|
Mike C. Fletcher <mcfletch <at> vrplumber.com> writes: > I'm definitely interested, but have very little time these days to play > with PyOpenGL. ok, thanks for your lights. i will digg into that/ask some guidance from pypy-dev. i'll report any progress here. renaud |
From: rndblnch <rnd...@gm...> - 2010-12-02 14:21:05
|
i'm back again with some news: shaders are now working, it required a minor fix of the StringLengths CConverter (in OpenGL/converters.py). the stringArrayForC method requires an explicit cast to make pypy ctypes version happy: def stringArrayForC( self, strings ): """Create a ctypes pointer to char-pointer set""" from OpenGL import arrays result = (ctypes.c_char_p * len(strings))() for i,s in enumerate(strings): - result[i] = arrays.GLcharARBArray.dataPointer(s) + result[i] = ctypes.cast(arrays.GLcharARBArray.dataPointer(s), ctypes.c_char_p) return result now, the following programs run fine: - 05-shader.py (partial shader-based implementation of the fixed pipeline) - 06-perpixel.py (per-pixel lightening) - 07-attrib.py (generic vertex attributes rather than pointers) - 08-pbo.py (using pixel buffer object to read back pixels from framebuffer) the last one does opengl à la opengles (without any fixed functionality) but does not work yet. this time, i think that it's pypy's fault :) stay tuned, renaud |