Software rendering

[AnotherGrunt]

TL;DR version: Just start any Doom3 port in Linux with LIBGL_ALWAYS_SOFTWARE=true variable, crank down the resolution, and other parameters and it should work.

 

 

As you may know, DOOM3 or any other idSoft game starting from idTech3 onwards never ever used software renderer (CPU). It always relied on GPU to render the game. DOOM3 especially heavily relies on the graphic card because GPU shaders are used for rendering (at least then) groundbreaking game graphics (Shadow volumes, unified lighting model, blending and some in-shader executed special effects). If you didn't owned a reasonable enough graphic card back in the day, you were done. Just as I was. For this reason, I haven't been interested in DOOM3 very much. But lately, for some weird reason I've ended up testing software rasterizers in GZDoom (discussed in a different thread here). And guess what…

As I was already there, I had to try it. It is possible to load DOOM3 without an operational GPU? Well, yes! Sorta.

 

In GNU/Linux, OpenGL (and Vulkan and other graphics API) is implemented in library called Mesa3D. And alongside HW device drivers, there are three software driver implementations:

• swrast/softpipe –⁠ the legacy Mesa rasterizer and "a Gallium reference driver" both using just CPU. Probably slow but they are there.
• llvmpipe –⁠ "a software rasterizer that uses LLVM to do runtime code generation". Just softpipe but translated to x86/x86-64 machine code. Very fast, multithreaded, and able to use SIMD Extensions.

• OpenSWR –⁠ "a high performance, highly scalable software renderer targeted towards visualization workloads". Surprisingly even better than LLVMpipe, but if you have enough cores/CPUs. 

 

 

 

I think it's clear now, how to play any OpenGL-designed game using a software rasterizer. Simply start it using any Galium software driver. llvmpipe preferably. Either as statically linked library (libGL.so) or systemwide library but with llvmpipe forced by environment variable. I'm using dhewm3, so LIBGL_ALWAYS_SOFTWARE=true ./dhewm3 it is. That's all. Should work out-of-box. Even in 4K resolution, AA on and Ultra-Details as shader-effects as Gallium has pretty complete OpenGL implementation in software rasterizer. And probably like one frame per second, maybe two if lucky.

 

Just idTech4 engine renderer itself uses two parts, frontend and backend. Ideally, both as separate threads each on their own core sending GL commands to GPU where results are accumulated via additive blending¹. So if you want to try it without GPU, I recommend something like modern Intel i5 with two or four cores or relative equivalent. No less. And even so on the default setting, it will propably run like slideshow more than a game.

Recommended reading: Mesa Performance Tips.

 

 

 

 

 

 

 

And few performance tips of my own:

• Turn off anti-aliasing, multisampling and anisotropic filtering (r_multiSamples 0, image_anisotropy 1) right from the beginning.
• No texture filtering. image_filter =  GL_NEAREST. Or GL_NEAREST_MIPMAP_LINEAR. Big performance boost but with small resolution, it is like DOOM2 vanilla without 8-bit palette. And fonts are not adjusted for small resolution, so good luck with Cuneiform-like font decryption.
• Reasonable resolution. 800x600 is good, 640x480 is better. Fullscreen or windowed. It is even possible to switch it to 320x240. Not in the setting menu, but by cvar r_mode 1. And I recommend at least trying GL_NEAREST and 320x240 for fun sake. It's like DOOM2 but with DOOM3 visuals and guns. Crispy DOOM3. 320x240 is good on my mobile Intel i5 even with the best texture resolution, bump mapping and height mapping on. 640x480 is better without shadows. Surprisingly higher resolution isn't much visual gain but definitely a burden on CPU.
• No (shader) special effects as there are no dedicated GPU shaders for them.
• No texture compression and preCaching necessary as textures are already in memory and transfers should be fast.
• 16-bit color depth is better than 24-bit color depth, but I have suspicion X11 system-wide depth is irrelevant for internal color depth which is always RGB + Alpha. And MESA_NO_DITHER has no effect on dithering as this variable has been removed a few years back. So no idea here.
• No need to lower texture resolution (High details are good) and there is no need to disable texture-related operations (bump mapping) as they gain little performance (MESA doesn't have dedicated VRAM). But if you want totally potato mode, it is possible.

 

And little more advanced performance tips:

• export MESA_BACK_BUFFER = ximage –⁠ not completely sure but it might be necessary to enable rendering into XImages in order to XShm extension to work. Not sure.
• export GALLIUM_DRIVER=swr –⁠ if you want to try OpenSWR. Should be better if you really have something like AMD Ryzen Threadripper.
• export MESA_GLX_DEPTH_BITS = 16  –⁠ it is possible to set bit depth for the depth buffer. Lower values shall result in faster processing but possibly visible z-fighting.
• in file neo/renderer/tr_backend.cpp is routine called RB_SetDefaultGLState() responsible for OpenGL state initialization. Here we can set global GLStates:
• qglDisable( GL_DITHER ); //as recommended by Mesa Performance tips but at least I'm not able to spot any difference. It still looks dithered. Not sure why.
  qglDisable( GL_MULTISAMPLE );
  qglShadeModel( GL_FLAT ); // model shading is for someone with GPU power not for us ;-)
  qglPolygonMode (GL_FRONT_AND_BACK, GL_FILL); //not sure if only front-face culling isn't faster.
• here we can comment qglEnable( GL_BLEND ); to completely disable blending. It is really fast then. But as fonts are implemented in alpha channel it isn't very useful. But for ultimate potato mode, here it is.

 

If you have any other performance tips, please don't forget to share them here. All attached pictures are results of the Mesa3D library.

Edited October 31, 2021 by AnotherGrunt

[Tetzlaff]

Looks really interesting. With those crispy pixel visuals the Doom 3 light and shadows magic stands out even more.

[AnotherGrunt]

Well,

 

 

Quote

r_mode 1

There is not much difference between playing it in r_mode 1 on GPU and CPU. On my PC only difference is CPU fan constantly throttling. 

[Coopersville]

How Doom III was intended to be played. 

[GuyMcBrofist]

Looks cool. Got any shots of enpro plant?

[Average]

It looks much prettier that I would've espected, to be honest.  Just shows how strong the art design is.  Those 2nd and 3rd screenies above look particularly lovely.  How many years before YouTube decides that D3 was actually a good game? :P

[AnotherGrunt]

On 11/19/2021 at 6:12 AM, GuyMcBrofist said:

Looks cool. Got any shots of enpro plant?

Sorry, but I don't own D3 - Full version. Just demo. But as I don't like D3 gameplay very much anyway, for my purposes it is just enough.

 

On the other hand:

DarkMod is Doom3 Mod and it works in the same engine (idTech4). Surprisingly, as DarkMod looks far less complex, it's just that more demanding. To get (sometimes) a slideshow, settings have to be reduced almost to DOS game level. But it looks interesting at least. Doom3 is much better optimized and uses engine features (dynamic lighting and full-color range) little better.

Recommended on low resolution (512x384/288) and NN filter.

 

 

Edited November 21, 2021 by AnotherGrunt