MSI AB / RTSS development news thread

Important note for those who use RTSS to display data from PresentMon data provider (or use standalone PresentMon beta overlay). Recently released v0.6 version of PresentMon overlay/service may report incorrect and abnormally high GPU busy value under certain conditions. Intel are investigating it, in meanwhile just roll back to v0.5 beta or simply remove Intel's PresentMon overlay beta to force RTSS to use bundled console version of PresentMon instead.

 

Remnant II patch released on 26th Oct integrated Epic Games overlay into Steam version, so it may crash due to conflict of multiple overlays when RTSS is active. Good thing is that “The Texas Chainsaw Massacre” did the same a few months ago and I added the fix for such delayed Steam + Epic games overlay injection pattern. So if you’re affected, just update to the latest public 7.3.5 beta 5, it should fix the crash.

 

Found something pretty fishy on my system today. I noticed suspicious MSIAfterburner.sys file inside the application install folder, which is not a part of my original distributive. Initially I assumed that I got some malware, which tried to mimic MSI Afterburner, but after short investigation I nailed down the source of this suspicious driver: it was LibreHardwareMonitorAfteburnerPlugin, which I tested in the past as a part of quality control. It installs its own copy of WinRing0 this way.
So if you notice similar driver on your system and if you use that plugin, don't trigger panic mode

 

AW 2 is banned for purchase here. So I don’t care, Remedy will need to do quality control on their own.

 

Unlikely. They also throw this message when non-overlay applications (like antiviruses or Logitech GHub) are running in background. Looks more like some protection layer of their authentication implementation, which dislikes either all types of third party hooks or (most likely) LoadLibrary hooks. If that's the case, using default low application detection level in RTSS (instead of High, which some users are still trying to enable globally) should fix that.
But I can only guess without seeing the game myself.

 

I've added the next portion of improvements to correction formulas syntax in addition to recently added conditional expressions support.
Previously you could access each data source's statistics via local xmin/xavg/xmax/xswa variables only and such variables couldn't be accessed from other data sources. For example, to display min/max GPU temperatures, you needed to create two similar GPU temperature derived data sources and specify xmin and xmax inside the correction formulas. Those local variables will be deprecated in the next version, now you can use more robust functions for accessing each data source's statistics:

- statmin, statavg, statmax and statstd functions can be used to get global min/avg/max/std statistics for each data source and you can access it from other sources, e.g. you may use statavg("CPU power") + statavg("GPU1 power")) to calculate average CPU+GPU power consumption. Global statistics is collected during whole OverlayEditor's runtime session for synchronically polled sources only, for frametime and PresentMon's data sources it reflects the last 1024 samples only.
- swmin, swavg, swmax and swstd functions can be used to get sliding window based min/avg/max/std statistics for each data source, for example you may use swavg("CPU power", 8) to smooth CPU power consumption graph by calculating average CPU power with sliding window by 8 last sampled CPU power values. Maximum sliding window size is limited by each data source's ring buffer size, it is 512 samples for the most of OverlayEditor's data sources and 1024 for internal frametime and PresentMon's data sources. You may specify sliding window size as 0 to use whole ring buffer.
- percentile and percentilei functions can be used to calculate classic (linear) and integral percentiles on ring buffer contents, so you can use it to calculate 1%/0.1% low framerates on PresentMon's data or add you own percentile based metrics.

 

I cleaned the thread again and ask one more time to avoid using it for general questions. Please leave it for news only.

 

It is not in the database, MSI didn't request it to be added and AFAIK don't even sell such cards. So new update is not a priority and I cannot give you any ETA. It will be released when I have some spare time and _ABSOLUTELY_ nothing more important to do, at the moment I'm entirely focused on RTSS only.

 

No. It is intended to set integer framerate limit multiplier without altering currently set framerate limit divider.

 

I've recorded small video for discussion in a different place, and I think it is useful to post it here too. It will give you better understanding of hybrid scanline sync mode when you use it in conjunction either with front edge sync framerate limiter mode (recommended) or with back edge sync framerate limiter mode.

"Just a small video demonstrating how different framerate limiting modes used in hybrid scanline sync configuration affect tearline stability and simulation-to-render latency.

- Front edge sync framerate limiter mode is used in the beginning. Such configuration favors tearline position stability. Expected simulation-to-render latency is close to 1 frame
- Back edge sync framerate limiter mode is selected in the end. It drastically reduces simulation-to-render latency at cost of less stable and more jittery tearline position."



More details on setting up hybrid scanline sync mode can be found in this post.