nvk is the reference Vulkan driver https://alyssarosenzweig.ca/blog/vk13-on-the-m1-in-1-month.html and nak is the reference Rust shader compiler
For a C shader compiler I'm pretty happy with how agx turned out, jay will be better code still. I'll refrain from making judgements about C++ Le Thu, May 28, 2026 at 11:33:28PM -0700, Dylan Barrie a écrit : > Hi all! > > I've spent the last couple years developing a fully-custom, FPGA-based GPU ( > www.furygpu.com) that I've recently gotten to the point where it should be > mostly compatible with the requirements of Vulkan (shaders, for one!), to > the degree that running simple programs would likely be possible. I've been > driving the hardware with a custom API that is basically an API-copy of > Vulkan, but given that the Mesa 3D project has already done a lot of the > heavy lifting in terms of all of the infrastructure, I'm thinking it would > probably be worthwhile to make use of it. It gets a bit tiring having to > re-write every program I want to run! > > Before I get started on this, I had a few questions that I hope those here > can answer: > > 1. I'm currently using a kernel-mode driver (on Windows) to communicate > with the actual hardware. Is there existing infrastructure to deal with > that kind of separation in Mesa 3D already? I've made efforts to slim down > the user-mode <-> kernel-mode interface as much as possible, and it > basically comes down to just setting up DMA ops and telling the GPU to > start executing from a given address. > 2. Is there an existing driver that would be a good starting point in > terms of best practices for working within the Mesa 3D ecosystem? > 3. How does Mesa 3D interact with the OS's windowing system? My current > setup is a kernel-mode display-only driver (like would be used for a > USB->HDMI converter or something), which allows Windows to treat my GPU as > a display output. When it comes time for an application to actually use the > GPU hardware, the driver switches to outputting the rendered image to the > display and the OS continues believing it's driving the display, none the > wiser. > 4. Is there anything else I should be aware of or understand before > starting? > > Thanks for any insight you all may have for me! > > - Dylan
