renderer: rework tone mapper and SSAO enablement

[illwieckz]

Rework tone mapper and ssao enablement.

Extracted from:

• renderer: add non-bitwise alternative for u_Color and u_ColorModulateColorGen #1570

[illwieckz]

Note that it renames r_tonemap to r_toneMapping to be consistent with other cvars, fell free to comment about that.

Other related r_tonemap* cvars were not renamed, but maybe that's fine as they may be seen as options for the tonemap.

[VReaperV]

This still has the issue of not being able to instantly turn tonemapping on/off.

[VReaperV]

Other related r_tonemap* cvars were not renamed, but maybe that's fine as they may be seen as options for the tonemap.

The naming should be consistent since that works better with console auto-complete.

[illwieckz]

The naming should be consistent since that works better with console auto-complete.

Now unified.

[illwieckz]

This still has the issue of not being able to instantly turn tonemapping on/off.

I'm not considering this an issue. I can see the annoyance when testing stuff, but normal usage never randomly switches such option.

For the annoyance of having to do a vid_restart, at some point we may implement a mechanism that automatically recompiles GLSL shaders when said shaders don't require any file to be loaded, this would benefit most screen shaders.

[slipher]

This still has the issue of not being able to instantly turn tonemapping on/off.

I'm not considering this an issue. I can see the annoyance when testing stuff, but normal usage never randomly switches such option.

I don't agree with the assumption "normal users should never want to toggle settings". How are you supposed to decide whether you want to use a setting without turning it off and on to compare the two configurations?

[illwieckz]

Using an uniform to disable the feature means the code is actually executed on hardware not supporting modern branching and then the renders still have to wait for the compute to be done and discarded. Here the disabled feature was still eating 30% of the performance on the testbed I was using when noticing it

I'm not saying it would not be nice to be able to toggle that without any vid_restart, I'm saying using an uniform for that is not a good solution because it fails to actually disable the code on some hardware. We better implement something like lazy permutations, allowing such permutations to be lazily (re)built without having to do a vid_restart.

[VReaperV]

For the annoyance of having to do a vid_restart, at some point we may implement a mechanism that automatically recompiles GLSL shaders when said shaders don't require any file to be loaded, this would benefit most screen shaders.

The problem here is that headers need to be regenerated. Shaders sources are all in a hashmap for built-in shaders.

[illwieckz]

That's part of implementation details to be discussed there:

• Rebuilding GLSL shaders that don't need a vid_restart #1580

[VReaperV]

Using an uniform to disable the feature means the code is actually executed on hardware not supporting modern branching and then the renders still have to wait for the compute to be done and discarded. Here the disabled feature was still eating 30% of the performance on the testbed I was using when noticing it

That is why I suggested just disabling based it on the GLSL version. Clearly such hardware is incapable of running it at a playable framerate when it's enabled.

[illwieckz]

That is why I suggested just disabling based it on the GLSL version. Clearly such hardware is incapable of running it at a playable framerate when it's enabled.

One thing is that I don't know what kind of hardware can truly branch. For example AMD TeraScale (the previous-to-current architecture) is GL 4.5 but has some VLIW architecture and I'm not sure they are good at branching because of that. I can test on them, but in general I prefer to skip building the disabled code.

[VReaperV]

One thing is that I don't know what kind of hardware can truly branch.

Proper branching at ~GTX 600 series, so probably around the same for AMD. Plus, all of those Terascale GPUs are at least a decade and a half old.

[illwieckz]

In fact, tone-mapping is cheap on high-end GLSL 120 cards, so, GLSL version doesn't matter. What matters is: is the hardware low-end or not?

Here is an ATI RV570 (Radeon X1950 PRO), it only supports OpenGL 2.1 with GLSL 120, but it has no problem at running the tone mapper:

resolution	preset	r_toneMapping off	r_toneMapping on; r_highPrecisionRendering on
640×480	lowest	310 fps	282 fps
640×480	low	295 fps	270 fps
1024×768	lowest	153 fps	138 fps
1024×768	ultra (image 256)	65 fps	64 fps
1280×720	lowest	132 fps	116 fps
1280×720	low	125 fps	113 fps
1280×720	medium	84 fps	81 fps
1280×720	high (image 256)	83 fps	80 fps
1280×720	ultra (image 256)	60 fps	58 fps
1920×1080	low	60 fps	60 fps
1920×1080	medium	40 fps	38 fps

This runs at 80 fps on “HDReady” 1280×720 on medium preset, or 60 fps on “FullHD” 1920×1080 on low preset. on medium preset it only eats between 1 and 3 fps. When testing presets above medium I still set the same image size as low or some images may be broken and performance may be unreliable. But with fairly acceptable image resolution 256×256, this card can run maps on ultra preset (with deluxe mapping, relief mapping, etc.) and tone mapping at 1280×720. Of course a real game with plenty of models and particles will differ a bit, but the GLSL version is definitely not a good determinant.

It should be noted that this card is currently plugged in as a secondary card and is rendering through DRI_PRIME (so basically transferring the render through PCIe in order to be displayed by another card), which is expected to reduce performance.

This is actually a good example of GL 2.1 card that is brings a very nice playing experience. The 0.55.2 benchmark gets 50 fps on 1024×768 with ultra presets and tone mapping, and 67 fps on 1024×768 with ultra presets and tone mapping, if I reduce images to 256×256 of course.

Actually it looks like this card even does branching properly, as the non-latched implementation also shows the frame rate difference on disablement.

So we can't use the GL or GLSL version to detect the card would suffer from tone mapping, we would have to resort on card family detection if we want to disable the feature (that would be really annoying).

But the good thing is that by doing this testing I noticed that frame rate was the same with or without tone mapping on low and lowest presets, and that the render looked the same. So I just got a revelation.

Tone mapping requires r_highPrecisionRendering to be enable, and this cvar is latched and will always be (changing it requires to recreate the frame buffers), so we can use that cvar to prevent the compilation of the tone mapping code on low and lowest presets which are expected to be used low-end cards not supporting tone mapping.

Actually I would prefer to disable the build of the tone mapper when the tone mapper is actually disabled, this is much much cleaner.

[VReaperV]

Something like an #ifdef for r_highPrecisionRendering would be fine?

[illwieckz]

Something like an #ifdef for r_highPrecisionRendering would be fine?

That's what I just did. This may be an acceptable compromise for now, but this is ugly. 🫣

The day we can do some lazy shader permutation rebuild I will likely revert that.

[VReaperV]

The day we can do some lazy shader permutation rebuild I will likely revert that.

Revert to what?

[illwieckz]

The day we can do some lazy shader permutation rebuild I will likely revert that.

Revert to what?

Revert to my first implementation of the commit:

#if defined(r_toneMapping)
…
#endif

[VReaperV]

So we can't use the GL or GLSL version to detect the card would suffer from tone mapping, we would have to resort on card family detection if we want to disable the feature (that would be really annoying).

Another option is to run this shader a few times while measuring performance to see if it has an effect, then cache the result in some cvar (and only check again if the detected hardware changes).

[VReaperV]

LGTM