Keith Packard Plumbs Direct Display Extensions Into RADV & ANV

[phoronix]

Phoronix: Keith Packard Plumbs Direct Display Extensions Into RADV & ANV

As part of his ongoing contract work for improving virtual reality head-mounted display (VR HMD) support on the Linux desktop, now that his DRM leasing and other X.Org Server / kernel level work is getting in order, Keith Packard sent out a set of patches implementing direct display extensions for Mesa's Radeon RADV and Intel ANV Vulkan drivers...

http://www.phoronix.com/scan.php?page=news_item&px=KeithP-Vulkan-Direct-Display

[tildearrow]

Typo:

The code added to Mesa for the ANV/RADV Vulkan drivrs implement

[TheOne]

Couldnt this get used for fullscreen games too? I wonder if there are performance gains...

[timofonic]

So why is this part of that instead being just part of Wayland protocol? Excuse me for my ignorance, but I don't understand the reasoning behind this. Can someone explain it? Please, I'm curious about all this VR fluff.

Is the ValveVR compositor Open Source or implementable as having Open Specifications or proprietary?

[FishPls]

So why is this part of that instead being just part of Wayland protocol?

Keith Packard doesn't really like Wayland, he's like the oldest X dev still around.

[haagch]

Couldnt this get used for fullscreen games too? I wonder if there are performance gains...

It could, but the problem is that there is the mouse & keyboard input in a lease. The VR applications get away with it because with OpenVR/SteamVR applications get input from the controllers via a special API in OpenVR and don't use the generic X keyboard and mouse input. Furthermore with OpenVR/SteamVR applications are supposed to have a preview or "companion window" on the desktop and applications that need it can just get mouse and keyboard input from that window.

There could of course be an automatic input forwarding service but someone would have to implement it.

So why is this part of that instead being just part of Wayland protocol? Excuse me for my ignorance, but I don't understand the reasoning behind this. Can someone explain it? Please, I'm curious about all this VR fluff.

Is the ValveVR compositor Open Source or implementable as having Open Specifications or proprietary?

Now it's part of the randr and X protocol. Wayland will probably add support soon.
SteamVR is closed source. Reimplementing the whole compositor with all the fancy frame prediction&interpolation when the application renders too slowly etc is probably a lot of work. But implementing OpenVR just so it gets something on the screen isn't too bad. See for example: https://github.com/ChristophHaag/openvr_api-libre. That project is just the bare minimum though, to make it usable for most OpenVR applications takes a lot more actual implementation.

[timofonic]

It could, but the problem is that there is the mouse & keyboard input in a lease. The VR applications get away with it because with OpenVR/SteamVR applications get input from the controllers via a special API in OpenVR and don't use the generic X keyboard and mouse input. Furthermore with OpenVR/SteamVR applications are supposed to have a preview or "companion window" on the desktop and applications that need it can just get mouse and keyboard input from that window.

There could of course be an automatic input forwarding service but someone would have to implement it.


Now it's part of the randr and X protocol. Wayland will probably add support soon.
SteamVR is closed source. Reimplementing the whole compositor with all the fancy frame prediction&interpolation when the application renders too slowly etc is probably a lot of work. But implementing OpenVR just so it gets something on the screen isn't too bad. See for example: https://github.com/ChristophHaag/openvr_api-libre. That project is just the bare minimum though, to make it usable for most OpenVR applications takes a lot more actual implementation.

What's the reasoning for not Open Source it? :O