OpenGL Renderer: massive performance decrease in Juce V.2

[sonic59]

If I had to guess, I'd point my finger at the graphic card drivers.
Are you using 10.7 and bootcamp? Latest bootcamp drivers?

[friscokid]

I'm using bootcamp win 7 and the latest official nvidia drivers for this card (no problems with 3d applications and openGL so far).
But how does this explain that juce before March 15. showed excellent performance?

I'm currently doing tests with other platforms and machines. Hope I have the results ready this evening.

[TheVinn]

There's one weak point in the win32 implementation that I never managed to figure out - if you look at OpenGLGraphicsContext, line 1029, there's a numQuads setting which defines how large the chunks of data are that get sent to the GPU.

If you could put together the smallest self contained test program that illustrates the problem, I can float it past the guys in ##OpenGL on Freenode (or you could go there yourself).

I took a look and I see numQuads = 64 for Win32, while it is 8192 for other platforms. That doesn't smell right!

[friscokid]

I took a look and I see numQuads = 64 for Win32, while it is 8192 for other platforms. That doesn't smell right!

Well, that code didn't change between the versions with good and bad performance.
The old version that shows excellent performance uses the value of 64, too.

I'm currently in the middle of some test and will post my results later.
Thanks.

[jules]

I've really no idea - although there were a lot of changes in that check-in, they were all just removal of code-paths that you wouldn't have been using. Perhaps something to try would be to build the old version, but set JUCE_USE_OPENGL_FIXED_FUNCTION=0 to make sure it really was using the shaders.

[friscokid]

Meanwhile I've done some tests with the different versions on different systems.

I have tested the 32bit and 64bit relase versions on three different systems.
All systems have graphic cards not older than 3 years with shader support. Two of them are ATI cards and one is an NVIDIA.

The results are always the same: between 15ms and 30ms rendering time when I use the current version and between 0.5ms and 2ms when I use the version before March 13.
The problem is definetly not specific to one system. The OS of all systems was Win 7 64 bit.

To reproduce the problem I compiled the Juce Demo as 32 and 64 bit release versions once using the current version and once using the older commit.

You can download the 4 versions by following this link. So everyone can test this on his system wihtout the need to compile the different commits.
http://www.mind-crafted-gear.com/media/temp/Juce_OpenGL_Renderer_Performance.zip

I included a small info file with infos about the versions and some hints how to test this, so that the results of others are compareable.
Could you please download the different versions and post your results here.
Thanks.

[TheVinn]

Results:

JuceDemo_V1_32bit.exe 2520x1335 - Render time: 1.25ms-1.55ms
JuceDemo_V1_64bit.exe 2520x1335 - Render time: 0.90ms-1.20ms
JuceDemo_V2_32bit.exe 2520x1335 - Render time: 12.35ms-13.65ms
JuceDemo_V2_64bit.exe 2520x1335 - Render time: 10.55ms-11.95ms

Conclusion: V2 is ten times slower, 64-bit is ~10% faster.

Card tested: GeForce 680GTX, Windows 7 64-bit.

[friscokid]

That's what I expected.
In my case the differences have even been greater.

So some changes of the following commit are responsible for a huge performance loss of the OpenGL Renderer on Windows plattforms:

Revision: b338698e346d3cb14e33e568f838a7e8523bb544
Author: jules
Date: 15/03/2012 12:13:38
Message:
OpenGL: removed the fixed-function rendering code, replacing it with a simple software renderer that blits its results to the GL context. Removed the public OpenGLGraphicsContext class, replacing it with a createOpenGLGraphicsContext() function which returns an appropriate shader-based or software-based renderer object.
----
Modified : extras/JuceDemo/Source/demos/OpenGLDemo.cpp
Modified : modules/juce_gui_basics/windows/juce_ResizableWindow.h
Modified : modules/juce_opengl/opengl/juce_OpenGLComponent.cpp
Modified : modules/juce_opengl/opengl/juce_OpenGLComponent.h
Modified : modules/juce_opengl/opengl/juce_OpenGLContext.cpp
Modified : modules/juce_opengl/opengl/juce_OpenGLContext.h
Modified : modules/juce_opengl/opengl/juce_OpenGLFrameBuffer.cpp
Modified : modules/juce_opengl/opengl/juce_OpenGLFrameBuffer.h
Modified : modules/juce_opengl/opengl/juce_OpenGLGraphicsContext.cpp
Modified : modules/juce_opengl/opengl/juce_OpenGLGraphicsContext.h
Modified : modules/juce_opengl/opengl/juce_OpenGLImage.cpp

This should be fixed, since the performance before this commit has been really impressive on win plattforms compared to the software Renderer.

[jules]

It's really no help to quote all these numbers or get other people to do the same test - I need to know *why* this is happening, not by how much! Even if it only happened on one machine, there'd still be a problem to fix. I just haven't a clue what it is, and throwing endless timing statistics at me is not useful!

I've already looked through that diff and really can't see anything that looks significant. I'll do some more investigating when I get chance, but any suggestions (other than lists of timings!) would be appreciated!

[friscokid]

I'm sorry, this was just to make sure things are not only happening on my end.

I did the test you suggested:

Perhaps something to try would be to build the old version, but set JUCE_USE_OPENGL_FIXED_FUNCTION=0 to make sure it really was using the shaders.

But that doesn't make any difference. I still get the same results.

If there's anything I could test for you, I'd be happy to help.

[TheVinn]

It's really no help to quote all these numbers or get other people to do the same test - I need to know *why* this is happening, not by how much! Even if it only happened on one machine, there'd still be a problem to fix. I just haven't a clue what it is, and throwing endless timing statistics at me is not useful!

I think that the intention is not so much to quote the difference in performance, but to illustrate that we know with certainty where the problem lies - it is exactly in those commits!

I've already looked through that diff and really can't see anything that looks significant.

"When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.” - Sherlock Holmes

The difference has to be somewhere in there. Is it possible to break the commit up into smaller pieces and figure out which piece caused it? Can we take the commit and factor out any changes that are not openGL specific, and reduce the search-space? This question is more aimed at friscokid.

[jules]

Yes, I know.. Annoyingly, the commit involves a huge number of changes - all just ripping out old code, but perhaps a typo crept in there somewhere which is messing something up. Strange that it's only a Windows problem, and not OSX, as there's very little platform-specific code involved.

[TheVinn]

juce_OpenGLComponent.cpp seems to have not that many changes, is it possible to mix the old version with the other new files? If it is still slow then we could possibly rule that file out.

juce_OpenGLContext.h and juce_OpenGLContext.cpp didn't change much either, and the class declaration has a trivial difference. It should be possible to use the old OpenGLContext object with the rest of the new code, and eliminate that as a source of problems.

[jules]

The rendering is all done in OpenGLGraphicsContext.cpp, that's by far the most likely culprit.

[TheVinn]

The rendering is all done in OpenGLGraphicsContext.cpp, that's by far the most likely culprit.

But you already looked and didn't find anything so maybe my ignorant approach will uncover something. I admit, I don't understand anything of what I'm loooking at in the Open GL code (maybe thats a good thing).