🚀 go-pugleaf

In article <1992Aug14.172943.22563@dsd.es.com>, rthomson@mesa.dsd.es.com (Rich Thomson) writes:
|> 
|> In article <1992Aug13.221534.29469@noose.ecn.purdue.edu>
|> 	luj@ecn.purdue.edu writes:
|> >I guess that PHIGS/PHIGS PLUS can never speed up to support 
|> >what you're demanding.
|> 
|> Can you please cite some facts to back up this assertion? 

The biggest plus of the PHIGS(+) seems to be the fact that it is
an international standard. Therefore one can expect to gain the portability
and performance across different hardware/software implementations. However, the
standard lacks many functionalities(e.g. immediate mode, anti-aliasing,
transparency, shadows, texture mapping ...) that users demand.  True, some
PHIGS implementation do support these functionalities.  But the portability
that one highly expects is gone. When will PHIGS/PHIGS PLUS incorporate
those requirements so that one can be _guranteed_ to have portablity and 
uniformity ?  


|> We've been
|> all over this before in this group.  Given any particular API or
|> programming model, its possible to create a hardware/software
|> combination that will run fast.  Our PEX servers regularly beat the
|> pants off any other PEX server on the market.  The Graphics
|> Performance Characterization Committee of the NCGA has a standard
|> suite of benchmarks used to evaluate the performance of different
|> vendor's platforms.  The Picture Level Benchmark is, in concept,
|> similar to the SPEC suite of applications for measuring CPU
|> performance.
|> 

That's why I was saying that PEX can probably catch up to support those
functionalities, though I'm not sure when the complete _inter-operability_
can be achieved.  If PEX spec chooses to be more strigent 
and to eliminate the subset problems, then PEXlib can probably supercede
the PHIGS API to compete with the OpenGL.


|> [...] What users care about is performance available to their
|> application, not just a peak number of for a contrived or pathological case
|> of data. 

As a user in the area of general-purpose computing, I can the performance 
as well as the portability of my applicaton software. 
Given a certain PHIGS implementation having
non-standard extension, how is the portability  guranteed ?


|> 
|> >By the time it did, another much better API would
|> >have probably widely accepted.
|> 
|> Wrong.  Performance is easily obtained through PEX, but I'll give
|> you a hint: you won't get it through a software renderer.  In order to
|> do graphics fast, you need hardware.  I don't see anything changing
|> that statement.  Of course, the details of the hardware (architecture,
|> clock speed, buffering, etc) are changing all the time, but I've yet
|> to see a software renderer that can outperform hardware.  
|> 

Never have I claimed that the software renderer will outperform the H/W. 
My points are:
	1). PHIGS standard promises the portability. However, due to
the lack of advanced features in the PHIGS and the nonstandard extensions 
from differnt PHIGS implemations, the highly expected portablity is lost.
	2). It is quite evident that the PHIGS API has _much_ room to desire.
I  was quite dismayed when I saw the phigs bindings at the first time. It is 
quite possible other API's such as PEXlib, OpenGL or yet to be designed API
will be the one of choice.
	3). I certainly do not expect that my graphics application have the same 
performace on all the plateforms. However, I do want my applications to 
run on as many plateforms as possible. I also expect that the application
have a high performance on a high-end workstation yet be able to run a low-end box. 
OpenGL seems to have solved this this problem. PEX's inter-operatbility and 
subset problems are yet to be resolved.  I certaily hope that the above PEX problems
can be resolved soon so that an application programmer can use much more elegant API such 
as PEXlib intead of the PHIGS API.


|> 
|> >I seem to have been convinced by Alan Akin that OpenGL superior to PEX
|> >in that there is little need in reformatting the application's data
|> >structure for graphics.
|> 
|> Unless your graphics hardware can accept all varieties of data
|> types for specifying geometry and associated information, there will
|> always be some reformatting.

Yes, there is _always_ the need for data reformating, but one wants to avoid this
as much as possible. In PHIGS and PEXlib, data reformating is almost essential,
it is ubiquitous.

|>  the network is still not the
|> bottleneck.  The system bus and the speed of the graphics hardware is
|> still the bottleneck 

I don't know much about this, someone else should be able to anwser this. 
I have to admit that this is quite a suprise to me.

-- 
-- John Lu 
   luj@ecn.purdue.edu


Disclaimer:  SGI has decided not to support the OpenGL for the SGI mahine I am running.
I do have some boxes running PEX-SI, though.