VortexCortex wrote:
I have to disagree. I don't know how much clearer I can be: Graf, Please stop spreading ATI FUD -- it sounds very foolish.
So it's FUD, just because you don't believe the benchmarks I made that clearly traced the performance loss to the amount of draw calls being made? This was one of the things I extensively investigated last year. The result was pretty clear what was causing the slowdowns.
Ugh...
Sorry, but I'll have to disagree here. I can't imagine any scenario which guarantees that no two changes of the same state are different unless the application does this kind of check itself. Even in the least optimal situation I can think of the caching would even out the overhead easily. (Let's just say that the caching overhead is 10% of the overall time for the state change so in order to win with ATI you only could afford 1 out of 10 changes being redundant which is ridiculously low.) So ATI just shoots itself in the head here by being less efficient than they could.
BTW, you can check in GZDoom (not Skulltag!) if state caching actually helps, by setting the CVAR gl_direct_state_change to false. This will cache all state changes and only apply the ones that really change things when a draw call is started. On NVidia this doesn't help and only causes more overhead than it saves, even though it does significantly reduce the amount of actual non-redundant state changes. But the added overhead for application side caching isn't even compensated by the savings inside the driver (that's why this feature is not active right now.) If ATI's drivers work as you say it might help but I doubt it's the main problem.
If gDEBugger is too pricy, you may find the free and open source GLIntercept a suitable OpenGL testing tool (both of which can be found via searching for "Debug OpenGL" via Google). Note: all of gDEBugger's features can be easily duplicated via extending the current X11+OpenGL source code (which can be obtained from nearly any Linux distro repository), or via extending GLIntercept's functionality. There are other OpenGL testing tools besides these as well...
I'll try glIntercept but you could do me a real favor if you checked one large level (Hellcore's MAP09 would be good). Just bind a key to 'bench', create a savegame from a good position (the steeple is perfect for this), load this savegame with the CVAR on and of and press the key bound to 'bench' for each. Then post the output (benchmarks.txt) here.
Graf Zahl wrote:
So the only way to bring the performance up would be to dump everything that's there, fully concentrate on somehow optimizing it for more modern methods and then hope that in the end it all works out (emphasis on 'hope'!)
Eeek!
"only way" ::runs screaming, "Nooo!"::
Seriously though, I've yet to find a problem that has only one solution... For one, you could run a performance analyzer tool on GZDoom and alleviate any issues (like redundant state changes) to improve performance. However, I do agree that the most performance can be gained via a total re-write of the code -- in which case it would be better to not use GZDoom as a base to avoid licensing issues, IMHO.
Moral of the story: "It's not what we know or don't know that brings us down. It's what we know for sure, but just ain't true."[/quote]
Let's be frank here:
The wall rendering code in GZDoom is an utter mess that has grown way beyond maintainability. No matter what I tried over the last few years, I always gave up when it came to the walls. Far too much there is just hacked in and causes problems now. If someone could clean up that mess in a way that still allows all the stuff that can be done right now I'm sure the renderer would be 50% faster on modern hardware that's mostly CPU limited.
But things like Decals, translucent sorting and portals all depend on the crappy data structures being used for walls. This has the unfortunate effect that once I start working on it the whole thing comes crumbling down and everything needs to be rebuilt, preferably in a more robust fashion.
Trust me, that code is not salvageable if optimization is the main concern..