MSI AB / RTSS development news thread

It is planned to release RTX compatible version it as public beta for everyone soon.

 

Soon is when it is done. It is not my personal property and it is up to MSI to decide when exactly, sorry.

 

Good news, I've just received a green light to release a public beta with GeForce RTX series support. Full changes list includes the following:


MSI Afterburner v4.6.0 beta 9 (build 13319)


· Added NVIDIA Turing GPU architecture support:
o Added voltage control for reference design NVIDIA GeForce RTX 20x0 series graphics cards
o Advanced GPU Boost control for NVIDIA GeForce RTX 20x0 series graphics cards. Extended voltage/frequency curve editor on GeForce RTX 20x0 family graphics cards allows you to tune additional piecewise power/frequency floor and temperature/frequency floor curves. Control points on those new curves allow you to control GPU Boost power and thermal throttling algorithms more precisely than traditional power limit and thermal limit sliders
o Hardware abstraction layer has been revamped to provide support for multiple independent fans per GPU due to introducing dual fan design on reference design NVIDIA GeForce RTX 20x0 series graphics cards and due to introducing native dual fan control in NVAPI. Both fans of NVIDIA GeForce RTX 20x0 can be monitored independently in hardware monitoring module now and can be controlled synchronically in manual mode
o Added NVIDIA Scanner technology support
· Improved hardware monitoring module:
o Added thermal offset for CPU temperature monitoring on AMD Ryzen 7 2700X processors
o “Pagefile usage” graph in hardware monitoring module has been renamed to “Commit charge”
· Improved hardware control shared memory interface. During the past years, external applications like MSI Remote Server were using this interface for tuning GPU hardware settings remotely from external applications. The improvements are intended to allow connecting external stress testing and automatic overclocking related applications to MSI Afterburner via this interface:
o Now voltage/frequency curve on NVIDIA Pascal and newer NVIDIA GPU architectures is accessible via hardware control shared memory interface
o New hardware control shared memory interface command allows MSI Afterburner to load hardware settings from external application without immediately applying new settings to GPU
o Added notification message, allowing external applications to notify MSI Afterburner about new command written to hardware control shared memory. Without the notification, MSI Afterburner is executing external commands on each hardware polling iteration like before. Please refer to SDK and MACMSharedMemorySample source code to see notification message usage example
o Added hardware identification info to GPU entries in hardware control shared memory. Hardware identification info allows external applications to reconcile own enumerated devices with logical GPUs enumerated by MSI Afterburner
o Now hardware control shared memory is refreshed on delayed fan speed readback events
· New bundled MSI Overclocking Scanner application in now included in MSI Afterburner distributive:
o MSI Overclocking Scanner is currently supported on NVIDIA RTX 20x0 series graphics cards under 64-bit operating systems only. On such systems you may activate the scanner directly from voltage/frequency curve editor window
o MSI Overclocking Scanner is powered by NVIDIA Scanner technology, which is using proprietary algorithms to quickly and reliably test manually overclocked GPU stability or find the maximum stable GPU overclocking in automatic mode with a single click. The scanner is using embedded NVIDIA test load to stress GPU. The scanner provides you two functional modes:
§ In test mode MSI Overclocking Scanner is stress-testing your manual GPU overclocking settings during approximately 5 minutes. The result is returned as GPU stability confidence level (0% - unstable, 100% - stable)
§ In scan mode MSI Overclocking Scanner is stress-testing and slowly increasing clocks on voltage/frequency curve points and this way automatically detecting the maximum stable GPU overclocking. The result is returned as modified voltage/frequency curve and average GPU overclocking in MHz
· Hardcoded voltage/frequency curve clock multiplier implementation has been replaced with heuristic multiplier detection in order to provide unified voltage/frequency curve control implementation for NVIDIA Pascal and newer NVIDIA GPU architectures
· Improved realtime voltage/frequency curve editor GUI scaling. Now GUI is scaled property when adjusting skin scaling with open voltage/frequency curve editor window
· Added Monolithic Power Systems MP2888A voltage controllers support to provide compatibility with future custom design MSI graphics cards
· RivaTuner Statistics Server has been upgraded to v7.2.0


RivaTuner Statistics Server v7.2.0 beta 5


· Added On-Screen Display performance profiler. Power users may enable it to measure and visualize CPU and GPU performance overhead added by On-Screen Display rendering. Two performance profiling modes are available:
o Compact mode provides basic and the most important CPU prepare (On-Screen Display hypertext formatting, parsing and tessellation), CPU rendering and total CPU times, as well as GPU rendering time (currently supported for Direct3D9+ and OpenGL applications only)
o Full mode provides additional and more detailed per-stage CPU times
· Improved built-in framerate limiter:
o Fractional framerate limit adjustment functionality is no longer power user oriented, now you may specify fractional limit directly from GUI
o Now you may click “Framerate limit” caption to switch framerate limiter to alternate “Frametime limit” mode. New mode allows you to specify the limit directly as a target frametime with 1 microsecond precision
o Added alternate framerate limiting mode, based on synchronization with display rasterizer position. Now you may synchronize the framerate to up to two independent scanline indices per refresh interval. Combining with power user configurable scanline wait timeout and graphics pipeline flushing options, those settings provide experienced users vendor agnostic ultra low input lag adaptive VSync, half VSync or double VSync functionality on any hardware
o Added power user oriented idle framerate limiting mode. Unlike traditional framerate limiting mode, idle framerate limiting mode is only affecting inactive 3D applications running in background. Idle framerate limit is specified as a target frametime with 1 microsecond precision. Idle framerate limiting mode helps to reduce power consumption when you minimize some heavy 3D applications and switch to other processes
· Various On-Screen Display optimizations and improvements:
o Added adjustable minimum refresh period for On-Screen Display renderer. The period is set to 10 milliseconds by default, so now the On-Screen Display is not allowed to be refreshed more frequently than 100 times per second. Such implementation allows keeping smooth animation when On-Screen Display contents are being updated on each frame (e.g. when displaying realtime frametime graph) without wasting too much CPU time on it
o Added alternate GPU copy based Vector2D On-Screen Display rendering mode implementation for Direct3D1x applications. New mode provides up to 5x Vector2D performance improvement on NVIDIA graphics cards, however it is disabled on AMD hardware due to slow implementation of CopySubresourceRegion in AMD display drivers
o Vector2D rendering mode is now forcibly disabled in Vulkan applications on AMD graphics cards due to insanely slow implementation of vkCmdClearAttachments in AMD display drivers
o Revamped geometry batching and vertex buffer usage strategy in pure Direct3D12 On-Screen Display renderer (currently used in Halo Wars 2 only)
o Added Vector2D rendering mode support to pure Direct3D12 On-Screen Display renderer
o Optimized On-Screen Display hypertext parsing and tessellation implementation
o Optimized state changes in OpenGL On-Screen Display rendering implementation
o Optimized state changes in Direct3D1x On-Screen Display rendering implementation
o Solid rectangles and line primitives in Direct3D8 and Direct3D9 On-Screen Display rendering implementations are now rendered from vertex buffer instead of user memory
o Improved OpenGL framebuffer dimensions detection when framebuffer coordinate space is selected
o Increased static command buffer size for Vulkan and pure Direct3D12 renders to increase amount of primitives rendered in On-Screen Display in a single pass
· Improved desktop duplication based desktop video capture implementation ( Windows 8 and newer OS versions):
o Now desktop video recording sessions do not stop on display mode switch or on switch to exclusive fullscreen mode. Such approach allows you to start capturing video on desktop then launch some 3D application and create a video file containing both desktop and 3D application’s video streams
o Improved video capture API allows video capture frontend applications (e.g. MSI Afterburner) to force desktop or 3D application video capture modes in addition to default mixed desktop/3D application capture mode
o Now desktop capture is using multhithreaded active busy-wait loop frame capture instead of timer driven frame capture in order to improve frame timing precision and resulting video smoothness. The previous timer driven frame capture can be enabled via configuration file if necessary
o Decreased desktop duplication timeouts in order to improve RivaTuner Statistics Server GUI response time under certain conditions during desktop videocapture sessions in timer driven frame capture mode
· Fixed On-Screen Display rendering in wrong colors when Vector2D mode is selected and Direct3D1x applications use 10-bit framebuffer
· Fixed Vulkan fence synchronization issue, which could cause GPU-limited Vulkan applications to hang due to attempt to reuse busy command buffer
· Active busy-wait loop in the framerate limiter module is now forcibly interrupted during unloading the hooks library to minimize the risk of deadlocking 3D application when dynamically closing RivaTuner Statistics Server during 3D application runtime
· Improved CBT hooks uninstallation routine to minimize the risk of deadlocking 3D application when dynamically closing RivaTuner Statistics Server during 3D application runtime
· Improved validation in OpenGL On-Screen Display rendering routine to minimize the risk of crashing OpenGL applications
· Changed OpenGL cleanup routines to improve compatibility with OpenGL applications using multiple rendering contexts (e.g. GPU Caps Viewer)
· Improved synchronization in 32-bit API hook uninstallation routines
· Added timeout to API hooks injection in CBT hook handler. The timeout is aimed to reduce injection related CPU overhead on some systems, related to high mouse polling rate combined with keyboard/mouse hooks installed by third party applications
· Interoperability D3D10 page flips on some systems are now filtered by framerate calculation module in OpenGL/Vulkan applications
· Added tri-state skinned buttons support in the skin engine
· Updated profiles list

https://www.guru3d.com/files-details/msi-afterburner-beta-download.html

Stay tuned!

 

Scroll the page down and read carefully.

 

It is not and was not intended for news and main G3D page, it is published in forum for testers.

 

No problem at all, thanks for trying.

 

Dear forum visitors,

I shared my impressions about NVIDIA Scanner technology from software developers’s point of view. Now I’d like to post the impressions from end user and overclocker POV.
I was never a real fan of automated overclocking because the reliability was always the weakest spot of overclocking process automation. NVIDIA Scanner is not a revolution like many newsmakers are calling it simply because different forms of automatic overclocking already existed in both NVIDIA and AMD drivers for couple decades, if not more (for example NVIDIA had it inside since CoolBits era, AMD had it in Overdrive). However, it was more like a toy and marketing thing, ignored by serious overclockers because everybody used to the fact that traditionally it crashed much more than it actually worked. Different third party tools also tried to implement their own solutions for automating the process of overclocking (the best of them is excellent ATITool by my old good friend w1zzard), but reliability of result was also the key problem.
So I was skeptical about new NVIDIA Scanner too and had serious doubts on including it into MSI Afterburner. However, I changed my mind after trying it in action on my own system with MSI RTX 2080 Ventus card. Yes, it is not a revolution but it is an evolution of this technology for sure. During approximately 2 weeks of development, I run a few hundreds of automatic overclocking detection sessions. None of them resulted in a system crash during overclocking detection. None of them resulted in wrongly detecting abnormally high clocks as stable ones. The worst thing I could observe during automatic overclocking detection was GPU hang recovered during scanning process, and the scanner was always able to continue scanning after recovering GPU at software level and lower the clocks until finding stable result. In all cases it detected repeatable approximately +170MHz GPU overclocking of my system, resulting in GPU clock floating in 2050-2100MHz range during 3D applications runtime after applying such overclocking. Even for the worst case (i.e. potential system crash during overclocking detection) Scanner API contains the recovery mechanisms, meaning that you may simply click “Scan” one more time after rebooting the system and it will continue scanning from the point before crash. But I simply couldn’t even make it crash to test such case and emulated it by killing OC scanner process during automatic overclocking detection. So embedded NVIDIA workload and test algorithms used inside the Scanner API look really promising for me. And it will be interesting to read impressions of the rest overclockers and RTX 2080 card owners who try NVIDIA Scanner in action in nearest days/weeks.

Stay tuned!

 

It is not a mistake, we've kinda pushed forward the 'availability' of the tool, to make it available for reviewers and RTX owners. So officially we did not release it, ahum. That status will change in the upcoming days.

 

Just found a nice portion of misinformation related to new version in EVGA forum from EVGA fanboys, and I’d like to comment it here:

“Remember that Unwinder said that he would never add support inside MSI Afterburner for multiple independent fans for cards like EVGA's iCX cards with Asynchronous fan technology? Unwinder even said that not only would he refuse to add support for EVGA's cards, but if MSI started using similar asynchronous fan control, Unwinder would decline to support it.

Well, it seems something has changed. Now that independent/asynchronous fans are now going to be showing up in reference NVIDIA designs, Unwinder has added support in Afterburner.”

…

And then NVidia added asynchronous fans and unwinder are his words and showed he will do what he is paid to do because money is more important than he wants to admit”


There is no any “if MSI started using similar fan control”. Actually, MSI started using dual independent fan control a few years before iCX was born. It debuted with in TwinFrozer V cooling on MSI GeForce GTX 980 GAMING 4G. And yes, even for native MSI cards with independent fan controller we didn’t provide support for it in MSI Afterburner due to one simple reason: safety and reliability. There was no native support for secondary fan control in NVIDIA driver and NVAPI and in order to implement independent fan control on such MSI non-reference card, it was necessary to work with fan controller directly at low level, bypassing NVAPI fan control mechanisms and it was and is unsafe and unreliable approach. The same applied to iCX and their proprietary fan controller, which was invisible to NVAPI and could be programmed at low level only.

The reason of adding secondary fan control now with RTX series is dead simple and it is even documented in the release notes (but those quoted users don’t seem to read it). Secondary programmable fan connector is assumed by reference PCB now and secondary fan control is now official part of NVIDIA driver and NVAPI.