home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / windows / x / pex / 476 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  8.8 KB

  1. Path: sparky!uunet!mcsun!uknet!mucs!lilleyc
  2. From: lilleyc@cs.man.ac.uk (Chris Lilley)
  3. Newsgroups: comp.windows.x.pex
  4. Subject: Re: Future development of PEX/PHIGS
  5. Message-ID: <5818@m1.cs.man.ac.uk>
  6. Date: 19 Aug 92 17:36:06 GMT
  7. References: <1992Aug14.210903.23864@noose.ecn.purdue.edu> <1992Aug18.182730.3478@dsd.es.com> <oodqpdc@fido.asd.sgi.com>
  8. Sender: news@cs.man.ac.uk
  9. Organization: Dept Computer Science, University of Manchester, U.K.
  10. Lines: 177
  11.  
  12. In article <oodqpdc@fido.asd.sgi.com> akin@sgi.com (Allen Akin)
  13. writes:
  14.  
  15. >In article <1992Aug18.182730.3478@dsd.es.com> rthomson@dsd.es.com
  16. (Rich Thomson) writes:
  17.  
  18.  >| Under OpenGL, the same reformatting happens; you merely get what
  19.  >| language designers call "syntactic sugar" so that you can provide the
  20.  >| data in any datatype you wish.  However, at the core of all graphics
  21.  >| rendering today (at least the PEX/OpenGL type) is a graphics pipeline.
  22.  >| Data goes in one side and pixels come out the other (I'm
  23.  >| oversimplifying).  This pipeline is going to have its own natural data
  24.  >| format for the data that is the most efficient for its algorithms.
  25.  >| Your data will be reformatted to this internal representation.
  26.  
  27. >No, the design issue here is much deeper than "syntactic sugar."
  28.  
  29. >With the OpenGL API, it's possible to extract graphics data directly
  30. >from application databases without having it travel through the CPU
  31. >and system busses for reformatting.  
  32.  
  33. What you seem to be saying is that some other subsystem reformats the
  34. data instead.
  35.  
  36. With a PHIGS- or PEXlib-style API
  37. >that defines primitives with high-level structures, or any API that
  38. >generates a memory-resident intermediate representation like a wire
  39. >protocol packet, this is not possible for arbitrary application
  40. >databases.
  41.  
  42. >Let's say you're writing a finite-element analysis program that uses a
  43. >tetrahedral mesh to represent a beam.  Suppose you've calculated the
  44. >stress at each point in the mesh, and now you want to display the beam
  45. >color-coded for stress in some way.
  46.  
  47.  
  48. >Neither PHIGS nor PEXlib has a "tetrahedral mesh" primitive, so if
  49. >you're using one of them you have to reformat your data to build some
  50. >set of primitives that the API can handle -- maybe fill-areas or
  51. >triangle strips.  Furthermore, the PEX protocol has no tetrahedral mesh
  52. >primitive, so even if you layer a fancier API on PEX, it still must
  53. >reformat your data to build PEX protocol packets for fill-areas or
  54. >triangle strips.  
  55.  
  56. OK, accepted.
  57.  
  58. You then do not explain in any detail how SGI's  GL or future OpenGL
  59. implementation would do this. It ois still extracting data from the
  60. application database; a bit here, a bit there. What is doing this? The
  61. CPU? or the graphics hardware?
  62.  
  63. How does it know how the user data is structured? Do you pass it a
  64. description of the data format and let it work it out? If so there
  65. must be some limit to the complexity of data you can describe to it.
  66.  
  67. If not, then the CPU and the application program must be scurrying
  68. around collecting data and transforming it to send in immediate mode
  69. to the graphics pipeline. The fact that it does not construct an
  70. in-memory version of the new data is a detail of implementation, in a
  71. sense; it is still being reformatted, regardless of whether you store
  72. the reformatted data.
  73.  
  74. >Either way, the CPU and system busses are spending a
  75. >lot of time unproductively rearranging data to suit the needs of a
  76. >software interface.  
  77.  
  78. This comment now seems to apply to GL as well.
  79.  
  80. >This cost becomes significant if the application
  81. >requires low latency for drawing or if the database changes at
  82. >interactive rates -- for example, if you want to show the deflection of
  83. >the beam under load, then all of the beam's geometry will change and
  84. >you'll have to regenerate the PHIGS, PEXlib, or PEX representation for
  85. >every frame.  
  86.  
  87. Well, no. Having reformatted the data, to show a dynamic bending under
  88. load you just edit the structure store and change some positions. The
  89. details of which element connects to which are constant. 
  90.  
  91. I accept that GL would have to regenerate another immediate mode
  92. frame. As I look at it above, this is reformatting. So GL has an
  93. additional overhead; it reformats/extracts/call it what you will the
  94. same data from the same places, frame after frame after frame. The
  95. PHIGS style implementation  does this only once, then stores the
  96. result (which seems to me only sensible).
  97.  
  98. It is rather like keeping loop invariant code inside the loop, then
  99. claiming this as an advantage!
  100.  
  101. >Or you can argue that the API shouldn't place any constraints on the
  102. >application's data structures.  This is the OpenGL approach.  The
  103. >OpenGL API allows individual vertex coordinates, colors, etc.  to be
  104. >extracted piecemeal or as a vector from an arbitrary data structure.
  105. >No data duplication is needed.  No data reformatting to match the API
  106. >is needed.  With proper hardware assist, no data reformatting to match
  107. >a wire protocol is needed.  
  108.  
  109. It is this extraction process, occuring for every frame, that I wish
  110. you would shed some more light on. I cannot accept that this
  111. extraction, regardless of the complexity of the users data, carries no
  112. performance penalty. Something must be doing it, either the CPU or the
  113. graphics hardware. So something is having its performance degraded
  114. because it is extracting data 'piecemeal'.
  115.  
  116.  
  117. I also don't see how the hardware buss stays out of this process.
  118. Whether the data is being sent to the graphics pipeline once, as with
  119. PHIGS using PEX, or for every frame, with GL, data is being shifted
  120. over the net from the machine holding the application data to the
  121. display surface. This has got to involve the busses.
  122.  
  123. I realise I am making an assumption here. I know that X is network
  124. transparent, so I assume GL is also. If this assumption is correct, my
  125. point stands. If it is incorrect, then there is massive data
  126. duplication going on; if the user data has to be copied to each
  127. workststion for display on a local display surface, then this is an
  128. overhead. Further, if this is the case, updataes to local data must be
  129. transmitted back to the central database, so you have a consistency
  130. problem in your central database.
  131.  
  132. Perhaps someone would care to explain or elaborate on the points I
  133. have raised; I am curious.
  134.  
  135. >So OpenGL has no tetrahedral mesh primitive, but that's not a problem.
  136. >Just make a series of glVertex3fv() calls to extract triangle vertices
  137.              ^^^^^
  138. >from the tetrahedral mesh.  No data structure reformatting is needed,
  139. >so the CPU doesn't waste cycles and there's less traffic on the system
  140. >bus.
  141.  
  142. Aha!. So the onus is on the application program to figure out how to
  143. pass over the database and extract the data to make the correct calls.
  144. The application program traverses the structure of the tetrahedral
  145. mesh and uses up CPU doing so, and this seems to me exactly the same
  146. procedure that would be required for a PHIGS style application to
  147. reformat the data. So I guess the overhead winds up being much the
  148. same.
  149.  
  150. >As for the remote rendering case:  I wish there were some easy way to
  151. >write an application that performs optimally in both the remote and
  152. >local cases.  I don't know of one.  There's still a big performance
  153. >payoff for choosing carefully between display lists and immediate-mode
  154. >rendering depending on the characteristics of the application and
  155. >whether the display is local or remote.  Data reformatting costs are
  156. >more important in the local case than the remote case, but the local
  157. >case is far more common (and will probably remain so, for performance
  158. >reasons).
  159.  
  160. Well, there is only a massive drop in performance from local to remote
  161. if you use an immediate mode API. With server side structure storage
  162. and traversal, performance is much the same in either case. There is a
  163. little drop because local displays can use shared memory transport,
  164. but that is just a little optimisation; it does not affect the
  165. generality of the network transparency approach.
  166.  
  167. It may be your belief that running displays on a local machine is far
  168. more common; that is not my experience. For example, I am sitting at a
  169. VAXstation 4000 and running programs on a Sun SPARC 2, an HP 9000/750,
  170. a VAXstation 3100 and a Meiko Computing Surface in addition to my
  171. local machine.
  172.  
  173. I sure would hate to walk around the building to each one, whenever I
  174. wanted to use it. (Luckily, they are all in the same building!).
  175.  
  176. It is my belief that this distributed model will fast become the norm,
  177. and if as you state GL does not address it without huge performance
  178. penalty, then that is a significant failing of GL.
  179.  
  180.  
  181. --
  182. Chris Lilley
  183. ---------------------------------------------------------------------------
  184. Technical Author, ITTI Computer Graphics and Visualisation Training Project
  185. Computer Graphics Unit, Manchester Computing Centre, Manchester, UK
  186. Internet:   lilley@cgu.mcc.ac.uk        Janet:   lilley@uk.ac.mcc.cgu
  187. Voice:      +44 (0)61 275 6095          Fax:     +44 (0)61 275 6040
  188. ---------------------------------------------------------------------------
  189.