In general, most Mesa drivers works in a similar way; they communicate with a kernel mode driver that programs the actual hardware. So you'd still need one of those.
On Windows, my understanding is that kernel module drivers would generally expose a WDDM2 driver, and we'd communicate with that, somehow. However, we don't have any GPU drivers that communicate with a kernel mode driver on Windows upstream in Mesa yet. This is all still work-in- progress Faith Ekstrand had a presentation about this on XDC 2024, which you can see here: https://indico.freedesktop.org/event/6/contributions/296/ Here's an MR relating to that topic: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29945 So yeah, I think choosing to do this on Windows kinda enables "Hard Mode" for your driver, but it's not impossible to do. On Fri, May 29, 2026 at 1:57 AM Erik Faye-Lund <[email protected]> wrote: > On Thu, 2026-05-28 at 23:33 -0700, Dylan Barrie wrote: > > 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! > > That's some impressive progress there for sure! Cool project :) > > > 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. > > In general, most Mesa drivers works in a similar way; they communicate > with a kernel mode driver that programs the actual hardware. So you'd > still need one of those. > > On Windows, my understanding is that kernel module drivers would > generally expose a WDDM2 driver, and we'd communicate with that, > somehow. > > However, we don't have any GPU drivers that communicate with a kernel > mode driver on Windows upstream in Mesa yet. This is all still work-in- > progress > > Faith Ekstrand had a presentation about this on XDC 2024, which you can > see here: > https://indico.freedesktop.org/event/6/contributions/296/ > > Here's an MR relating to that topic: > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29945 > > So yeah, I think choosing to do this on Windows kinda enables "Hard > Mode" for your driver, but it's not impossible to do. > > > 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? > > I would usually say "look at the most modern driver in Mesa", which > probably would be NVK at this point, and copy that as a starting-point. > But you probably want to look at other actively developed drivers as > well, such as RADV, Turnip and PanVK. It's usually better to look at > what multiple drivers are doing, and try to understand why their > approaches sometimes differ. > > Other than that, we have a lot of documentation at docs.mesa3d.org, > including for the Vulkan Runtime, NIR, how to submit patches etc. > > > 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. > > Communication with the window system happens using shared memory. This > would typically be something like DMAbufs on Linux, and AFAIK WDDM > shared memory handles on Windows. > > Doing it this way lets the operating system do things like multi-GPU, > where it can render on one GPU and display on another. There's a lot of > little details to this, but the gist is that we need some shared memory > objects, fences to control the timing of the access to the memory > objects and some memory layout negotiation to all ends agree on these. > > I only know the Linux side here well, and in that case these pieces > would be dma_buf, dma_fence and DRM modifiers. > > > 4. Is there anything else I should be aware of or understand > > before starting? > > Just a heads up: making a GPU driver is a huge task. Doing it alone > makes it even harder. So consider teaming up with someone, and make > sure it's as easy for others as possible to help out! > > Also, one of the biggest job of a GPU driver is making the shader > compiler. There's a lot of videos of XDC and FOSDEM presentation about > the shader compilers in Mesa, those would probably worth a look. > > Oh, and also, if you're serious about this, consider attending XDC! > https://xdc2026.x.org/ > > > Thanks for any insight you all may have for me! > > > > - Dylan > > Thanks for sharing your cool project, and good luck! > > - Erik >
