Apologies for the half-sent reply, Gmail has gotten super fun with all of its... changes.
Thanks for the info, Erik! 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. I'm already doing very much that - I've got a WDDM2 driver (that just so happens to be the "display-only" portion, as far as the OS is concerned) and I utilize the DxgkddiEscape <https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/d3dkmddi/nc-d3dkmddi-dxgkddi_escape> function to send data back-and-forth between the user and kernel mode drivers. So far, has worked great! As Faith points out in her presentation slides, having a full D3D12 stack in the kernel driver is generally a requirement for all of the windowing system interop stuff - having it use the GPU to composite the display, allowing D3D stuff to live in a window and not forced to be full-screen, etc. At the moment, I'm okay with bypassing all of that and pretending that full screen is the only thing it can do. I'm mostly interested in running games, and games typically take up the entire screen anyway! 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. Awesome, I'll start there! 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. I've got a very "simple" mechanism for fencing ops at the moment, where I basically just wait for a device address to be set to a given value and stall/delay the host until that value is DMA'd back. I've been considering adding a better mechanism (interrupts, something) and some more hardware to make it a bit cleaner in that regard, but yeah I'll take a look at how it works for Linux in Mesa to see how I might want to adapt my own setup. 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. Don't I know it! I've been doing rendering work for games for my entire career (and earlier, honestly!), and part of the reason I started this project was to dig a bit further into the lower-level details of the hardware and driving it. Doing it alone is half the fun. ;) I took a few shortcuts, but the shader compiler is already done on my side - I'm cheating a bit by utilizing the very fast A53 cores in the Zynq UltraScale+ as shader execution units, utilizing their NEON instructions to go wide. I have a custom SPIR-V-to-NEON-intrinsics translator, so as long as whatever high-level language can be compiled down to SPIR-V, I can translate it to what my hardware needs. I use Clang compiled as a static library to actually compile the translated code down to an executable, and the driver manages copying it to the device and setting it up for execution as needed during command-list generation. It's certainly not perfect, and it's only really been tested on the few small shaders I've written or adapted for Quake and Doom 3, but it does work! Thanks again! - Dylan 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 >
