Okay, so after doing some research, I think I have finally gotten a handle on how the new Longhorn driver stack functions. I am going to reprint my own OSnews.com post here.
What is really important to note is this is the FIRST time that the rendering extensions portion of the driver (the GFX engine components supplied by OEM’s) has actually been moved out of kernel mode or OS subsystem address space.
Most people (including nearly every post on OSNews) misunderstand the NT 4 architectural changes that were made. In that case, user+GDI windowing and graphics subsystems (Microsoft supplied) components were moved out of the user mode win32 subsystem (csrss.exe) and moved into kernel mode as a driver (win32k.sys). The vendor supplied components (miniport and hardware specific rendering routines) were always either in kernel mode or ran in the same address space as vital operating system code (csrss.exe). The code was NEVER isolated in a separate (non-OS critical) address space.
It is also very important to note that any failure that occurred in csrss.exe, despite running in user mode, would take the system down with a bluescreen indicating that a fault in a critical subsystem (csrss.exe) had occurred. Csrss.exe is the user mode integral win32 application environment subsystem and, as such, the system can’t function with out it.
The stability issues with NT 4 were a result of a rushed development process, not fundamental architectural issues. The moving of user+GDI code to kernel mode made tremendous sense as there was little logic to keeping it in csrss.exe when all sorts of “rule breaking” and resource expensive tricks were needed to improve performance (thread paring, special fast context switch routines, shared buffers, etc.). Windows Server 2003 is very stable by any measure (the most stable version of NT to date) and is based on what is a nearly identical graphics driver model to NT4.
Now, what has changed in Longhorn is that some of the hardware specific rendering routines (Direct3d related) that used to run in kernel mode have been moved into user mode via the D3d runtime environment used by D3d application and the new compositing display engine (uxss.exe), which is completely Direct3d based on the output or backend via the Direct3d runtime environment.
It is interesting to note that user+GDI applications still call (via stub dll) into routines hosted in the KERNEL mode win32k.sys driver which in turn calls functions in the new DirectX kernel mode subsystem rather than the old vendor supplied routines. This new DirectX kernel subsystem has a GPU scheduler, memory manager and the ability to render GDI apps either directly to the screen (via the miniport driver if the compositor is turned off) or to an off-screen texture buffer which is then used as a texture by the compositor (uxss.exe) and placed on top of a 3d surface. This is how Longhorn can switch dynamically between composited and traditional modes on the fly.
It is VERY important to note that this new Microsoft supplied kernel mode subsystem takes over much of the work the old vendor supplied routines were responsible for. Only the D3d implementation specific code is left for the vendor to implement and that runs in the user mode uxss.exe process (that aforementioned compositor) or the user mode address space of a Direct3d application. It is through both a combination of Microsoft taking over a large amount of the hardware control process and moving vendor supplied portions of code to user mode that a big gain in stability is expected (note: nowadays, it is very rare that Microsoft supplied kernel mode code is responsible for system stability issues)
In short, the user+GDI pieces that were moved to kernel mode as of NT 4 are still in kernel mode. Also, the lowest level hardware control driver, the miniport driver, is still in kernel mode. However, much of the code the vendor used to write has been subsumed by the DirectX kernel mode subsystem. What remains, that isn’t miniport, is in user mode as part of the D3d runtime environment.
All of this, by the way, sits BELOW Avalon, which is a display PROGRAMMING model that wraps around the D3D engine to provide an easy to use device independent vector based presentation engine (think of it as a super-wrapper for D3D).
For more information, be sure to visit: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Display_d/hh/Display_d/DisplayDriverModel_Guide_36da9e1a-2bf8-4336-b213-3bf5b703ef18.xml.asp
Until next time…
