QubesOS
Support for opt-in GPU acceleration via virtio-GPU native contexts
The problem you're addressing (if any)
All rendering happens in software. This is fast enough for many uses, but some users need better performance, even at the expense of increased attack surface.
The solution you'd like
Opt-in GPU acceleration via virtio-GPU native contexts.
The value to a user, and who that user might be
Users for whom software rendering has unacceptable performance will be able to use Qubes OS, without resorting to PCI pass-through.
Dependency tree
Any issue in this list should have https://github.com/QubesOS/qubes-issues/labels/C%3A%20GPU%20acceleration and, if it relates to Wayland support, https://github.com/QubesOS/qubes-issues/labels/C%3A%20Wayland as well.
Basic GPU acceleration
This is sufficient for GPU compute but not for rendering.
Cross-vendor
- [ ] #8983
Intel-specific
- [ ] Wait for Intel virtio-GPU native contexts to be merged upstream.
- [ ] Optional: Wait for them to be shipped in Google ChromeOS, which would make them in-scope for Google’s Vulnerability Rewards Program.
AMD-specific
- [ ] Wait for AMD virtio-GPU native contexts to be merged upstream.
- [ ] Optional: Wait for them to be shipped in Google ChromeOS, which would make them in-scope for Google’s Vulnerability Rewards Program.
Wayland support
virtio-GPU will use Wayland to pass GPU buffers to the host display server, so Wayland support is required.
- [ ] #8973
- [ ] #3366
- [ ] #8515
User control over GPU acceleration
Users need to be in control over which VMs have GPU acceleration
- [ ] #8962
Security hardening
Qubes OS must remain reasonably secure even if GPU acceleration is in use.
- [ ] #8969
- [ ] #8972
- [ ] #8974
- [ ] #8984
Testing
Shipping an untested feature is quite ill-advised.
- [ ] #8554
- [ ] #8968
Fault detection and recovery
GPUs can have problems and users need to be able to recover.
- [ ] #8963
- [ ] #8971
- [ ] #8982
https://github.com/orgs/QubesOS/projects/17 bundles efforts regarding GPU acceleration in Qubes OS
