On Wed, Jan 27, 2010 at 2:44 PM, Florian Bösch <[email protected]> wrote:
> On Jan 27, 2:50 pm, Tristam MacDonald <[email protected]> wrote: > > As I have mentioned many, many times now, it isn't OpenGL which is broken > > here - it is wave.py. > No mention of RGBA32F made so far. > I didn't detect this particular performance issue up until that point, because I didn't want to take the time to debug the program. > > In particular, GPU-to-GPU glReadPixels is only supported for some > particular > > pixel formats, and GL_RGB (which you are using) is not one of them. > > Switching the texture formats to GL_RGBA32F, the glReadPixels mode to > > GL_RGBA, and switching the vertex buffers to 4 elements per vertex brings > > the application above 30 fps for a map size of 1024x1024. > Thanks a bunch, it's true, I switched over and it copies much faster. > > Now if you had mentioned the GL_RGBA issue from the start, we could > have saved ourself a lot of bytes. > My assertion was never that wave.py could be perform better - though it obviously can. My assertion is that you cannot make a general statement about the performance of OpenGL on the basis of a single test program. It was obvious from the start that an existing game like Quake 4, or indeed any of NVidia's OpenGL examples, manages to push more than 75 MB/s bandwidth on your card. This immediately indicates that your program is broken - thus my incredulity at your repeated assertion that the API itself (which has been vetted by thousands of programmers) is broken. -- Tristam MacDonald http://swiftcoder.wordpress.com/ -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
