Maes
I like big butts!
Posts: 8662
Registered: 07-06 |
Csonicgo said:
SO I ask, has anyone ever attempted to multithread any parts of the doom renderer, or convert any parts to ASM? Have there been any other serious optimization efforts done?
Affirmative on the first account. I have experimented with multithreading the drawing of wall and sky columns, sky and floor flats, and even masked columns (sprites, transparent textures) in Mocha Doom for at least a year now. You can find posts and reports about this all over DW.
I also tried several multithreading/work distribution strategies. In general, you might get a measurable performance boost only in very specific situations, and then rarely over 10-15% at regular resolutions, when the time to render to the screen is usually a fraction of normal processing. Higher resolutions make multithreading more appealing (I'm always talking about software rendering here), but still nothing to write home about.
Such situations include e.g. rendering many separate visible walls at high resolutions (provided you parallelize by walls and not by columns), or drawing thousands of sprites in something like NUTS.WAD (provided you have devised an efficient method for splitting work/dealing with overlapping/masked textures and avoiding overdrawing).
With all the possible variations and experimentations I've tried in Mocha Doom, I never achieved speedups over 25% on a quad core, because in maps where multithreaded rendering would help, there are often non-rendering related bottlenecks as well (e.g. NOT rendering NUTS.WAD's sprites AT ALL results in 90 FPS at a given resolution, serial rendering results in 60 fps, best possible multithreaded method for rendering sprites resulted in around 70-72 fps, after I got around all stability/display glitches). Even if I could render in zero-time with infinitely many cores, there would still be at most a speedup of 90/60 = 1.5 aka 50%. An overall speedup of 16.7% with just 4 cores seems about right.
Read Amdahl's law about that.
Other people who work on ZDoom/prBoom/etc. (C/C++ based ports) occasionally reported maximum gains of 10% or so with their own multithreaded renderers, so the general feeling is that they are not worth the effort.
As for the second part of your question... it has been debated to death over here. The general opinion (and probably quite close to the truth) is that, from a language standpoint, Doom wouldn't gain much from being coded entirely in ASM instead of C: there would be next to zero benefits for the complex gameplay code (other than making it fucking hard to debug), and the final renderer functions for the DOS version were written in ASM anyway, so none the richer.
Last edited by Maes on 01-04-12 at 17:19
|
01-04-12 16:52 
