home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!mcsun!uknet!mucs!lilleyc
- From: lilleyc@cs.man.ac.uk (Chris Lilley)
- Newsgroups: comp.windows.x.pex
- Subject: Re: Future development of PEX/PHIGS
- Message-ID: <5818@m1.cs.man.ac.uk>
- Date: 19 Aug 92 17:36:06 GMT
- References: <1992Aug14.210903.23864@noose.ecn.purdue.edu> <1992Aug18.182730.3478@dsd.es.com> <oodqpdc@fido.asd.sgi.com>
- Sender: news@cs.man.ac.uk
- Organization: Dept Computer Science, University of Manchester, U.K.
- Lines: 177
-
- 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
- ---------------------------------------------------------------------------
-