home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!sgiblab!sgigate!odin!fido!verite!billt
- From: billt@verite.esd.sgi.com (Bill Torzewski)
- Newsgroups: comp.sys.sgi.graphics
- Subject: Re: Software Z-buffer grabs too much memory
- Date: 4 Jan 1993 20:12:06 GMT
- Organization: Silicon Graphics, Inc. Mountain View, CA
- Lines: 79
- Message-ID: <1ia5mmINNjqe@fido.asd.sgi.com>
- References: <1992Dec31.202430.24500@camax.com>
- NNTP-Posting-Host: verite.esd.sgi.com
-
-
-
- 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
-
-
-