Re: Mesa 3D driver for custom GPU hardware?

Hello Dylan,


I remember coming across FuryGpu last year and reading the texture unit 
blog post. It's great seeing you've progressed further with this.


At the time of writing, I believe there is no Mesa3D Vulkan driver 
working on Windows, apart perhaps virtualization, WSL, or translation 
layer between two APIs. Please correct me if I'm wrong here.

In XDC 2024 Faith Ekstrand did demonstrate running RADV on Windows: 
https://indico.freedesktop.org/event/6/contributions/296/ . From the 
slides it seems like for the windowing side of things WSL was used since 
it "exposes a Wayland compositor with wl_shm" - "I didn’t have rewrite 
the Vulkan WSI before I can see something".

The starting point for WDDM2 in Mesa is: 
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29945 .


To try answer some of your questions with how things work on Linux (an 
hopefully transfer to Windows through WDDM2):

1.

Mesa3D implements the userspace drivers, which then work with the kernel 
driver through the kernel's Direct Rendering Manager (DRM) subsystem. 
DRM provides a common interface but some things have to be implemented 
per GPU architecture. See 
https://gitlab.freedesktop.org/mesa/mesa/-/tree/main/include/drm-uapi?ref_type=heads 
where the Linux DRM Userspace API (UAPI) headers are included, to see 
what this interface looks like. On Windows, I'd assume this interface to 
be through WDDM2 and what Faith mentioned being the `pPrivateData`.

On a high level, the userspace driver compiles the shaders (In Mesa we 
have NIR and then each driver's own backend to finally produce the GPU 
assembly), constructs the command/control stream, and submits it to the 
kernel. And the kernel is then in charge of scheduling jobs on the GPU, 
although in some cases the GPU firmware might be doing the scheduling. 
Job synchronization is handled through Linux'es syncobj, the userspace 
driver creates the chain of how jobs should be synchronized with each 
other, but the lower level details and how this transfer to the hw is 
handled by the kernel driver.


2.

Not sure on this. v3dv might be good as a stating point, I think it 
should be approachable. For best practices, I think nvk was one of the 
more recent drivers so perhaps it has the best structure. Maybe someone 
else can chime on this. If you want to look at a tiler GPU driver, like 
I think FuryGpu is, maybe turnip or panvk.


3.

For Vulkan this is through the Vulkan Window System Integration (WSI). 
See https://docs.vulkan.org/guide/latest/wsi.html . Mesa support 
VK_KHR_win32_surface in Dozen (Vulkan to D3D 12 driver) and Zink (OpenGL 
to Vulkan driver), but this I think it's just for dealing with windows 
within Windows itself, so I guess Windows'es compositor, rather than 
taking control of the full display like direct-to-display 
(https://docs.vulkan.org/spec/latest/chapters/VK_KHR_surface/wsi.html#display) 
would do. I think we don't have support for direct-to-display for 
Windows in Mesa, so if you want to take full control of the display, 
that would likely need to be implemented.

In Linux, on a high level simplified view, how things work are that in 
the kernel you'd have a display driver controlling the hardware, Linux 
has DRM/KMS (Kernel Mode Setting), and generally you'd have your Wayland 
compositor (or X server) in userspace working with DRM/KMS. When a new 
window is opened, WSI works with the compositor and I think generally 
we'd have a shared buffer (dmabuf) which we use to render content from 
the GPU. The compositor is then in charge of compositing/showing the 
final window to the screen. With direct-to-display you don't have a 
compositor running, instead WSI works directly with DRM/KMS to display 
the rendered content (this is the part that we're missing for Windows I 
think, maybe it works through WDDM2 or maybe Windows has a different API 
for this, not sure).


I hope this helps.


Regards,

Karmjit

On 29/05/2026 07:33, Dylan Barrie wrote:

> Hi all!
>
> I've spent the last couple years developing a fully-custom, FPGA-based 
> GPU (www.furygpu.com <http://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