🚀 go-pugleaf

In article <1992Dec31.202430.24500@camax.com>, grose@camax.com writes:
> We have an application that uses Z-buffering.  It creates one window that
> occupies the full screen (either 1280x1024 or 1024x768, depending on the
> graphics card being used).  The problem is the SGI Entry graphics card, which
> does software Z-buffering and has a screen resolution of 1024x768.  According
> to information from SGI back in the days when an Indigo was a Hollywood, we
> would expect GL to malloc approximately 3 Mb the first time our application
> does Z-buffering (1024 * 748 * 4 bytes for a 32-bit Z-buffer).  However, an
> Indigo Entry running IRIX 4.0.5A actually malloc's 16 Mb!  Since we don't
> have infinite swap space and RAM, this means that we run out of virtual
> memory much more quickly than we would expect to.

  Entry graphics allocates the software zbuffer in 2 sizes, 3MB or 16MB,
  3MB for windows 1023x766 (or so) or less, or 16MB for larger windows,
  for the maximum 2K x 2K viewport. Entry graphics requires that the zbuffer
  covers the entire viewport.

> 
> I logged a call to the TAC and the official answer is that this is a
> deliberately designed feature!  Apparently, GL allocates 3 Mb for "small"
> windows and 16 Mb for "large" windows, since it supports virtual windows up
> to 2K x 2K pixels, in order to avoid excessive realloc'ing (not
> unreasonable).  The problem is that a standard full screen window is
> considered a large window, while a slightly smaller one (1024x767) is
> considered a small window, thus needing only 3 Mb.  What in the world is the
> logic behind this? I would think that 1024x768 should be the largest small
> window, and anything bigger than that implies a virtual window, justifying
> the larger allocation.  Am I stuck with this?  Does anyone know any
> workarounds?

  We have found that if we allocate only enough zbuffer memory to cover
  a window, and the window is later resized larger, we'd have to deallocate
  and reallocate the zbuffer memory. Often, the size of the program then grows
  by the newly allocated space, and is not reduced by the deallocated space.
  I think this is because the memory allocation system can't defragment
  the deallocated memory, and must add to the program size to allocate more.
  If a window is resized frequently, the program tends to use huge amounts of
  memory.
  
  If we initially allocate 3MB, and have a small window, we only touch the
  memory space required by the zbuffer to cover the window, the untouched
  pages never takes up any real memory, only page table entries.

  The 3MB will cover any window < screen size, if a program needs a larger
  window, we allocate a 16MB space.

> 
> Editorial side comment: SGI said that the extra allocation shouldn't make any
> difference because it doesn't actually take up "real memory".  Of course,
> this is due to SGI infamous sbrk (malloc) implementation, where you find out
> that you have run out of virtual memory when you reference a pointer one too
> many times and your program suddenly exits with no hope of recovering
> gracefully (and professionally).  This feature is very popular with our
> customers :-( .  To minimize the terrible side effects of that, we have our
> own version of malloc that verifies enough virtual memory is available to
> satisfy a call to sbrk, then it touches every page that has been added, so
> that programmers will know when no more virtual memory is available and take
> appropriate action.  As a result, our application is affected by the extra
> allocation.

  Changing malloc's default behavior by touching every allocated page
  defeats the scheme we used in the software zbuffer, forcing
  the use of virtual memory in otherwise untouched pages.

  If you keep the size of your window to under 1023 x 766, you will use only
  3MB. Since the software zbuffer uses some extra memory, a full 1024 x 768
  window needs more than 3MB, and we allocate a 16MB space.
  
  What I can do to minimize the use of the 16MB allocation, is to change
  the implementation to initially allocate the extra memory (approx. 32K
  more than 3MB) so a full screen window will use the smaller allocation
  size, but, sorry, you'll have to wait for the next release.

> 
> -- Larry Grose / CAMAX Systems, Inc. / 612-854-5300 / grose@camax.com