Re: [PyOpenGL-Users] Suspiciously slow script

[Mike C. F. <mcf...@vr...>]

On 10-05-22 04:00 PM, Derakon wrote:
> Responses inline.
>
> On Sat, May 22, 2010 at 12:04 PM, Mike C. Fletcher
> <mcf...@vr...> wrote:
>   
>> To start debugging:
>>
>> does disabling OpenGL_accelerate change your performance (on my machine
>> there is no difference, which suggests that OpenGL_accelerate isn't likely
>> to be your problem)
>>
>> import OpenGL
>> OpenGL.USE_ACCELERATE = False
>>
>>     
> Tried this; no change.
>   
Okay, so not likely an issue with OpenGL_accelerate (good).
...
> No idea how to do this on an OSX box, but given that I'm using a card
> that shipped with the box, and that games do work properly, I'd be
> extremely surprised if I were using software rendering.
>   
Good surmise, I hadn't realized you were on OSX, that should always have
DRI available.
...
> They are. I've been playing Torchlight all last week; I assume it's
> OpenGL because what else would it be on a Mac? DirectX is out of the
> question and I'm not aware of any other graphics libraries that would
> work.
>   
Yup, it would have to be OpenGL AFAIU.
>> confirm that you are not using an OpenGL compositing desktop (e.g. compiz on
>> Linux) which may cause indirect rendering of OpenGL windows
>>     
> Again, not certain how to do this; however, I tested the script in
> OSX's built-in X11 system, which (I'm fairly certain) skips most of
> the pretty-ifying steps that the window manager normally does, and
> it's still slow.
>   
OSX has compositing by default, but it should work properly (whereas
there's some situations on Compiz (Linux) that cause issues).

> No ATI control panel, but again, something like this would affect games.
Yup.
>> try generating mipmaps and using mipmap-nearest (just for kicks)
>>     
> Okay, I replaced the glTexImage2D in the script with this:
>
> GLU.gluBuild2DMipmaps(GL.GL_TEXTURE_2D, GL.GL_RGBA, surface.get_width(),
>         surface.get_height(), GL.GL_RGBA, GL.GL_UNSIGNED_BYTE, textureData)
>
> and replaced the GL_TEXTURE_MIN_FILTER line with this:
>
> GL.glTexParameterf(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_MIN_FILTER,
> GL.GL_LINEAR_MIPMAP_LINEAR)
>
> and now I get 333FPS! What the heck?
>   
That's what I was half expecting.  OpenGL drivers tend to be optimized
along certain (common) paths, use of MipMaps is pretty much universal,
so they will be very fast.  You're scaling the view constantly (IIRC) so
you're going to have every pixel doing sampling, and it looks like on
your driver the linear bitmap sampler is doing something non-optimal
when it's sampling a (large) texture down across a large scale
difference.  With the MipMap, the textures being sampled are much
smaller.  You could ask on the OpenGL.org forums and likely get a
definitive answer as to why this particular operation is slow.  I
normally chalk it up to the old "do what everyone else does and you'll
be fast" rule of thumb and move on in my code.

Still a surprisingly low MTri on the performance test.  That is,
however, likely a different issue from the texture-fill one.

Enjoy,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com