Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!DDATHD21.BITNET!XBR2D96D
From: XBR2D96D@DDATHD21.BITNET (Knobi der Rechnerschrat)
Newsgroups: comp.sys.sgi
Subject: Misc.
Message-ID: <8812200602.aa17057@SMOKE.BRL.MIL>
Date: 19 Dec 88 06:43:53 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 71

Hello Netlanders,

  I've a few questions about SGI's new GTX architecture. They are based
on the 3.1 release notes and a document called "IRIS GTX: A Technical
Report, Rev 2":

- which type of CPU (16 MHZ or 25 MHZ) and how many of them do I need
  to get the full graphics speed (100.000 Z-buffered 4-sided, G-shaded,
  P-lighted, independent polygons). I ask this question, because one of
  SGI's competitors (they have a vector/parallel-oriented Workstation
  with up to 4 CPU's, Graphics computations done in the CPU) had to admit
  (after applying some spanish inqusition tools) that they need 4 CPU's
  to reach their maximum graphics performance and  that there may exist
  situations, where graphics can consume all resources of the system.

- Chapter "8.2 Graphics Notes" in the 4D-3.1 release notes states that
  some of the graphics routines (c3*, c4*, n3f, v2*, v3*, v4*) should be
  called with quadword-aligned data to get full GTX performance.
  Does this mean all the variables have to be "double" (which I don't
  beleave) or that the first byte of a "float x[3]" vector has to start
  on a quadword-address? In the latter case I only have to rearrange our
  data-structures.

- does shademodel(FLAT) work again under 3.1?

As a  last point I want to comment on Jim Frost who wrotes a note about

> Subject: SGI's interesting idea of a "speedup"
                        .
                        .
                        .
                        .
>Interestingly, the 10x factor seems to be correct as one of our
>customers reported that our product "ran ten times slower" on the GT.
>
>We happily followed the SGI guide to speed them up.  At one point we
>changed all our readpixel() calls to rectread() calls, a non-trivial
>task because they don't have the same arguments at all.  To our great
>surprise, the following was printed when the new call was made:
>
>    <rectread> is not implemented.
>
>We were impressed at just how fast their new function didn't work, as
>I'm sure you can guess.
>
>Curious, we investigated.  Making use of "strings", we found that
>libgl_s.a contained the string "<%s> is not implemented.".  Just how
>many functions might call whatever routine has that string is
>something that scares me.
>
>Jim Frost
>Associative Design Technology
>(508) 366-9166
>madd@bu-it.bu.edu

Did you get your "not implemented" on a G or GT. If its on a G (as I
suspect) how can you expect routines to be implemented that make only
sense on the GT architecture (another example is smoothline())? I think
its a good idea to allow you to use the calls, but to tell you that they
don't work.


Have a merry Christmas and a happy new year 89
Martin Knoblauch

TH-Darmstadt
Physical Chemistry 1
Petersenstrasse 20
D-6100 Darmstadt
West-Germany

BITNET: <XBR2D96D@DDATHD21>