🚀 go-pugleaf

In article <1992Aug20.155104.15645@dsd.es.com> smitty@dsd.es.com writes:
| 
| 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.

I'd argue that:

   1)   The data reformatting issues I've been discussing are different
	from the data type conversion that Rich mentioned, and that Kurt
	addressed in his message.  See my recent posting in response to
	Chris Lilley's questions for an example.

   2)   I've seen other manufacturers' machines with
	data-type-conversion capability at the head of the pipeline.
	As Rich pointed out, many pipelines require some kind of
	conversion from an external data type to the internal data type
	used by the pipe. In short, this is not a feature exclusive to
	SGI machines, nor is it restricted to the high end.

   3)   Feature subsetting is completely independent of data
	reformatting or type conversion.

   4)   Software emulation is usually independent of data reformatting
	and type conversion.  The connection is rare, and involves some
	design extremes (e.g. complete absence of floating-point
	support, or insufficient memory to reformat a complete
	primitive).  I don't think this is an issue in practice.

There's a widespread belief that OpenGL can't be implemented
efficiently on machines other than SGI's.  Having spent some time
working on graphics architectures other than SGI's, I don't believe
this is true.  SGI has no monopoly on computer graphics design talent,
and there are a lot of people out there who understand all the
fundamental issues.  I think other manufacturers will be able to
implement OpenGL quite successfully when they choose to do so.

Allen