🚀 go-pugleaf

I agree with most of what Rich said, but there were a few points that
need further discussion.

In article <1992Aug18.182730.3478@dsd.es.com> rthomson@dsd.es.com (Rich Thomson) writes:
| 
| Complete interoperability is functionally here right now.
| [Valid points about registered identifiers omitted for brevity.]

I don't think anyone is arguing that PHIGS or PEX lack *mechanisms* for
interoperability.  People are concerned that *in practice*
implementations don't interoperate.  Witness the messages on this
newsgroup documenting interoperation failures between Sun PHIGS and DEC
PEX.  Or Rich's comments about which vendors support antialiasing, and
in what ways.  Applications developers are right to be worried about
this problem, and should persuade their vendors to provide a solution.
Disallowing subsets is one approach that helps.

| If your application requies interactivity, and not just static
| renderings, then the performance will be critical to the usefulness of
| the application.  Attempting to interactively manipulate 10,000
| polygons on an underpowered machine is going to be so frustrating as
| to make the application useless.

I used to believe this argument, too.  But the truth is that end-users
are amazingly creative, and they can get work done even on machines
those of us in the workstation world consider hopelessly underpowered.
Based on past experience at a Macintosh software vendor, I'd bet a
substantial sum that there are more people doing 3D graphics on
unaccelerated Macintoshes than on SGI's entire installed base.  For
most of those people, a 386/33 is quite comparable to the systems
they're using, and a 486/50 would be significantly faster.

The key to this mystery is understanding the way users manage the
complexity of their databases.  A Mac IIci may only be able to
manipulate a few hundred polygons with reasonable interaction times, so
its user will be forced to express his task in terms of a database the
machine can handle.  But even that performance level gives him the
ability to solve problems he could never tackle before.  If you give
him a faster machine, he takes on larger problems with more complex
databases until the interaction time once again reaches his personal
tolerance level.  In any performance band the machine helps him do some
class of job, so it's always a net win.

The bottom line is that there are a lot of potential users out there in
the real world, and many of them are addressing problems that *can* be
tackled productively even on "slow" machines... provided that the
vendors make the necessary functionality available.  That's what SGI
and Microsoft are attempting to do with OpenGL.

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

No, the design issue here is much deeper than "syntactic sugar."

With the OpenGL API, it's possible to extract graphics data directly
from application databases without having it travel through the CPU
and system busses for reformatting.  With a PHIGS- or PEXlib-style API
that defines primitives with high-level structures, or any API that
generates a memory-resident intermediate representation like a wire
protocol packet, this is not possible for arbitrary application
databases.

Let's say you're writing a finite-element analysis program that uses a
tetrahedral mesh to represent a beam.  Suppose you've calculated the
stress at each point in the mesh, and now you want to display the beam
color-coded for stress in some way.

Neither PHIGS nor PEXlib has a "tetrahedral mesh" primitive, so if
you're using one of them you have to reformat your data to build some
set of primitives that the API can handle -- maybe fill-areas or
triangle strips.  Furthermore, the PEX protocol has no tetrahedral mesh
primitive, so even if you layer a fancier API on PEX, it still must
reformat your data to build PEX protocol packets for fill-areas or
triangle strips.  Either way, the CPU and system busses are spending a
lot of time unproductively rearranging data to suit the needs of a
software interface.  This cost becomes significant if the application
requires low latency for drawing or if the database changes at
interactive rates -- for example, if you want to show the deflection of
the beam under load, then all of the beam's geometry will change and
you'll have to regenerate the PHIGS, PEXlib, or PEX representation for
every frame.  I showed one way to quantify the cost of this
reformatting in the PEX/OpenGL analysis paper; lurkers might find it
instructive to apply the technique to their favorite computer system,
and see the effect one or two reformatting operations have on maximum
drawing rate.

You can argue that applications developers should use data structures
that are identical with those of PEX or their favorite PEX API.
Sometimes that will work.  However, many software vendors have told me
it isn't acceptable.  They use a particular data structure (like the
tetrahedral mesh in our example above) for very good reasons of their
own, and they don't want to be jerked around by their graphics hardware
vendors.  They make their money from the added value provided by their
own algorithms and data structures.

You can argue that applications developers should use PEX structure
store for graphics data, so that the data reformatting happens only
once (when the structures are created).  Sometimes that will work.
However, if the graphics data is dynamic (as for the deflecting beam in
our example above) then the reformatting (and possibly structure
editing as well) still has to take place for each frame.  Furthermore,
even if the graphics data is relatively static, it's effectively
duplicated:  once in the application's private data structures (e.g.
the tetrahedral mesh) and once in the PEX structure store.  This drives
up the real-memory requirements of the application.  Since typical
CAD/CAM databases today are in the 20MB-40MB size range, this
duplication can result in significant memory or performance (paging)
cost to the end user.

Or you can argue that the API shouldn't place any constraints on the
application's data structures.  This is the OpenGL approach.  The
OpenGL API allows individual vertex coordinates, colors, etc.  to be
extracted piecemeal or as a vector from an arbitrary data structure.
No data duplication is needed.  No data reformatting to match the API
is needed.  With proper hardware assist, no data reformatting to match
a wire protocol is needed.  (I know of three workstation vendors whose
hardware designs show an understanding of this last point, so it's not
an SGI secret.  I suspect the techniques are widely known, but I
haven't had the opportunity to make a survey.)

So OpenGL has no tetrahedral mesh primitive, but that's not a problem.
Just make a series of glVertex3fv() calls to extract triangle vertices
from the tetrahedral mesh.  No data structure reformatting is needed,
so the CPU doesn't waste cycles and there's less traffic on the system
bus.

I realize this is a subtle aspect of the OpenGL design, but it's a
significant one.  Definitely worth thinking about.  I apologize if
I've belabored the point.

As for the remote rendering case:  I wish there were some easy way to
write an application that performs optimally in both the remote and
local cases.  I don't know of one.  There's still a big performance
payoff for choosing carefully between display lists and immediate-mode
rendering depending on the characteristics of the application and
whether the display is local or remote.  Data reformatting costs are
more important in the local case than the remote case, but the local
case is far more common (and will probably remain so, for performance
reasons).

Changing data types at the head of the pipeline is an entirely
different issue, conceptually independent of the reformatting discussed
above.  I believe Rich is correct that PEX and OpenGL have similar
concerns for data entering the pipeline.

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

As noted above, if there's any mismatch of data structures along the
line from application to PHIGS to PEXlib to PEX protocol packet, then
you pay reformatting costs for each mismatch.

Building an OpenGL API on PEXlib is impossible with current versions of
PEX, because of functionality mismatches.  But even if you could,
layering an OpenGL API on PEXlib would be a bad idea because you'd
incur data reformatting costs from OpenGL to PEXlib.  You might also
incur reformatting costs from PEXlib to PEX protocol packets, but I
don't know that to be the case; perhaps a PEXlib expert could comment.

I think the original poster hit the issue right on the nose:  In a
system where the wire protocol is the fundamental concept, there will
almost always be data reformatting to convert application data
structures to protocol packets.

Allen