VPro supports bitmap, CI, L, LA, RGB, RGBA, ABGR, BGRA, and YCrCB (through the subsample and YCrCb_format specification) in hardware. All color buffers are either single-, double-, or quad-buffered (stereo). The resolution and number of buffers is dependent on the amount of graphics memory. A 32MB system will not be able to do RGBA16 quad buffering.

The following formats are supported ^[3] :

Data Formats:

UNSIGNED_BYTE_3_3_2
UNSIGNED_BYTE_2_3_3_REV
UNSIGNED_BYTE_5_6_5
UNSIGNED_BYTE_5_6_5_REV
UNSIGNED_SHORT_4_4_4_4
UNSIGNED_SHORT_4_4_4_4_REV
UNSIGNED_SHORT_5_5_5_1
UNSIGNED_SHORT_1_5_5_5_REV
UNSIGNED_INT_8_8_8_8
UNSIGNED_INT_8_8_8_8_REV
UNSIGNED_INT_10_10_10_2
UNSIGNED_INT_10_10_10_2_REV

Framebuffer Formats:

R8
[]
, G8
4,B8
4, A8
4,
L8[]

I8
LA8
R3_G3_B2
5 
B2_G3_R3
5 
R5_G6_B5
5 
B5_G6_R5
5 
RGB8
5 
RGBA4
ABGR4
ARGB4
BGRA4
A1_RGB5
A1_BGR5
BGR5_A1
RGBA8
ABGR8
ARGB8
BGRA8
YCrCb_444(byte or ubyte)[]

YCrCb_422 (byte or ubyte)
6 
R16
4, G16
4, B16
4, A16
4 
R32
4, G32
4, B32
4, A32
4 
L16
5 
I16
LA16
RGB32
5 
RGBA32
4 
ABGR32
4 
RGB16
5 
RGB10_A2
A2_BGR10
BGR10_A2
A2_RGB10
RGBA12
ABGR12
RGBA16
ABGR16
YCrCb_422 (short or ushort)[]

L8, I8
CI8
L16, I16
CI12, CI16
L32
LA8
LA16
LA32
Bitmap
CI8
CI16
CI32

The OpenGL accumulation buffer is fully hardware-accelerated if the X server is configured to advertise hardware-accelerated accumulations buffers. VPro also supports an accumulation buffer within a pbuffer. Using setmon or xsetmon, you need to do configuration before X server startup time for either software accumulation or shallow hardware accumulation. The software accumulation buffer supports 16-bit precision per component RGBA and the hardware accumulation buffer can support 24-bit precision per component RGBA.

There is one single-buffered 8-bit overlay buffer.

There is one Z/stencil buffer_per_color_buffer_ for supported formats. The stencil and depth buffers are packed into one 4-byte value on reads and writes. Hence, requesting stencil does not add an additional memory hit over requesting only depth. However, since the stencil planes cannot be cleared using the hardware fast clear mode, it should not be requested as part of the visual unless it is going to be used. When using stencil and depth buffers, it is fastest to clear them both simultaneously.

The depth buffer is in eye space instead of the traditional screen space. Depth is calculated before the projection matrix, not afterwards. This allows greater precision in the depth buffer as the space is no longer non-linear due to the perspective divide. Depth buffer readback must be converted from eye space to screen space. Applications need to ensure that the depth buffer is cleared when changing the depth range and other depth buffer state operations.

Off-screen rendering areas are known as pbuffers. Pbuffers support all main buffer configurations including color (resolution and format), depth, stencil, and accumulation.

Pbuffers are allocated and destroyed through the fbconfig set of commands which become part of the GLX spec as of GLX 1.3. Based upon the video format loaded, buffer allocations are done statically when the X Server activates. Since pbuffers are allocated out of the on-board memory, pbuffer allocation can fail when graphics memory is depleted. This can happen if there are too many pbuffers, deep or wide main buffers (such as for dual-channel mode) or too many textures defined. VPro supports pbuffers as single-buffered entities only.

Two modes of stereo are supported: SGI full screen and quad-buffered.

Moving data between buffers is very fast since the buffer-to-buffer copy happens entirely on-board. No round trip to the host is required. Moving data between any buffer (color, depth, stencil, and accumulation) and texture objects is also very fast. Copying data from graphics memory to the host will run at a slower rate. Buffer copies can be accomplished by using the MakeCurrentRead GLX extension.

To optimize performance, use the native VPro formats to read and write data. Use this guideline to ensure that the host does not have to convert the data. The host must convert the data when reading and writing in GLfloat format or reading in GLint format.

All OpenGL 1.2 blending modes are supported to take incoming RGBA fragments and blend them into the existing framebuffer. Table 2-1describes VPro blending.

Of interest is a new blend extension, SGIX_BLEND_ALPHA_MINMAX, which is similar to the EXT_BLEND_MINMAX extension but uses the minmax comparison result of only the alpha channel to choose all the color components.

Texture memory is shared with the on-board framebuffer SDRAM. Since the texture memory size is not constant it is important to use the texture proxy mechanisms to find the maximum texture size.

The following internal texture formats are supported:

ALPHA4
ALPHA8
ALPHA12
ALPHA16
LUMINANCE4
LUMINANCE8
LUMINANCE12
LUMINANCE16
LUMINANCE4_ALPHA4
LUMINANCE6_ALPHA2
LUMINANCE8_ALPHA8
LUMINANCE12_ALPHA4
LUMINANCE12_ALPHA12
LUMINANCE16_ALPHA16
INTENSITY4
INTENSITY8
INTENSITY12
INTENSITY16
R3_G3_B2
RGB4
RGB5
RGB8
RGB10
RGB12
RGB16
RGBA2
RGBA4
RGB5_A1
RGBA8
RGB10_A2
RGBA12
RGBA16

Table 2-2 summarizes the VPro texture features:

The following qualifications apply:

Both Gouraud (per-vertex) and Phong shading (per-fragment) are supported in hardware. One single per-fragment light and eight per-vertex lights are supported in hardware. The per-fragment light and the per-vertex lights can be enabled simultaneously allowing a total of nine hardware-accelerated lights in a scene. A single light of each type is fastest. Each additional per-vertex light added will incrementally decrease performance. As with all of VPro, shading is done with 12-bit per-component resolution. Two-sided lighting, local lighting, local viewer, and the other standard OpenGL 1.2 lighting properties, are all implemented in hardware.

Use the rescale normal OpenGL 1.2 extension instead of NORMALIZE when introducing a scale into the model view matrix. Rescale normal is fully hardware-accelerated in the case where normalized normals are used with a scale in the model view matrix.

Shading is perspective-correct.

Point, line, and polygon AA is supported in hardware for both RGBA and CI visuals. Non-AA lines and points are supported in hardware up to a width of 10 with a very small incremental performance decrease for each additional width increment. AA points and lines are supported to a width of 2.0; AA widths above 2.0 will be clamped to 2.0. AA lines are hardware-accelerated, although the end caps will be French-cut, not AA. Full-scene AA will be supported using multi-pass to the hardware accumulation buffer.

Instrumentation is not yet implemented but will be supported in the future.

Texturing and user clip planes both use a shared hardware texturing resource. VPro supports six user clip planes. There are three hardware clip planes that are implemented using the texturing hardware. The remaining three of the total six are implemented in software. Each texture dimension that is enabled moves a hardware-accelerated user clip plane to software. For example, there is only a single hardware-accelerated user clip plane when 2D texturing is enabled.

Fast Path

Geometry rates are bounded primarily by the host-to-graphics download rate, although textured geometry can become fill-limited. VPro is efficient with short strips ( 4 to 5 triangles), although long strips are better since they help to reduce the amount of data downloaded. There are three methods of sending data to the VPro board: immediate mode, display lists, and vertex arrays. All geometry is pushed to the graphics board from the CPU while textures and pixels are transferred using a DMA engine.

Immediate-mode rendering pushes each vertex and associated vertex data to the graphics pipe through a function call. This is the slowest method to send data to the pipe. Display lists can pack all data into one list and send it to the pipe more efficiently. Geometry calls within an VPro display list are optimized on the host for more efficient rendering. Adding mode changes or other state manipulation commands to a display list will not affect the performance of the entire display list. This is a change from previous hardware, where certain commands in the display list would be a performance penalty. Additionally, system memory is used to hold all display lists. This ensures that display list performance does not vary with the number or size of display lists.

Vertex arrays also offer an efficient way to send data to the graphics pipe. Packed vertex arrays are fully hardware-accelerated, though slightly slower than display lists. Optimizations are implemented for the commonly used packed vertex arrays and for some of the common separate arrays. The separate arrays will always be slower than the packed arrays due to cache effects. Likewise, the glDrawElements() and glArrayElement() calls will be slower than the corresponding non- gl*Element() calls.

The following array formats are explicitly tuned:

V3F
N3F_V3F
N3S_V3F
V3F_N3F
C3F_V3F
T2F_V3F

Much of the VPro state is shadowed on the host. The OpenGL libraries will be able to determine if a state change actually changes hardware state without a need to flush the pipe and query the hardware. The state shadowing allows glGet* operations that occur outside of a glBegin/End pair, the equivalent set operations, and glEnables and glDisables to be very efficient for applications that do a lot of state manipulation. Matrix manipulations are also shadowed.

Color, Normal, and TexCoord calls are not shadowed, nor are the push and pop attribute calls. The glPushAttrib() and glPopAttrib() calls will be costly compared to a single state change. If possible, applications should carefully monitor and control their own state instead of pushing and popping attributes.

Buffer-to-buffer copies are fast as all buffers reside in on-board memory. This includes copies to and from pbuffers and textures. Pixel and texture data is transferred to the host by a DMA engine. There is hardware on-board to convert from an internal pixel format to an external pixel format; so, the format that is read or written is not important. When working with YCrCb and color conversions, the color matrix path will introduce a slight performance penalty.

Depth and stencil are stored in an internal floating-point format and packed together. Reading and writing depth and stencil buffers will be slower than the other buffers due to float conversions.

Pixel transfer speed will depend on the data types. The number of bytes transferred per pixel is shown in Table 2-3.

Data type conversions are done to any float format and readback of integer formats. ARGB and BGRA short and integer are host-converted unless they are one of the packed formats (for example, 10/10/10/2).

VPro supports the GL_SGIX_async and GL_SGIX_async_pixel set of extensions, which allow non-blocking texture and pixel reads and writes. This means that other graphics operations can proceed immediately after a texture load request. You must properly synchronize commands to guarantee that texture data is resident in the graphics memory before rendering of data using that texture begins.

7 x 7 convolutions will be done in hardware while larger convolutions require multi-pass rendering and will go slower. At some convolution sizes, the hardware speed is slower than a software convolve. The cutoff may be as low as 7 x 7 and is dependent on both kernel size and pixel depth.

There is no direct support for YCrCb format. However, VPro supports the subsample and resample extensions in hardware.

 VPro supports pixel textures (1D, 2D, and 3D) and a hardware accumulation buffer.