Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!newshost.telstra.net!act.news.telstra.net!psgrain!newsfeed.internetmci.com!info.ucla.edu!csulb.edu!drivel.ics.uci.edu!news.claremont.edu!muddcs.cs.hmc.edu!mmicek
From: mmicek@muddcs.cs.hmc.edu (Michael J. Micek)
Newsgroups: comp.os.linux.development.apps,comp.os.linux.development.system,comp.os.linux.x,comp.os.linux.hardware,comp.os.linux.setup,comp.unix.bsd.386bsd.misc,comp.unix.bsd.bsdi.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc
Subject: Re: Why to not buy Matrox Millennium
Date: 27 Mar 1996 08:54:21 GMT
Organization: nil
Lines: 156
Message-ID: <4javnt$qo5@jaws.cs.hmc.edu>
References: <4j21ph$crr@slappy.cs.utexas.edu> <ROELL.96Mar25214459@blah.xinside.com>
NNTP-Posting-Host: muddcs.cs.hmc.edu
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.apps:13713 comp.os.linux.development.system:20074 comp.os.linux.x:27703 comp.os.linux.hardware:34460 comp.os.linux.setup:47393 comp.unix.bsd.386bsd.misc:304 comp.unix.bsd.bsdi.misc:2800 comp.unix.bsd.netbsd.misc:2577 comp.unix.bsd.freebsd.misc:16066
In article <ROELL.96Mar25214459@blah.xinside.com>,
Thomas Roell <roell@xinside.com> wrote:
>There are now a couple of real problems with HW acceleration.
> Because every chip has a different scheme of mapping
>certain functions to the buffers (like limits/clamping for the
>z-buffer) you have to write a software emulation of each chip for the
>cases where the chip cannot render directly a specific thing. As the
>OpenGL invariance rules state that the same pixels get rendered
>whether you draw to the backbuffer or the frontbuffer you have a
>serious limitation here. The next hugeish problem is feeding the
It would be interesting to know what the heck he's talking about.
Anybody not working in the industry (an engineering student, say) care
to explicate, just for the heck of it? What's a z-buffer?
>graphics engine with the vertex data. For a normal shaded triangle you
>usually have to supply MINIMMALY 29 register contents. Add now fogging
>and texture mapping and you'll see the magnitude of the problem. That
>means it's not nessesarily the case that if you use the 3D hardware
>that you can render stuff faster than using software. Our experiance
>shows that you spend 80% of the complete time not in the real
>pixel-pushing, but rather in setting up the operation somehow
>(clipping, xforms, subpixel correction, clamping, delta computation).
>Therefor the comments about the to be expected performance increase
>are rather immature.
("premature?")
>Another piece of writing indicated that you want to run anything
>without X-Server. This is now in my oppionion extremely stupid and
>seems to come from persons who have not clue about implications. UNIX
Well, yeah, probably, but you might cut 'em *some* slack. This
reflects the Linux feature that you can run graphics programs without
X, using a Linux SVGA library. This used to make sense when most
people running Linux had *less* than eight megs of RAM.
>is a time-sharing multiuser system. It is kind of obvious that you
>want to take this philosophy into your GUI environment. If you need to
>do this, then you have the need of managing resources like the mouse,
>the keyboard or the clip of a window. And of course you want to use a
>centralized instance to coordinate all this and to offer you abstract
>services like puting the graphics card into a specific mode. All those
>issues are not really trivial to implement (although they might appear
>to be trivial) and it's a useless idea to go out and reinvent the
>wheel once again.
But if it means I can get away with not upgrading my
hardware (even though I have a $300 video card and only $200 worth
of RAM)... remember, you're talking to a lot of people who have more
time than money. And people who enjoy retrocomputing. (linux-8086, for
instance, seems to be humming right along. Somebody the other day
asked if anybody was working on support for the *Z80*. Yes, it's
comical. But it's real.)
Besides, no more than one person can use a PC video card at a time,
right?
> One might succeed to get something running for one
>graphics chip, but as soon as there are more than one applications
>which want to get part of the drawing area there has to be a good
>mechanism. My personal experiance has shown that with a very few
>exceptions rendering throu the X-Server is faster than doing the
>private wizbang library.
What about in an embedded application? (Don't know what the heck kind
of system would have embedded 3D rendering... it just popped into my
head. Maybe a video game system?)
> The few cases where it's faster to not have
>the X-Server in between mostly fall into the cathegory of bad
>implementations (i.e. written with direct framebuffer access in mind),
>or simply suffer from the fact that a X-Server cannot give guaranteed
>minimum response times.
>I really don't want to comment on the reverse engeneering as it is
>obvious by Matroxes license agreement, and with X Inside's license
>agreement that reverse engeneering is prohibteted. Hence any source
>redistribution would be legally illegal and hence highly risky. The
>point I do want to make however is that it is increadibly braindead of
>attempting to even try it.
Sounds like "famous last words" to me. Software piracy and system
cracking are pretty braindead pursuits in my opinion as well, but that
doesn't stop people from doing them, if for no other reason than to
piss Matrox (or whoever) off. (Whether it actually would or not is
irrelevant. It's an ego thing.)
Thank God for the free software ethic that has some of these people
(the smarter ones, I'd think) directing their efforts towards positive
pursuits.
> A typical graphics engine those days has
>100+ registers. Every reasonable driver uses implicite state changes
>of register to avoid reloading. It is exteremly timeconsuming to do
>it, if possible at all. The question is now why does anybody want to
>waste the time. If one feels that the spec of a graphics chip is
>ultimately necessary to buy any product based upon this chip, well
>then buy another card. If you really don't want to be bothered with
>all the details and all you really want is to have the fastest card
>with the fastest driver (2D and 3D) then why not buying the best
>available combination of software and hardware.
Yeah, you don't get it. You're not being illogical, you just don't
get it.
> People seem to be so
>ambitious to always get the fastest piece of hardware but completely
>forget about software. Now look at the Imagine128. There is not *free*
>support for this chip. But it's framebuffer only.
Pardon my ignorance, but don't you mean that there *is* free support,
but it's framebuffer only?
> You payed a lot of
>bucks for the card, just to have something that's not faster than a
>cheap $100 TGUI9440 based board.
(Personally, I bought the TGUI9440.)
>My personal oppion is that reverse engeneering is very highly
>questionable in the moralistic view.
Yup. I don't pirate video games, either, but I know people who know
people who do.
> The ice is very thin in this
>area. Just suppose one steps with reverse engeneering onto the foot of
>somebody big, who can win a lawsuit, or even worse get laws up against
>it. Right now the internet is a very liberal environment. But by
>exploring the edges of legality people are forceing government into
>taking steps to enforce the law even internationally.
Hm. Scary, but I don't think it's going to turn out that way. The
real way to rid oneself of the underground is to acknowledge the
driving forces and try to create socially acceptable outlets. If
there's an extensive black market, it probably means your market isn't
free enough, and eventually the whole system's going to keel over.
Things would be a whole lot nicer if these guys (in industry) would
loosen up and not try to match egos with the hacker community. They
(you) have better things to do than to try to out-ego a bunch of 14-24
year olds with more brains than sense.
(I could be wrong. "About a _great_ _many_ _things_." <grin>)
>Denver Office THOMAS ROELL /\ Das Reh springt hoch,
>+1(303)298-7478 X INSIDE INC / \/\ das Reh springt weit,
>1801 Broadway, Suite 1710 / \ \/\ was soll es tun,
>Denver, CO 80202 roell@xinside.com / Oelch! \ \ es hat ja Zeit.
Say "Hi" to the 16th street Mall for me. Thanks.
--
Michael J. Micek, peripatetic philosopher. Try 'em all (Mt 8:20) mmicek@nyx.net
mmicek@muddcs.cs.hmc.edu Hi! sam@butthead.colorado.edu ab496@freenet.uchsc.edu