MSI AB / RTSS development news thread

It depends on definition of "CPU frametime". It is really specific to engine implementation, something close to "CPU frametime" could be measured at least for Direct3D apps via measuring time between BeginScene and Present calls.

Maybe in far far future. Currently I don't see how to fit it in existing implementation.

 

Done, OSD layout editor got new prolog/epilog fields (aliases for initially planned intro/outro fields) in "Separators" node. Both prolog and epilog separators currently support the following macro names for displaying system specs: %FullCPU%, %CPU%, %RAM%, %FullGPU%, %GPU% and %Driver%. %CPU% and %GPU% are used to display compact CPU and GPU specs (e.g. compact "GTX 1080" instead of full "NVIDIA GeForce GTX 1080" and compact "i5 3570K @ 3.4GHz" instead of full "Intel(R) Core(TM) i5 3570K CPU @ 3.4GHz"), but %FullCPU% and %FullGPU% can be also used to show full CPU/GPU specs). Probably I'll add new layout "modern web" with system specs displayed by default.

 

Insert new child item for desired field (e.g. "GPU usage") into "Value alignment" node and specify different alignment for it.

Editable group separators will be available in the next beta, it will allow you to insert new line symbols before desired groups.

 

You're confusing something, modern OSD layout is just a differently formatted text, text is formatted on MSI AB side, it doesn't affect OSD rendering approach, it doesn't put any additional load on hooked 3D application and rendering is unified for all layouts.

 

New MSI Afterburner beta is available.

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

Changes list includes:

- Partial AMD Vega support:
+ Fan control for Vega is supported now. Please take a note that Vega doesn’t provide native support for traditional PWM duty cycle based fan control (i.e. it doesn’t allow setting desired fixed fan speed in % directly). So fan speed percent scale in MSI Afterburner is internally linearly mapped to RPM scale.
+ Low-level voltage control via direct access to SMC is currently not implemented for Vega, so voltage is controlled via AMD ADL API. Which means that you cannot set voltages higher than allowed by Wattman’s. Honestly I’m not sure if it worth implementing low-level voltage control for those cards, they are really power hungry and power limited even on default clocks/voltages.
- Now drag and drop is supported for multiple selected graphs in active hardware monitoring graphs list in “Monitoring” tab. So it is a bit easier to rearrange the graphs list now.
- Now you may right click active hardware monitoring graphs list in “Monitoring” tab and select “Reset order” command from the context menu to reset default active graphs order.
- Added Prolog and Epilog properties to “Separators” property node in OSD layout editor. Prolog and epilog allow you to display any custom text info above and below OSD (e.g. branding text, URL, your system specs etc). Both prolog and epilog support macro variables, allowing you to insert desired system specs automatically. The list of supported macro variables includes: %CPU%, %FullCPU%, %RAM%, %GPU%, %FullGPU%, %Driver% and %Time%.
- Added new “Group separator” property node to OSD layout editor. Group separators can be used to vertically split the groups if necessary.
- Added new “modern web” OSD layout to OSD. The layout is using new prolog and epilog to render branding text and system specs in OSD and group separators to split GPU, CPU/RAM and 3D application related statistics in OSD.
- Both MSI Afterburner and RTSS installers are preserving installation path now.

 

I'm afraid that it's not an option as well. RTSS included in the last beta is the same as a couple months old beta 28, the only difference (and the only reason to increment RTSS version) is a different digital signature. All changes is the last beta are related to MSI AB, not RTSS.

 

It can be installed on top of the previous installation.

 

Check your hardware monitoring polling rate, amount of sensors you're refreshing and total hardware polling time. Performance profiler info is displayed in hardware monitoring status area not just for fun.
And I'd really prefer to focus on new functionality testing instead of hunting for ghosts.

 

Tick "Show status" in hardware monitoring window and pay attention to hw_polling_time/hw_polling_period ratio. It will give you roughly approximated CPU load coming from hardware polling. E.g. if average polling time displayed there is 30ms and polling period is 1000ms then you're wasting approximately (30/1000)*100%=3% of CPU time per second on reading data from sensors. Personally I try to limit amount of simultaneously monitored graphs to keep hardware polling time below 20ms limit. You may identify most performance consuming sensors with status info as well. That's normally external GPU sensors, i.e. the sensors connected to GPU via relatively slow I2C bus (power/voltage sensors etc). Internal GPU performance counters like GPU usage, clocks etc are fast and read in less than millisecond.