Greg,

The only bit of code that is relatively awful as it relates to IBM's
original decisions in 1980 or thereabouts is the bit that takes a card from
being mapped as a "VGA" card via I/O ports to being accessible via full
linear memory mapping. To get it from one to the other is the work of about
10-50 lines of code depending on the card and the system (for example, on
ppc it is already pretty much ready). This code is executed once. And after
that, it's all good. If you use option "noaccel", those 10-25 lines of code
do their work, and there's a linear framebuffer for the (mostly) X.org
software routines to use. That's not pc-centric design, it's how device
drivers work. And the entire architecture outside of that init section
(which btw, your Sun fb also executes) cannot be accused of being
PC-centric. It's the proper evolution of the old X.org server architecture,
to be more streamlined, more modular, and faster.

The mud-slinging fest can be said for the i386 bootstrap code in the loader
that takes us from 16-bit real mode to 32 bit protected mode when NetBSD
boots. Same sort of length. Same execution profile. Is NetBSD PC-centric? Of
course it is! Get real.

In general, the XFree86 server does not know that much about your system.
Everything about your cards is contained in one or more scrninfo structures,
and there's no place in it for anything like a CPU id, or anything like
that. Please take the time to look at the source code, and see for yourself.

The reason we aim for good benchmarks is pretty much every increase above
"noaccel" increases the amount of parallelism in the system. Your ye olde
Sun fb is dumber than my brother's dog (and Chloe is not a smart animal).
Anything post-1990 in the consumer video card arena can do Bresenham lines
(or a good enough faked version), rectangular fills and memory-to-screen and
screen-to-screen blits with various masks. These are the most common video
operations. If by setting up the equivalent of five "pokes" using about
30-40 cycles of CPU time and going away to do something else saves some
million or so cycles on the host CPU, I'm all for it. In the meantime, it's
possible to let the CPU do actual work for you, rather than munge through
the laborious process of doing everything by hand.

The reason that most of the people operating old SparcStation 5s never used
the graphical console is that you could easily DoS the system by getting it
to scroll text without X11 present. If the Sun fb could do a simple scr-scr
memcpy (one of the most basic GOPs), that wouldn't be true. Parallelism is
good. Ask anyone who uses FDDI or SCSI or the nicer NICs.

XFree86's design is elegant, clean, very nearly optimal and documented.
Please go in there, have a look, compare it to the pre-ANSI C rubbish that
exists in the X.org mainline servers. They are pre-historic, single
threaded, nasty pieces of work. Quite possibly the pure embodiment of your
epithet "PC-centric".

Saying a piece of code "PC-centric" as a method of slagging it off doesn't
wash. There's nothing wrong with PC-centric. I'm hereby declaring PC-centric
to mean "correct, stable, efficient code in a clean, generic modular
architecture".

kill thread

Andrew

----- Original Message -----
From: "Greg A. Woods" <woods@weird.com>
To: "NetBSD-current Discussion List" <current-users@NetBSD.ORG>
Sent: Thursday, July 19, 2001 2:58 AM
Subject: Re: Why not track our xsrc with X11R6.6 from X.org?


[snip]

> Oh, but I DO!  I really Really REALLY do!  Or rather I absolutely do not
> ever want the Xserver to have to know anything about the wiring of my
> system, or if possible even the type of the CPU(s)!

[snip]

> There's absolutely no way I'm willing to give
> it either direct or indirect control over anything but the graphics
> card.  To do so would be ugly and inelegant on many levels and is why I
> and others call XFree's design "PC-centric" (i.e. not because of modern
> PCs, but because of the legacy of bad design IBM-PC descendants have to
> live with).  We've already seen dozens of examples of how the lines
> between the kernel and userland can be drawn much "better" without too
> much impedement to getting the job done "right".

[snip]
> OK, so those are some very fast numbers.  What do they mean to human
> visual perception?  I suspect they're all stupidly over-kill for the
[snip]