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.
Sorry if you receive it twice. I seem to have had some issue with the
mailing list.
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
