Glide manages several logical hardware graphics buffers, all of which are based out of the same area of memory known as the “frame buffer”. Depending on the amount of memory installed on the hardware,
the frame buffer is typically arranged as three logical units:

the front buffer,

the back buffer and,

optionally, the auxiliary buffer.

grRenderBuffer() selects the buffer for primitive drawing and buffer clears.
Valid values are

GR_BUFFER_FRONTBUFFER and

GR_BUFFER_BACKBUFFER;  [default]

The auxiliary buffer in a Voodoo Graphics subsystem can be used either as a :

• depth buffer,
• an alpha buffer, or as
• a third rendering buffer for triple buffering.

The auxiliary buffer is not available on systems with 2MB of frame buffer DRAM running at 800x600. However, it is always available on systems with 4 MB of frame buffer DRAM installed or with the screen resolution set to 640x480.

Triple buffering allows an application to continue rendering even when a swap buffer command is pending. When triple buffering is enabled an application can act as if the hardware is operating in double buffer mode; intricacies of dealing with the third buffer are hidden from the application by the hardware. Since the auxiliary buffer can serve only a single use, depth buffering, alpha buffering, and triple buffering are mutually exclusive.

An application selects the purpose of the auxiliary buffer implicitly whenever depth buffering, alpha buffering, or triple buffering are enabled.

For example, if grDepthBufferMode() is called with a parameter other than GR_DEPTHBUFFER_DISABLE ( see Chapter 7 ), it is assumed that the auxiliary buffer will be used for depth buffering. Similarly, grSstWinOpen() enables triple buffering; alpha buffering is enabled if grAlphaBlendFunction() selects a destination alpha blending factor (see Chapter 6) or grColorMask() enables writes to the alpha buffer. The release build of Glide does not check for contention of the auxiliary buffer. Unexpected results may occur if the auxiliary buffer is used for more that one function (e.g. both depth buffering and triple buffering are enabled). The debugging version of the library will report the contention.

Note : that source alpha blending can coexist with depth or triple buffering, but destination alpha blending cannot.

Table 3.2 Frame buffer resolution and configuration.
The frame buffer can be configured with two or three rendering buffers. In double buffer modes, an alpha or depth buffer can also be used. The available resolution depends on the amount of installed memory.

Logical Layout of the Linear Frame Buffer

The frame buffer is logically organized as 1024 scanlines (a 1024x1024 array) of 16 or 32-bit values, regardless of the amount of memory installed on the board, and is shown in Figure 3.2. Scan-line size is independent of screen resolution and is always 1024 pixels wide. The stride is returned in the GrLfbInfo_t structure, as described in Chapter 11. The data format within the frame buffer is programmable and is described in detail in Chapter 11.

Figure 3.2 Logical layout of the linear frame buffer.
The frame buffer is logically organized as 1024 scanlines (a 1024x1024 array) of 16 or 32-bit values, regardless of the amount of memory installed on the board and the screen resolution. The drawable area is a rectangular subset of the frame buffer; its location depends on the location of the y origin. The remainder of the board's memory (shaded area) is used as an auxiliary buffer that can be utilized as an alpha/depth buffer or as a third display buffer (triple buffering). This logical layout is independent of the user specified origin location.