home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / graphics / opengl / 240 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  2.9 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!sgi!fido!tuolumne!akin
  2. From: akin@tuolumne.asd.sgi.com (Allen Akin)
  3. Newsgroups: comp.graphics.opengl
  4. Subject: Re: Software speed?
  5. Date: 11 Jan 1993 19:52:07 GMT
  6. Organization: Silicon Graphics, Inc.  Mountain View, CA
  7. Lines: 51
  8. Message-ID: <1isj57INNp2d@fido.asd.sgi.com>
  9. References: <1993Jan8.174025.21761@eye.com>
  10. NNTP-Posting-Host: tuolumne.asd.sgi.com
  11.  
  12.  
  13. In article <1993Jan8.174025.21761@eye.com>, erich@eye.com writes:
  14. > Lines: 13
  15. > 
  16. > I would like to know how fast the provided code for the OpenGL API performs.
  17. > That is, if you get a level 2 commercial license, how fast is the software
  18. > only version of the X11 sample implementation for shaded polygons?  I'm
  19. > interested in figures on any machine - GPC type figures are fine, or any other
  20. > 3D illuminated polygon benchmark you guys at SGI might have (Bill Glazier, are
  21. > you still out there?  You seem to be in the know).
  22.  
  23. As Kipp said... The sample OpenGL implementation is intended to be
  24. functionally complete and readily customizable, but it isn't optimized
  25. to the extent that you could ship it as a product off-the-shelf.
  26. Therefore measuring its performance isn't very meaningful -- you'd be
  27. getting some measurement of the schedule pressures faced by its
  28. implementors :-), but not any measurement of the intrisic capabilities
  29. of the API or the software or the hardware on which it's run.
  30.  
  31. FYI, the sample OpenGL implementation is being used as the basis for
  32. SGI's product implementations, so we're pretty confident that it
  33. doesn't present any unreasonable limits to optimization.  Some of the
  34. changes we make for our products will be fed back into the sample
  35. implementation, so it will continue to improve.  Perhaps the other
  36. licensees will contribute optimizations, too.
  37.  
  38. Sorry we have to be this cautious.  People do use performance numbers
  39. out of context, so it pays to avoid misunderstandings.  Could you give
  40. us a clue as to what questions you're trying to answer?  Perhaps that
  41. would help us provide more useful information.
  42.  
  43.  
  44. > I'm also interested in how this compares to SGI hardware speeds, i.e. how
  45. > much does various dedicated graphics hardware buy you vs. just using the raw
  46. > compute power of the machine and a software only render?  100x?  10x?  1.5x?
  47. > Does anyone else out there have any feel for this?
  48.  
  49. Could you give me a little more context?
  50.  
  51. As I understand your question, the answer depends pretty drastically on
  52. which model of graphics hardware and which graphics primitive (among
  53. other things) you'd like to use for comparison.  I've seen cases in the
  54. past where adding graphics hardware yielded performance improvements of
  55. greater than 1000X (textured polygons) and performance degradation of
  56. 0.5X (image transfer).
  57.  
  58. The general question of using dedicated hardware vs. general-purpose
  59. hardware, and the resulting cost tradeoffs for particular markets, is a
  60. very interesting one.
  61.  
  62. Allen
  63.