I’m beginning work on a WDDM driver for a custom-designed FPGA-based GPU. From what I’ve understood of the MSDN documentation, there is a minimum level of hardware functionality that is required to allow the driver to work with the D3D runtime, namely, that some level of programmable vertex and pixel processing be available. As it stands, my GPU is entirely fixed-function and does not support any programmable shading.
I do not really intend to have support for the D3D runtime (and given the shading requirements, I can not), instead using my own rendering API to perform any rendering. One thing I do want, however, is to have my hardware able to display the Windows desktop so the machine can be interacted with entirely through this custom GPU.
So, I’ve got a few questions before I start going down the long and incredibly complex path of building a full WDDM mini port driver:
- Is a WDDM driver appropriate here?
- Can I somehow have the driver inform the D3D runtime that programmable shading is unavailable, and have the runtime work around that restriction (using WARP and performing D3D rendering on the CPU, for example)?
- Would writing a KMDOD instead of a WDDM driver be a better way to go? Does such a driver provide ways to hook in when I want to stop displaying the Windows desktop and start rendering 3D scenes using my rendering API that would behave correctly from a user perspective?
I have already written a basic kernel-mode driver that can talk to the hardware and a user-mode implementation of my rendering API that work together to allow me to render scenes, but one of the goals of the project is that the GPU work as the only display output device in the system, and having the Windows desktop display through it is a requirement there. One thing that I have considered (but not yet decided) is potentially exposing an INT10h VGA interface from the hardware, which would let both the UEFI boot and the Basic Display Driver “just work” (as far as I understand), but I’d rather not do that unless there’s no other option.
I would very much appreciate it if anyone familiar with this stuff give me some pointers on the best way to approach this!
I’m beginning work on a WDDM driver for a custom-designed FPGA-based GPU.
I’m astonished by this. What’s your end goal? Most non-server CPUs these days have graphics devices built-in, and they have a 30-year head start on you.
Is this just for fun? Windows is a hostile environment for display drivers. You would find much more satisfaction by doing this in Linux, where you could create a kernel frame buffer driver and an X Windows driver in relatively little time.
> @Tim_Roberts said: > I’m astonished by this. What’s your end goal? Most non-server CPUs these days have graphics devices built-in, and they have a 30-year head start on you. > > Is this just for fun? Windows is a hostile environment for display drivers. You would find much more satisfaction by doing this in Linux, where you could create a kernel frame buffer driver and an X Windows driver in relatively little time. My masochistic streak does go pretty deep, I’m well aware! Yes, this is purely a “for fun” (given a very loose definition of the word “fun”) project - the hardware is designed and built to a mid-90s-era feature level, entirely fixed-function. My test application has primarily been a port of Quake (seen here running on one of the FPGA’s hard ARM cores), and from the beginning one of the main goals of the project has been to have something I can plug into a PC, install some drivers, and have it run actual applications (old though they may be!). I’ve built a full PCIe add-in card for the design from scratch, built runtime drivers for the card itself, and spent countless hours simulating and debugging all aspects of it. I say this not to brag about my technical achievements (well, maybe a *little*), but to make it clear the effort and dedication I’ve put into the project. I fully understand the complexity involved here, what am I less familiar with is the feasibility. I certainly could just use Linux and save myself a lot of effort, but doing so would also mean that showing off the project becomes far less “impressive” to the kinds of people who would understand what’s involved. The goal is to run it on Windows, and Linux is simply not Windows! As mentioned, I’ve already written a simple kernel mode and user mode driver pair for the hardware that I’ve used to prove that the hardware can and does work on Windows, so assuming that I am able to work around the fixed-function nature of the design with respect to the WDDM driver (possibly by manually converting the shaders used by the windows display manager into fixed-function equivalents or something), I do not believe the effort to be futile. I’ve put a significant amount of effort into this project, and am more than willing to continue doing so. My background is in graphics engineering and low-level engine design (AAA video games), and as mentioned, I’m **extremely** aware of how much work is involved here. Edit: I thought markdown syntax was supported? Ah well, copy and paste the links manually, I guess!