🚀 go-pugleaf

In article <oodqpdc@fido.asd.sgi.com> akin@sgi.com (Allen Akin)
writes:

>In article <1992Aug18.182730.3478@dsd.es.com> rthomson@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.

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

What you seem to be saying is that some other subsystem reformats the
data instead.

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.  

OK, accepted.

You then do not explain in any detail how SGI's  GL or future OpenGL
implementation would do this. It ois still extracting data from the
application database; a bit here, a bit there. What is doing this? The
CPU? or the graphics hardware?

How does it know how the user data is structured? Do you pass it a
description of the data format and let it work it out? If so there
must be some limit to the complexity of data you can describe to it.

If not, then the CPU and the application program must be scurrying
around collecting data and transforming it to send in immediate mode
to the graphics pipeline. The fact that it does not construct an
in-memory version of the new data is a detail of implementation, in a
sense; it is still being reformatted, regardless of whether you store
the reformatted data.

>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 comment now seems to apply to GL as well.

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

Well, no. Having reformatted the data, to show a dynamic bending under
load you just edit the structure store and change some positions. The
details of which element connects to which are constant. 

I accept that GL would have to regenerate another immediate mode
frame. As I look at it above, this is reformatting. So GL has an
additional overhead; it reformats/extracts/call it what you will the
same data from the same places, frame after frame after frame. The
PHIGS style implementation  does this only once, then stores the
result (which seems to me only sensible).

It is rather like keeping loop invariant code inside the loop, then
claiming this as an advantage!

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

It is this extraction process, occuring for every frame, that I wish
you would shed some more light on. I cannot accept that this
extraction, regardless of the complexity of the users data, carries no
performance penalty. Something must be doing it, either the CPU or the
graphics hardware. So something is having its performance degraded
because it is extracting data 'piecemeal'.


I also don't see how the hardware buss stays out of this process.
Whether the data is being sent to the graphics pipeline once, as with
PHIGS using PEX, or for every frame, with GL, data is being shifted
over the net from the machine holding the application data to the
display surface. This has got to involve the busses.

I realise I am making an assumption here. I know that X is network
transparent, so I assume GL is also. If this assumption is correct, my
point stands. If it is incorrect, then there is massive data
duplication going on; if the user data has to be copied to each
workststion for display on a local display surface, then this is an
overhead. Further, if this is the case, updataes to local data must be
transmitted back to the central database, so you have a consistency
problem in your central database.

Perhaps someone would care to explain or elaborate on the points I
have raised; I am curious.

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

Aha!. So the onus is on the application program to figure out how to
pass over the database and extract the data to make the correct calls.
The application program traverses the structure of the tetrahedral
mesh and uses up CPU doing so, and this seems to me exactly the same
procedure that would be required for a PHIGS style application to
reformat the data. So I guess the overhead winds up being much the
same.

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

Well, there is only a massive drop in performance from local to remote
if you use an immediate mode API. With server side structure storage
and traversal, performance is much the same in either case. There is a
little drop because local displays can use shared memory transport,
but that is just a little optimisation; it does not affect the
generality of the network transparency approach.

It may be your belief that running displays on a local machine is far
more common; that is not my experience. For example, I am sitting at a
VAXstation 4000 and running programs on a Sun SPARC 2, an HP 9000/750,
a VAXstation 3100 and a Meiko Computing Surface in addition to my
local machine.

I sure would hate to walk around the building to each one, whenever I
wanted to use it. (Luckily, they are all in the same building!).

It is my belief that this distributed model will fast become the norm,
and if as you state GL does not address it without huge performance
penalty, then that is a significant failing of GL.


--
Chris Lilley
---------------------------------------------------------------------------
Technical Author, ITTI Computer Graphics and Visualisation Training Project
Computer Graphics Unit, Manchester Computing Centre, Manchester, UK
Internet:   lilley@cgu.mcc.ac.uk        Janet:   lilley@uk.ac.mcc.cgu
Voice:      +44 (0)61 275 6095          Fax:     +44 (0)61 275 6040
---------------------------------------------------------------------------