Comment by delta_p_delta_x
3 days ago
By 'impossible', I mean it in a very strict sense of blitting full-screen frames directly into the framebuffers provided by HDMI or (e)DP representing a visible surface. This is still kind of possible in Windows when games are properly full screen and not 'borderless full screen', but the OS still does compositing in the background, and the GPU is still involved to some extent.
Of course, offline rendering is a different story.
Modern "GPUs" have the ability to scan out from multiple buffers at the same time and do rectangular compositing during the scan out -- basically like a few giant sprites. It's got absolutely nothing to do with normal GPU work. Zero.
It lets a few unobstructed windows do animation without having to involve the compositor => lower latency AND lower energy use. They do NOT have to be full screen at all.
Oh, and they can also handle framebuffer formats that aren't RGB. This is very useful for video, as the natural format there is YUV or something similar. The YUV => RGB conversion step becomes unnecessary.
I suppose the disagreement here is on the scope of “rendering.”
There's in no path for that. Each GPU is different, and I suspect won't even let the CPU access the final framebuffer they use for video signals, even if you wrote the driver yourself.
As for Windows compositing, use the graphics API to acquire exclusive fullscreen. Vulkan gives this example:
https://github.com/KhronosGroup/Vulkan-Samples/tree/main/sam...
> the OS still does compositing in the background
Since Windows 10 fullscreen mode can use a borderless window, with DWM not compositing if the game covers the entire screen. That's how Alt-Tab switches smoother and faster now.
https://devblogs.microsoft.com/directx/demystifying-full-scr...