Discussion in 'MSI AfterBurner Application Development Forum' started by Unwinder, Feb 20, 2017.
Hello, your UI is too simple, I like it too much, can you give me your configuration file? thanks
Unfortunately no, but it's easy enough to make if you follow the guides on this forum.
I know, @toyo shared such one with me yesterday in addition to what you provided.
I've also got a free code for anyone that wants it?
Nevermind I found someone that wants it, I've directed him too this forum to get the latest Riva Beta version as well.
I've published beta 5 yesterday late in the everning right before going off to bed, so I had no time to document all changes in details and promised to do it later. Here is full changes list for beta 5:
· Various compatibility improvements in the hook engine:
o Added hooking support for Microsoft DirectX 12 Agility SDK based Direct3D12 applications (e.g. Halo Infinite insider tech preview and possibly other future Direct3D 12 applications compiled with Agility). New DirectX 12 Agility model assumes that the game can be shipped with a local copy of Direct3D 12 runtimes, which can be newer than your system Direct3D12 runtimes. By default RivaTuner Statistics Server’s hook engine is configured to block injection into any custom Direct3D runtimes located outside OS system folder because such case is typical to Direct3D proxy libraries used in third party game mods, which are frequently fundamentally incompatible with overlays. So hooks were blocked on purpose in such environment, making overlay invisible. Running RivaTuner Statistics Server in such environment also reduced performance due to periodically repeating and failing overlay injection attempts. Previously this could be solved by creating application profile for such game with enabled “Custom Direct3D support” option, which is intended to allow injecting custom Direct3D runtimes located outside system OS folders. New Agility compatible hooking path automatically addresses it in the following way:
§ Simplified form of “Custom Direct3D support” mode is now internally engaged by RivaTuner Statistics Server when Agility SDK based Direct3D12 application is detected. Full “Custom Direct3D support” mode functionality is overabundant and not necessary for Agility case. New Agility compatible hooking path is optional and can be disabled by power users at application profiles level for troubleshooting or performance testing
§ Added retry counter for reinjection attempts, aimed to minimize performance penalty for situations when Agility SDK based Direct3D12 application cannot be injected
§ DXGI swapchain hooks are now suspended during dynamic hook offsets initialization, this change is aimed to reduce risk of incompatibilities caused by enabling “Custom Direct3D support” profile in conjunction with application detection level set to “High” for Agility based Direct3D12 applications
· Added unified Direct3D12 command queue caching based algorithm for handling periodic swapchain recreation in some Blizzard games (e.g. Diablo 2 : Resurrected and World of Warcraft). This makes previosly added On-Screen Display rendering profiles for these games optional, they are no longer mandatory
I think we'll also put beta 5 to main download page now, so it will be easier to find it for those who will be testing Halo Infinite in the next few days
The PassiveWait value in Global file doesn't change when toggling the option in RTSS settings, is it stored elsewhere?
It changes inside global profile, most likely you're peeking into global profile template instead.
After seeing your post I noticed same behavior but after restarting RTSS it is now actually writes PassiveWait properly
It always writes it properly and definitively doesn't require restart. Monitor changes into the profiles you're editing, do not confuse profiles with profile templates and keep in mind that it is profile specific setting similar to the rest framerate limiter options, so it is expected to be directed to global file if you select global profile into GUI, otherwise it is applied to currently selected application profile.
I've made my overlays available on the megathread https://forums.guru3d.com/threads/rtss-overlay-editor-megathread.436443/page-5
The next phase of Halo Infinite insider preview just started, so I finally had a chance to get past main menu (the rest was locked during past week) and test 7.3.2 beta 5 in action, in gameplay with bots. I'm happy to report that overlay works with it as expected and game it butter smooth with RTSS hybrid scanline sync mode enabled:
On a side note: my main development PC decided that it is a good idea to perform forced upgrade of my Win10 to Win11, right in the middle of work day, grrr. I was not planning to migrate to it and start intensive internal Win11 compatibility testing before the OS officiall launch, but it looks like I have no choice now The first and currently the only Win11 related incompatibility in RTSS which I noticed is broken <Alt> + framerate limit edit field click feature. It was aimed to simplify the process of hybrid scanline sync configuration, under Windows 10 holding <Alt> while clicking framerate limit edit field in RTSS automatically sets the limit to preciese fractional display refresh rate (e.g. 59.951Hz, which is frequently used instead of 60Hz). It doesn't work under Win11 yet, it looks like DwmGetCompositionTimingInfo is currently broken in Win11 or timing info format changed (but no MSDN documentation reflects it yet for Win11). I'm investigating it further.
You're right, thanks!
Small addition to DwmGetCompositionTimingInfo issue, which I mentioned in the previous post, probably it will be useful for software devs. I nailed down the reason and submitted the following bug to MS:
"I noticed that DwmGetCompositionTimingInfo API is returning weird data in DWM_TIMING_INFO.rateRefresh on Windows 11 22000.194. Refresh rate denominator changes with each call and seems like it is always matching DWM_TIMING_INFO.rateCompose. So for me it looks like rateRefresh is not a monitor refresh rate like it is supposed to be but composition rate instead. Is it intended behavior?"
Yup just jumped on the new flight and RTSS beta is working like a dream. Thanks for all your hard work Unwinder!
How shortly we are talking about here.
When it is done, no need to be impatient. If you didn’t notice that, unexpected Halo Infinite related changes shifted the priorities.
MSI Afterburner 4.6.4 Beta 4 Build 16117 is available for download:
The main and the only reason behind releasing new beta is making it compatible with RTSS shared memory layout changes, introduced in recent RTSS betas and required for displaying in-process RAM/VRAM usage performance counters properly. The rest changes are pretty minor: new NVIDIA GPU has been added to database, internal hotkey handler got DirectInput bug workaround similar to one recently introduced in RTSS and tray icon monitoring module got some minor changes aimed to prevent monitoring tray icon blurring in high DPI modes. Bundled RTSS version has been upgraded to 7.3.2 Beta 5.
As a part of RTSS quality control I frequently monitor application related discussions in different places in the net so I can see that a lot of users are loving and enabling RTSS scanline sync feature. However, in absolutely each case I can see that users simply enable classic scanline sync mode in RTSS, which puzzles me a lot because there is more robust hybrid scanline sync implementation available in RTSS since v7.3.0. The main idea behind classic scanline sync mode was synchronizing each frame presentation time to desired rasterizer position (i.e. scanline index). This requires polling graphics card rasterizer state in the loop on each frame presentation. However, rasterizer status polling is rather resource heavy, it stalls GPU rendering pipelines, and that’s the reason why you can achieve desired effect with classic scanline sync mode in not too demanding games, where your GPU is not too busy. New hybrid mode was introduced to bypass that limitation. The main idea behind hybrid scanline sync mode was getting rid of performance hungry per-frame rasterizer status polling. In case of hybrid scanline sync mode actual synchronization with real rasterizer postion is performed just once then RTSS continues steering tearline position with high precision timer and traditional framerate limiter module. It is not that hard to configure RTSS to enable hybrid scanline sync mode. The first thing you need to do is switch framerate limiter to synchronous mode:
By default framerate limiter is asynchronous, i.e. it is allowing presentation times to drift when framerate is below the limit. For hybrid scanline sync mode we’ll use framerate limiter to steer tearline position so it cannot be asynchronous for this specific task.
Now you need to enable both framerate limiter and scanline sync:
Scanline sync settings will be used by hybrid mode for initial synchronization and tearline positioning and framerate limiter settings will be used for steering tearline position after that. Selecting proper framerate limit value for hybrid scanline sync mode is the most tricky part. It must be as close to your real hardware refresh rate (which rarely matches true 60Hz refresh rate for example) as possible. In my example it is 59.951Hz for my 1440p display. If you don’t know your videomode timings and real refresh rate, you may hold <Alt> and click “Framerate limit” edit field in RTSS to autodetect it. In this case RTSS will ask DWM to report it (please take a note that currently <Alt> + click functionality is not supported under Win 11 like I mentioned in a few posts above). That’s it, hybrid scanline sync is enabled after that.
While configuring scanline sync (both classic and hybrid modes) you can also enable “moving bar” mode in FCAT indicator. It is intended to help you to determine tearline position visually.
Power users may also edit global profile template and set SyncInfo to 1 there. After doing that and enabling “Show own statistics” in RTSS it will display debug scanline sync panel in OSD:
Your main point of interest in debugging hybrid scanline sync settings is a “Present” line, which is showing index of scanline where the last frame was presented. It must be static (ideally) or fluctuate near desired target if you set up scanline sync correctly. If it is monotonically decreasing in hybrid mode – tearline will be drifting up, which means that framerate limit value you specified is greater than your actual hardware refresh rate. If it is monotonically increasing – tearline will be drifting down, which means that framerate limit value you specified is less than your actual hardware refresh rate. In both cases you need to tune your framerate limit.
"Sync start" and "Sync end" lines will easily show you if you use classic or hybrid scanline sync mode. They are displaying initial and final rasterizer positions (i.e. scanline indices) for the last scanline sycnhronization event. If they change on each frame - classic scanline sync mode is in use, i.e. rasterizer status polling is performed on each frame. If that's the case, it means that either synchronous framerate limiter mode is not enabled or framerate limit is not specified, both things will prevent hybrid mode from enabling and force classic mode usage. If they stay static - hybrid mode is in use, because rasterizer position synchronization is performed just once.
Just a small request for the overlay Zoom slider, can there be additional steps added between step 0 and step 1?
i noticed with a font like arial nova at 6pt that it goes from tiny at 0 to atleast 3x as big on the first step.
This could be dpi related and i didn't get a moment to check, but i've worked around it by using no overlay zoom and 10pt font size, except where i happen to use vector3d which seems comparable to 10pt raster fonts.