🚀 go-pugleaf

-- 

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