OSNews

That's what happens when you put php+mysql @ 3.95mo kids writing tech articles...

a lot like this site... heh

No, they don't move graphics out the kernel: Avalon is a high-level-layer, more like an API. It's likely rendered by some lower-level stuff like OpenGL or normal Windows graphics drivers.

No, they don't move graphics out the kernel: Avalon is a high-level-layer, more like an API. It's likely rendered by some lower-level stuff like OpenGL or normal Windows graphics drivers.

This isn't about Avalon. It's about Vista's display driver architecture (VDDM). Display drivers written for Vista consist of a display driver and a miniport driver. This is not unlike the Windows 2000/XP driver model except in those OSes both driver components and the graphics engine were in kernel mode.

In Vista, the graphics engine and display driver are in user mode while the miniport is still in kernel mode.

Here are a couple of diagrams to make things clearer:
2000/XP
http://msdn.microsoft.com/library/en-us/Display_d/hh/Display_d/Vide...

Vista
http://msdn.microsoft.com/library/en-us/Display_d/hh/Display_d/Disp...

beat me to it Anonymous (IP: 70.70.144.---) :-)

Edited 2005-12-18 00:27

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).

I hope this clears things up.

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.

I think that this is crucial for (mis)understanding the claim that "Vista moves graphics out of kernel". The only thing that has been moved is SOME part of vendor-supplied driver logic that has been moved to userland (ring3) - the user mode display driver.

Inside the ring0 (kernel-mode) there are still:

1) vendor-supplied display miniport driver

2) win32k.sys which on NT 5.2- contanis USER/GDI/CON logic and on Vista this has all been mostly routed to kernel-mode DirectX driver

3) dxgkrnl.sys which is basically the core of Vista graphic subsystem as even OpenGl is routed onto it, and it's obviously NOT "moved out of kernel".

So basically user-mode WPF components are something analogue to gdi32.dll/user32.dll/comctl32.dll etc. for USER/GDI that we have today on winXP.

Also, WinFX redistributable (which contanis WPF/WCF/WWF) will be back-ported to winXP (you can download beta now), and I think that this very fact dismisses most claims of moving graphics to userland, since winXP DOESN'T and WON'T support LDDM and you DON'T need to reinstall your GPU drivers after winFX installation.

So from how you explained it (ivans), Microsoft has basically taken on more of the back end work so that the vendor needs to do less to get their driver up and running - now in theory, that sounds nice, but it simply pushes the responsibility for (in)stability back to Microsoft - its a nice way of Microsoft to implicitly state, "the driver manufacturers can't get their shit together, so we're going to take on a large portion of the work involved".

As for instability, per say, it isn't always the drivers fault; I've seen instability that can be basically put right down to the poor quality of the actual hardware - I've run Matrox cards for most of my computing existance, and coupled with their drivers, I've never experienced the kinds of instability that I saw with my first (AND LAST!) Nvidia graphics card.

The issue shouldn't be so much "lets copy [operating system]" but asking HOW and WHY they can get performance so similar to Windows and yet, their graphics 'gear' sits on the outside of kernel space - Windows Vista was the perfect time to let loose with the slicer and remove the crap that was causing problems, but like so many other releases, Microsoft crumpled like a styrofoam cup, and scaled back their vision to something also resembling a service pack.

"its a nice way of Microsoft to implicitly state, "the driver manufacturers can't get their shit together, so we're going to take on a large portion of the work involved". "

They did it for that reason, and because they needed to implement a controlled gfx pipeline, video memory management and device virtualization. The new directX kernel mode subsystem is a very sophisticated (I highly recommend reading some of the published documentation, it's really cool stuff) and, well, the old model just wasn't going to cut it going forward.

-Mak

RE: makfu

Yes, but what I am saying is this, does it actually *REALLY* fix the inherient flaws that exist within the Windows driver framework or is it simply a matter of moving the chairs on the deck?

Yes, its all very nice to have sexy, sophisticated technologies, but if the underlying structured is completely buggered, is it really smart to all that based on a rotting copse?

Microsoft needs to have a good long hard look at the MacOS X driver kit, and same goes for the way they've done their 3d and 2d accelerated framework - and its not about copying copying something, but accepting that if someone works, then why not research it.

The only thing that actually helps Microsoft from its NIH syndrome is the massive R&D - if it weren't for all the cash they have on hand, the ability for them to unjustifiably re-invent the wheel each release would difficult; what Microsoft needs is some hardship, the $50billion taken off them, then maybe they would finally take pragmatic approaches to fixing problems using existing technologies rather than reinventing the world for the sake of it.

I decided to finally register.

I wrote the rather long description that you summed up pretty well. The real issue that is causing so many people to misunderstand the LDDM is that the industry press (populated by people who really don't know very much about ComSci or OS internals) keeps making sweeping statements that mischaracterize the statements made by Microsoft.

All of this is very clearly (in my mind) publicly documented in the MSDN library.

Oh, you mean those fake hardware requirements that were made up at some point, and then subsequently posted all over the Internet as the official Vista hardware requirements?

Yeah, don't believe it. Vista will run fine on 512 MB -- and I know this because the latest Betas do so along with all of their debug/unoptimized code.

An irony, of course, is that by the time Vista is sold these fake statements may not be different from the reality.

Today's budget notebook or PC goes with 512MB RAM, and more often than not you can get 1GB RAM with a new decent personal computer.

By the time Vista sold preloaded on new PCs, 1 GB RAM could become a low-budget option.

An irony, of course, is that by the time Vista is sold these fake statements may not be different from the reality.

That still doesn't make those statements true as they were usually touted as requirements to run Vista. Just because the mainstream new computers of the time might meet those fake requirements doesn't mean you suddenly can't run Vista on lesser hardware that will be detailed in the official requirements.

That still doesn't make those statements true as they were usually touted as requirements to run Vista.

The requirements to simply run Windows and the requirements to run Windows and actually run applications and get work done have historically been two different things with ;-).

If you were to try and run any of the Vista builds as a day to day OS, and install your usual software on it you'll find those hardware requirements are more than accurate. In many ways it looks as if they will be quite conservative.

Oh yeah, because you're a Microsoft engineer now or something? Give it a break.

Vista will run fine with 512 MB -- because it already does. Once the debug cruft is cleaned out, and the code optimized, it will run perfectly.

glad to hear that Vista has improved since beta one was released when it needed an infinite ammount of memory dependent on how often you felt like rebooting it.

"No one will us it xept for basic webpages. I do use a managed form of code but not locked in to only managed, this shows that .NET isn't compatible with C++. Too bulky."

... That statement doesn't make any sense... Can you clarify it?

What do webpages have to do with it at all? And of course .NET isn't compatible with native C++. Native C++ doesn't run as managed code, and that defeats pretty much the entire purpose of .NET

And now I need you to clarify...what do you mean by ".Net isn't compatible with native C++?"

It also depends on what you mean by native C++; .NET allows C++ to be used, the only down side, is you have to drop of a few unsafe C++ calls and start pulling in stuff from the .NET Framwork - thats no different to how Apple says that Cocoa supports native C++ through Objective-C++ support.

As for managed code, I think people need, especially the elitist ivory tower residing coders, and see it as a benefit which will allow them to tackle larger, more complex problems, and leave the mundane, accident prone crap to be taken care of by a managed environment - it isn't about duming down programmers, its about handing over mundane crap to a manager as to allow the individual to concerntrate on the more important things.

"And now I need you to clarify...what do you mean by ".Net isn't compatible with native C++?""

Well, I think what the original poster meant is that you can't run native C++ binaries under .NET... Well duh...

Edited 2005-12-18 01:54

With WPF the rendering pipline can be marshalled over the wire so that all rendering of the graphics developed with WPF can be rendered on a client machine using whatever capabilities the client can offer.

So for example you can have a terminal session that send rendering instructions rather than bitmaps to the client and if the client has a Direct3D 9 capable graphics card then all the work will happen on the client GPU.

So you're saying that Vista is X11 + GLX?

No offense to Microsoft --- if a good idea is available, you're stupid if you don't copy it!

Actually, truth be known. X11 was not a good idea. The only reason we got stuck with it is because the alternatives (which were technically superior) were closed and proprietary standards. X11 was open, and so ultimately we got stuck with an inferior system.

It's basically Microsoft's equivalent to JNI. It allows you to run native, unmanaged code outside of .NET. This is usually not a good idea unless there aren't any other options.