Re: [PyOpenGL-Users] Suspiciously slow script
Brought to you by:
mcfletch
Menu
▾
▴
Re: [PyOpenGL-Users] Suspiciously slow script
|
From: Mike C. F. <mcf...@vr...> - 2010-05-22 19:05:07
|
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: * 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) o import OpenGL OpenGL.USE_ACCELERATE = False * confirm that your machine is using direct rendering (i.e. actually using your hardware driver, not a software renderer) o on Linux: glxinfo | grep direct * confirm that non-Python OpenGL programs are *currently* running reasonably well on this machine * confirm that you are not using an OpenGL compositing desktop (e.g. compiz on Linux) which may cause indirect rendering of OpenGL windows * confirm that you do not have system-level anti-aliasing settings enabled (i.e. a 4x or 8x antialiasing specified in ATIs control panel) * try generating mipmaps and using mipmap-nearest (just for kicks) Realize that isn't all that much help, but this is looking like a system/config issue. Good luck, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
