Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!newshost.telstra.net!act.news.telstra.net!vic.news.telstra.net!news.mira.net.au!yarrina.connect.com.au!news.mel.connect.com.au!harbinger.cc.monash.edu.au!nntp.coast.net!fu-berlin.de!news.dfn.de!gina.zfn.uni-bremen.de!marvin.pc-labor.uni-bremen.de!news.uni-stuttgart.de!uni-regensburg.de!lrz-muenchen.de!isar.de!augsburg.isar.net!194.45.233.6!roell From: roell@xinside.com (Thomas Roell) 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: 25 Mar 1996 20:44:59 GMT Organization: X Inside Inc. Lines: 109 Message-ID: <ROELL.96Mar25214459@blah.xinside.com> References: <4j21ph$crr@slappy.cs.utexas.edu> NNTP-Posting-Host: blah.a.isar.de In-reply-to: pmcdermo@cs.utexas.edu's message of 23 Mar 1996 17:34:09 -0600 Xref: euryale.cc.adfa.oz.au comp.os.linux.development.apps:13668 comp.os.linux.development.system:20005 comp.os.linux.x:27613 comp.os.linux.hardware:34362 comp.os.linux.setup:47235 comp.unix.bsd.386bsd.misc:293 comp.unix.bsd.bsdi.misc:2786 comp.unix.bsd.netbsd.misc:2561 comp.unix.bsd.freebsd.misc:16017 Sorry,. for jumping in lately, but here a few random comments to a bunch of peoples claims. It is correct that X Inside right now ships a SW only OpenGL on FreeBSD, NetBSD, LINUX and BSD/OS. Upon request there are other OSes supported for special contracts. Secondly it is incorrect that our next version of OpenGL, which will use full hardware acceleration, is only supporting the Millenium. There will be support for the 3Dlabs GLINT 300SX, 500TX, Delta and Premedia, the S3 Virge, Virge/VX to just enumerate the popluar ones. My personal comment is that with the execption of the 3Dlabs chips (as commonly know chips where I can talk about) all the other chips are pretty much not what you want for OpenGL. Most 3D graphics chips do support only Gouraud shading and a 16bit z-buffer. None of them has a stencil buffer or OpenGL compliant texture mapping (see calculation of rho for mipmaps). There are now a couple of real problems with HW acceleration (guess I should not talk about those problems, but given the level in this discussion, it couldn't hurt to outline a few of those problems). 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 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. Then to the comment about SVGA vs. Matrox. SVGA is not standard in itself. It just says SuperVGA (which is actually a copyrighted name for a graphics card from Genoa), which means a superset of the original VGA architecture. This refers only to the fact that a graphics chip implements higher resolutions than the original VGA, or packed pixel modes. It does not state anything about the interface. In fact many newer graphics chips include a so called SVGA core that implements a standard VGA plus all the modes possible in 1MB. They don\t allow you accessing all the memory of the card. The ATI 264CT chip would be a popular example. Hence the label SVGA compatible is kind of stating nothing. 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 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. 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. 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. 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. 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. You payed a lot of bucks for the card, just to have something that's not faster than a cheap $100 TGUI9440 based board. My personal oppion is that reverse engeneering is very highly questionable in the moralistic view. 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. - Thomas -- 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.