Win10, OpenGL, and Full-Screen Exclusive Replacement

Before I spend any more time digging, I thought I’d just ask.

From what I can gather, “Full-Screen Exclusive Mode” is no more in D3D12 and Win10. It’s been replaced with:

[li]Windowed Flip (iFlip Immediate) [/li][li]aka Independent Flip with True Immediate Present [/li][li]aka Independent Flip Swap Chains with True Immediate Presentation (via Waitable Object Swap Chains) [/li][/ul]
I’ve got several questions:

[li]Is this your understanding? [/li][li]Can OpenGL apps make use of iFlip Immediate mode? How? (MS’s info says D3D12 only) [/li][li]If not, what’s the best alternative to synchronize with GPU scan-out, bypass as much DWM overhead as possible, and minimize display latency? [/li][/ul]
If you can answer any of these, or even provide some related info about them (even speculative), I’d appreciate it!

(If you’re scratching your head at this post or are interested in more background, here’s a pretty good video: DirectX 12: Presentation Modes In Windows 10.)

Just curious if you made any progress?

The priority on this issue hasn’t been very high, so no I haven’t done much with this.

One correction: I think “iFlip” (Independent Flip) is more the analog to Full-Screen Exclusive (FSE) with SwapInterval(1) (VSync), whereas “iFlip Immediate” is more like FSE with SwapInterval(0) (i.e. no VSync). That’s what I gather from what I’ve seen since anyway.

Also, I’ve recent found out that NVidia has a graphics API interop sample that shows how to render with one API and present with another API. Supported APIs are GL, DX11, DX12, and Vulkan, with all permutations of render API -> present API supported (except DX11 <-> DX12; no point I guess). So with this it looks like you can render with GL and present with DX12. That said, I haven’t actually spent anytime profiling this, so I’m not sure what kind of overhead we’re talking about from doing this.

The DX12 present client shows presenting with DXGI_SWAP_EFFECT_FLIP_DISCARD, but if I understand correctly using either this or FLIP_SEQUENTIAL should support iFlip when all the conditions are fullfilled. Also, I see no references to DXGI_SWAP_CHAIN_FLAG_ALLOW_TEARING and DXGI_PRESENT_ALLOW_TEARING, so it appears it’ll only support iFlip (VSync) and not iFlip Immediate (no VSync), but that’s probably an easy add when needed.

Related to the link I posted above with Jesse Natalie (Microsoft) talking about these presentation modes, this thread is a worthwhile read (SoldierOfLight is Jesse).

If there truly isn’t a much simpler way for an OpenGL application to get Full-Screen Exclusive equivalent capability in Win10 (cutting DWM/compositing overhead/latency completely out-of-the-loop), then I really hope NVidia or one of the vendors will write a nice, clean WGL extension to abstract all this DXGI/D3D12 complexity and let OpenGL apps create a truly maximum performance hardware accelerated window (with associated swap chain) that’ll yield iFlip/iFlip immediate support on Win10+. Failing that, perhaps GLFW/etc. will provide a nice GL wrapper for doing this.

Hi Dark Photon, could you share the link to the NVidia interop sample, please?

I haven’t seen it available online (doesn’t mean it’s not there though). I’d suggest posting a request for it on Just ask for a pointer to some Interop code that shows how to interoperate between DX11, DX12, OpenGL, and Vulkan.

On my system without this mode (called D3DSWAPEFFECT_FLIPEX on D3D9) steady frame rates, regardless of work load, just don’t exist, i.e. there’s a basic synchronization problem… every so many frames something skips a frame with OpenGL or using D3D9 without this mode on Windows 10. I assume it’s the compositor not giving priority to such apps. (I wonder if having to work with D3D11/12 is still the only recourse for OpenGL apps.)

EDITED: Some talk here ( suggests there is some spooky auto-detection logic for this. But it’s not about OpenGL. I couldn’t find a solution to turn it on in this link.)

Yep, very used to seeing that for real-time rendering that is composited by DWM. However…

Since the above, I’ve learned more about this, and there is (at least on NVIDIA drivers) a fairly straightforward way to get fast path rendering to the display rendering purely with OpenGL on Windows 10. In PresentMon, it’s called “Hardware: Legacy Flip”. In this mode, the rendered swap chain image bypasses WDM composition and most of WDM’s overhead, permitting VSync to the display rather than WDM’s virtualized VSync.

On a single GPU system (NVIDIA GPU), you obtain this the same way as usual for Full-screen Exclusive windows (fullscreen window with focus, etc.). On a multi-GPU system, you’ll need a vendor-specific “trick” to bypass DWM composition and force flip presentation mode. This is all with a pure GL app.

Of course via Vulkan, there’s now direct mode which lets you take whole monitors away from DWM and render to them directly. That’s an alternative: Render with GL and display with Vulkan.

1 Like

This is really bad for OpenGL! I think earlier this year everyone was talking about sharing texture memory (pretty much one-way between DXGI/Vulkan and OpenGL) like it’s a standard feature now. That would be better than an Nvidia only extension (which is not really anything unless your software is only used in house) but I wonder if true, it may be limited to very new drivers, and may not be back-ported to old hardware. It was just a topic I came across searching for OpenGL stuff online.

P.S. I don’t think “fullscreen exclusive” is a very good deal, but how this new compositor mode works, as I recall (you probably know this, but readers sake) is instead of compositing, space is reserved for the app in the real (desktop/display) buffer where its window is on screen, and somehow it draws more directly to that space. It sounds like compositing but I think normally there’s a two-step buffer for the “present” under the compositor, and here there is like a waiting area for the compositor to pull from.

Anyway, it’s not a fullscreen mode. It can be a sub-window. I don’t like having to fill a buffer as big as the screen with discard semantics because I often like to leave a big matte region around a game style app. With edge-lit monitors the glow drives me crazy and with a more square aspect on wide-screen no reason to fill a buffer almost twice as large as the screen.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.