MSI AB / RTSS development news thread

There were no changes in this area in the last RTSS beta and it is not a new functionality. Cannot confirm it on my system either. Check if core isolation/HVCI is disabled, as is breaks dedicated OCMailbox clock reporting implementation.

 

Did I mention AB? Everything I said apply to RTSS internal HAL and clock frequency estimation in general.

 

You're free to continue using HwInfo or debug open source implemntation of OverlayEditor on your system where you have the problems. Or buy HwInfo core and create HwInfo core based plugin and share it with community. It costs just around 7K euro per YEAR. I cannot allow myself to invest that much in a project I provide to anyone for free.

 

Installed OS with core isolation enabled and confirmed that wrong clocks after resuming from sleep are the case of active HVCI blocking OC mailbox bus reporting interface. It is easy to see if OverlayEditor's HAL can use OC Mailbox for bus clock reporting on a system by running tiny DbgView tool and seeing what HAL is logging there during RTSS startup.
Typical effects of enabled HVCI in the log are:

- Zeroes reported as nominal clocks in CPUID.16H due to virtualization
- Line with OCMailbox bus clock is either missing or contains abnormally low bus clock due to virtualization

In both cases realtime base clock -> bus clock estimation will be used instead of allowing CPU/BIOS to report it preciesly via OC mailbox. I guess I can bypass screwed clocks after resuming for this case rather easily by forcing recalibration on resume from sleep event.

 

All,

AMD Radeon 7900 launch day is approaching. Previously AMD were not too focused on ironing compatibility with third party software products unlike green vendor, but this time they pleasantly surprized me. Got contacted by part of AMD SW team on MSI AB compatibility with upcoming GPU family, they want to ensure compatibility prior to product launch. Working on providing software support on day one is a nice thing and definitively right way to go so I can only welcome it. Anyway, just like NVIDIA's 40x0 was happliy backward compatible from NVAPI side with 30x0 series (which means it didn't require major software updates to got it working with new GPU architecture), new AMD GPUs also seem to be backward compatible on ADL API side with the previous RX 6x00 series cards. Which effectively means that majority of overclocking/monitoring software supporting RX 6x00 series cards will start working with 79xx out of box. According to AMD testing most of AB functionality works and the only locked/missing thing is voltage control/monitoring feature. But that's expected, I already mentioned it during 4090 series launch: AB is fully locking voltage control on unreleased/unknown cards by design. So we'll just release new beta with 7900 series PCI DevID added to supported hardrware database to unlock voltage control slider and voltage monitor on it. Summarizing, if you don't need voltage related functionality, current public MSI AB beta should work with 7900 as is.
Also I'm expecting 7xxx family sample card from MSI in December, so I'll see if I can improve anything for new GPU family myself when it arrives.

 

Also noticed some room for optimization in RTSS OverlayEditor during refactoring internal HAL's CPU architecture database. Back in June when working on workaround for broken CPU reporting under 22H2, I added 4 optional CPU usage calculation modes for power users. Two of those optional modes are based on % Processor Utility performance counter, which is displayed by task manager itself. It is not recommended for everyone because due to some weird reason Microsoft decided to get rid of traditional CPU usage reporting and introduce some kind of virtual combined clock/usage uber metric, which scales actual CPU usage by clock frequency and confuses unexperienced users much more than it helps them. Anyway, such CPU usage calculation form is also available for power users and those who what to sync OverlayEditor's CPU usages with task manager.
However, I noticed that I init those helper performance counters in OverlayEditor's HAL always, even when traditional (default, non-scaled) CPU usage calcluation is selected. Unnecessary performance counters initialization adds about 500ms to HAL start time. I changed the implementation so RTSS will start 0.5s faster now if alternate performance counter based CPU usage calculation is not enabled in config.

 

We've compiled MSI Afterburner 4.6.5 Beta 4 Build 16358.

It is exactly the same build as the previous beta 3 with minor addition, it just adds upcoming RADEON RX 7900 family PCI DeviceID to the database to unlock voltage controls on new cards like I mentioned a copule posts above. So there are no reasons for you to update to this version if you're not future 7900 card owner.
Anyway, you may download it here:

https://download-eu2.guru3d.com/afterburner/[Guru3D.com]-MSIAfterburnerSetup465Beta4Build16358.rar

 

I'll add PerfCap mask to OverlayEditor's internal HAL for those who miss it after migrating to OverlayEditor from legacy MSI AB overlay. By default it will report a bitmask containing combination of performance capping reasons and automatically decode the mask in human readable text form similar to MSI AB overlay if you display it as a macro:



Such implementation allows you to display PerfCap reasons in text form easily, however, if you try to attach such combined data source to a graph it won't be too much useful because physically it is a bitmask combining different types of limiting factors in one binary number. So to allow you to extract and independently display different simultaneously active limiting factors in graph form (e.g. extract and display power cap events only) I'll also add new bit(x, N) function to correction formula parser, which will allow you extract just one desired bit N from a bitmask and display graph for it instead of whole bitmask. In my example, I add one more PerfCap mask derived data source called "No load cap" and apply bit(x,4) correction formula to extract "No load" perfromance cap reason from mask and display it in a graph form. This way you may create a few overlapping graphs with custom colors for earch capping reason and easily reproduce GPU-Z styled colored PerfCap events bar directly in your overlay.

 

In addition to the post above. After playing with new functionality a bit, I decided to replace previously announced bit(x, bit_index) function with alternate new test(x, bit_mask) function in correction formula parser. Unlike bit() function, allowing you to extract just one bit from PerfCap mask, test() allows extracting multiple bits from it. It can be useful when working with voltage related performance capping limits. If you carefully compared performance capping limits displayed in GPU-Z and MSI AB/EVGA Precision (legacy), you probably noticed that there are two independent voltage related limits displayed in GPU-Z: VRel and VOp for reliability and operational voltage limits, but MSI AB and EVGA Precision combine those two limits into single voltage limit. Actually I displayed voltage limits independently in the first versions of MSI AB/EVGA Precision, but NVIDIA contacted both vendors and asked to merge both VRel and VOp into single voltage limit displayed to end user to avoid confusions. So it is displayed in such form since that time. New formula parser's test() function will allow you to implement that and easily check if either VRel or VOp limit is reached and display it on single graph. To do so you may simply use test(x,12) to set resulting value to 1 if either VRel limit (bit index 2 = bit mask 4) or VOp (bit index 3 = bit mask 8) is set, or 0 otherwise. And of course you can still extract just VRel or VOp limits independently with test(x,4) and test(x,8) functions if necessary.

 

And the the final result of new OverlayEditor's functionality. Colored GPU-Z styled PerfCap reasons events bar is easily implementable in overlay now. I added PerfCap mask data source as is to display text names of active perf capping limits. Additionally I created 4 more PerfCap mask derived data sources and extracted independent performance capping limits inside each data source with new bit-testing test() function in each data source's correction fomula. Power limit correction formula extracts desired limit bit from mask with test(x,1), temperature limit extracts it with test(x,2), combined VRel/VOp voltage limit extracts it with test(x,12) and finally no load limit extracts it with test(x,16). Then I simply created 4 filled diagram-styled overlapping graphs and attached those data sources to them to emulate colored GPU-Z PerfCap reasons events bar.

 

And one more new small but useful feature of OverlayEditor born due to recent PerfCap related enhancements. Now you may hold <Ctrl> when "Overlay data sources" is open to see correction formulas deriving actual values in all data sources in "Value" column in one window without the need to peek into each independent data source properties. This can be handy when creating and debugging multiple data sources post processing their data in any form.

 

We're preparing RTSS 7.3.4 Beta 7 Build 27504 to uploading. RTSS core libraries didn't change comparing to beta 6, I just recompiled it to have a different build number. All changes are related to OverlayEditor plugin enhancements, most of them were reflected in a few posts above.

I'll summarize full changes list a bit later.

Stay tuned!

 

RTSS 7.3.4 Beta 7 Build 27504 is available for download, changes list includes the following features:

- Improved OverlayEditor plugin:
+ Refactored CPU architecture detection implementation inside internal HAL to provide better soruce code readability, simplify the process of adding new CPU architectures support in future versions of plugin and provide unified Intel/AMD CPU architecture definition inside the database. Technically I could miss some previously supported CPU architectures during refactoring, so if your CPU related sensors were supported inside OverlayEditor's Internal HAL before and became invisible now - please report it.
+ MPERF/APERF based sensors are now forcibly recalibrated after resuming from suspended mode
+ Improved base (max non-turbo) clock estimation approach, now it is calculated on the most loaded CPU core instead of the first core. Base clock is used by HAL to derive estimated BCLK in cases when OCMailbox dedicated BCLK reporting interface is not available (e.g. when core isolation/HVCI is enabled)
+ Optimized OverlayEditor initialization time. Helper performance counters, used for alternate power user oriented CPU usage calculation modes, are no longer initialized by default. This allowed to reduce the plugin initialization and RTSS start time by approximately 500ms
+ Added PerfCap mask data source for NVIDIA GPUs. This data source duplicates combination of MSI Afterburner's original binary "Power limit", "Temeprature limit", "Voltage limit" and "No load limit" monitoring graphs and allows displaying them natively in OverlayEditor
+ Added new test(x,mask) function support to correction formula parser. You may use such bit-testing function to extract desired bits from bitmask, it is intended to be used in conjunction with new PerfCap mask data source to extract independent performance capping limits from it and display them as independent graphs
+ Now you may hold <Ctrl> button pressed in "Overlay data sources" window to show correction formulas used by each data source inside "Values" column

Grab it here:
https://download-eu2.guru3d.com/rtss/[Guru3D.com]-RTSSSetup734Beta7Build27504.rar

 

Yup, got similar info from Tamas (AIDA64). But had no chance to verify it yet, too busy with my primary job past week.

 

It was not the problem with Afterburner. It was a problem with NVAPI, which broken power/temperature prioritizing functionality inside any AIC-partner's software providing such feature. It is fixed now.