Overlay will disable Nvidia G-Sync

[zzonez]

If you have an app that is running in g-sync mode and attach an overlay to it, g-sync will be disabled.

You can quickly test it, if you change the electron-demo.ts and make it attach itself to poe.

overlayWindow.attachTo(window, 'Path of Exile')

[SnosMe]

I don't own G-Sync monitor to test.
It is very unlikely that someone else will investigate this. 😄

[ogidimitrov]

@zzonez is your g-sync enabled for both windowed and fullscreen apps ? Also what criteria you have to conclude g-sync is affected?

[RichardCsiszarik]

@ogidimitrov this is a well established behaviour on NVIDIA (AMD and Intel GPUs seem unaffected, though I can't test as I don't own one of those atm) - when any window/overlay moves over a game's screen that doesn't directly hook into the framebuffer (like say RTSS or other performance overlays) to display their info but are instead separate, NVIDIA G-Sync gets disabled, and the game goes from very performant low latency HW independent flip model to composed flip model, reducing performance and introducing a great amount of input latency, as the game's presentation is now routed through windows' DWM.

See here for this common question for example: https://forums.developer.nvidia.com/t/fix-vrr-for-overlays-always-on-top-windows/296168

The flip presentation model swap is easy to observe by using Intel's Presentmon tool as it can tell you what present model the game is currently at.
The G-Sync thing can be easily tested as you can enable an indicator for it in the NV Control Panel and notice how the indicator disables the moment you have any window/overlay moved over the game's screen.

Unfortunately, electron-overlay-window and thus tools using it like Awakened PoE Trade even when not showing anything are an always on (just fully transparent) overlay over the game, thus preventing game from going into a much more performant present model (I can for example observe my input latency triple because of it). I've just spent many hours trying to look into the code of that (otherwise great) tool and this dependency, but my programming experience is unfortunately very small.

I've attempted to change this utility to enable receiving functions like OverlayController.electronWindow.show() or .hide() but before I was done with that I saw SnosMe's description about how this overlay window will shut down when not attached, as it's not meant to do that.

My other solution that I wanted to attempt is that whenever the overlay is not actually used to display anything and thus would just be sitting over the game as an invisible window, to instead move and resize the overlay to say bounds x=-9999 and y=-9999 and with a width/height of 1px, to effectively hide it away so it's not over the game to re-enable HW independent flip presentation during gameplay, and only move it back when an overlay is called to be visible. I'm not quite sure if this is possible with my current approach, I'll need to revisit this as I really appreciate this tool otherwise and I'm hoping to grow my understanding to possibly fix this.

[RichardCsiszarik]

Okay in the meanwhile I've actually finally found further information on this since it felt like this wasn't always the case, but information about MPO (multipane overlay, a feature supposed to fix this entire issue), other than many discussions everywhere on internet about disabling it for both AMD and NV GPUs as it caused plethora of issues in the past.

So in short, for NV GPUs, MPO is only enabled on one monitor, and it has to be in 8-bit mode, with RTX HDR and RTX VSR (video super resolution) both off, and the display can't be using DSC, otherwise it doesn't work. Also, crucially, the monitor it's enabled for is going to be the "first monitor" (or rather, the monitor plugged in the lowest of the order of display output ports on the GPU). This is decided at a hardware level, discussions about flashing custom VBIOS for it also fell flat, apparently it's decided at HW level, that the ports on every model of GPU (I presume AIB models can flip this around too) have a certain order. Anything set by drivers/OS is ignored (so this doesn't go by what your primary/main display is set in windows/drivers, the order/numbers listed either in windows display settings or GPU driver control panel).

This order can be found by running dxdiag and saving the full information, the displays connected will from my observation be in this specific order. Also, it seems to me that in the NV control panel for example under configure surround, physX there's a little picture showing the GPU's ports and what monitor is connected to which port, and this coincidentally is exactly the order my physical port IDs are in from left to right (ignoring slightly offset diagonal, if there's a port below but in between the top first two ports, then that one is actually the second port as it purely goes left to right. Also note, this is NOT necessarily the same as the order the actual physical ports are on the GPU itself, it isn't at all for my model).

In that dxdiag report there'll be a section called MPO MaxPlanes at every display, if this is 1 then MPO is disabled for that display, and if MPO is enabled it'll show something like 4 for the first monitor in order that's compatible. I'm not sure if it'll always try to be the first physical connected one and if that doesn't support it, it's just disabled entirely, or if the first monitor is not compatible then it'll try the second and so on - in this case you could nudge the MPO to the correct wanted monitor by e.g. bumping previous monitors in the order to 10-bit colour or higher (as it has to be 8-bit apparently for MPO to work), in case you can't connect it in that order (mostly an issue if some displays use DP and some use HDMI, as there's usually only 1 HDMI port on most modern GPUs, outside of specific models like some ASUS AIBs having 2).

This way, if you have your primary monitor (that you use for games) with MPO enabled, it does actually work and any overlays (like moving windows volume up/down, tabbing out and moving another window over the game in background, or, related to this subject, an electron app overlay like Awakened PoE Trade or presumably anything using electron-overlay-window) will still allow the game to be in Hardware Independent Flip present model, and thus also have VRR / G-Sync working still.

This does impose limitations, like:

• not being able to physically connect your main screen to the first physical ordered port on your specific GPU model, like say your main monitor specifically uses HDMI, but your HDMI port is 3rd out of 4 ports and you use 3 displays, so you can't possibly have your 2 extra monitors come after in order, or say HDMI is your 4th port and you have any other displays, or perhaps vice versa and one of your secondary monitors uses HDMI but the HDMI port on your GPU happens to be the first physical in HW order)
• using a main monitor at higher than 8-bit colour (especially as many recent displays are properly 10-bit, or you use HDR for example)
• you use any functionality that disables MPO (like RTX VSR or RTX HDR, using DSC for display which is more and more common nowadays, perhaps other features too that we don't know about) or you need to disable MPO for stability/performance reasons (NVIDIA still even lists a registry tweak on their site to quickly toggle MPO as it's known to cause issues for some setups)

...then having overlays on will still cause this unwanted loss of HW Independent Flip model and thus come with great performance/latency/feature (VRR/G-Sync) loss, which is why I'd still love for the overlay to be able to say resize and move off-screen when it's not showing anything, instead of staying over the game as an invisible canvas, so that a game would continue using HW:IF at least while the overlay isn't showing anything on screen.