RTSS 6.7.0 beta 1

Discussion in 'MSI AfterBurner Overclock Application Discussion' started by Unwinder, Feb 20, 2017.

  1. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,921
    Likes Received:
    2,050
    That drastically depends on 3D application’s VRAM resource allocation strategy. The applications, which frequently create and destroy VRAM resources (especially variable sized!) on the fly are the “best” candidates to fragment it.
     
    HARDRESET, Dark.talon and toyo like this.
  2. TheRealKaldaien

    TheRealKaldaien Member

    Messages:
    15
    Likes Received:
    5
    GPU:
    RTX 2080 Ti K|NGP|N
    Awesome, I think this will help put a stop to discussions that cite numbers generated by Afterburner as VRAM _requirements_ for game title XYZ.

    People really have been doing that for years, because they had no view of data isolated to just the running software. No measure of this stuff is completely accurate, but the new per-process counters will help reduce Internet arguments I am sure. The driver / HW GPU scheduling takes care of many of the scenarios where the sum total of ALL graphics memory allocated by everything on the system is too much to fit into VRAM, so realistically any question of "can my system run it?" needs to focus on some kind of per-process working set.

    With this update, per-process numbers are finally available (in said process), and that's highly valuable information for analyzing the running game.

    Thank you.


    Could I bring your attention to another issue that could affect FPS numbers reported by RTSS in advanced graphics engines and/or Chromium-based games?

    upload_2020-9-22_6-8-50.png

    As funny as this is, the real problem comes from the way framerate is currently counted by RTSS.

    SKIF is running at 120 FPS, just with multiple swapchains to composite the different UI windows and RTSS does not know the difference between
    1 swapchain and 6 running concurrently.

    If RTSS’s framerate limiter were turned on like this, it would slow down the software to 1/6th the correct rate because there are a sequence of 6 buffer swaps (happening in parallel on independent swapchains) that must happen every time I refresh all of these windows.

    I am in the process of updating Special K’s in-game UI to use multi-plane overlays to draw and RTSS is going to start reporting wrong framerates (it will over-report by 2x) to users in all games unless changed to count framerate per-swapchain. Once this starts happening, we will have a flood of confused users accusing either Special K or RTSS of misrepresenting performance :-\

    ---

    If you need to test software with multiple swapchains, SKIF.exe ( https://sk-data.special-k.info/SpecialK.7z ) is the software shown in the screenshot.

    SKIF has a dynamic number of DXGI swapchains (at minimum 2) depending on how much of the UI is visible. RTSS can be considered multi-plane overlay / composition-aware when it stops reporting the same aggregate framerate on all of these UI sub-windows.

    After testing any potential fixes, SKIF.exe also needs to be added to the default RTSS blacklist because this is distracting :p
     
    Dark.talon likes this.
  3. TheRealKaldaien

    TheRealKaldaien Member

    Messages:
    15
    Likes Received:
    5
    GPU:
    RTX 2080 Ti K|NGP|N
    Also, your overlay is impossible to see in HDR :)

    I'd like to offer some assistance in making your overlay HDR compatible since I have fixed Valve and Ubisoft's overlays already

    There are three cases you must handle:

    1. DXGI:

    Hook IDXGISwapChain3::SetColorSpace1 (...) and watch for sRGB, scRGB (FP16 HDR) and HDR10 (R10G10B10A2 HDR).

    When the colorspace is set to scRGB (swapchain fmt=R16G16B16A16_FLOAT), color is a linear scale w/ 1.0 = 80 nits, you can easily boost your overlay's white point by multiplying the color (e.g. if user wants overlay running at 240 nits, then multiply color values by 3.0 and you are literally done because the colorspace is the same as Rec 709).
    When the colorspace is set to HDR10 (swapchain fmt=RGB10A2UNORM), color is in Rec 2020 and gamma is Perceptual Quantization (SMPTE 2084).

    The HDR10 case is harder to handle, you will have to transform your colors (overlay was written for Rec 709) from Rec 709 to Rec 2020 to prevent everything from going hyper saturated, then you must apply PQ gamma to scale your SDR luminance to HDR.

    2. NVAPI:

    Hook NvAPI_Disp_HdrColorControl and watch for cmd == NV_HDR_CMD_SET, hdrMode == NV_HDR_MODE_UHDA_PASSTHROUGH means HDR10 and is the only type of HDR I have ever seen games that use NvAPI for HDR utilize

    3. AGS:

    AMD has a proprietary API for HDR too, but I could not tell you anything about it.


    To save you a LOT of time, here's a patched version of Valve's Steam overlay shader I wrote to handle both types of HDR:

    https://gitlab.special-k.info/Kalda...iberated/resource/shaders/steam_d3d11_ps.hlsl

    You just need to get a luminance scale into that shader

    * I wrote the user's desired "paper white" luminance value to uv2.x

    - Negative values of uv2.x = HDR10, and they represent your user's preference for peak luminance. This value is fed into PQ gamma (ApplyREC2084Curve) to rescale your SDR color values to fit the new range.
    - Positive values of uv2.x = scRGB. I pre-scaled this (e.g. since 1.0 = 80 nits bright, take user's luminance preference and divide by 80 before passing values to shaders).


    If you intend to do alpha transparency in HDR, things get complicated fast. My suggestion is do not bother, I did not for Valve.

    My own overlay handles alpha transparency correctly, but it's very complicated and requires implementing a custom three-input blend equation in pixel shaders to keep the source image from overpowering your overlay when the pixels underneath your overlay are significantly brighter.

    https://gitlab.special-k.info/Kalda...iberated/resource/shaders/imgui_d3d11_ps.hlsl
    ^^^ That's what it takes to do alpha transparency in HDR.

    Just make the overlay opaque in HDR unless you have an actual HDR display and a lot of time to learn this stuff :)
     
    Dark.talon likes this.
  4. kx11

    kx11 Ancient Guru

    Messages:
    3,217
    Likes Received:
    304
    GPU:
    RTX 3090
    i don't know if i understood what you said about the Overlay with HDR on but it looks good to me

     

  5. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,921
    Likes Received:
    2,050
    Yep, I documented that RTSS implementation is targeted on global process-wide framerate statistics only so cumulative framerate is expected to be displayed for processes using multiple Direct3D devices or multiple swapchains per device. The same apply to vendor specific overlays like GFE, as far as I remember. See no much real use in collecting framerate statistics independently for each swapchain, that's not a typical behavior and presentation model for games and much more typical for D3D accelerated GUI where FPS counters are not necesssary.
    I can offer quick and dirty fix - simple profile swicth, forcing RTSS to latch the first swapchain used to present a frame then ignore presentations from other swapchains. That will make OSD appear on that latched swapchain only and Presents on different swapchains will be filtered from framerate calculation statistics.
     
    Dark.talon likes this.
  6. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,921
    Likes Received:
    2,050
    I'm aware that RTSS overlay colors look unnatural in HDR mode. But I don't have proper HDR output device to debug and validate changes, so I shift this task to future over and over again ;) One of my monitors is "HDR compatible", but in realitty it is cheap HDR400 so HDR mode looks that bad on it so I never use it. Probably I'll finally decide to give this task a try, thanks for your implementation hints ;)
     
    Dark.talon likes this.
  7. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,921
    Likes Received:
    2,050
    He means that overlay colors are overbright and distorted. Color correction is required for them to look as supposed.
     
    kx11 and toyo like this.
  8. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,921
    Likes Received:
    2,050
    There is no direct dependence between size of application's VRAM commit and this gap size. It can be easily close to desktop VRAM usage with no overhead even when the appplication allocate more VRAM than in your case. For example, that's one of my home PCs with 8GB VRAM in the same MSFS 2020. After clean system boot and game start the gap is tiny and close to 300MB on 4.3GB VRAM commit, that's typical desktop VRAM usage on that PC so there is close to zero fragmentation overhead. But once you make game or OS deallocate/reallocate VRAM, you can easily see how the gap increases drastically, up to 1GB and more. It is enough to increase display resolution (so we deallocate render targets and try to allocate _bigger_ ones, which surely won't fit into deallocated chunk) or just ALT-TAB (so videomemory manager will start evicting VRAM used by MSFS, change its budget causing it to deallocate something etc etc). After doing so the gap can grow up fast. But it won't be that big as you expect.

    MSFS3.png
     
    Last edited: Sep 22, 2020
    Dark.talon, Dan Longman and Tomatone like this.
  9. Netherwind

    Netherwind Ancient Guru

    Messages:
    7,473
    Likes Received:
    1,431
    GPU:
    MSI 3080 Gaming X
    Hello @Unwinder
    Just got a 3080 and I'm having trouble with fan speeds in MSI AB. Looks like setting a fan curve doesn't work properly and same with setting a fixed fan speed. For example, if I set 60% then the fan only goes up to 46% and displays 60%. So with the fan curve, even if I set something like 60% the fans won't go up there as described.

    Am I doing something wrong?

    [​IMG]
     
  10. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,921
    Likes Received:
    2,050
    @Netherwind

    Fan speed adjustment scale of reference design RTX 3xxx series cards is normalized by NVIDIA design. It means that target 0-100% fan speed range is mapped to [min_bios_pwm…max_bios_pwm] range (both BIOS min and max PWM fan speeds are displayed as dotted horizontal lines in MSI AB fan curve window). So for example 0% is mapped to min BIOS PWM (30% reference cards) and 50% is not a real 50% PWM but a PWM sitting exactly in the middle between BIOS min and max. MSI AB beta 2 conforms to NV’s reference design 3xxx fan scale normalization and normalizes requested target fan speed to [min..max] range. Looking at your result I’d say that BIOS min is set to 25% but NV’s reference fan speed normalization scale is forcibly disabled due to some odd reason from MSI BIOS side on it (probably to maintain compatibility with some old software like Dragon Center without actually updating it?). In this case simply reverting to beta 1 (which knows nothing about 3xxx fan speed normalized scale) should work for you.

    I’ll leave it for MSI reps to comment the rest. I have no ideas why it is done this way without notifying me and how it is planned to address that properly, without hurting compatibility with reference 3xxx fan cooling implementation.
     
    boogieman and Netherwind like this.

  11. Netherwind

    Netherwind Ancient Guru

    Messages:
    7,473
    Likes Received:
    1,431
    GPU:
    MSI 3080 Gaming X
    Thank you!
     
  12. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,921
    Likes Received:
    2,050
    Is BIOS min PWM limit really set to 25% on that card (displayed as horizontal dotted line on fan curve) like I assumed?
     
  13. SweatyBumSmell

    SweatyBumSmell New Member

    Messages:
    7
    Likes Received:
    0
    GPU:
    Palit RTX 3080
    Same exact problem as I have and my card is a Palit GamingPro, not MSI...

    I asked Unwinder if the fan control behaviour is different for Ampere but instead he just replied with "it's intended" which was not helpful, he could have replied with the comment he made at #2570 in this thread and I would have said "Ok that explains that it is different and why 0db mode doesn't work with the fan curve, but there still seems to be some funkiness going on as setting the fan speed doesn't seem to work properly.", but instead, he proceeds to block me after pointing out that there's definitely something dodgy going on.

    Sigh...

    All Unwinder had to do was actually explain things to me rather than treat me like a dumbass and I wouldn't have flamed out of frustration, I recently reformatted and installed AB fresh, the fan issue is still there and now I know it's something to do with the partner BIOS and not AB apparently, that's all I needed to know.....
     
  14. Netherwind

    Netherwind Ancient Guru

    Messages:
    7,473
    Likes Received:
    1,431
    GPU:
    MSI 3080 Gaming X
    Imgur is currently down so I cannot upload a picture of the fan curve but in Beta 2 the dotted line is at 30%. Interesting though, setting one point in the curve to 0% does nothing, 30% seems to be the minimum which must be intended.
     

    Attached Files:

    Last edited: Sep 23, 2020
  15. Astyanax

    Astyanax Ancient Guru

    Messages:
    7,932
    Likes Received:
    2,652
    GPU:
    GTX 1080ti
    you can attach pictures to posts now
     
    Netherwind likes this.

  16. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,921
    Likes Received:
    2,050
    The post above has zero relation to your false claims about "broken" fan stop functionality. It is INTENDED and by design on NV driver to not allow you to set manual fan speed below below manufacturer defined minimum BIOS fan speed limit. Minimum fan speed is NOT ZERO on reference design and custom Ampere cards. Period. You cannot change it without BIOS flash. Period. It is not a bug, it is your bugged understanding. It was so with every single generation of NVIDIA cards before Ampere. And new family is not an expection. It is INTENDED.
    I closed eyes on personal insults coming from your side once, I closed eyes on your attempts to post insults @ reddit after that so you're still not banned but you decided to come back again. One more post about "arrogant tosser ignoring your important fan stop problem" and you're gone, take it as the final warning.
     
  17. Netherwind

    Netherwind Ancient Guru

    Messages:
    7,473
    Likes Received:
    1,431
    GPU:
    MSI 3080 Gaming X
    Didn't know that :)
     
  18. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,921
    Likes Received:
    2,050
    Weird, I’d expect it to be set to slightly different target for normalized scale bypass case. Normalization for reference design Ampere cooling system is applied in the following way: it is 100% * (pwmTarget – pwmMin) / (pwmMax – pwmMin). So for target 60% I’d expect it to be 100 * (60 – 30) / (100 - 30) = 43% on raw fan controller’s input. 46% is slightly off and it matches 25% pwmMin precisely. So there is probably more mess in BIOS, with limits altered in different places.
    Can you try to set a few different target fan speeds, for example 40%, 50%, 70%, 80% to see how it transforms to actually programmed values in each case to see mapping pattern better?
     
  19. SweatyBumSmell

    SweatyBumSmell New Member

    Messages:
    7
    Likes Received:
    0
    GPU:
    Palit RTX 3080
    Now you are just twisting my words, I don't care about being banned from this forum - I only came here to let you know there was a problem and there still is a problem regardless of the fan stop function so instead of being a massive raging arrogant know-it-all how about you consider investigating it and stop making excuses as to why it's everyone else's fault that it doesn't work properly because it clearly couldn't be you and your superior intellect, there's clearly, blatantly and obviously an issue with how AB is messing with the fans and the guy posting about it happening on his MSI card as well as it happening on my Palit card just proves there is something wrong with how AB is doing it, both companies are separate entities and I'm pretty sure they don't share the same BIOS that happens to have the same issue...

    Just an FYI the fan control works PERFECTLY on EVGA Precision X1 which is what I have now switched to, further leading to the point that the fan control on AB is not working right, be arrogant all you want and go ahead and ban/ignore me, it's not going to change the fact that you are in the wrong no matter how much of a genius you think you are, there's an issue and that's the entire reason I made an account to begin with, frack me for trying to point out software bugs in the future when someone like you is at the helm.
     
  20. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,921
    Likes Received:
    2,050
    Bye. I gave you multiple chances to stop.
     

Share This Page