CODEWITHSUNDEEP
winapiopengldirectx
matthias_buehlmann
matthias_buehlmann

Reputation: 5081

Windows, how to render to video scan-out memory directly?

On Windows and optimally using OpenGL, can I render directly to video scan-out memory (hdmi port of the graphics card)? No buffer swapping, no windowing system - directly rendering to the buffer from which pixels get copied to the wire. Ultimately I want to implement a scanline-racing prototype. But it seems the default way of creating an opengl context on windows involves creating a pixelformatdescriptor and as far as I understand it that just allocates an offscreen buffer (doubly buffered if requessted), the content of which is then copied by the window manager and composited before somehow set as the video scan-out memory.

Upvotes: 1

Views: 697

Answers (1)

datenwolf
datenwolf

Reputation: 162297

On Windows and optimally using OpenGL, can I render directly to video scan-out memory (hdmi port of the graphics card)?

In the days before Windows-Vista DWM/Aero you'd just create a window and create a single buffered OpenGL context. Back in those days, the client regions were memory views of the actual scanout buffer.

Of course OpenGL already back then didn't specify any relationship between when drawing commands were issued and when or in which order they were executed; as long as the "the result looks exactly as-if things were executed in this order" rule was adhered to, any reordering was fair game. So already then you couldn't practically use OpenGL to race the beam. And neither you could with Direct3D, I might add.

What you was possible however is using DirectDraw in exclusive mode, which would actually give you direct access to the whole of the scanout buffer, in a way that'd you'd actually could race the beam.

But given the modern graphics stacks, even with that racing the beam no longer works, because:

No buffer swapping, no windowing system - directly rendering to the buffer from which pixels get copied to the wire.

Well, if you can get hold of ancient hardware that actually works that way. These days it's all about swap chains. On current generation Intel integrated graphics for example, even in text mode the display wouldn't even update if something wasn't pumping the swap chain.

Of course you can still issue a swap while mid frame-scanout, thus tearing the frame. (which is part of the reason, why to this date double buffering in X.Org usually tears moving pictures (video)).

In your comment:

Looking at VR headsets, the VIVE for example, it can run in ‚extended mode‘, in which the headset is just treated as a secondary monitor, or ‚direct mode‘

This direct mode is nothing special. Two things are happening:

  1. The HMD is simply hidden from the selection of displays you can expand the desktop to.

  2. To access the display a direct mode graphics context (using DirectX or Vulkan) is created, which mostly behaves as a fullscreen window, complete with a swap chain.

Vulkan (that text referring to an older version of Vulkan but still applies): https://vulkan.lunarg.com/doc/view/1.0.30.0/linux/vkspec.chunked/ch29s03.html

DRM leases on Linux: https://keithp.com/blogs/DRM-lease/

Upvotes: 2

Related Questions