Well, Peter…
Graphics is an immense field. It involves hardware, 2D drivers, 3D drivers,
kernel mode libraries, user mode libraries. It is a vertically integrated
field too, and there’s a huge amount of code in there, from the tip of the
app to the bottom of the chip. Furthermore, it evolves at a dizzying pace.
So, it’s only too natural that there’ll be a lot of crashes due to graphics
! Like Klaus said, people doing graphics are often confronted with the need
of doing things that the OS doesn’t do yet. Or with the need of doing things
that the OS says people shouldn’t. And that’s not because of us (now I’m
putting on my old graphics developer cap on!) but because of our users:
things evolve that fast due to user demand.
So, for example, the other day people were talking about floating point in
Ring 0, and someone said that people shouldn’t use FP in Ring 0. Well, I
wrote a whole OpenGL ICD with my team, and we did Floating Point in the
kernel as a matter of fact, and it worked fine - now, if the OS didn’t
support it, too bad, we did it anyway. BTW, the OS didn’t support AGP
either, yet we put it in and it worked. Because we’re talking about high
speed graphics, and we don’t do high speed graphics for people who don’t
need it ! But those people who need it keep reminding graphics developers,
continuously, all the time, the difference a benchmark score makes.
It may be the case that certain subsystems, used in certain ways, may hog
system resources beyond the point where a non-graphics app would be
comfortable with. But then, heck, this is a PC, use a lesser graphics
subsystem if a Radeon or FireGL won’t do ! And I do not buy that using the
hardware the way the hardware demands to be used will necessarily lead to
instability!
You see, this ain’t Win 3.1 no longer, indeed, but I can make the point that
it ain’t Win2K or WinXP either, not really. To an extent, it ain’t even X86.
We’re talking about functionality that is overwhelmingly implemented in the
chip, inaccessible to both processor and OS. Your typical video board has
almost as much memory as your machine, it does most of the rendering itself,
it caches textures and bitmaps in video memory, it has the whole 3D pipeline
on chip, so, the kind of OS functionality we’re talking here about moving
control information fast between the app and the chip, and little else. To
get the right perspective, pretend you had a network card that implemented
the whole of the TCP/IP stack on board, or a disk controller that
implemented the whole of the file and directory system on board: what would
the point of having operating system functionality duplicating what’s
already on chip ? If I say “open” today and that goes to an OS function, but
if tomorrow my chip implements the whole of that “open” function, why should
I need the OS at all ?
It is more or less clear that graphics subsystems, because they require both
throughput and response time, don’t like to share datapaths with other
peripherals. So, it’s just as well that we have AGP, and if video chips can
talk directly to the OpenGL library, I don’t see how that’s going to make
the life of the OS any harder.
As for NT being a general purpose OS: I believe we’re losing the perspective
that this is a PC, after all. It’s configurable. The fact that NT is a
general purpose OS doesn’t mean that a PC running it shouldn’t be
configurable to better suit a user’s need, be it graphics, servers,
programming, or anything else. We want true general purpose, configurable
and tunable, not a one-size-fits-all straightjacket. The strength of the PC
standard has been its flexibility!
Alberto.
-----Original Message-----
From: Peter Viscarola [mailto:xxxxx@osr.com]
Sent: Monday, August 06, 2001 11:58 AM
To: NT Developers Interest List
Subject: [ntdev] Re: AW: RE: Mapping scattered pages into process addr
ess space
“Moreira, Alberto” wrote in message
news:xxxxx@ntdev…
>
> What we do have to get away from, IMHO, is the straightjacket imposed by
the
> current party-line way of writing drivers. And let me put it this way, if
> you cringe at the relatively mild liberties graphics people take with the
> system, I wonder what your reaction would be to what we do within SoftIce
or
> BoundsChecker, or even TrueTime ? Yet we don’t crash systems any more than
> anybody else.
>
There’s been lots of good feedback already, but I just couldn’t keep silent:
1) I don’t really understand your argument, Alberto. Cuz SoftICE and
BoundsChecker do unspeakable things in the kernel, it’s OK for graphics
drivers to do so, too?? And, while ICE and BoundsCheker might be decent
diagnostic tools – and enagage in their hacks in support of their
short-term diagnostic mission – I, for one, am nauseated by some of the
hacks these products engage in. (sorry, but you asked for that one!)
2) You DO realize that graphics drivers are the #1 cause of Windows NT/2K/XP
system failures, right? So, I’m thinkin’… QED. Hacking the O/S is bad
for stability.
While there are undoubtedly people who have the requisite skill, experience,
and deep understanding of NT kernel architecture to be able to do things
that are counter to recommended practice, I’m sorry to say that (in my
experience, at least) those people are few and far between. AND, the
“clever” things that even THOSE knowlegeable few do OFTEN come back to haunt
them as unanticipated side-effects emerge and the o/s evolves around them.
No, this ain’t Windows 3.1 anymore where we could “hook INT 21 and party…
yeeee haaa!”.
Performance second. STABILITY FIRST.
If people want unltra hot graphics, they can buy an xbox or something –
Knock knock?!? NT is a general purpose operating system! (eh, GADS! There I
go agreeing with Roddy AGAIN),
Peter
OSR
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com