Re: [PyOpenGL-Users] Rolling spectrogram with pyopengl

[Gijs <in...@bs...>]

On 6-12-2009 12:58, Timothée Lecomte wrote:
>
> Le 3 déc. 09 à 17:10, Gijs a écrit :
>
>> Hello Timothée,
>>
>> You could try to use two textures instead of one. When you display 
>> one, you can write to the other and swap them and continue (also 
>> called the "ping-pong" technique). Another possibility is to use 
>> shaders to change your texture, but I'm not too sure if that is any 
>> faster. Also, since Python is actually quite slow when compared to 
>> languages like C, even OpenGL slows down considerably when used in 
>> Python. So if possible, push as much commands to display lists, 
>> vertex arrays, or VBOs. You can push all commands you use to draw the 
>> quad to a display list, which basically brings down the number of 
>> calls to one (since you only need to call the display list).
>>
>
> Hello Gijs,
>
> I am very new to both OpenGL and pyopengl worlds, but I'll try to 
> answer to your suggestions :
> Since I'm doing things synchronously in one thread, I don't see how 
> using two textures could make the whole thing faster.
> Moreover, there's one single bottleneck which is the writing of the 
> two columns of the texture (that's two times approx. 500 pixels every 
> 20 ms, with the glTexSubImage2D calls). The display in itself appears 
> much below in the profile, so converting it to a display list is not 
> my first priority.
>
Even if it looks to be executing synchronously, underneath, the GPU 
actually performs commands asynchronously. You provide the GPU with a 
whole bunch of commands and the GPU itself decides when and how it will 
execute the commands. For certain commands like glReadPixels, the CPU 
waits for the GPU to finish before it continues to read the texture. For 
optimal GPU performance, you would want as little of those commands as 
possible. This is the very reason why ping-ponging gives you a 
performance boost. The GPU knows that you don't access texture A for 
instance, while you are writing to texture B, so it can schedule the 
execution of the commands more efficiently (that's the basic idea anyway).

However, after reading the reply of Ian Mallett, I would also suggest 
using a shader. As Ian said, you can use shaders and render-to-texture 
techniques with FBOs (that's something different than PBOs) to achieve 
high performance. You can supply the shader with the old data and the 
new data in the form of textures. You offset everything by one texel, 
and for the last column of pixels you use the new data. You could use 
PBOs to transfer the new data to the input texture which should make it 
a little bit faster, if properly used. For some good tutorials regarding 
FBOs, PBOs and other GPGPU stuff, I'd suggest the site of Dominik 
Göddeke 
(http://www.mathematik.uni-dortmund.de/~goeddeke/gpgpu/tutorial.html 
<http://www.mathematik.uni-dortmund.de/%7Egoeddeke/gpgpu/tutorial.html>). Even 
though it's C code, most of the code is practically the same in PyOpenGL.

Hope this all makes sense :)

Regards, Gijs