MSI AB / RTSS development news thread

Searching is not hard.
https://forums.guru3d.com/threads/rtx-3080-custom-fan-profile-issue.434499/

 

Guys, I’m afraid that we have to stop waiting for a fix from NVIDIA side for RTX 30x0 series fan speed reporting issue, it is taking way too long. So here is new beta with small “hack”, which we’ll use to bypass the problem from our side until the fix arrives form NV side (if it ever arrives). The root of this problem is normalized fan speed reporting, which NVIDIA decided to introduce with 30x0 series cards. Fan speed % reported by NVIDIA driver and displayed in _any_ monitoring software is no longer reflecting the real fan speed %. Now it is normalized value, which is mapping vendor specific RPM limits to GUI min%-max% fan speed range. For reference design min% is equal to 30% and max% is 100% and RPM limits are properly mapped to that range. But the chaos began when partners started altering reference cooling system and tune their RPM limits, while leaving min 30% limit unchanged. As a result, on some custom design cards min% is still set to 30% and you can see it as the minimum fan speed for automatic fan control mode, but the real fan speed can be MUCH slower or faster. This is confusing users and causes effects of weird jumps in fan speed, i.e. you can see a few % (or even a few dozen %) difference between the speed you set and the speed you see reported back by driver. Until it is addressed by driver and VGA BIOS updates, we fix it the following way:

- Afterburner will stop relying on NVIDIA’s native fan speed reporting in monitoring module for 30x0 series cards as soon as you enable manual fan speed control (i.e. set fixed fan speed of software fan curve). In this case it will simply display you the last programmed fan speed instead of reading back normalized (and possibly distorted) fan speed value from NVIDIA driver. NVIDIA’s normalized fan speed monitoring is still being used as soon as you enable default automatic fan speed control, because it is the only way to read fan speed in this case. Just keep in mind that in this case you’ll always see fan speed floating inside (30%-100%) range, and it may not match the real fan speed range. So always pay attention to tachometer readings.

- Afterburner will stop relying on NVIDIA driver’s native fan speed limits for GUI on 30x0 series cards. Currently they don’t reflect the reality on many non-reference cards.

In addition to fan speed problem workaround new beta also adds an ability to force legacy OC Scanner usage on 455+ and newer drivers on Pascal and Turing series GPUs. New scanner API has limited support for pre-Ampere GPUs, e.g. it is currently unsupported on Pascals and seem to be broken on Turings in SLI configs. So you may force old legacy scanner usage, if your system is affected. To force it set LegacyOCScanner to 1 in [NVAPIHAL] in MSIAfterburner.cfg

Grab new beta here:

https://download-eu2.guru3d.com/afterburner/[Guru3D.com]-MSIAfterburnerSetup463Beta3Build15854.zip

 

Yes. For auto mode NVIDIA’s monitoring implementation is used, so it may be incorrect if VGA manufacturer altered reference fan limits.

 

I do not own RE3 and do not plan to buy it, sorry. Plese don't use this thread for general troubleshooting questions, this way important info anout new releases is just getting lost in something, which is not imprtant for anyone else. Create own threads for things like that.

 

No, it is not in progress.

 

New RTSS beta is around the corner. Many changes inside this build are related to scanline sync. But a lot of changes are also aimed to ... educate reviewers:

· Various Vulkan bootstrap layer and Vulkan overlay renderer cleanups aimed to improve compatibility with Vulkan validation layer
· Improved compatibility with multithreaded Direct3D1x applications, using multiple Direct3D devices and swapchains and concurrently presenting frames on them from different threads (e.g. Windows Terminal)
· Added RenderDelay profile compatibility switch, allowing delaying On-Screen Display initialization and rendering for some applications when it is necessary (e.g. Resident Evil 3 in Direct3D11 mode when HDR mode is enabled)
· FCAT overlay update rate is no longer limited to overlay content update rate in offscreen overlay rendering mode
· Added new hypertext tags for displaying process specific 1% low and 0.1% low framerate graphs. Now multiple simultaneously running 3D applications can display their own independent 1% low and 0.1% low framerate graphs instead of foreground 3D application’s 1% low and 0.1% low framerate graphs in the previous version
· Improved 1% low and 0.1% low framerate graphs rendering implementation for graph and diagram rendering modes. The graphs showing the history of 1% low and 0.1% low framerate changes has no statistical sense, so now RivaTuner Statistics Server is showing you more informative dynamic histogram of sorted and the most slowest immediate framerates with highlighted 1% or 0.1% areas on it. For barchart rendering mode 1% low and 0.1% framerate graphs still display the current value like before
· Added new “moving bar” rendering mode for FCAT overlay. New mode is aimed to simplify visual identification of tearline position and it can be used when calibrating Scanline Sync settings
· Added new “Frametime calculation point” option to “General” application properties. This option is aimed to help those who try to directly compare frame rendering start timestamp based frametimes with frame presentation timestamp based frametimes. Please refer to new option context help to get more detailed info
· Added new “Percentile calculation mode” option to “General” application properties. This option is aimed to help those who try to compare different implementations of 1% low and 0.1% low framerate metrics in different applications. Please refer to new option context help to get more detailed info
· Added new “Framerate limiting mode” option to “General” application properties. Two alternate framerate limiting modes selectable with this option (“front edge sync” and “back edge sync”) are intended to be used in conjunction with scanline sync mode. Using those options in tandem allows enabling so called hybrid scanline sync mode. In this case actual target scanline synchronization is performed just once for initial tearline positioning then tearline position can be steered with high precision system clock. This option can also help those who try to compare flatness of frametime graphs measured at different points (frame start vs frame presentation timestamp based)
· Added power user controllable passive wait stage to framerate limiter’s busy waiting loop. It is aimed to help those who is ready to sacrifice timing precision in favor of lower CPU load
· Improved power user oriented scanline sync info panel. New performance counters are aimed to improve the process of scanline sync calibration and help you to diagnose tearline jittering. The following new performance counters have been added to it:
o Sync start – index of scanline where 3D application called 3D API frame presentation function and scanline sync engine started the process of waiting for the target scanline
o Sync end – index of scanline where scanline sync engine ended the process of waiting for target scanline. Ideally it must be as close to expected target scanline as it is possible
o Present – index of scanline where 3D API frame presentation function was actually called after performing scanline synchronization. For normal scanline sync modes it is pretty close to the previous performance counter. For hybrid scanline sync mode it can drift depending on your framerate limit, if it doesn’t match with your display refresh rate
o Present latency – time spent inside 3D API frame presentation call