🚀 go-pugleaf

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.

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?

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.

I have re-created the problem with the following small program:

    #include <gl.h>

    main ()
    {
	prefposition (0, 1023, 0, 767),
	winopen ("zbuff");
	system ("ps -l");
	zbuffer (1);
	system ("ps -l");
	return (0);
    }

Running the program should show that the number of pages grows from 363 to
4459 (an increase of 16 Mb).  If you replace 767 with 766 and run it again,
the number of pages will grow to 1135 (an increase of just over 3 Mb).

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