G-sync\VRR support

[MaxiJazzer]

Is it possible? For now even forcing G-sync for a window mode not helping.

[Blinue]

I can't help since I don't have such a monitor. Frame rate of Magpie is different from the source window, and the fullscreen window is created dynamically so you can't specify it in window mode. If you find a solution, please share it with others.

[mirh]

Many monitors can have freesync forced with a CRU hack.

Anyhow, I don't really think there's any window recording framework that will scan and paint frames line by line.
Maybe you could reinvent the wheel with some driver and DMA tinkering (optimus can do it after all?), but you'll always be one frame behind. The algorithms can only process the whole image.

[hauuau]

I was playing around with G-Sync in the recent versions of Magpie (render-system branch) and it almost works but not quite.
If Magpie is used to scale its own main window then G-Sync gets enabled but if it's used to scale any other window normally then it doesn't get enabled.
The only way I've found to get G-Sync enabled temporary when scaling other applications is to move Magpie main window to another display and make it active there. As long as Magpie main window has focus, the render window gets G-Sync enabled. But of course such arrangement isn't very useful.
I wonder if it could be possible to find some workaround to force Windows DWM to consider Magpie scaling window as focused to enable G-Sync.

[Blinue]

According to this document, we should turn off Vsync for VRR support. Try adding the DXGI_PRESENT_ALLOW_TEARING flag to Present.

Magpie/src/Magpie.Core/Renderer.cpp

Line 266 in cec40f7

_swapChain->Present(0, 0);

[hauuau]

I've tried that when I was playing around with it and it doesn't change any behavior here as far as I can tell.

If I understand it correctly either DWM or the GPU driver engages VRR and changes framerate based on the current focused window (at least in the windowed VRR mode). When Magpie is scaling some app that app has focus (taskbar highlight, Alt+Tab target, etc), not Magpie, while G-Sync gets engaged only if the app which owns the render chain also has focus.

I tried googling a bit and there are usually opposite user complaints that in the windowed G-Sync mode some app in focus drags down global framerate due to erroneous activation of G-Sync. But there doesn't seem to be much information about how to control that behavior more precisely or if it's possible at all.

[Blinue]

DCompositionBoostCompositorClock is an API introduced in Win11, which can force the system to switch to a higher frame rate according to the documentation. Does it work?

[hauuau]

It returns S_OK but it doesn't look like it changes any behavior of G-Sync or Magpie.
And it doesn't look like Windows enables Dynamic Refresh Rate (DRR) on desktop hardware anyway, which that API call is related to. I could only select constant frame rate in advanced display settings, there is no
"Dynamic (60 Hz or 120 Hz)" mode there . So I can't tell if that call actually does something or is just a no-op in this case.

[hauuau]

And just an additional note: inserting a call to SetForegroundWindow(ScalingWindow::Get().Handle()) enables G-Sync on scaling window properly when scaling any app but it obviously breaks way too many assumptions in Magpie architecture and I'm not familiar with it enough to even attempt to fix it.

[Blinue]

Thank you for your investigation! I realized that I mixed up VRR and DRR, VRR is for reducing tearing, while DRR is for lowering power consumption. DCompositionBoostCompositorClock has to do with DRR, it does nothing if the device doesn’t support DRR.

I did some more research, and it turns out that the DXGI_PRESENT_ALLOW_TEARING flag is essential for VRR support. The issue is that the OS or driver won’t enable VRR when scaling, as you pointed out, they might only detect the foreground window. There might be a solution to this problem, because as far as I know, LosslessScaling supports VRR, but I don’t have a VRR monitor to verify that.

And just an additional note: inserting a call to SetForegroundWindow(ScalingWindow::Get().Handle()) enables G-Sync on scaling window properly when scaling any app but it obviously breaks way too many assumptions in Magpie architecture and I'm not familiar with it enough to even attempt to fix it.

This solution breaks the way Magpie works, we should look for other alternatives.

[mirh]

Does it make any difference whether you enable the thing for just windowed and full screen (not that I would normally recommend it) or just the latter?
Alternatively, did you try to check the window styles?

[hauuau]

@mirh, no difference for me here. Other applications are affected by that setting but Magpie has the same behavior in both modes, so it seems that the driver considers Magpie scaling window as a fullscreen application. But it still applies G-Sync only if Magpie is the foreground application. I'm not sure what you mean by window styles, could you elaborate?

@Blinue, If you have any other ideas I could test, I'm happy to help. I don't have LosslessScaling though.

[mirh]

These (which aren't that important usually, but they are fundamental for borderless).
WinSpy++ is such a tool that could be used for experimentation.

[EzioTheDeadPoet]

Hmm seems like for games like Titanfall 2 that sadly don't have a borderless window nor a borderless fullscreen mode this wouldn't work to force that while still keeping VRR/FreeSync/Gsync enabled ?

For most games that don't support this natively that I would also care about I don't think I need VRR since locking the FPS to 144 should work with my hardware. But I hope you find a way to enable VRR support so people can use it for some more demanding games as well or on weaker hardware.

This is because I am trying to quit using Borderless Gaming. Due to recent actions he has taken I don't trust its developer anymore (lack of released source code for new updates even though the software is licensed under GPLv3).