Could it be that GLSL is more effective than pure "old-school" ARB ASM shaders?

Hand-coded ASM shaders should be more efficient as you get more direct control over what instructions get executed, and in which order they happen, but you really need to know what you're doing and know what GPUs like and don't like to get the best out of them. Could be that the Cg to ASM converter was doing a bad job, could be that your GLSL compiler is actually really really good.

You're still measuring performance in FPS, and still haven't determined weather you're CPU bound or GPU bound.
Until then, these tests are meaningless -- if your 40ms frame times are bottlenecked by GPU time, then the API-side draw call cost isn't even being measured...

On Intel integrated chips like the HD Graphics the difference is ridiculous - although the rendering is correct, OpenGL gets single-digit framerates where Direct3D9 would get something like 40-50.

That is an indication that you're using some feature that is not supported in hardware, which forces GL to run in software emulated mode (e.g. performing an array-lookup in a pixel shader on a card with no pixel-shader address registers may cause that pixel shader to run on the CPU!).

Intel seems to have a reputation for not giving a crap about writing OpenGL drivers that don't actually suck, so it can be a good idea to implement a Direct3D code path for those poor unfortunates with Intel integrated.

Since your test case includes a lot of overdraw, did you manually change the depth-test settings?
OpenGL defaults to GL_LESS while DirectX defaults to D3DCMP_LESSEQUAL.
A fair test will require you to manually change one or the other.

As for my experience, I wonder why you expected OpenGL to be faster than DirectX.
My engine from a tiny shell to what it is now has always shown OpenGL to be slower than DirectX, and the more I add to it the farther OpenGL falls behind. Currently, the OpenGL side is literally half the speed of the DirectX side, thanks to a lot of optimizations that work for DirectX but not OpenGL, such as padding vertex buffers to 32 bytes. That helped DirectX tremendously whereas doing so for OpenGL just made it slower (extra bus transfer).

But as mentioned that usually falls back on the drivers the vendors (didn’t) care(d) to implement.
I have tested on a lot of machines though, and the best my OpenGL side can do is about 80% of the DirectX side.


L. Spiro

That is an indication that you're using some feature that is not supported in hardware, which forces GL to run in software emulated mode (e.g. performing an array-lookup in a pixel shader on a card with no pixel-shader address registers may cause that pixel shader to run on the CPU!).

Now that you said that it inspired me to pinpoint exactly when the slowdown happens in my engine, and turns out it's when there are any hardware skinned characters visible. Thank you! Now to just find the solution

EDIT: The real culprit appears to be vertex count, not skinning per se. I'm led to believe that for some reason the driver decides to execute the vertex shader in software. Fragment shaders seem to execute at acceptable speed, though.