home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / sgi / graphics / 80 < prev    next >
Encoding:
Text File  |  1993-01-01  |  3.1 KB  |  69 lines
  1. Newsgroups: comp.sys.sgi.graphics
  2. Path: sparky!uunet!rosevax!camax01!grose
  3. From: grose@camax.com (Larry Grose)
  4. Subject: Software Z-buffer grabs too much memory
  5. Message-ID: <1992Dec31.202430.24500@camax.com>
  6. Summary: Indigo grabs 16 Mb for Z-buffering
  7. Sender: grose@camax.com (Larry Grose)
  8. Organization: CAMAX Systems, Inc.
  9. Distribution: usa
  10. Date: Thu, 31 Dec 1992 20:24:30 GMT
  11. Lines: 56
  12.  
  13. We have an application that uses Z-buffering.  It creates one window that
  14. occupies the full screen (either 1280x1024 or 1024x768, depending on the
  15. graphics card being used).  The problem is the SGI Entry graphics card, which
  16. does software Z-buffering and has a screen resolution of 1024x768.  According
  17. to information from SGI back in the days when an Indigo was a Hollywood, we
  18. would expect GL to malloc approximately 3 Mb the first time our application
  19. does Z-buffering (1024 * 748 * 4 bytes for a 32-bit Z-buffer).  However, an
  20. Indigo Entry running IRIX 4.0.5A actually malloc's 16 Mb!  Since we don't
  21. have infinite swap space and RAM, this means that we run out of virtual
  22. memory much more quickly than we would expect to.
  23.  
  24. I logged a call to the TAC and the official answer is that this is a
  25. deliberately designed feature!  Apparently, GL allocates 3 Mb for "small"
  26. windows and 16 Mb for "large" windows, since it supports virtual windows up
  27. to 2K x 2K pixels, in order to avoid excessive realloc'ing (not
  28. unreasonable).  The problem is that a standard full screen window is
  29. considered a large window, while a slightly smaller one (1024x767) is
  30. considered a small window, thus needing only 3 Mb.  What in the world is the
  31. logic behind this?  I would think that 1024x768 should be the largest small
  32. window, and anything bigger than that implies a virtual window, justifying
  33. the larger allocation.  Am I stuck with this?  Does anyone know any
  34. workarounds?
  35.  
  36. Editorial side comment: SGI said that the extra allocation shouldn't make any
  37. difference because it doesn't actually take up "real memory".  Of course,
  38. this is due to SGI infamous sbrk (malloc) implementation, where you find out
  39. that you have run out of virtual memory when you reference a pointer one too
  40. many times and your program suddenly exits with no hope of recovering
  41. gracefully (and professionally).  This feature is very popular with our
  42. customers :-( .  To minimize the terrible side effects of that, we have our
  43. own version of malloc that verifies enough virtual memory is available to
  44. satisfy a call to sbrk, then it touches every page that has been added, so
  45. that programmers will know when no more virtual memory is available and take
  46. appropriate action.  As a result, our application is affected by the extra
  47. allocation.
  48.  
  49. I have re-created the problem with the following small program:
  50.  
  51.     #include <gl.h>
  52.  
  53.     main ()
  54.     {
  55.     prefposition (0, 1023, 0, 767),
  56.     winopen ("zbuff");
  57.     system ("ps -l");
  58.     zbuffer (1);
  59.     system ("ps -l");
  60.     return (0);
  61.     }
  62.  
  63. Running the program should show that the number of pages grows from 363 to
  64. 4459 (an increase of 16 Mb).  If you replace 767 with 766 and run it again,
  65. the number of pages will grow to 1135 (an increase of just over 3 Mb).
  66.  
  67. -- 
  68. -- Larry Grose / CAMAX Systems, Inc. / 612-854-5300 / grose@camax.com
  69.