🚀 go-pugleaf

In article <op6up5g@fido.asd.sgi.com>, kurt@cashew.asd.sgi.com (Kurt Akeley) writes:
> -- 
> 
> In article <1992Aug18.182730.3478@dsd.es.com>, rthomson@mesa.dsd.es.com (Rich Thomson) writes:
> >
> > ...
> >
> > Under OpenGL, the same reformatting happens; you merely get what
> > language designers call "syntactic sugar" so that you can provide the
> > data in any datatype you wish.  However, at the core of all graphics
> > rendering today (at least the PEX/OpenGL type) is a graphics pipeline.
> > Data goes in one side and pixels come out the other (I'm
> > oversimplifying).  This pipeline is going to have its own natural data
> > format for the data that is the most efficient for its algorithms.
> > Your data will be reformatted to this internal representation.
> 
> Not so, at least on high-end machines.  Silicon Graphics machines such as
> the GT, GTX, VGX, VGXT, and RealityEngine all have pipelines that accept
> data in arbitrary formats and do the conversion with no performance loss.
> To call this "syntactic sugar" is to call all of the pipeline operations,
> such as matrix multiplication and texture mapping, syntactic sugar.  After
> all, any of these operations can be performed by the CPU at reduced
> performance.
> 
> The OpenGL X protocol allows servers to implement data conversion by
> including separate tokens for all data types.  Thus, for example, the 24
> OpenGL vertex commands (e.g. glVertex2i, glVertex3f, and glVertex4d)
> all have their own tokens in the protocol.
> 
> > >In PHIGS and PEXlib, data reformating is almost essential, it is 
> > >ubiquitous.
> > 
> > PEXlib is not intended to be an API, but an SPI.  If you want the
> > same syntactic sugar that is provided in OpenGL, you can write a
> > toolkit on top of PEXlib that does this reformatting for you.
> 
> And you will pay the resulting performance penalties.  Performance is
> maximized when low-level operations that can be performed by the graphics
> pipeline ARE performed by the graphics pipeline.  When these capabilities
> are not supported by the low-level protocol, toolkits cannot patch things
> up without performance loss.
> 
> > If possible, I recommend you get a PEX server from your workstation
> > vendor instead of the PEX-SI.  The SI is, after all, a Sample
> > Implementation, and can't be expected to run blazingly fast or provide a
> > gigantic feature set.
> 
> I guess I wouldn't consider the OpenGL feature set to be gigantic, but it is
> large, and the OpenGL sample implementation includes all of it.
> 
>  -- Kurt Akeley	    kurt@sgi.com  (415) 390-3612  M/S 7U-550

OK, lets say I buy all this.  What happens when someone implements this
(OpenGL) on something other than a high-end SGI graphics pipe?

IMHO, unless this non-SGI pipe has all of the features of the SGI pipe,
then you immediately get into data reformating, feature subseting, software
emulation of features, all the stuff that is supposedly "not a problem" in
OpenGL.

-- 
======================================================================
 Maurice Smith                     |" I feel much better now that I've
 smitty@dsd.es.com  (use it!)      |  given up all hope." 
 Evans & Sutherland Computer Corp. | 
 Salt Lake City, Utah              |  #include <standard_disclaimer>