An initial investigation into WDDM on ReactOS(reactos.org)
reactos.org
An initial investigation into WDDM on ReactOS
https://reactos.org/blogs/investigating-wddm/
14 comments
This is true.
Microsoft and GPU companies (nvidia, amd, intel mostly, but there obviously were many others) collectively spent literally billions (not a typo - think about the engineer-hours on these multi-million-LOC code bases) on getting the windows graphics driver model mostly right. The amount of tooling is staggering and the fact that a crash in the driver most of the time just causes the screen to blink for a second instead of a bsod is amazing.
Microsoft and GPU companies (nvidia, amd, intel mostly, but there obviously were many others) collectively spent literally billions (not a typo - think about the engineer-hours on these multi-million-LOC code bases) on getting the windows graphics driver model mostly right. The amount of tooling is staggering and the fact that a crash in the driver most of the time just causes the screen to blink for a second instead of a bsod is amazing.
https://www.yosoygames.com.ar/wp/2015/09/maybe-its-time-to-t... (2015)
Still seems very relevant.
Still seems very relevant.
I am not sure if this is relevant because most of the things listed there are not problems anymore. X11 is mostly replaced with Wayland, VSync generally just works, we have lightweight Compositors now. Heck, the other day I was messing with VFIO and for some reason the early GPU grab didn't work, so my system booted in the external GPU instead of the internal GPU, but after booting my VM KDE just flashed because my external GPU was gone but everything went back working without a need for relogin.
I am not sure about security or how easy it is to hang the system though, I assume those are still true.
I am not sure about security or how easy it is to hang the system though, I assume those are still true.
> after booting my VM KDE just flashed because my external GPU was gone but everything went back working without a need for relogin.
What GPU are you using and how did you configure this, if you don't mind me asking? On my end I just can't unload the driver for it if I let KDE start with the external GPU available.
What GPU are you using and how did you configure this, if you don't mind me asking? On my end I just can't unload the driver for it if I let KDE start with the external GPU available.
A Sapphire Radeon 9070 as the external GPU and a Ryzen 7 7600 as the integrated GPU. But I don't recommend this particular model for the 9070 if you want to do VFIO, it has the infamous reset bug so after booting the VM once I can't use the external GPU anymore unless I restart the machine. Also I never got the VFIO completely working, I could pass the GPU to the VM but the VM could not find the GPU (e.g., the AMD drivers said "no GPU found" while running the installer).
Actually, now that I think about this could be that my system is set to autologin (I am using Jovian-NixOS to get a almost SteamOS experience), so maybe this is not KDE being smart and could just be that it crashed and the system automatically login again. So yes, maybe this doesn't work.
[deleted]
What I don't really get about ReactOS is... why did they not go for the route of focusing on getting the Windows binary compatibility layer for drivers working first? I 'member some horrible WINE plus other stuff layer for NDIS network drivers to be used on Linux, so the theory should work out.
That way, they could have used allll the existing Windows drivers there are, by prompting the user to insert a legitimate Windows CD to pull them from (similar to how OpenTTD or Doom ask for the original asset files) they wouldn't need to take care of copyright as well...
That way, they could have used allll the existing Windows drivers there are, by prompting the user to insert a legitimate Windows CD to pull them from (similar to how OpenTTD or Doom ask for the original asset files) they wouldn't need to take care of copyright as well...
Most likely, it didn't happen (yet) due to kernel related stuff being still actively worked on¹ and (more importantly) due to a shortage of developers willing and capable to tackle that kind of challenge.
¹ At the time of this writing, there are open PRs like this one: https://github.com/reactos/reactos/pull/8422
¹ At the time of this writing, there are open PRs like this one: https://github.com/reactos/reactos/pull/8422
Confusingly written article, to the point of being unreadable unless you already know exactly how graphics drivers in Windows work.
"WDDM is a major overhaul that shifts responsibility of managing the GPU away from Win32k and gives better control over the GPU to the driver vendor. Dxgkrnl.sys, the DirectX graphics driver, talks to a miniport driver to provide varying levels of WDDM interfaces."
"Officially starting with Windows 8, every GPU driver for the system had to be a WDDM driver. But all that was really dropped was the miniport driver."
"For WDDM, the communication back to the miniport driver is more direct."
So does the miniport driver exist in modern Windows at all (and is an essential part of how WDDM works), or was it dropped?
"WDDM is a major overhaul that shifts responsibility of managing the GPU away from Win32k and gives better control over the GPU to the driver vendor. Dxgkrnl.sys, the DirectX graphics driver, talks to a miniport driver to provide varying levels of WDDM interfaces."
"Officially starting with Windows 8, every GPU driver for the system had to be a WDDM driver. But all that was really dropped was the miniport driver."
"For WDDM, the communication back to the miniport driver is more direct."
So does the miniport driver exist in modern Windows at all (and is an essential part of how WDDM works), or was it dropped?
Always happy to see reactos news!
DWM is also an unsung hero of the Windows graphics stack that isn't equalled elsewhere.