Demi Marie Obenour writes: > On 1/29/26 09:10, Alyssa Ross wrote: >> Worth marking patches like this as RFC or similar in future, so >> everybody looking at it is on the same page about its status. (I'm >> assuming this was meant as a proof of concept and not meant to be >> applied as is.) > > With the hash change, I was hoping it could be applied. I forgot to > run scripts/genfiles.sh, though, and completely missed the missing > fallback in crosvm. > >> Demi Marie Obenour writes: >> >>> This exposes GPU acceleration to VMs via virtio-GPU native contexts on >>> AMD and Qualcomm GPUs. Apple GPU support also exists but might require >>> patches to virglrenderer that are not upstream yet. >>> >>> On a system with an AMD GPU, this has been tested by running vkcube in >>> the VM. It reports that the AMD GPU is being used for rendering. >>> >>> Signed-off-by: Demi Marie Obenour >>> --- >>> I used an empty string for the hashes in 'gitfetch' and >>> 'buildRustPackage'. This is, of course, incorrect. The correct value >>> according to my own testing is >>> "sha256-EOMkQ0aPRjsowdGuZjy5K1yKyKEzd5AVYxaECTz7n6k=" (git hash) and >>> "sha256-k3dmxIuCQoOrn/VwauTdzuRw/XKQB6LPLgO5ql0rE7E=" (cargoHash). >>> However, these should be validated before applying them, which is why I >>> didn't include them in the patch themselves. This is a security >>> precaution: anyone who wants to inject malicious content must serve it >>> to multiple people, not just one. >>> --- >>> .../template/data/service/vhost-user-gpu/run | 2 +- >>> img/app/Makefile | 2 +- >>> img/app/default.nix | 14 ++++++++++++-- >>> img/app/image/etc/mdev.conf | 1 + >>> .../notification-fd | 0 >>> .../notification-fd.license | 0 >>> .../{wayland-proxy-virtwl => wl-cross-domain-proxy}/run | 17 +++++------------ >>> .../type | 0 >>> .../type.license | 0 >>> 9 files changed, 20 insertions(+), 16 deletions(-) >>> >>> diff --git a/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/vhost-user-gpu/run b/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/vhost-user-gpu/run >>> index fb9ac9971aef82dabe0b54c1299ac8c66d133eb5..87d72f55e293ea81b6f4aa12786a993bafc623e2 100755 >>> --- a/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/vhost-user-gpu/run >>> +++ b/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/template/data/service/vhost-user-gpu/run >>> @@ -42,4 +42,4 @@ bwrap >>> crosvm --no-syslog device gpu >>> --fd 0 >>> --wayland-sock $WAYLAND_DISPLAY >>> - --params "{\"context-types\":\"cross-domain\"}" >>> + --params "{\"context-types\":\"cross-domain:drm\"}" >> >> I suppose we'll need to get some sort of graceful fallback into >> crosvm/rutabaga, or to somehow detect native contexts support in this >> script before we enable it on the crosvm command line? >> >> 2026-01-29 14:06:30.082434936 [2026-01-29T14:06:30.082073581+00:00 ERROR rutabaga_gfx::virgl_renderer] failed to initialize drm renderer >> 2026-01-29 14:06:30.082842461 [2026-01-29T14:06:30.082652949+00:00 WARN rutabaga_gfx::rutabaga_core] error initializing gpu backend=virglrenderer, falling back to 2d. >> 2026-01-29 14:06:30.099779984 [2026-01-29T14:06:30.099379669+00:00 WARN devices::virtio::gpu::virtio_gpu] virtio-gpu get_capset_info(index=1) failed. intentionally poisoning response > > Ideally crosvm would fallback automatically, but on ChromeOS it never > needs to because it is built specifically for its target hardware. Okay, but crosvm is open to contributions. They're willing to accept affordances for non-Chrome OS use. Even Google doesn't use it exclusively on Chrome OS… > It should be sufficient to detect if an AMD or Qualcomm GPU is > available and the user has enabled GPU acceleration. That doesn't sound very good, because then we'll have to keep updating it as new GPUs are supported.