Use DXGI to present frames rendered by OpenGL on Windows

[alvinhochun]

• Related to Use DXGI to present frames rendered by Vulkan on Windows #5692.

Describe the project you are working on

The Godot editor?

Describe the problem or limitation you are having in your project

Native OpenGL has suboptimal present behaviour which may increase input lag.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Using a DXGI 1.3 swap chain and flip model presentation lets us control frame presentation more precisely, which may let Godot reduce input lag, similar to #5692.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

The WGL_NV_DX_INTEROP2 extension allows us to pass a D3D11 buffer into OpenGL to render onto it directly.
Note: despite having NV in its name, this extension is also available on Intel and AMD drivers, at least from what I read. It does work on my Intel integrated graphics driver.

I have a experimental branch here: https://github.com/alvinhochun/godot/tree/opengl-with-dxgi-present

If this enhancement will not be used often, can it be worked around with a few lines of script?

No, as presenting frames is handled by the renderer.

Is there a reason why this should be core and not an add-on in the asset library?

This is core rendering functionality.

[alvinhochun]

I am not quite sure how to move forward with this. I'll write down some questions/points so I don't forget:

• How should DXGI flip model present be toggled?
  • Make it yet another rendering driver, e.g. "opengl3_dxgi" alongside "opengl3" and "opengl3_angle", or
  • Add a new project property and a new command line flag for this.
  • It is currently impossible to toggle it at run-time, since switching will require recreating the native window and the OpenGL contexts. (Sort of related to Implement changing RenderingDevice at runtime #6423 and Handle and recover from graphics driver restart gracefully #10269)
  • What if we also implement flip model present for ANGLE? Should they share the same toggle?
• Should it by default automatically be used if supported?
• Should it use waitable swap chain?
  • Perhaps not in the initial implementation.
  • It is somewhat complicated to use with multiple windows.
  • Related to [RFC] D3D12: Use waitable swap chain to reduce input latency godot#94960
• Last time I checked, wglDXUnlockObjectsNV seems to wait for all the previous OpenGL commands to complete, at least on Intel, which may be a bit bad.

[Calinou]

• How should DXGI flip model present be toggled?

Does it need to be an option? I thought you'd always enable it whenever it's supported by the OS/driver. Apps like Special K highlight any other presentation model (such as GDI compose) as legacy.

If it needs to be disableable for troubleshooting reasons, we can add a command line argument for it.

• Should it by default automatically be used if supported?

Yes. There might be use cases that require it to be disabled, but it's very unlikely for games (maybe for some non-game applications that use features like per-pixel transparency?).

• Should it use waitable swap chain?

I'd leave that for a future PR.

• Last time I checked, wglDXUnlockObjectsNV seems to wait for all the previous OpenGL commands to complete, at least on Intel, which may be a bit bad.

I'd check performance in a draw call-heavy project to make sure it doesn't regress.

[mirh]

libsdl-org/SDL#10160
You might be interested to this discussion (particularly the last link I posted)

Does it need to be an option? I thought you'd always enable it whenever it's supported by the OS/driver.

I suppose that for whatever the reason some die-hard fan of exclusive fullscreen may always want to keep using it.

[expikr]

I suppose that for whatever the reason some die-hard fan of exclusive fullscreen may always want to keep using it.

specifically, those who prefer frame mistiming to manifest as tearing rather than as motion jitter.

[mirh]

DXGI_SWAP_CHAIN_FLAG_ALLOW_TEARING should actually address that too (including even in non-fullscreen windows)

On the other hand, I believe the feature may require Multi-Plane Overlays which isn't always granted (even on newer hardware/drivers, and for sure on older ones).

[expikr]

Which I guess is precisely why traditional exclusive fullscreen is irreplaceable in the foreseeable future, Microsoft’s disingenuous “you think you do, but you don’t” push for “flip fullscreen is better than exclusive!” shows a misunderstanding of the frame pacing problem as blindly lumped into a single criteria of “latency” and missing all the nuances.

[mirh]

The only misunderstanding seems to be yours of what I said.
The fact that some unlucky situations (or altogether users) may be out of luck, doesn't mean that if you care (or even most people) would find themselves in any struggle.

Not sure what you mean by pacing lumping, especially considering the great lengths you can notice they went in the famous W10 presentation modes dev video.