🚀 go-pugleaf

In article <1992Aug13.170434.18221@hsr.no>,
   jarl@hsr.no (Jarl Haugland) writes:

|> Interesting questions are:
|>   * When (if ever) will the official PHIGS version have support for
|>     immediate mode?

PEX already supports immediate mode; as Gary Cannon mentioned, it may
be officially added to PHIGS, but PEX != PHIGS.  PEX doesn't have to
way for PHIGS to adopt immediate-mode -- it has it right now.  There
are several contributed APIs for generating the immediate-mode portion
of the PEX protocol.  I posted a note earlier about these APIs, but
the one that most closely corresponds to a PHIGS programming model is
PEXIM.

>|>   * Will PEX/PHIGS support additional advanced graphical techniques like:
>|>     - double buffering

PEX already supports double buffering.  We've supported and
demonstrated double buffering on our PEX server for the past 3
SIGGRAPHs.  Perhaps you're waiting for the PEX-SI to support double
buffering.  You'll have to talk to the X Consortium about that, but I
don't know of a single vendor with a PEX server product that doesn't
support double buffering.  Unless you're forced into using a software
renderer (i.e. PEX-SI), you should use the vendor's server anyway as
they will have optimized and/or rewritten chunks of the PEX-SI to
obtain the full rated speed of their graphics devices.

>|>     - texture mapping

Some vendors plan to extend the data mapping concept of PHIGS-PLUS to
incorporate texture mapping.  Data mapping lets you have a set of
floating-point values attached to the vertices of a primitive.
Obviously, for texture these would be the texture coordinates -- (u,v) for
2D textures, (u,v,w) for 3D textures.  The extension of data mapping
would define a 'data mapping record' that has other parameters needed
for texture mapping (texture wrap, etc.).  I believe this is also
being considered for incorporation into PHIGS-PLUS.  However, vendors
don't have to wait for the standards committee to approve something
before they can implement it in an interoperable fashion (i.e. consistent
across different vendor's platforms).

>|>     - antialiasing

Our products have had the highest quality anti-aliased lines in the
industry for 3 years.  For full-scene anti-aliasing, we implemented a
multiple pass traversal mechanism by extending the number of HLHSR
modes.  Granted, this isn't as good as full scene anti-aliasing by
supersampling, but doing that fast in hardware requires a much larger
frame buffer (since you typically want 16 samples per screen pixel
instead of 1 sample per screen pixel).

>|>     - etc....
>|>     My understanding is that OpenGL will support many of these when it's
>|>     available, so PEX/PHIGS will have to speed up to be into the race...

PEX, via its extensibility, is already there in most respects.
Full-scene anti-aliasing by supersampling (as done in our CDRS
product) is a matter of hardware (and software simulation).

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?  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.

Here are some numbers for the picture level benchmark on our machines (from
the GPC Quarterly Report, Vol. 2, No. 2, 2nd Qtr 1992):

Configuration		PLB(lit):PLB(opt)
			pc_board  sys_chassis  cyl_head  head       shuttle
ESV 10/32		21.9:23.8  21.9:30.1   16.2:28.0 18.0:NA    39.8:NA
ESV 20/33		25.7:28.5  26.2:36.9   15.7:39.5 29.4:NA    60.7:NA
ESV 30/34 HC		27.3:31.1  28.8:45.9   57.0:NA   40.2:NA    75.2:NA
ESV 50/34 HC & LS	27.5:32.2  28.8:46.6   64.1:NA   58.9:59.3  85.9:NA

The first number is the GPCmarks reported for the benchmark when
interpreted literally, while the second number is the GPCmarks reported for
the benchmark when the benchmark data has been optimized for the particular
machine.  Some numbers for the optimized cases were not available.  The
vendors participating the GPC are: DEC, E&S, HP, IBM, SGI and Sun.

E&S has the highest reported GPCmark for the Shuttle benchmark (85.9).

SGI only reported results for the sys_chassis benchmark (on a VGX) and
our entry level machine's optimized numbers are comparable to a 5-span VGX
on that benchmark (30.1/E&S vs. 31.1/SGI); the 10-span VGX only gets 36.0
which just tells you that the benchmark isn't fill-rate limited.

If you want to talk about performance, you have to ignore the glossy
marketing hype from _all_ vendors and look at the numbers.  The above
benchmarks are described in full in the GPC quartlerly report.  The inside
of the first pages says:

    ``The GPC Quarterly Report is published by the National Computer
    Graphics Association (NCGA), 2722 Merilee Drive, Suite 200, Fairfax, VA
    22031.  For more information regarding the report or GPC Committee
    membership, contact Dianne Dean, NCGA, 703-698-9600, or FAX
    703-560-2752.''

SGI talks alot about performance, but they quote peak numbers for their
graphics hardware.  Peak numbers are often not realized by applications and
as such don't tell you much about how fast the box is going to run your
application.  What users care about is performance available to their
application, not just a peak number of for a contrived or pathological case
of data.  SGI is beginning to address this, but to obtain typical
performance comparable to peak performance, you'll have to buy a
RealityEngine.  If you, as an SGI user, care about performance, you should
ask SGI why they don't publish more GPC benchmark numbers so that you can
evaluate their products on an even footing with other vendors.

>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.  

>Maybe PEX can catch up in supporting those
>functionalities.  

See above.

>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.  Every network protocol is going to incur
some reformatting.  Guess what, though: the network is still not the
bottleneck.  The system bus and the speed of the graphics hardware is
still the bottleneck, so all this talk about reformatting doesn't have
a large impact upon performance.  I regularly run AVS across the
network on another machine, while displaying on mine through PEX.  AVS
is a wonderful tool, but the generality tends to come at the expense
of resources.  However, the rendering time and interactivity isn't
diminished at all by the fact that I'm running the program remotely.
In fact, this user can't notice any difference at all when interacting
through the geometry viewer.

						-- Rich
-- 
	Repeal the personal income tax; vote Libertarian in 1992.
Disclaimer: I speak for myself, except as noted; Copyright 1992 Rich Thomson
UUCP: ...!uunet!dsd.es.com!rthomson			Rich Thomson
Internet: rthomson@dsd.es.com	IRC: _Rich_		PEXt Programmer