NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/sys/amiga/graphics/5644

Text File | 1992-08-17 | 3.6 KB | 71 lines

Newsgroups: comp.sys.amiga.graphics
Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!mips!sdd.hp.com!elroy.jpl.nasa.gov!nntp-server.caltech.edu!harry!andrey
From: [e-mail] (Andre Yew)
Subject: Re: Vivid 24 graphics card
Message-ID: <andrey.714094078@harry>
Sender: [e-mail]
Nntp-Posting-Host: harry.ugcs.caltech.edu
Organization: California Institute of Technology, Pasadena
References: <[e-mail]> <[e-mail]> <andrey.713925244@harry> <[e-mail]>
Date: Mon, 17 Aug 1992 23:27:58 GMT
Lines: 58

[e-mail] (Scott Townsend) writes:

>For a fair comparison, you want to compare the relative CPU figures
>(i.e. r40000 vs. 68040) and the graphics pipeline figures (VGX whatever-is-
> in-there vs 32040)

    That's right, and the DMI advertisement was pretty
wrong in the implications it put out.  From real-world
experience (Crimson versus HP 425), the MIPS R4000 is at
least 4 times as fast as the HP for my computations.  It's
much, much faster for compilations.

>I'll admit, I don't know where this 40 MFLOPS number came from
>(peak pipeline speed?, LINPACK? SLALOM? single/double precision?) but for
>graphics pipeline operations, which tend toward 'embarassing' parallelism,
>you can get close to linear speedup.  In an Amiga system where the '30 or '40
>is updating a display list, etc and the DMI processors are just blasting pixels,
>I don't think quoting 160 MFLOPS for the processors on the board is
>out of line.  A bit agressive perhaps ;-)  (and certainly not without precedent)

    I don't know what kind of MFLOPS it's quoting either,
but I don't think you can get that kind of speedup with the
way the Vivid board is setup.  Here I go into assumption land.
In most normal scanline renderers, the heaviest computation
happens in the pixel-blasting stage, because that's where you
interpolate your colors, normals, and texture coordinates.
Sure you could split the screen into different portions (like
SGI does), but do each of the Vivid coprocessors do this?
Can they have access to their own polygon tilers and the
DACS?  How do the coprocessors contend for access to the
main VRAM?  If they have to go through the 34020, they aren't
going to be as fast as a VGX system.  And how fast can the
Vivid board blast pixels onto the screen anyway?  SGI has
separate processors to do this as well.

>I assume we're talking VGX update _rates_, the effects are simply computations
>which the VGX is quite quick at.  I could compute the same effects on
>my vanilla A3000, (or A1000!) just depends on how long you wait.
>(I'm using 'effect' here to mean what I see on the screen, is some other
>definition intended?)

    Yeah, that's what I meant -- that kind of rendering
quality at that kind of speed.  For example, can the Vivid
board do texture mapping?  Quadruple-buffered 36-bit color
screens?  HDTV output?  Encoded NTSC and PAL?  Does it have
an accumulation buffer and a stencil buffer?  Is it easily
integrated into the operating system?  Can it do all of this
in realtime at full-screen resolution (1280x1024 in the non-TV
modes) for hundreds of thousands of polygons for most scenes?
I have a feeling that the answer is no to all of these questions.
I'm not aiming this at you Scott, just the people who believe
the DMI advertisement.  There are many good reasons to pay
that much money for an SGI system.  (To be fair, I described
a Reality Engine setup, but VGX is almost as fast and
is missing the encoded NTSC/PAL and 36-bit color.)

--
Andre Yew                     [e-mail] (131.215.131.169)