Ok, you are aware that renaming the .exe makes a fps difference. But do you know why?  It's because drivers are specifically tuned to that game. It was a big controversy 10 years ago with the whole quake/quack things. Drivers were taking quality shortcuts to get artificially inflated fps scores. Things like forcing trilinear filtering off even when you enable it and reducing texture quality behind the scenes, again something the user has no control over. 

So there are quality shortcuts hard coded into drivers left over from 10 years ago. If you really care about this issue you need to approach AMD and nvidia about enabling their "optimizations" for a binary loaded into memory called ioquake*. You will also want to get them to disclose exactly what is going on so we know what the trade offs will be if this is force enabled and ioquake3 has no control over the quality settings anymore. 

Now maybe they are just really optimized and there are no shortcuts being taken anymore. I am dubious, though. 

Another thing you will want to test is scaling. Yes, the old renderer is faster, but it does less. And the most important part is what fps does it get at high rspeeds?  The old renderer does 1000 fps until you get rspeeds above about 40,000 when it tanks sharply. The new renderer, I believe we are making maps with rspeeds up to 500,000 and keeping playable fps with extra visual goodies enabled.  Testing with a vast majority of q3 maps (max rspeeds probably around 30,000) won't show this advantage but it allows mappers/modelers to use more modern assets and improve both level geometry and complexity as well as overall visual appeal since the triangle count can be much higher with playable fps. 

Have you renamed ioquake3 to quake3 and tested to see if the new renderer gets higher fps?  I see mainly comparisons to the old one with higher fps and the new ones unaltered. If you have done the renaming test on the new renderer, did it break anything or have any affect?  The new renderer uses a very different rendering method than the original so the driver optimizations/shortcuts may not be relevant in a modern renderer or game. Quake 3 was relatively simple. It may not be possible to see those gains in modern times even with driver cheating.

Created attachment 3373 [details]
renamed exes comparison

I tested both renderers, the influence is higher on OpenGL2, thats why I called it OpenGL2 bug.
I didn't talk about a comparision of opengl1 vs. opengl2.
Hmm, maybe my english is too bad, so I will attach a screenshot, have a look at it!
At the screenshot I will show:

Top: ioquake3.x86.exe + cl_renderer opengl2
Middle: ioquake3.x86.exe, renamed exe to quake3.exe + cl_renderer opengl2
Bottom: ioquake3.x86.exe, renamed exe to quake3.exe + cl_renderer opengl2 + r_forcesun 1

The picture at the bottom shows the only issue I can find when renaming the exe (some textures are darker when r_forcesun or r_mapoverbrightbits is 0).

So it is not an opengl1 vs. opengl2 test. I tested ioquake3.x86.exe + opengl2 vs. renamed ioquake3.x86.exe + opengl2.

Zack Middleton already told me that this is a driver hack, though I was under the assumption that a new renderer doesn't depend on these hacks/bugs from ATI or/and Nvidia anymore.
Therefore I was under the assumption that ioquake can't fix opengl1 renderer but has the possibility to do this in opengl2 renderer :(
Maybe this is the thing I understand wrong. Though, it still seems weird to me that all the same OpenGL optimizations/shortcuts are relevant in such a modern renderer.
Sorry, I am no rendering expert...

Thanks for your reply,

Tobias Kuehnhammer

The trouble is that without know /what/ the drivers hacks are, we can't fix the code path which is slow without the hacks. In other words, we need information from Nvidia/ATI.

Okay, I asked Nvidia, I hope they can help us!
Thanks to all of you!

Tobias Kuehnhammer

This is a driver issue.