MSI AfterBurner 4.3.0 Beta 14 Available For the Public

Discussion in 'MSI AfterBurner Overclock Application Discussion' started by Hilbert Hagedoorn, Sep 2, 2016.

  1. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,469
    Likes Received:
    1,483
    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.
     
  2. woodaxe

    woodaxe New Member

    Messages:
    4
    Likes Received:
    0
    GPU:
    sapphire 470x nitro +
    unwinder thank you very much yes its working well now
    i did try reading up on how to use ab before i made this post
    but must have missed something
    gpu0 26.5 m/hs gpu1 26.5 m/hs gpu2 27.1 m/hs

    many thanks again
     
  3. TheRealKaldaien

    TheRealKaldaien New Member

    Messages:
    9
    Likes Received:
    0
    GPU:
    ASUS GTX 1080 Strix
    Regarding RTSS 6.5.0

    Thanks a million for this D3D12 update to RTSS, you have saved me from writing and maintaining my own text rendering system for all the APIs I work with.


    I do have a few things to bring to your attention though:

    1. The shared memory header in the SDK references a hook header that is not included with RTSS
      • I had to comment out the last part of the RTSS_SHARED_MEMORY_OSD_ENTRY data structure because I have no matching typedef

    2. Now that the API flags are 0x1, 0x2, 0x3, ... 0xn there seems to be a collision with the flag used to force RTSS to update OSD parameters
      Code:
      [LIST]
      #define OSDFLAG_UPDATED	0x00000001
      #define APPFLAG_D3D9	0x00000004
      #define APPFLAG_D3D9EX	0x00000005

      • If I OR OSDFLAG to tell RTSS to update color/scale/etc. what happens is the API flag momentarily changes...

        (Example: Game is running D3D9 -- (dwFlags & APPFLAG_API_USAGE_MASK) == APPFLAG_D3D9)

        dwFlags |= OSDFLAG_UPDATE causes (dwFlags & APPFLAG_API_USAGE_MASK) == APPFLAG_D3D9EX, but the game's still using D3D9 not D3D9Ex :)


    [*] The scale cannot be adjusted through Shared Memory when Raster3D font rendering is used, only Vector2D or Vector3D support this


    [*] In D3D9 mode, the limit for number of characters in Raster3D mode is lower than the other two.
    • Long before the 4096 character limit is reached, Raster3D text will vanish
    • That does not affect any API other than D3D9{Ex}.
    [/list]




    If you are still reading this (sorry for length), can I request a feature?

    By design, RTSS prints the last thing printed for each OSD entry. This text persists even after the process that printed the text exits. If an application that prints text happens to crash without cleaning up (zeroing) the text, stuff is stuck on screen permanently.

    Would it be possible to add a field to the shared memory structure to tell RTSS to cleanup the OSD itself? Maybe when the process exits or after a certain amount of time passes without any new text?​


    Thanks again :)
     
    Last edited: Sep 10, 2016
  4. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,469
    Likes Received:
    1,483
    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.
     

  5. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,469
    Likes Received:
    1,483
    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
     
  6. Odellot

    Odellot Master Guru

    Messages:
    681
    Likes Received:
    32
    GPU:
    2080TI SLI PG348Q
    Thanks Unwinder..Just installed the beta RTSS..I can now run DX12 like Rise of the Tomb Raider without Disabling SLI or Afterburner albeit no OSD..
     
  7. GalaxyMaster

    GalaxyMaster New Member

    Messages:
    2
    Likes Received:
    0
    GPU:
    MSI RX 480 Gaming X 8G
    While using Afterburner for my RX 480 I have found a bug in profile hotkeys.

    I have multiple profiles set up with different voltage offsets and bound to hotkeys. When I am in game and switch to a profile with a higher voltage than my current one, it works as expected. But when I switch to a profile with lower voltage than my current one, it applies all settings except the voltage, which stays the same. If I then press the hotkey for the profile again it changes the voltage this time.

    I would also like to know if you have plans to add support for the 'memory voltage' present in wattman (AFAIK this is the memory controller voltage)? I found that it definitely helps with stability on memory overclocks, and it would be nice to use it with Afterburner.

    Thanks!
     
  8. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,469
    Likes Received:
    1,483
    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?
     
  9. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,469
    Likes Received:
    1,483
    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.
     
  10. GalaxyMaster

    GalaxyMaster New Member

    Messages:
    2
    Likes Received:
    0
    GPU:
    MSI RX 480 Gaming X 8G
    Darn. I also tried setting the memory voltage in wattman while using afterburner, but that setting gets erased every reboot, regardless of the "erase autosaved startup settings".
     

  11. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,469
    Likes Received:
    1,483
    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
     
  12. Odellot

    Odellot Master Guru

    Messages:
    681
    Likes Received:
    32
    GPU:
    2080TI SLI PG348Q
    Thanks Unwinder..Tested the build8511 RTSS..I played Rise of The Tomb Raider..OSD doesn't crash the game anymore...The Flickering OSD is noticeable on loading screens but in game can't notice the flickering of the OSD although the text seems to be lighter..Like not bold..
     
  13. Prophet

    Prophet Master Guru

    Messages:
    800
    Likes Received:
    7
    GPU:
    Msi 680 Gtx Twin Frozr
    Thanks Unwinder.
     
  14. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,469
    Likes Received:
    1,483
    Thanks for testing, that's exactly what I've expected and wanted to confirm.
     
  15. Haldi

    Haldi Master Guru

    Messages:
    240
    Likes Received:
    3
    GPU:
    R9-290 CF
    https://www.youtube.com/watch?v=IEf7nndGNGM


    And i'm off repairing my computer... mainboard issues... that blackscreen at the end of the video was not intentional. -.- :bang:
     

  16. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,469
    Likes Received:
    1,483
    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.
     
    Last edited: Sep 20, 2016
  17. Haldi

    Haldi Master Guru

    Messages:
    240
    Likes Received:
    3
    GPU:
    R9-290 CF
    That would be really nice.

    So i assume the Multi-GPU rendering is also responsible for this white frame flickering in this video? (P.S It's the new one with OSD :banana: )
    https://youtu.be/QYrrY0QuvKc

    Because Deus Ex Mankind Divided DX12 Beta recorded just fine without this in SingleGPU.

    For Video recording will DX12mGPU profit or does it still have the same disatvantages as on DX11 with Multiple GPUs?



    Oh, and did anything change with Video recording?
    If you compare these two Videos (one above and this older one: https://www.youtube.com/watch?v=uKrA_XcFGGA) Both have this horrible white flickering which gives a headache, but it looks like the new one with OSD hase some extreme stutter issues, it looks like the video is playing backwards for half a second.
    Especially easy to spot after 1:06
     
  18. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,469
    Likes Received:
    1,483
    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.
     
  19. pimp_gimp

    pimp_gimp Ancient Guru

    Messages:
    6,600
    Likes Received:
    8
    GPU:
    EVGA Geforce GTX 980 SLI
    I have also tested this build with Rise of the Tomb Raider, and the OSD works as you expected in MultiGPU mode under DirectX 12.

    EDIT: Upon further testing RTSS also only seems to work if you leave the NV control panel setting to "Nvidia Recommended" with SLI enabled. If Single-GPU, AFR1, or AFR2 modes are forced via the Nvidia Control Panel the game refuses to load (at least for me it behaves in this manner).
     
    Last edited: Sep 21, 2016
  20. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,469
    Likes Received:
    1,483
    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.
     

Share This Page