RTSS 6.7.0 beta 1

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.

 

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.

 

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.

 

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..

 

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.)

 

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.)

 

Microsoft.Photos.exe

 

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.

 

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.)

 

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.

 

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.

 

Thank you! Can't wait to test it out!

 

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.