Pull in Google's gfxstream (Graphics Streaming Kit) for Hardware Acceleration

[dylangerdaly]

The problem you're addressing (if any)
Utilize Google's Graphics Streaming Kit to allow 3D/2D hardware acceleration from the hosts GPU within dom0 to other domU's

Describe the solution you'd like
We need more attack surface please /s

Allow for hardware acceleration for specific domU's, this would be similar to Intel's GVT-g but would hardware agnostic (including ARM)

Forwards both OpenGL and Vulkan workloads to the hosts GPU

Where is the value to a user, and who might that user be?
YouTube that doesn't turn my laptop into a melting firepit, even terminal windows are being accelerated now

Describe alternatives you've considered
Intel's GVT-g

Additional context
Google's gfxstream is the default accelerator for crosvm

Obviously this opens attack surface, essentially opening dom0 up to direct chicanery, however I think a discussion should still be had.

Relevant documentation you've consulted
https://android.googlesource.com/device/generic/vulkan-cereal/
https://source.android.com/setup/create/cuttlefish-ref-gpu

Related, non-duplicate issues
NIL

[DemiMarie]

Qubes OS will implement hardware-accelerated graphics eventually. It could take a very long time, though, so don’t hold your breath.

[DemiMarie]

I think this should be closed. gfxstream uses the host’s OpenGL and Vulkan implementations, and these are not supported security boundaries. This means that gfxstream would likely allow a VM escape. Google might have the resources to prevent this in ChromeOS, but we don’t. Instead, virtio-GPU native contexts will be used (#8552).

[github-actions]

This issue has been closed as "declined." This means that the issue describes a legitimate bug (in the case of bug reports) or proposal (in the case of enhancements and tasks), and it is actionable, at least in principle. Nonetheless, it has been decided that no action will be taken on this issue. Here are some examples of reasons why an issue may be declined:

• No solution can be found.
• The proposed action is not possible.
• The proposed action would weaken security to an unacceptable degree.
• The proposed action would be too costly (in time, money, or other resources) relative to the benefits it would provide.
• The proposed action would make some things better while making other things worse, and the trade-off is not worthwhile.

These are just general examples. If the specific reason for this particular issue being declined has not already been provided, please feel free to leave a comment below asking for an explanation.

We respect the time and effort you have taken to file this issue, and we understand that this outcome may be unsatisfying. Please accept our sincere apologies and know that we greatly value your participation and membership in the Qubes community.

If anyone reading this believes that this issue was closed in error or that the resolution of "declined" is not accurate, please leave a comment below saying so, and the Qubes team will review this issue again. For more information, see How issues get closed.