From: Fred Kleinsorge [kleinsorge@star.enet.dec_nospam.com]
Sent: Thursday, November 11, 1999 12:54 PM
To: Info-VAX@Mvb.Saic.Com
Subject: Re: alpha longevity

Rick Cadruvi wrote:
> 
> I hate to disagree with Arne, but I think it was an EXTREMELY good
> architectural decision to move the video handling of Windows NT into
> the Kernel.  It makes sense on lots of levels.  The argument against doing
> it would be no different than arguing that VMS should have continued to
> use an ACP for the Files-11B file system rather than going to the XQP.
> That decision made sense and for many of the same reasons, the NT decision
> makes sense as well.
> 

There no really good argument either way from an architectural
perspective on the best place to implement graphics drawing.  Mostly it
is a tradeoff between performance, and implementation/debug difficulty.

The best performance is direct rendering - that is, when a user makes a
call to draw something, the routine that is called directly accesses the
hardware.  That was essentially what DOS/Windows - and VWS - used to
do.  There are major problems with this when you have multiple
concurrent writers to the HW.  For some class of users - like
high-performance 3D - the problems are worth solving.  But there can
also be security problems with direct rendering, so many implementations
are "indirect" using a kernel mode driver to restrict access.

You can get nearly direct rendering performance, and synchronization by
having a single hardware point of access - by making it kernel mode.  In
this case, the call is replaced by an IOCTL or some other inner mode
call, and a privleged interface is invoked.  You are still in process
context, and didn't have to pass data out of the application thread, and
did not have to male a context switch.  But writing and debugging a
complex software component like a graphics subsystem - is harder to do,
and your bugs are more likely to crash the system.

A process like the XServer, or the original GDI implementation, is a
protected subsystem.  It can run in user mode, and thus is easier to
write and debug.  You can still crash the system (or more likely machine
check the hardware on Alpha), but simple bugs - like an ACCVIO, or a
resourcer exhaustion are more likely to simply kill the graphics (BTW -
the "example" of the backspace problem, which was fixed ages ago, was
purely a input device driver bug - not a drawing bug).  The downside to
this is that you now have to send the drawing command and data outside
of the thread doing the drawing - in X11's case using a network (or
network-like) protocol - and in NT's case, a highly optimized Local
Procedure Call.  But what you can't avoid is a process context switch,
and the places where you need a round trip because the caller needs to
know when the operation has been done.  Throw this in with the generic
process scheduling, and this will *always* be slower than the previous
two methods.  The MS folks naively believed they could make the penalty
less than 10% (as they stated at the first NT developers conference, and
at which the graphics guru's in the audience laughed).  A big benefit is
that it is much easier to distribute the drawing across a system barrier
- like over a LAN.  Since the drawing commands are inherently a command
packet.


From a architectural perspective, the GDI as a protected subsystem makes
sense for NT - because that was how NT was designed - avoid kernel mode
for protection, and use protected subsystems.  Very cutting edge
computer engineering thinking... but in the end, the performance issues
won out.


> However, I do agree with youcomputer engineering thinking... but in the end, the performance issues
won out.


> However, I do agree with you that the obsession with the screen in NT Server
> is totally misplaced and demonstrates that Microsoft has little understanding of
> Enterprise computing.  The problem, however, is not because the video was
> moved into the Kernel.  The problem is the failure to understand how server
> schedulers should be written and what computing resources matter in a server
> environment.  The NT scheduler is just plain awful.  It works nicely for making
> all the pretty pop ups and mouse movements when they really count.  However,
> it gets in the way of REAL computing.  The NT scheduler guarantees that SMP
> machines will be the norm rather than the exception, ESPECIALLY for Servers.
> 
> Just my opinions,

Well, the NT scheduler isn't that much different than VMS (guess who
designed both).  You can argue that there is an inherent priority that
is given by the system to maximize screen performance.  But take a VMS
system and start up a bunch of graphics intensive operations on a
uniprocessor server -- it will eat up every bit as much resources --
unless you properly balance the priorities.  And note that by default
VMS gives the XServer and window manager a slight priority bump over the
default.

But on VMS, you don't *need* a directly connected graphics subsystem to
operate.