On 10-05-22 01:24 PM, Derakon wrote:
I'm including the mailing list again, because at this point it looks
pretty clear that there's something wrong with my PyOpenGL install,
and I have no idea how to figure out what it could be. 
I'd tend to agree that *something* is wrong with your installation, either PyOpenGL or the OpenGL driver.  My laptop gets 1000+fps on the test3 script on a Radeon Mobile HD 3650 under Kubuntu Lucid (64-bit) using bzr head of PyOpenGL on Python 2.6.5.  The test2 script gets 990+fps on the same machine.

Your hardware is a generation older than mine, with ~= pixel-fill bandwidth and ~2/4 texture-fill bandwidth, so we'd expect to see around 500fps for the same texture-fill-rate-limited code.  You're 30x slower than that, so yeah, something isn't configured properly.
My PyOpenGL install was created by downloading the PyOpenGL and
PyOpenGL-accelerate packages from
http://pyopengl.sourceforge.net/documentation/installation.html and
doing "python setup.py install". The only problem I ran into there was
that PyOpenGL-accelerate was trying to pass -Wno-long-doubles to gcc,
which didn't recognize it as a valid commandline option. I told it to
use gcc 4.0 instead of gcc 4.2 and it built without complaints.
Hmm, sounds like Cython's distutils extension might need to be updated on that system.
If I remove the GL_TEXTURE_MIN_FILTER line then I get an absurdly fast
(830FPS) set of white rectangles. As I understand it, doing this
causes OpenGL to assume that I'm going to provide mipmaps for the
texture, and since I don't it defaults to white. Which is, apparently,
much easier to draw than the textured quads.
It is certainly much easier, even software rendering could handle that without blinking (which I'm guessing is what's happening with your system).
If I switch to RGB instead of RGBA and turn off blending, then it's still slow.

Switching from an 800x600 window to a 400x300 window gets me 104FPS;
likewise, switching to a 1600x1200 window gets me 3FPS.

Here's the output of running PyOpenGL's performance test (from
tests/performance.py); I have no idea how to interpret it.
You expect results on the order of a handful of mega-triangles per second on reasonable hardware with the middle array sizes (basically there's a sweet-spot where you're maxing out your hardware's capabilities per-call), on my machine the values for 16,000 and 32,000 are about 9 MTris.

mcfletch@sturm:~/OpenGL-dev/OpenGL-ctypes/tests$ python performance.py
Count: 256 Total Time for 100 iterations: 0.0823800563812  MTri/s: 0.310754824949
Count: 512 Total Time for 100 iterations: 0.0618591308594  MTri/s: 0.82768702516
Count: 1024 Total Time for 100 iterations: 0.0667719841003  MTri/s: 1.53357731359
Count: 2048 Total Time for 100 iterations: 0.0698039531708  MTri/s: 2.933931256
Count: 4096 Total Time for 100 iterations: 0.0796709060669  MTri/s: 5.14114901186
Count: 8192 Total Time for 100 iterations: 0.113540887833  MTri/s: 7.21502196819
Count: 16384 Total Time for 100 iterations: 0.1773250103  MTri/s: 9.23953139623
Count: 32768 Total Time for 100 iterations: 0.360249996185  MTri/s: 9.09590571741
Count: 65536 Total Time for 100 iterations: 0.921277046204  MTri/s: 7.1136039121
Count: 131072 Total Time for 100 iterations: 2.15656399727  MTri/s: 6.07781638597
Count: 262144 Total Time for 100 iterations: 5.70130205154  MTri/s: 4.59796722977

The values you are seeing are extremely small, and would indicate that your hardware isn't being used properly.  This may be a PyOpenGL issue, given that you are seeing such slow performance in all PyOpenGL scripts tested so far, but I don't intuitively see what it would be.

To start debugging:
Realize that isn't all that much help, but this is looking like a system/config issue.  Good luck,

  Mike C. Fletcher
  Designer, VR Plumber, Coder