RTSS 6.7.0 beta 1

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

  1. EdKiefer

    EdKiefer Ancient Guru

    Messages:
    2,328
    Likes Received:
    189
    GPU:
    MSI 970 Gaming 4G
    Everything seems to be working as far as I can tell with plug-ins. Played around a little but I have 1 question with min/max values in data source settings.
    I normally alter min max values of the graph limits to match the HW better.
    Example: CPU fan I set max to 2100rpm for a fan that has 1900 or so max. This gives better scaling and shows delta better on the graph.
    So is there any advantage to doing the same with the data source, looks to me probably should just leave defaults as long as HW sensor is below the value.

    Edit: only thing close to a bug is if you have show profiler panel on, you can not right click properties to bring up monitoring tab if you do it in the profiler green section.
    This is not really an issue with graph detached as there plenty of space but with it attached you have limited graph space for the properties to work.
     
    Last edited: Apr 27, 2018
  2. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,439
    Likes Received:
    1,464
    There is no any advantage. Min/max values for plugin specific data sources just define default values for min/max adjustable for each hardware monitoring graph. So values you edit there (i.e. in graph properties) have higher priority.

    That's by design. "Properties" command in the context menu is getting you directly into the properties of desired graph, which you're right clicking when activating the menu. So it is working only when you're pointing some specific graph by mouse cursor.
     
    Falkentyne likes this.
  3. boogieman

    boogieman Ancient Guru

    Messages:
    1,935
    Likes Received:
    14
    GPU:
    MSI GTX 1080X
    Just installed the latest 4.5.0 and was reading through the changes. I assumed the above command line switches are used as follows in my case:
    D:\Afterburner\MSIAfterburner.exe /backup

    Assuming this is right, AB does not launch but creates backup\nameless\profiles folder. How does this part come into play "create multiple named restore points".
    Can you give a bit more detail on this feature?

    BTW, awesome job, liking the new features and customization.
     
  4. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,439
    Likes Received:
    1,464
    Almost correct, Marc. Synaxis is:

    MSIAfterburner.exe /backup [name]
    and
    MSIAfterburner.exe /restore [name]

    This way you’re creating multiple named restore points. Name can be missing to use default nameless restore point. Each restore point is represented by independent subfolder in .\Backup folder. If you don’t specify a name then peek inside the folder, you’ll see that MSI AB simply saves settings to or restores settings from a restore point called “Nameless”.
     
    CaptaPraelium and boogieman like this.

  5. EdKiefer

    EdKiefer Ancient Guru

    Messages:
    2,328
    Likes Received:
    189
    GPU:
    MSI 970 Gaming 4G
    Yes, that worked fine with MSIAfterburner.exe /backup backup1
    I got backup1 under the backup folder.

    PS: I like the selection section of the graph, very handy to see min/max of the selected section.
     
  6. MaxMidnite

    MaxMidnite Member

    Messages:
    10
    Likes Received:
    0
    GPU:
    ATI RX580
    So what now? is there another thread or this beta goes on, any people reported any issues with 4.5 Final?

    .PS. is there a way to disable the settings but just keep fan settings. I use another program to control my values etc. If this makes sense..
     
  7. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,439
    Likes Received:
    1,464
    Some development related news:

    In the previous version of MSI AB we introduced new performance profiler in hardware monitoring module, allowing experienced users to estimate hardware polling related performance hit and identify the slowest sensors. Upcoming version of RTSS will also introduce its own performance profiler, allowing experienced users to see how much CPU and GPU performance is eaten by OSD rendering. Probably this feature will teach some youtubers to avoid using Vector2D compatibility renderer instead of much more fast Vector3D/Raster3D renderers:

    [​IMG]

    RTSS 7.2.0 beta is around the corner, stay tuned!
     
  8. JonasBeckman

    JonasBeckman Ancient Guru

    Messages:
    15,703
    Likes Received:
    1,705
    GPU:
    Sapphire 5700XT P.
    Nice, I don't know if it will change anything but I like the feature, more statistics and information doesn't hurt and having a better overview of the OSD's cost can't be a bad thing. :)
    (Though a few titles also requires this mode for compatibility as I recall but it's probably pretty uncommon, something with idTech5 and their games as I remember.)
     
  9. cookieboyeli

    cookieboyeli Master Guru

    Messages:
    298
    Likes Received:
    42
    GPU:
    Gigabyte 1070 @2126
    I've always wondered about this!!! Awesome!

    Hey since you're going to be putting out a new beta you'd probably like to know that these programs can be added to the global "block list" for OSD detection:

    7zFM.exe (7-Zip file manager)
    Discord.exe
    DiscordPTB.exe
    MEGAsync.exe
    notepad++.exe
    OCCT.exe (Crysis2.exe is the actual renderer for OCCT, that's just the UI)
    Pingplotter.exe
    Powerpnt.exe
    SVPManager.exe

    And the Windows 10 Picture app. (I don't know the exe for that, I've removed all metro apps form my PC.)
     
  10. bigcid1

    bigcid1 Master Guru

    Messages:
    296
    Likes Received:
    19
    GPU:
    ROG-STRIX-RTX2080
    Microsoft.Photos.exe
     
    cookieboyeli likes this.

  11. gatecrasher

    gatecrasher Member

    Messages:
    20
    Likes Received:
    0
    GPU:
    8GB GTX 1070
    The bug report topic seems to be locked:
    Running Windows 10 version 1803, Afterburner/RTSS seems to break the Game Bar.
    Sometimes it works one or twice after launching AB/RTSS, but after toggling the OSD a few times, I can no longer bring up the Game Bar until I restart the PC.
    Without AB/RTSS running, I have no issues using it.
     
  12. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,439
    Likes Received:
    1,464
    I'm not developing Game Bar and this thread is not indended for general problem reporting and troubleshooting.
     
  13. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,439
    Likes Received:
    1,464
    I'm preparing the first beta of RTSS 7.2.0 to uploading. Changes list includes the following:

    · Added On-Screen Display performance profiler. Power users may enable it to measure and visualize CPU and GPU performance overhead added by On-Screen Display rendering. Two performance profiling modes are available:
    o Compact mode provides basic and the most important CPU prepare (On-Screen Display hypertext formatting, parsing and tessellation), CPU rendering and total CPU times, as well as GPU rendering time (currently supported for Direct3D9+ and OpenGL applications only)
    o Full mode provides additional and more detailed per-stage CPU times
    · Improved built-in framerate limiter:
    o Added power user oriented profile setting, allowing you to specify the limit directly as a target frametime with 1 microsecond precision
    o Added power user oriented profile setting, allowing you to adjust throttle time. Throttle time adjustment is aimed to reduce input lag when framerate is below the target limit or without limiting the framerate
    · Various On-Screen Display optimizations and improvements:
    o Added adjustable minimum refresh period for On-Screen Display renderer. The period is set to 10 milliseconds by default, so now the On-Screen Display is not allowed to be refreshed more frequently than 100 times per second. Such implementation allows keeping smooth animation when On-Screen Display contents are being updated on each frame (e.g. when displaying realtime frametime graph) without wasting too much CPU time on it
    o Added alternate GPU copy based Vector2D On-Screen Display rendering mode implementation for Direct3D1x applications. New mode provides up to 5x Vector2D performance improvement on NVIDIA graphics cards, however it is disabled on AMD hardware due to slow implementation of CopySubresourceRegion in AMD display drivers
    o Vector2D rendering mode is now forcibly disabled in Vulkan applications on AMD graphics cards due to insanely slow implementation of vkCmdClearAttachments in AMD display drivers
    o Revamped geometry batching and vertex buffer usage strategy in pure Direct3D12 On-Screen Display renderer (currently used in Halo Wars 2 only)
    o Added Vector2D rendering mode support to pure Direct3D12 On-Screen Display renderer
    o Optimized On-Screen Display hypertext parsing and tessellation implementation
    o Optimized state changes in OpenGL On-Screen Display rendering implementation
    o Optimized state changes in Direct3D1x On-Screen Display rendering implementation
    o Solid rectangles and line primitives in Direct3D8 and Direct3D9 On-Screen Display rendering implementations are now rendered from vertex buffer instead of user memory
    o Improved OpenGL framebuffer dimensions detection when framebuffer coordinate space is selected
    · Fixed On-Screen Display rendering in wrong colors when Vector2D mode is selected and Direct3D1x applications use 10-bit framebuffer
    · Fixed Vulkan fence synchronization issue, which could cause GPU-limited Vulkan applications to hang due to attempt to reuse busy command buffer
    · Updated profiles list
     
    yasamoka, XXXR, jiminycricket and 7 others like this.
  14. JonasBeckman

    JonasBeckman Ancient Guru

    Messages:
    15,703
    Likes Received:
    1,705
    GPU:
    Sapphire 5700XT P.
    Good to see the first beta build being close to a public release. :)

    Not much I can say but I do like the changes I'm seeing. Those AMD issues with that Vulkan command are a bit of a surprise.
    (And a lot of optimizations, a few fixes and new features.)
     
  15. gatecrasher

    gatecrasher Member

    Messages:
    20
    Likes Received:
    0
    GPU:
    8GB GTX 1070
    The bug reporting topic is locked, and this seemed to be focused on active development.
    The Game Bar is a standard Windows 10 function that AB/RTSS is breaking.
     

  16. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,439
    Likes Received:
    1,464
    When RTSS is not working the fix is expected from my side. When some other overlay not working and cannot co exist with RTSS compatibility must be added from that software side. No need to continue it here please. That's not a case of "RTSS breaking something".
     
  17. Unwinder

    Unwinder Moderator Staff Member

    Messages:
    14,439
    Likes Received:
    1,464
    Cannot say that it is a surprise, since DirectX8 times (i.e. since the first 3D API that allowed to clear multiple 2D rectangular areas of backbuffer in a single call) AMD drivers traditionally handle multiple backbuffer clears much less efficiently than NVIDIA ones, and seem to add rather serious CPU overhead per each additional rectangle, which you try to clear in one pass. It could be easily optimized inside the driver as clears can be represented by internally rendering multiple solid screen aligned quads, that's what can be done even if there is no native hardware accelerated clear implementation. But probably AMD feels that clearing framebuffer more than once per frame is not a realistic scenario and it doesn't deserve the optimization, and I can understand them.
     
  18. JonasBeckman

    JonasBeckman Ancient Guru

    Messages:
    15,703
    Likes Received:
    1,705
    GPU:
    Sapphire 5700XT P.
    So that's the situation, no wonder it's disabled then as it sounds like it could be a major bottleneck if it's up to 5x slower than for NVIDIA and has a possible CPU overhead issue too at that.
    Not too many Vulkan games out yet although emulators that are traditionally CPU bound could be another problem area then if Vector 2D mode was to be used for compatibility.
    (Though it's forcefully disabled for AMD GPU's as of this version now and I guess that will stay until AMD resolves the issue in a later driver update.)

    Good to know about that, well the changelog already makes it clear that there's a serious speed difference here between AMD and NVIDIA. :)

    And I see I glossed over a change to framerate limiting, Afterburner's option always seemed more consistent over AMD's plus it works outside of fullscreen too and there's no need to have the GPU run at max for simple main menu backgrounds or similar after all though it will take some per-profile tuning to smooth out input lag especially for sudden framerate drops or situations with more varied fluctuating framerate values.

    I still have a lot to learn but I can see this coming in use in several titles without dropping the framerate cap to a lower value.

    EDIT: Well I guess that's being a bit redundant, it's a huge subject area and the new API's of DirectX 12 and Vulkan are changing things up quite a bit even if adaption is currently a bit slow plus both are also actively developed and added to.
    But that's diverging from the topic at hand, going to be fun giving this new version a try once the beta is available for download.
     
    Last edited: May 22, 2018
  19. RealNC

    RealNC Ancient Guru

    Messages:
    3,108
    Likes Received:
    1,339
    GPU:
    EVGA GTX 980 Ti FTW
    Thank you! Can't wait to test it out!
     
  20. mdrejhon

    mdrejhon Member Guru

    Messages:
    103
    Likes Received:
    61
    GPU:
    4 Flux Capacitors in SLI
    On behalf of Blur Busters, thank you very much!

    Much tests will need to be begun on these tweaks to see how they affect the following:
    - Impacts on VRR operation (GSYNC, FreeSync)
    - Impacts on HOWTO: Low-Lag VSYNC ON operation

    Minor additional tweak:
    Also, is there a setting that dynamically detects the frequency (aka fractional refresh rate) that Present() begins blocking (VSYNC ON queue became full) and automatically slew the framerate cap fractionally lower than Hz to eliminate the VSYNC ON buffer backpressure automatically to the point where Present() stops blocking? That way, this eliminates user tweaking of a framerate cap for the low-lag VSYNC ON situation.
    .... Even reading the floating-point refresh rate (GPU video output timing clocks is not perfectly aligned with CPU / RTDSC / QueryPerformanceCounter() timing clocks - there's often microseconds of slewing between the GPU clock and the CPU clock) is not sufficient enough to guarantee against a slow buildup of VSYNC ON buffer backpressure especially if the video output is several microseconds slower than expected.
    .....The fractional-Hz-readout, while perfect sync, can still automatically seed a starter-cap, potentially subtract a default fraction automatically, and/or then use Present()-blockage-detection to provide a slight dynamic slewing to the cap. This could provide an improved automatic low-lag VSYNC ON algorithm that can be much more tightly-capped with even less manual configuring.

    The microsecond accuracy is very important to prevent the stutter-surge effect of the framerate cap beat-frequencying against refresh-rate during the low-lag VSYNC ON HOWTO. The tighter the cap is to Hz, the fluctuations in capping accuracy causes the stutter-surge effect at the crossover points. Improved microsecond capping accuracy eliminates the stutter-surge effect of these beat-frequency crossover points, down to as little as a single microstutter.

    In the past, doing a super-tight cap 0.0001fps below refresh rate, often caused long sessions of perfect low-lag VSYNC ON smoothness, followed by long sustained surges of annoyingly continuous microstutter (as the capping inaccuracy continuously jittered across the VBI pageflip threshold -- causing some pageflips to randomly delay a refresh cycle).

    Another possible framecapping technique is polling D3DKMTGetScanLine() for a target scanline specified at command line (BTW: This API works with OpenGL too....) to automatically set the framerate cap darn nearly perfectly right before a VSYNC ON pageflip threshold.

    e.g. scanline #1075 of 1080p or scanline #400 of 1080p. That would provide near-perfect slew-proof (no sawtooth lag) low-lag VSYNC ON for just-in-time render-and-deliver -- meaning RTSS would behave as an 'inputdelayer' putting input reads closer to perfect VSYNC ON pageflips. Or possibly a tearingless VSYNC OFF by steering the tearline just right off the bottom edge of the screen, as a low-lag VSYNC ON alternative.

    I have source code that successfully polls D3DKMTGetScanLine() even while OpenGL/D3D9/D3D10/D3D11 is running. First I simply GetsAdaptor the devicestring (e.g. \\\\.\\DISPLAY1) and then I get an hAdaptor suitable to pass along to D3DKMTGetScanLine() which is simply an API built into GDI, despite its suggestively-D3D-specific Windows API function call name.

    D3DKMTGetScanLine() returns the scan line number that the GPU output is currently scanning-out, and works on Intel/AMD/NVIDIA GPUs, so that can be used for perfect framecapping to VSYNC ON.

    Jerry of Duckware (author of vsynctester.com) gave this open source code to me, for use in some of my software, and I'm happy to provide a copy, as well as the appropriate C# port that I've made, so it's now really easy to poll for scanline # as a perfect display signal clock reference to derive a Hz-following framerate cap that's right before a VSYNC ON timing threshold...

    Essentially "VBI racing" the VBI via a poor-man's beam racing.

    In theory, with some programming tricks in RTSS, it can make possible a super-user-friendly non-power-user checkbox setting "[X] Low-Lag VSYNC ON mode" or "[X] Low-Lag Double VSYNC ON mode" that is perfect Hz-following with no deltas necessary.

    This also makes possible ultra-low-lag perfect VSYNC ON 60fps at 120Hz ....or..... 60fps @ 240Hz for all 60fps console ports too on non-VRR displays, without the input-lag of driver-based double-VSYNC or quadruple-VSYNC algorithms.

    This might be low priority, but I thought I'd post here, because of my experiments in Lagless VSYNC ON for Emulators (tearingless VSYNC ON via beamraced frameslicing) and beam racing experiments, I've discovered additional methods of reducing input lag -- and some of my algorithms are now built into certain emulators.

    That said, if you want my source code, reach out to me mark@blurbusters.com .... (it's just a "Hello World" D3DKMTGetScanLine() program without graphics -- it can poll the "Are we in VBlank" state, as well as display output's currently-scanning-out scanline number -- even without a 3D window -- no Direct3D handle needed (unlike D3D9's RasterStatus.GetScanLine). This API (Win8.1+) allows you keep merrily using OpenGL/Mantle/D3D/2D/whatever -- so it (D3DKMTGetScanLine) can simply behave as an optional additional clock reference only for the purpose of dynamically auto-adjusting the framerate cap, whenever a checkbox is enabled or a configuration setting is set.

    The suggestion that I have posted here is much simpler, it is essentialy simply racing the VBI only (no beam racing) as a method of generating a perfect refresh-rate clock reference that has reliable advance notice to the next framebuffer flip. When RasterStatus.ScanLine equals 540 means you have almost exactly 1/120sec until the next blanking interval to successfully do a perfectly microstutter-free Present() on a 1080p display.

    -- Could allow easier automatic low-lag VSYNC ON 60fps (for 60/120/180/240Hz)
    For fast-frametime software that normally is hobbled by the latency of a frame queue (of even 1 frame) -- creating next-refresh-cycle response time for many categories of 60fps applications (including unoptimized emulators) - basically RTSS can behave as an inputdelayor (for just in time rendering) + backbuffer-pressure preventer.
    -- Could allow easier automatic VRR-Max-following framerate cap
    It's also potentially another useful "reference clock" that RTSS capping can utilize -- and it can even help one detect whether or not a monitor is still refreshing when a new frame is delivered by the game (e.g. getting very close to a GSYNC/FreeSync cap, and automatically backing off from that) -- and automatically cap -- long before VSYNC ON framebuffer backpressure begins to build up from framerates trying to run higher than a VRR maximum. The VRR cap would then thusly, automatically self-optimize from this feedback effect -- eliminating users from needing to remembering to set "X frames per second" below Hz. It'd automatically adapt when users changed refresh rate, too.
     
    Last edited: May 22, 2018
    yasamoka, cowie, XXXR and 2 others like this.

Share This Page