Investigate Intel/NVIDIA Venus Vulkan failure on current runtime

[btsouth]

Goal

Make the current bundled runtime's translated Vulkan path usable on Intel/NVIDIA hosts where OpenGL already boots, and retain a reliable CPU/OpenGL fallback when it cannot.

Observed result

On a Windows 11 Pro Intel Core i9-14900KF / RTX 5080 host, the v0.0.20-preview runtime booted Hyprland with accelerated VirGL OpenGL. In the same guest, vulkaninfo --summary failed at vkCreateImage with ERROR_FORMAT_NOT_SUPPORTED; Godot Forward+ detected Venus then wedged QEMU; stock Blender's OpenGL viewport failed with EGL_BAD_MATCH. The exact driver, runtime hashes and commands are in the September 20 record.

The PC now runs Omarchy and its owner does not want it rebooted into Windows. These observations are from an older runtime and do not establish that r19 still fails. They are a concrete compatibility gap to investigate when a current-runtime report or suitable host is available; they do not block normal 0.x releases or require a broad hardware matrix.

Acceptance

• Reproduce or rule out the recorded Vulkan and Godot failures against the current r19 or newer runtime with the same guest/driver facts captured.
• If reproducible, isolate whether the failure is guest Mesa, VirGL/Venus, host Vulkan driver, QEMU's graphics path, or application requirements. Make a source-locked runtime/guest fix or a capability-based fallback with a clear user-facing result.
• Keep OpenGL desktop and CPU fallback working. Do not promise CUDA/OptiX or physical GPU passthrough from virtio GPU translation.
• Record an application-level retest, not just a GPU desktop boot.

[btsouth]

Closing this one. It's based on an older runtime and the PC it came from no longer runs Windows, so there's nothing to test against. If you hit Vulkan problems on Intel or NVIDIA with a current release, please open a new issue with vulkaninfo --summary output and your GPU and driver version.