Yagisan
Mini-Member
Posts: 69
Registered: 01-06 |
DaniJ said:
Looks like I'd better try and clear things up. There is a fair amount of half truth and just general misinformation in this thread.
Ouch - that's harsh.
DaniJ said:
Firstly, lets put asside the temporary, naive resource search routines. They are indeed a big (unnecessary) bottleneck that we are well aware of but haven't addressed yet because we are still radically redesigning the engine architecture. For example, systems that were game-side have moved through the engine and are now in plugins and conversely, some plugins have been swallowed up by the engine. In other words, the architecture is in a state of flux, so spending too much time on optimizing at this point would (largely) be a waste.
Profiler logs please. Doomsday has way to much premature optimisation in it. Relatively speaking, how can you be sure this is the big bottleneck.
DaniJ said:
Threaded Optimization:
The problem here is that Nvidia's threaded optimization quite simply does not get on with applications that frequently update vertex arrays (as Graf encountered). Way back around the version 1.5.x era (I think) Doomsday's renderer was enhanced so that rather than send a stream of "immediate mode" GL, API calls, instead our renderer would maitain (large) arrays and then upload large chunks of data for a given render frame in one go. Back then, this was a pretty good idea and it noticeably improved frame rates. Fast forward to 1.9.0-beta5 (a year ago) and the situation is very different. What was once a good optimization is no longer so. Now, I'm no Nvidia driver developer but I would suppose that vertex arrays are now rather low on the list of priorities given that there are better alternatives which most current applications will be using anyway.
So, a couple of versions ago I began work on removing the use of global vertex arrays and as of 1.9.0-beta6 we no longer upload data using them. The exception to this is the model renderer which will still use them as it is quite convenient to do so.
I'll try to ignore the bit that feels like nvidia fanboism (why justify what changes they make ? - just accept that they do change and sometimes - much like doomsday releases - it's not for the better), what your saying is, only the models use vertex arrays, and the rest of the engine doesn't. So how does the rest of the engine talk to opengl ? I don't see any newer methods in the codebase such as glsl, therefor with a little deductive reasoning, you must be using something like say immediate mode.
DaniJ said:
If therefore you are not using 3D models with Doomsday, you won't be affected by the threaded optimization issue. If you do and you are affected by this problem then you currently have two options:
a) Disable the transfer of models using vertex arrays in Doomsday using the -novtxar command line option.
b) Disable Nvidia's threaded optimization when playing Doomsday via the Nvidia driver control panel.
This looks awfully like you are in fact confirming what I said.
DaniJ said:
Come the scheduled renderer rewrite, this problem will be addressed by redesigning how models are handled so that all T&L is done on the GPU.
And on the vast majority of GPU's (which by volume shipped are intel chips) how will this work ?
DaniJ said:
"Immediate mode" in GL DOOM renderers:
Strictly speaking there is nothing at all wrong with immediate mode drawing. The notion that drivers might not handle it all that well I find somewhat ridiculus so lets put that argument to rest. Yes, most modern games do very little drawing via immediate mode but if an implementation were to seriously handicap immediate mode there would be uproar.
I've never said there is anything wrong with immediate mode, just that a certain driver vendor no longer optimises their drivers for it. It really is an easy test, benchmark on the extact same system, just changing the driver versions between runs. Watch the frame rate start to dip, then plateau out in recent releases. This particular vendor tends to optimise for the hardware they are currently selling, drops support for older, yet still working gpu's, from their drivers, and is known to have their drivers cheat in benchmarking by detecting popular benchmarking applications, and changing internal settings. If you were this vendor, would you want to optimise for older applications, or your new expensive hardware no one needs (yet). I'm sure they get a lot of sales from people that feel their application is now too "slow".
DaniJ said:
As far as I am concerned there is nothing "broken" that needs fixing in the current Doomsday renderer. There are some issues to be worked out certainly but given that the fundamental design of which is geared towards hardware which 99.9% of users won't be using anyway, resolving those issues would be wasted effort. It makes far more logical sense to spend that time on a new renderer designed to take advantage of modern systems, which is what we intend to do.
EDIT: Spelling (whoops).
Issues are brokenness. I argued that the problem was not in doomsday. you posted and basically argued the problem is in doomsday. Which is it ?
|
06-06-09 22:14 
