home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / sgi / graphics / 88 < prev    next >
Encoding:
Internet Message Format  |  1993-01-04  |  4.7 KB

  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!sgiblab!sgigate!odin!fido!verite!billt
  2. From: billt@verite.esd.sgi.com (Bill Torzewski)
  3. Newsgroups: comp.sys.sgi.graphics
  4. Subject: Re: Software Z-buffer grabs too much memory
  5. Date: 4 Jan 1993 20:12:06 GMT
  6. Organization: Silicon Graphics, Inc.  Mountain View, CA
  7. Lines: 79
  8. Message-ID: <1ia5mmINNjqe@fido.asd.sgi.com>
  9. References: <1992Dec31.202430.24500@camax.com>
  10. NNTP-Posting-Host: verite.esd.sgi.com
  11.  
  12.  
  13.  
  14. In article <1992Dec31.202430.24500@camax.com>, grose@camax.com writes:
  15. > We have an application that uses Z-buffering.  It creates one window that
  16. > occupies the full screen (either 1280x1024 or 1024x768, depending on the
  17. > graphics card being used).  The problem is the SGI Entry graphics card, which
  18. > does software Z-buffering and has a screen resolution of 1024x768.  According
  19. > to information from SGI back in the days when an Indigo was a Hollywood, we
  20. > would expect GL to malloc approximately 3 Mb the first time our application
  21. > does Z-buffering (1024 * 748 * 4 bytes for a 32-bit Z-buffer).  However, an
  22. > Indigo Entry running IRIX 4.0.5A actually malloc's 16 Mb!  Since we don't
  23. > have infinite swap space and RAM, this means that we run out of virtual
  24. > memory much more quickly than we would expect to.
  25.  
  26.   Entry graphics allocates the software zbuffer in 2 sizes, 3MB or 16MB,
  27.   3MB for windows 1023x766 (or so) or less, or 16MB for larger windows,
  28.   for the maximum 2K x 2K viewport. Entry graphics requires that the zbuffer
  29.   covers the entire viewport.
  30.  
  31. > I logged a call to the TAC and the official answer is that this is a
  32. > deliberately designed feature!  Apparently, GL allocates 3 Mb for "small"
  33. > windows and 16 Mb for "large" windows, since it supports virtual windows up
  34. > to 2K x 2K pixels, in order to avoid excessive realloc'ing (not
  35. > unreasonable).  The problem is that a standard full screen window is
  36. > considered a large window, while a slightly smaller one (1024x767) is
  37. > considered a small window, thus needing only 3 Mb.  What in the world is the
  38. > logic behind this? I would think that 1024x768 should be the largest small
  39. > window, and anything bigger than that implies a virtual window, justifying
  40. > the larger allocation.  Am I stuck with this?  Does anyone know any
  41. > workarounds?
  42.  
  43.   We have found that if we allocate only enough zbuffer memory to cover
  44.   a window, and the window is later resized larger, we'd have to deallocate
  45.   and reallocate the zbuffer memory. Often, the size of the program then grows
  46.   by the newly allocated space, and is not reduced by the deallocated space.
  47.   I think this is because the memory allocation system can't defragment
  48.   the deallocated memory, and must add to the program size to allocate more.
  49.   If a window is resized frequently, the program tends to use huge amounts of
  50.   memory.
  51.   
  52.   If we initially allocate 3MB, and have a small window, we only touch the
  53.   memory space required by the zbuffer to cover the window, the untouched
  54.   pages never takes up any real memory, only page table entries.
  55.  
  56.   The 3MB will cover any window < screen size, if a program needs a larger
  57.   window, we allocate a 16MB space.
  58.  
  59. > Editorial side comment: SGI said that the extra allocation shouldn't make any
  60. > difference because it doesn't actually take up "real memory".  Of course,
  61. > this is due to SGI infamous sbrk (malloc) implementation, where you find out
  62. > that you have run out of virtual memory when you reference a pointer one too
  63. > many times and your program suddenly exits with no hope of recovering
  64. > gracefully (and professionally).  This feature is very popular with our
  65. > customers :-( .  To minimize the terrible side effects of that, we have our
  66. > own version of malloc that verifies enough virtual memory is available to
  67. > satisfy a call to sbrk, then it touches every page that has been added, so
  68. > that programmers will know when no more virtual memory is available and take
  69. > appropriate action.  As a result, our application is affected by the extra
  70. > allocation.
  71.  
  72.   Changing malloc's default behavior by touching every allocated page
  73.   defeats the scheme we used in the software zbuffer, forcing
  74.   the use of virtual memory in otherwise untouched pages.
  75.  
  76.   If you keep the size of your window to under 1023 x 766, you will use only
  77.   3MB. Since the software zbuffer uses some extra memory, a full 1024 x 768
  78.   window needs more than 3MB, and we allocate a 16MB space.
  79.   
  80.   What I can do to minimize the use of the 16MB allocation, is to change
  81.   the implementation to initially allocate the extra memory (approx. 32K
  82.   more than 3MB) so a full screen window will use the smaller allocation
  83.   size, but, sorry, you'll have to wait for the next release.
  84.  
  85. > -- Larry Grose / CAMAX Systems, Inc. / 612-854-5300 / grose@camax.com
  86.  
  87.  
  88.