I yet again improved the texture discard bias algorithm in v1.32.2.20.
The goal is to try and avoid as much as possible sudden bias jumps to 5.0, when hitting the low free VRAM limit, and to further reduce the yo-yo effect in low free VRAM conditions.
The discard bias is now influenced by three, distinct mechanisms:
- The free system RAM. When the available RAM is low, the discard bias is increased to decrease the resolution of GL images (each such image is stored both in RAM and in VRAM). This algorithm is also influenced by the "Texture memory" slider in the Graphics tab (GPU/GL features sub-tab) of the Preferences floater: the viewer will also make it so that the GL images memory usage does not exceed this setting (which specifically and only applies to GL images, not to bound textures since those only consume VRAM, even if they also most often have a GL image associated to them).
- The amount of VRAM used, as calculated by the viewer. This amount accounts for the vertex and frame buffers as well as the textures, and the VRAM usage limit for the bound textures is adjusted to fit the VRAM with a security margin (this is the same "low free VRAM" margin as used for the last mechanism below). The viewer computes in real time how much bound textures memory it can use at the maximum to avoid eating up too much VRAM, and when the bound textures memory usage overshoots that (varying) limit, it increases the discard bias to reduce the rendered textures resolution. The novelty in v1.32.2.20 is that the bound textures memory usage limit is computed and adjusted in real time, instead of relying on a fixed, user-configurable setting that won't account for VB and FB memory usage.
- The amount of free VRAM, as reported by the OpenGL driver. This last mechanism sadly cannot apply when the OpenGL driver does not provide a call to report the free VRAM (such as Intel's drivers), or when the reports are plain bogus (as seen with proprietary AMD drivers when you got both a discrete and an integrated GPU in your PC) and you therefore ticked the "Disable VRAM checks" in the preferences. This mechanism is also of no concern whatsoever for iGPUs and APUs since they do not have VRAM and won't suffer from stutter and freezes seen with dGPUs when their data spills over to the RAM. This mechanism increases the discard bias when the "low free VRAM" margin is about to be reached, and maxes out the bias (to 5.0) when free VRAM falls below that margin. Sadly, the free VRAM reports by the driver are not very accurate (e.g. VRAM fragmentation may cause a lower amount to be reported, and the updates to the free VRAM numbers may be not too frequent, depending on the driver implementation, causing slow reaction time). Yet, for dGPUs, this mechanism is a good way to avoid freezes and sever stutter in frame rates, as well as slower frame rates after some buffers or textures have been spilled out in RAM (and even after VRAM is freed).
Note that, in v1.32.2.20, any change to the various settings impacting these mechanisms (VRAM spinner, Texture memory slider, and various debug settings) are taken into account in real time, allowing you to adjust them to best fit your needs. For example, if you want to run simultaneously two sessions of the viewer and not see texture trashing happening, you may want to artificially limit the VRAM amount in the corresponding spinner to half of your actual VRAM...
The texture console was also changed: the frame buffers memory usage was added ("FB:" number, in MB), and the "Free VRAM" number is now only shown when the corresponding OpenGL call exists and you did not disable the VRAM checks from the settings; the free VRAM number also sees an exclamation mark printed next to it when the minimum free VRAM margin is reached.
|
