Thread: [PyOpenGL-Users] PyOpenGL accelerator module
Brought to you by:
mcfletch
From: Eric J. <jonas@MIT.EDU> - 2009-04-20 12:51:19
|
Hello! First my apologies if this has been discussed on the list recently, I couldn't find the relevant sf page for searching the mailing list archives. I'm interested in constructing an openGL-based time series viewer for some of our tens-of-megabyte time series data, that will work interactively from python. Matplotlib totally fails when looking at data of this scale, and the speed of navigation is pretty crucial. But I'd like to do as much as possible from python/numpy/scipy, and then pass the loosly-processed data off to the GPU (i've done a bit of GLSL work) for visualization. My only concern is that, with its new ctypes-based bindings, pyopengl3 will be too slow for this sort of application. ...Which brings me to the accelerator module -- do people think this would really be necessary for this sort of app? How much work would it be to prototype things with the existing pyopengl3 interface and then "drop in" the accelerator module? I've not been able to find much documentation about the shape of the eventual module. Thanks again, I'm excited to get back to hacking OpenGL ! ...Eric |
From: Mike C. F. <mcf...@vr...> - 2009-04-20 14:10:47
|
Eric Jonas wrote: > Hello! First my apologies if this has been discussed on the list > recently, I couldn't find the relevant sf page for searching the mailing > list archives. > Don't think we've ever discussed it on-list. > I'm interested in constructing an openGL-based time series viewer for > some of our tens-of-megabyte time series data, that will work > interactively from python. Matplotlib totally fails when looking at data > of this scale, and the speed of navigation is pretty crucial. > > But I'd like to do as much as possible from python/numpy/scipy, and then > pass the loosly-processed data off to the GPU (i've done a bit of GLSL > work) for visualization. My only concern is that, with its new > ctypes-based bindings, pyopengl3 will be too slow for this sort of > application. > Actually, that's the use-case where the ctypes bindings tend to be irrelevant. There is a per-array overhead in the bindings to get the data-pointer out of the array, but once the data-pointer is retrieved it's basically just passing the value directly in to OpenGL. If you're processing huge data-arrays you're likely not going to notice the overhead of the data-pointer retrieval, as it will be swamped in the real work getting done. > ...Which brings me to the accelerator module -- do people think this > would really be necessary for this sort of app? How much work would it > be to prototype things with the existing pyopengl3 interface and then > "drop in" the accelerator module? I've not been able to find much > documentation about the shape of the eventual module. > It's intended to be an entirely transparent accelerator module. The core code already has hooks for most of the accelerator modules, so it will attempt to import from OpenGL_accelerate the various functions that are available. The basic code is already in the bzr/source packages with a script called setupaccel.py which builds the package. Mostly the intent is just to extend and debug it to eliminate significant hotspots. Usage will just be to install the accelerator module, no changes to code should be necessary. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |