David Mathog wrote in message <91ohf8$...@gap.cco.caltech.edu>...
>In article <91o7u9$7bi...@lead.zk3.dec.com>, "Fred Kleinsorge"
>>I doubt that anything I say will make you very happy.
>That's a safe bet!
>>There isn't some sinister plot to force people to buy expensive 3D
>>controllers. What you are seeing is the collision between commodity
>>graphics cards, and traditional "workstation" graphics cards. In terms of
>>raw performance, there is now little difference between the two. There
>>some serious quality and feature problems however.
>Going off on a tangent for a second - this "quality" argument keeps raising
>its head. Now I'll agree that VMS is a small market without much pull but
>Compaq _also_ sells about a bazillion PCs a year. Ok, the consumer grade
>ones are really crappy but supposedly the commercial grade ones are better.
>Is there some reason Compaq can't throw its weight around a little bit more
>by requiring a certain quality level for the parts it buys? And couldn't
>some of that spill over into VMS land, with the standard having been set
>high enough that the SCSI cards, disks, and Graphics boards which go out on
>the commercial PCs will be stable enough to use on VMS as well? It seems
>like a win/win proposition for Compaq - they obtain more stable components
>for the PCs _and_ lower cost components with acceptable quality for VMS.
>Heck, it's probably even a win for the vendors because if the standards are
>precisely defined they know exactly what they must produce and who's
>responsible if something does or doesn't work.
The problem here is that the PC market is mostly a component integration
business. A number of vendors make high-quality options and drivers for
them -- but it really is a matter of what they are targeted at. 3DLabs for
instance makes graphics for the "professional" market, and their PC OpenGL
implementations tend to be quite good. nVidea on the other hand, targets a
gaming market - and their products do not tend to work good if you are doing
CAD/CAM instead of running Quake.
A lot of "quality" (as well as performance) in the PC world depends on the
software the vendor supplies - not just the HW.
So when someone puts together a PC configuration, they simply pick from a
palette of available options, cost, functionality, and quality for the
market for their PC. A PC with an Oxygen VX1 on it will make a fine CAD/CAM
system, an nVidea won't (I just helped a friend though just this exact
situation not long ago). But it makes a fine system for games.
But the PC market also does not make use of functionality that might be
required in a traditional UNIX/VMS CAD/CAM or server. Sticking with
graphics, most commodity graphics cards do not offer multiple-simultanious
pixel formats, and their overlay plane support tends to be limited
(actually, overlay planes are making a comeback here and there on some
boards). Moving away from graphics, to say SCSI - VMS and SCSI clusters
push disks in ways that require a strictly correct implementation of the
standard. A lot of them cheat - but they cheat in ways that are not
material to how PCs use the disks or even how UNIX uses them.
>>Yes, our strategy is to move to off-the-shelf "industry standard" cards.
>>no longer design our own graphics, and the P300/350 is probably the last
>>card we will buy.
>>There is an internal struggle among the engineers and management who have
>>deliver graphics on Alpha (VMS and Tru64). The struggle is between those
>>who believe that it is only worth doing the fastest graphics (and that
>>time), and those who would trade off performance for time-to-market.
>Ah very much like the Genome project! The public guys insisted on a level
>of accuracy that was attainable but extremely expensive and slow to obtain.
>Meanwhile Celera came along and quickly cranked out a rough draft which has
>98% of the utility at a fraction of the cost. Now the public guys are
>playing catchup and are wondering how they're ever going to get funding to
>move from the 98% good enough that Celera delivered to the 99.999% that
>they wanted to deliver. You see, the big questions in genetics can all be
>pretty much answered with the rough draft, so the cost/benefit analysis
>does not favor ever reaching the level of accuracy that the public camp
>In the case at hand we have the "better nothing than perfect" camp again,
>versus the "better something than nothing." Right now we've (most of us
>anyway) effectively got nothing, and we want something. Perfect can wait.
>Perfect may not even be needed.
Well, let's not try to extend personal needs/wants to a generalization of
what "most" need/want. For the most part, the P300/350 satisfies the target
customer base that are currently using 3D on VMS. It could be better,
faster, cheaper. That is always the case. The wide difference between what
you can get on a PC in price/performance will shrink when we finally replace
the P300/350. 2D graphics (which, by-the-way, is what more than 90% of what
VMS users need/want based on research) will get better performance
The compromise we reached internally was to pass up the opportunity to put
low-end 3D onto the next "2D" card, to allow us to eventually do away with
the need to have a 2D versus a 3D card, and have a family of cards that do
both 2D and 3D and span low-end to high-end. That is, just what you want.
To do that meant *not* doing 3D on the ELSA follow-on.
>>the NT market, we don't just get the software for free from the board
>>vendor, nor is there uniform quality in SW or HW on NT - many so-called
>>OpenGL implementations are really designed for full-screen simulation
>>(gaming). We are looking to leverage work being done for Linux and
>>xFree86 - but frankly, *high-quality* and *high-performance* Linux 3D
>>drivers are not readily available, and this market is in it's infancy.
>This comes back to the argument I was making before. Why does Compaq have
>to accept the situation that the board vendors get to deliver only a driver
>for one OS but not another? REQUIRE them to produce the driver in such a
>form that it will "make" to an NT driver, and also "make" under a different
>OS to VMS or XFree86 driver. I know I'm grossly simplifying things here,
>but what I mean is hardware acceleration of any particular 2D or OpenGL
>function might as well shove the same series of bytes into the card no
>matter what the OS is. Sort of a universal driver interface. There's no
>such thing now, and Microsoft would prefer that one never exist, but
>everybody else would certainly benefit from its existence. Maybe Compaq
>has the oomph to make it happen. Again - this may not be the perfect
>OpenGL driver, but if we can get 90% of it using the standard, that's
>probably good enough for most people.
Actually, some of that is happening. The problem is that the Linux graphics
market is still in it's infancy. The PC option makers are recognizing the
need to offer both Windows and Linux software - but to date, there are few
vendors out there with *real* Linux OpenGL implementations (especially 3D)
that are anywhere near as good as their NT/Windows implementations. The
system vendors are, or will be, moving to XFree86 to take advantage of the
Linux DDX/Drivers... that is likely to be the case for VMS and Tru64 --
although I think everyone wants x.org and XFree86 to merge their code bases
first. In any case, what we have found, and are finding, is that it is
taking time for the vendors to catch up to Windows with their Linux
We are looking to leverage the xFree86 code for the next set of boards as
much as possible (even to the point of porting XAA and FB back to the MIT
server from xFree86).
>>Having said all that, we are in the final stages of qual for a replacement
>>for the ELSA card that will phase in as the ELSA inventory is used up. It
>>will also only be 2D, although the card is quite capable of being a fine
>>entry/low-mid 3D card. Rather than spend the limited 3D budget on this
>>card, instead we are working on support (in late 2001) for a family of
>>that will span low-end to high-end 3D -- and are off-the-shelf commodity
>Now I'm just confused. The half life of a graphics card seems to be about
>9 months, so if these cards exist now this means Compaq will be coming out
>with support just as the cards reach their end of life (in the PC market,
>anyway.) Or has Compaq found a way around that problem, for instance,
>drivers which are somehow guaranteed to be compatible with newer variants
>of the card? If not this strategy leaves you perpetually behind the curve
>(and uncompetitive) in the graphics arena.
The way to do it is to target initial delivery for the start of, or mid-life
of an "architecture". Even the option makers are having trouble keeping
up - so while a specific card, or chip may have a 9-month lifetime, the
"architecture" it uses tends to last at least 1-2 years. The new versions
are faster, smaller, bug fixed, and with added functionality -- all around a
core that isn't far removed from the previous incarnation. Look at S3 as an
example. They took the 864 to the Trio32, the Trio64, the Trio64+, the
Trio64V+, and the Trio64V2. All pretty much compatable, but spanning a
multi-year life. The same is true for 3DLabs, ATI, and others. They will
then have periodic "new" architectures to break through bottlenecks.
>>VMS is tied to Tru64 for graphics. We are not driving it. We will get
>>whatever the Tru64 market gets.
>That's really too bad - graphics there are only (very) marginally better
>than under VMS.
>It would really be nice to see Compaq work with the graphics card vendors,
>the Xfree86 folks, and even Sun, Apple and Be to arrive at some sort of
>"portable graphics card driver". It benefits nobody but
read more »