MSI AfterBurner 4.3.0 Beta 14 Available For the Public

Disabling ULPS in AB requires doing it for each target GPU independently and desired GPU must be connected to windows desktop at this time. Absolutely the same scenario applies to extending overclocking limits. And it is reflected in the context help.
So in your case you effectively performed that for the GPUs connected to desktop only.

Do you understand the meaning of settings enabled on the previous step? What were you trying to achieve with enabling extending official overclocking range? It is aimed to extend the maximum allowed clocks in any overclocking tools including AMD's official ones. So that's not wrong, that's absolutely expected.

And that's supposed to be so.

 

Yep, that's definitively not supposed to be that way, thanks for reporting. I'll add RTSSHooksTypes header to SDK as well.

You're confusing two different bitmasks. APPFLAG_ values apply to application specific flags bitmasks and should use APPFLAG_PROFILE_UPDATE_REQUESTED to notify RTSS about external application profile update, OSDFLAG_ values apply to old deprecated dwOSDFlags field in early layouts of shared memory.

That sounds like a result of improper profile update notification (i.e. wrong OSDFLAG_UPDATED flag usage). Scaling vector fonts kind of works because no actual D3D resources recreation is required in this case, but raster font requires new texture to be generated and created so OSD needs to be notified properly.

Cannot comment it without investigation, but too busy to do it in nearest few weeks, sorry.

I'll think about it, but no promises.

 

Guys, I'd like to test the following build of RTSS 6.5.0 on SLI/CF systems in DX12 applications using explicit multi-GPU rendering mode (3DMark TimeSpy an Rise of Tomb Raider). As you noticed, currently OSD doesn't support such applications and prevent them from starting when OSD is enabled. I tired to add detection of explicit multi-GPU DX12 rendering pattern and auto disable OSD usage if such unsupported environment is detected. So I'd like to verify the implementation. I expect that TimeSpy and ROTR will be able to start on such systems now while RTSS is running with no OSD displayed. OSD should become visible as soon as you disable SLI/CF of explicit multi-GPU usage from application side.

http://office.guru3d.com/afterburner/RTSSSetup650Beta5Build8502.rar

 

Thanks for confirming, does it display properly in other DX12 apps (which do not support explicit mGPU mode) and does it start displaying in ROTTR after disabling SLI on your system?

 

That's not a bug in profile hotkeys. That's specifics of voltage offset implementation on AMD SMC side. The offset doesn't get applied immediately, it is applied on the next VID change.
On cloning Wattman's "Memory voltage": no, it is not planned to bring it to AB, sorry.

 

One more experimental build of RTSS 6.5.0 to be tested on SLI/CF systems in DX12 applications using explicit multi-GPU rendering mode (3DMark TimeSpy and Rise of Tomb Raider). I expect to see OSD partially visible on SLI/CF now: the OSD should be rendered when the frame is being processed by GPU1 only, so in case of AFR usage you'll see OSD displayed on odd frames only (it will result in OSD flicker effect). I'd like to see confirmations of such expected OSD behaviors from SLI/CF system owners.

http://office.guru3d.com/afterburner/RTSSSetup650Beta5Build8511.rar

 

Thanks for testing, that's exactly what I've expected and wanted to confirm.

 

Thanks for one more confirmation, that's what I absolutely expected to see. So now explicit mGPU AFR usage pattern detection, separete codepath for mGPU systems and forcible rendering on the primary GPU are confirmed to be working. The last (and most difficult) step would be correctly duplicating resources for all joined GPUs performing mGPU rendering and drawing OSD in different GPU's frame buffer on each frame. MSI is going to provide me both SLI and CF DX12 setups so I guess I'll be able to compete that task with those systems rather easy once it arrive.

P.S. Considering that DX12 multi-GPU rendering path is drastically different comparing to single GPU one I guess I'll reflect it somehow in the OSD, most likely display "DX12mGPU" or "DX12AFR" instead of "DX12" next to framerate.

 

Of course video recording also needs separate path for DX12 mGPU. And no, I didn't change anything in that area for mGPU systems yet since public beta.

 

That doesn't depend on RTSS. That's a game/driver behavior and it is actually really bad idea to force anything multi-GPU related for DX12 applications providing own explicit multi-GPU support. The only reason why SLI/CF needs to be enabled in the control panel for such games is to see multiple linked GPUs (or nodes in DX12 terms) for application usage. No multi-GPU processing is done at driver level in this case, the application is fully implementing AFR and utilizing all nodes on its own. Attempt to force the driver to override any kind of multi-GPU processing will break application functionality.