New Vulkan vsync mode! FIFO latest ready

[netborg]

Seems you never tried dxvk-low-latency, some games run so good with this that you have never experienced any other platform, especially concerning the VRR capabilities. So d3d8-d3d11 is fully covered, the only thing missing on Linux is great frame pacing on d3d12.

[RealNC]

Seems you never tried dxvk-low-latency, some games run so good with this that you have never experienced any other platform, especially concerning the VRR capabilities. So d3d8-d3d11 is fully covered, the only thing missing on Linux is great frame pacing on d3d12.

I'm talking about FPS limiting with MangoHUD without VRR. With VRR the limiter doesn't need to be very accurate, it still looks smooth.

[netborg]

That has too much lag. And on top of that, vulkan lacks fractional vsync (present interval 2/3/4) so you can't do a 120Hz vsync at 360Hz for example (present interval 3.)

What is needed is being able to, for example, use normal 360Hz vsync with a 1/3 FPS cap and have the frame presentation pacing be so accurate as to perfectly output 120FPS at 360Hz but never miss the correct display scanout for each frame.

Obviously all of this isn't important with VRR, but without VRR it's not looking great right now on Linux.

I don't know why you would ever want to use V-sync with fixed refresh like that, but of course you can just use a great limiter with VRR, or if you don't have VRR, just use tearing:
DXVK_FRAME_RATE=120 DXVK_FRAME_PACE=low-latency-vrr-360

There are plenty of people reporting issues with MangoHud frame limiting, I'm not the only one:
https://github.com/doitsujin/dxvk/issues/5340

(and yes, I keep the DXVK_FRAME_RATE variable in dxvk-low-latency)

[RealNC]

I don't know why you would ever want to use V-sync with fixed refresh like that

Because I want a fixed frame rate at 120 or 90FPS while keeping my display at its maximum refresh rate. This keeps render latency at 0 (because it never hits the vsync ceiling) and coupled with the high scanout speed of the monitor's max refresh rate, latency overall is quite good.

but of course you can just use a great limiter with VRR, or if you don't have VRR, just use tearing

When there's tearing, I'd rather not play the game at all. VRR is not an option because it flickers on my W-OLED monitor.

Right now, the best way to run games for me is on Windows 10 with Special K's frame limiter.

[netborg]

When there's tearing, I'd rather not play the game at all. VRR is not an option because it flickers on my W-OLED monitor.

Then you are unlucky, VRR is something I wouldn't want to miss out on. Lots of people use my VRR mode with OLED monitors, but occasionally I get reports that their setup flickers - so this is then an hardware issue.

DXVK supports the mode you're using though too, but don't expect to get good input lag with it:
dxgi.syncInterval = 3 ... 4, etc.
https://github.com/doitsujin/dxvk/blob/ ... .conf#L214

[RealNC]

DXVK supports the mode you're using though too, but don't expect to get good input lag with it:
dxgi.syncInterval = 3 ... 4, etc.
https://github.com/doitsujin/dxvk/blob/ ... .conf#L214

The mode I'm using is present interval 1 with a fractional FPS cap. Fractional vsync is a last resort (due to latency) for games that don't like to be FPS capped.

With normal vsync and a fractional FPS cap, latency is almost as good as VRR. But the FPS limiter needs to take display scanout timing into account for it to be smooth.

[netborg]

Idk, I'm not into v-sync with fixed refresh. I tried to do such a mode in the past, but my focus is on low-latency frame pacing and when you miss the v-sync window, you get a stutter. For me, this is just old tech. VRR is much superior.

And your claim that the pacing wouldn't matter when you have VRR is completely wrong. It matters a ton, in fact due to VRR you can observe the pacing much cleaner than when you'd tear.

[RealNC]

Idk, I'm not into v-sync with fixed refresh. I tried to do such a mode in the past, but my focus is on low-latency frame pacing and when you miss the v-sync window, you get a stutter.

That's what I'm saying. On Windows, the limiter never misses a vsync window. It's absolutely perfect. 120FPS@240Hz will always show the same frame twice. Motion looks exactly like 120FPS@120Hz, except it's 240Hz and thus all vsync backpressure lag disappears.

This what I'd like to see on Linux some day. But apparently the APIs for that don't exist yet?

And your claim that the pacing wouldn't matter when you have VRR is completely wrong. It matters a ton, in fact due to VRR you can observe the pacing much cleaner than when you'd tear.

I don't know. With VRR, even retroarch looks perfectly smooth to me. And the low-latency VRR limiters (Special K's "low latency" limiter or the Nvidia limiter) are not accurate, they have like +/- 0.3ms jitter or so, but it doesn't affect smoothness when in VRR mode.

The only case where VRR isn't smooth is when the game stutters (which of course isn't something that VRR can fix.)

[netborg]

That's what I'm saying. On Windows, the limiter never misses a vsync window. It's absolutely perfect. 120FPS@240Hz will always show the same frame twice. Motion looks exactly like 120FPS@120Hz, except it's 240Hz and thus all vsync backpressure lag disappears.

This what I'd like to see on Linux some day. But apparently the APIs for that don't exist yet?

Well, I can implement that if more people would request that. But it wouldn't be low-latency then, cause in order to not miss v-blanks you have to have a sizable buffer.

I don't know. With VRR, even retroarch looks perfectly smooth to me. And the low-latency VRR limiters (Special K's "low latency" limiter or the Nvidia limiter) are not accurate, they have like +/- 0.3ms jitter or so, but it doesn't affect smoothness when in VRR mode.

The only case where VRR isn't smooth is when the game stutters (which of course isn't something that VRR can fix.)

Afaik retroarch should be doing the fps limiting, so there is not much to do from the VRR side, especially if retroarch just pushes out 30/60 fps?!

You can have well below 0.1 ms jitter with my pacing, at which point it gets super smooth. Of course you can even go lower and smoothness will further improve to previously unknown territory, but things like turning off SMT, enabling a gaming scheduler, etc. matters a lot then, because low latency pacing relies on predictability.

And yes, compare normal dxvk with dxvk-low-latency in Overwatch for example, there is just no contest in smoothness. So for you normal dxvk might already be smooth, but to me it was laggy and video playback speed wobbles back and forth. This is why I've put more than half a year of full time work into this and it finally payed off.

[RealNC]

Well, I can implement that if more people would request that. But it wouldn't be low-latency then, cause in order to not miss v-blanks you have to have a sizable buffer.

The queue is 0 in Windows, same as when using VRR with an FPS cap. It can be seen in DXGI stats as "render latency", and it stays at 0 at all times when the FPS limiter is engaged. It can also be felt, since there's no lag.

You can increase the buffer size if you want. Like 5 frames even, but it will never fill and the queue will always be 0. I'm not sure how you'd even have the buffer contain anything more then the scanout frame and the currently rendered frame even if you wanted, since the frame rate is half the refresh at most. It never hits the vsync ceiling.