To add to that, I have two Vulkan drivers running behind the vulkan.hidd that is in master since the Mesa 26 port, and I would like to send them upstream over the next few days. What exists today, in a tree based on master of 2026-10-15: 1. lavapipe.hidd: Mesa's software Vulkan driver, linked statically withllvmpipe, gallivm, the Vulkan runtime and the target LLVM, registeredas one software GPU with vulkan.hidd. The Vulkan runtime gains whatlavapipe needs (acceleration structure builds, their compute shaderscompiled by glslangValidator as the meson build does, the memory traceexporter). It allocates through stdc/posixc rather than the exec mallocoverride, which lost about 6 MiB of aligned buffers per context. 2. venus.hidd and venusrenderer.library: Mesa's Venus driver with an AROStransport, and virglrenderer's vkr renderer serving it. The Linux filedescriptor and socket plumbing is replaced by shared memory (blobs asregions with handles, host-visible memory imported throughVK_EXT_external_memory_host, 64-bit sync counters). A client in aseparate address space can therefore submit Vulkan work to a rendererthat runs it on a native driver, lavapipe for now. 3. VulkanTriangle: a test program that renders through the whole stack,checks all 4096 pixels against exact coverage, waits on a fence and atimeline semaphore, presents in an Intuition window and reads back,three cycles without leaks. It passes through lavapipe directly andthrough Venus -> renderer -> lavapipe. What I need to do first: • Rebase on Mesa 26.2.5. My tree still carries mesa-26.0.0-aros.diff. • Split the series so each PR builds on master alone:a) lavapipe.hidd against the current interface version 2;b) vulkan.hidd interface version 3: CreateInstance receives the fullVkInstanceCreateInfo instead of a name and a version, and aVulkanHidd_FindDriver() lookup by class so a renderer can pick anative driver whatever the preferred GPU is. This is the ABI changeand I will send it as its own PR with the reasoning;c) venus.hidd and venusrenderer.library. • Fetch virglrenderer (e0a1caf3) and venus-protocol through the tree'sfetch macros and mirrors, with the AROS diff next to the Mesa one. • Headers in the tree's style on every new file. Two questions before I send: • Is a vulkan.hidd interface bump to 3 acceptable, or would you ratherkeep 2 and add the createInfo and the lookup as new methods? • virglrenderer is a second fetched third-party tree under workbench/libs.Any preference between that and a vendored copy under external/? Tested on aarch64 (hosted on macOS and under QEMU/HVF). I cannot test the 32-bit or big-endian targets; the drivers are 64-bit only in Mesa anyway, and the hidd changes are pointer-size neutral, but I will state that in each PR.

but but but sanpos is bringing us Vulkan!!

Actually, ignore most of what I wrote given that @Kalamatee made it not needed anymore last night or needed but different. Kalamatee: your loader gets the Vulkan object from the display driver or falls back to lavapipe: for Venus (Vulkan over virtio-gpu in a VM), would you rather have the virtio-gpu display driver return a hidd.vulkan.venus subclass from CreateObject, or a lookup for a driver that is not owned by a screen?

CreateObject is the correct way to provide the vulkan instance for graphical output.

While lloking into it right now, one detail I should have said: my Venus renderer runs inside the guest, over lavapipe, not on the virtio-gpu host. Wine doesn’t need the HIDD. Do you still want the display to return it before a host-backed transport exists, or should it return NULL until then, so native programs get plain lavapipe?