MSI AB / RTSS development news thread

Dear forum visitors,

Two things I'd like to note. First, I won't directly comment the thread @ reddit (linked in the previous post) about Vulkan OSD in DOOM because some AMD fanboys (including our local LocoDiceGR who post under valantismp there) already crapped and derailed it, so discussion is flooded by trolls with false rumors about it as a part of GPP, about shady MSI tactics or about "crappy MSI AB hammering CPUs".
But I'll gladly refresh memory of our forum readers and remind that DOOM Vulkan OSD rendering specifics on AMD GPUs and higher than normal overlay related performance hit on such systems were documented in details since day one when we released Vulkan OSD support for this game on AMD graphics cards:

"Vulkan OSD should now work properly in Vulkan applications when frames are being presented from non-graphics queue. The only currently existing Vulkan application behaving this way is DOOM (only on AMD graphics cards), because it is asynchronously presenting frames form async compute queue in AMD codepath. Such presentation implementation makes Vulkan OSD rendering rather expensive in performance hit terms, because it requires forcible graphics and async compute queues synchronization. So now rendering OSD in DOOM/Vulkan on AMD cards may reduce performance by approximately 5% (the same applies to Steam FPS counter in DOOM/Vulkan on AMD), but I believe that there is some space left for optimization and it can be improved in future versions."

Second, my apologies on delaying 4.5.0 release a bit. Sadly I'm having some issues in my real life now, so currently I cannot invest too much time into MSI AB. We planned to release 4.5.0 right after Win10 Spring Creators Update but it is delated due to issues I mentioned above. I hope that I'll have a bit more free time on the next week so I'll be able to post 4.5.0 RC in this thread, then we'll put MSI AB 4.5.0 and RTSS 7.1.0 in Guru3D downloads and make them visible to update servers. It won't be much different to previously posted 4.5.0 beta 5, just some minor GUI fixes and one new feature:

- Fixed invisible hardware monitoring selection in hardware monitoring log viewer
- Plugin specific hardware monitoring graph names are localized properly in hardware monitoring log viewer
- Hardware monitoring correction formulas are more powerful now, now you can use values from sibling hardware monitoring graphs in formulas. For example, you may define x - "RAM usage" correction formula for Pagefile usage (Commit charge) to subtract current RAM usage from this value.

 

It is so brave to delete your own statement about "f#$%#g stupid MSI AB developer" _then_ to attempt to report a reply. I stand corrected, you're not a fanboy, you're just a troll who's words do not worth anything. Bye. Stay away from AB section please, I gave you the chance to change after your trolling in AMD driver threads in the past, you missed it.

 

Why? Your post on Reddit was completely out of line.

 

You're not a bad guy at all, but posting f#$%#g stupid MSI AB developer on one site and behave like normal here, really? I read it yesterday as well and indeed, you quickly deleted the comment after UW noticed it was you.

It's the unfortunate side effect of the anonymous web these days, especially on sites like Reddit. A little more respect gets you so much more. Nobody is looking for a fight or has beef with you mate, I suggest you count to three go do something fun and let's just leave it as it is.

 

Bad guy? It is Internet where you’re communicating with people you don’t know in your real life. There are no bad guys online, there are just bad words, which should be avoided when you’re talking to people you don’t know privately. I’m not a friend of you and you’re not a friend of mine. I see zero problems saying “hey, stupid mother#$%r” to one of my friends when we’re sitting with a bottle of whiskey and seeing each other, but that’s definitively not something to be said to the person I don’t know during some serious discussion, because the meaning will be painted into drastically different color. Once you understand it and change your language, feel free to come back.

 

That's not something that can be fixed on your driver side, Matt. That's entirely dependent on this game's 3D engine implementation.

 

The same ID engine, the same rendering behavior, the same issue. Sounds logical, isn't it? I'd like to focus on 4.5.0 instead, sorry.

 

Release candidate for MSI AB 4.5.0 is available for download:

http://download-eu2.guru3d.com/afterburner/MSIAfterburnerSetup450Build12819.rar

I've documented the differences from the previous beta 5 a few posts above. Full changes list includes:

MSI Afterburner v4.5.0:

· Minimum, average, maximum, 1% low and 0.1% low framerates are now displayed in On-Screen Display with special text formatting tags introduced by new RivaTuner Statistics Server. The tags are allowing On-Screen Display clients to display independent benchmark statistics simultaneously for multiple running 3D applications instead of displaying foreground 3D application statistics only
· Improved default MSI Cyborg White skin. Monochrome on / off states of fan speed auto button were hardly identifiable before, they are more contrast now
· Added power user oriented restore points system. Experienced users may use new /backup and /restore command line switches to create multiple named restore points containing full backups of MSI Afterburner’s settings (including hardware profiles and custom hardware monitoring plugin configurations) and restore settings from any previously created restore point if necessary
· Improved hardware monitoring module:
o Improved built-in performance profiler. Now you may enable “Show profiler panel” option is the context menu of hardware monitoring window to see additional panel with detailed per-sensor polling statistics in hardware monitoring window status area. Polling statistics visualizes information about the slowest polled sensors with maximum polling time, so power users can easily identify problematic sensors eating most of CPU time on each polling period (e.g. abnormally slow GPU power sensor in some versions of NVIDIA drivers)
o Improved correction formulas support. Now in addition to “x” variable representing current data source the formulas may also use sibling data sources. For example, you may use “x – “RAM Usage”” correction formula for “Pagefile usage” (commit charge) data source to subtract RAM usage from displayed value
o Fixed incorrect tracking markers rendering on the graphs dynamically added to hardware monitoring module
o Fixed incorrect tracking markers rendering when monitoring ring data buffer is full
o Added experimental support for Intel i7 and i9 7XXXX LGA2066 CPUs
o Added CPU package power monitoring for Intel CPUs
o Minimum sampling interval for CPU usage calculation has been reduced from 1000ms to 100ms
o Original RivaTuner’s monitoring history fragment selection and selected fragment processing functionality is back! Now you may hold <Shift> and press left mouse button on initial desired position in hardware monitoring window to begin fragment selection, then drag mouse cursor to desired final position and release left mouse button to select a fragment. The following functionality is available for selected fragments:
§ When the fragment is selected, minimum and maximum displayed values are estimated within selected fragment only. This feature can be used if you don’t need the global minimum and maximum values, estimated during whole monitoring session, and wish to see local minimum and maximum values estimated within some shorter period of time (e.g. during benchmark application runtime only)
§ When the fragment is selected you may use the context menu of any graph to set tracking marker into the local minimum or maximum position within the selection. This feature can be used to automate the process of identifying and visualizing the moments of reaching peak values (e.g. peak GPU temperature) on desired fragments
o Improved monitoring plugins architecture:
§ Added plugin descriptions to plugins selection window
§ Added new SetupSource API function allowing you to configure the plugins. This function is allowing you to customize the plugins either globally from plugin selection window (e.g. configure whole list of data sources exported by each plugin) or customize desired data source only directly from corresponding graph properties window (e.g. change network download rate units from MB/s to KB/s). SetupSource function usage is demonstrated in SDK in updated AIDA64 and PerfCounter plugins
§ Added new GetHostAppProperty API function allowing the plugins to retrieve various properties from the host application (i.e. MSI Afterburner), e.g. retrieve GUI color scheme specific to currently selected skin. GetHostAppProperty function usage is demonstrated in SDK in updated AIDA64 and PerfCounter plugins
o Improved monitoring plugins:
§ Now the plugins store user customized and built-in default configurations in separate files, so your custom plugin settings won’t be lost on new version install
§ Added configuration GUI for AIDA64, HwInfo and PerfCounter plugins. Each plugin’s user interface is allowing you to edit the list of sensors exported by each plugin, export full list of available sensors to a text file, customize each sensor’s properties or reset plugin settings to defaults
§ Improved PerfCounter plugin:
· Added support for performance counters with non-localized names (e.g. “GPU Engine” under Windows Fall Creators Update)
· Added support for dynamic data sources. Dynamic data sources are not validated during creation, such sources are allowed to export no data until some condition is met (e.g. “CPU usage” performance counters specific to some target process export data only when the process is running)
§ Improved SMART plugin:
· Added airflow temperature SMART attribute support for Intel/Samsung SSDs.
§ Added new CPU plugin:
· The plugin fully duplicates MSI Afterburner’s built-in CPU temperature monitoring implementation (with the only exception of AMD Ryzen codepath, which cannot be open sourced due to NDA) and shows third party plugin developers how to implement low-level CPU specific sensors in plugins using CPU MSR registers and PCI configuration space access API
§ Added new GPU plugin:
· The plugin shows third party developers how to extend MSI Afterburner’s GPU monitoring functionality and implement own GPU specific sensors in plugins using GPU enumeration and identification API. The plugin is demonstrating implementation of D3DKMT GPU performance counters providing unified vendor agnostic per-engine GPU usage, dedicated and shared memory usage monitoring
· Fixed issue in context help system, which could cause the tooltip to flicker when it was displayed below mouse cursor
· RivaTuner Statistics Server has been upgraded to v7.1.0

RTSS v7.1.0:

· Added On-Screen Display locking mechanism for third party On-Screen Display client applications. The mechanism is aimed to eliminate unwanted On-Screen Display flickering effect when some client application is performing risky two-stage On-Screen Display refresh while On-Screen Display is being actively refreshed by another client. Please take a note that third party On-Screen Display clients must be also updated in order to use this mechanism and get rid of flickering
· Added new text formatting tags support for displaying minimum, average, maximum, 1% low and 0.1% low framerates in benchmark mode. The tags are allowing On-Screen Display clients to display independent benchmark statistics simultaneously for multiple running 3D applications instead of displaying foreground 3D application statistics only
· Now it is possible to adjust frametime history graph size via RivaTuner Statistics Server properties. Please take a note that you may use positive values to specify the size in pixels or negative values to specify it in symbols
· Now it is possible to toggle benchmark mode state from RivaTuner Statistics Server properties. However, third party benchmark client applications like MSI Afterburner are still required to toggle benchmark mode state with hotkeys during 3D application runtime and to save benchmark results to a text file
· Now it is possible to toggle between averaged or instantaneous calculation modes for peak (i.e. minimum and maximum) framerates for benchmark mode via RivaTuner Statistics Server properties
· Fixed issue in context help system, which could cause the tooltip to flicker when it was displayed below mouse cursor
· Fixed screen capture feature in On-Screen Display preview window when RivaTuner Statistics Server is installed in UAC-protected folder
· Updated SDK:
o Now RTSSSharedMemorySample sample code is demonstrating the implementation of On-Screen Display locking and flickering filter
· Updated profiles list

We'll put in into Guru3D and MSI download sections and make it visible to update servers a couple days later. Separate installer for RTSS 7.1.0 will be also available once MSI AB 4.5.0 is released officially.

 

Considering that many inexperienced users tend to misinterpret Commit charge / Pagefile usage graph, it worth stating that you can add alternate pagefile related performance counters in PerfCounter plugin. Paging File \ % Usage performance counter can be used to monitor each independent swapfile (or total swapfiles) usage in %. You may also use correction formula and multiply value in % on actual pageile size to get reading in bytes/MB. HDD read/write rate monitoring for the drive hosting your swapfile can be rather useful as well.

 

There is a discussion of RTSS OSD in Vulkan on AMD cards in DOOM on reddit. Some useful facts related to Vector 2D OSD rendering mode usage are also covered there. I've already documented it here in the past, but I think it worth quoting it here one more time. Please keep it in mind while using Vector 2D mode:

"Vector2D is not the only OSD rendering mode affecting DOOM's Vulkan implementation on AMD cards. Forcible compute & graphics queue sync is performed for any OSD rendering mode in RTSS for this game (and BTW for Wolfenstein the new colossus, using very similar engine end renderer), it is just less noticeable in Vector / Raster 3D modes, but it still hurts performance due to forcible sync performed on each frame. Also, as it is documented in RTSS context help, Vector 2D is a compatibility rendering path with much more slower implementation comparing to Vector / Raster 3D modes. So it is intended to be used at application profile level and only for 3D applications/engines incompatible with Vector / Raster 3D modes. Enabling it globally and for everyday usage is definitively not the best idea. The only advantage of Vector 2D mode is that it is based on simple 2D backbuffer clear operations for text rendering (for example "+" symbol in the text is represented by clearing 2 crossing rectangles in a backbuffer). Due to its 2D nature such implementation doesn't require complex 3D pipeline reconfiguration for OSD rendering, so it has close to zero chances to conflict with some sophisticated 3D engines. However, depending on optimization of 2D backbuffer clear operations in a D3D/OGL driver, it can be much more performance demanding than the rest modes. For example, it is very fast for NVIDIA D3D9 driver, relatively fast on NV/AMD D3D 1x drivers, but really slow on AMD OGL drivers (probably AMD think that backbuffer is normally cleared just once per frame and don't feel that optimizing multiple backbuffer clears is important in their OpenGL ICD). So summarizing it, avoid enabling Vector 2D mode unless it is absolutely necessary (i.e. unless some game completely refuse to render OSD in Vector / Raster 3D modes)."