Rob Jenkins (robj++at++barney.reading.sgi.com)
Wed, 17 Apr 1996 17:19:57 +0100
you're forgetting the multisample buffers I think. 256 is the minimum ( with 1
RM4 board )
1 RM board: 1280x1024x256 deep , 48 bit FB,BB, 32bit Z, WIDs, CIDs etc,but no
multisamples
2 RM boards: 1280x1024x512 deep , 48 bit FB,BB and up to 8 multisamples
4 RM boards: 1280x1024x1024 deep, 48 bit FB,BB and up to 16 multisamples
and you're right - pretty impressive. I've attached a good Pipeline article
'Calculating RealityEngine Pixel Depth'
Cheers
Rob
-- ________________________________________________________________ Rob Jenkins, Software Support Group, Silicon Graphics UK Ltd. Forum 1, Station Road, Theale, Reading, UK, RG7 4SB. tel 01734 257736, fax 01734 257553, email robj++at++reading.sgi.com,
Calculating RealityEngine Pixel Depth
In September 1992, Silicon Graphics released another high performance graphics system known as RealityEngine. This graphics subsystem can be installed into DieHard or rack systems and is useable with both the R3000 and R4000 cpu family lines. During the design phase of the RealityEngine, two considerations were paramount: 1) antialiasing without penalty and 2) increased texture capabilities. This article will primarily address the topic of pixel depth, which impacts multi-sampling, RealityEngine's method of antialising.
In addition to these two items, other features have been added or enhanced. With the RealityEngine it is possible to have stereo on a per window basis. Another feature of this system is 12 bits per component of RGBA. In addition to increased textured performance, many capabilities have been added to the texture mapping set of functions, including three dimensional textures, fast hardware shadow algortihms and an increased number of texture filtering functions. There are also methods of sharpening textures for extreme magnification. Detail Texture is another method for looking at polygons up close. Texture lookup tables are available for greater control of the final output. For more information on texture mapping, see chapter 18 of the Graphics Library Programming Manual.
In the past, framebuffer* size and configurations have been fairly static. (*The term "framebuffer is often used inconsistently. It is best to think of each of the available bitplane sets as a seperate framebuffer, for example, overlay, underlay, popup, zbuffer, etc. The multisample buffer is another buffer assosciated with the normal buffer. For the purposes of this article, "framebuffer will refer to the normal buffer.) With the advent of the VGX, came increased flexibility in configuration. A bank of memory could be either used for accumulation buffering or additional texture memory. The RealityEngine introduces a framebuffer that is very flexible in attainable configurations. The GL programmer has more flexibility in making ordered and reasonable requests to the GL such that all requests will be honored. To fully utilize this flexibility, one must first understand the underlying concepts. (For a discussion on the multisample API, see the GL Programmers Guide, and the manual pages for mssize and multisample. Also see the Crimson and POWER Series technical reports for detailed information about the RE architecture. Also figure 1 below.)
Upon consulting these sources, you will notice that on occasion a requested configuration may not be granted. This is due to the amount GL resources that may be requested in contrast with the amount of hardware that is installed. When more resources are requested than are available, the GL will determine which requests will be honored. RealityEngine supports one, two, or four Raster Memory (RM) boards. Each RM board contains roughly 40MB of memory for framebuffer configurations. The final configuration of the framebuffer is determined by the video output Format (VOF) and GL resources such as multisampling, accumulation buffer, stencil, z-buffer, high resolution color, and buffer modes (single, double, stereo).
----------------------------------------- | GE Board | | | | ---- | | |-| |-| | | | | |--| | | | | MPG CP |-| |-| | T | | ___ ___ | |--| | | | |-->| |-->| |-->|-| |-|--->| | | --- --- | |--| | | B | | |-| |-| | U | | | |--| | | S | | |-| |-| | | | | |--| | | | | -| |- | | | ---- | | | | / \ | | / \ | | / \ | | / \ | | / \ | | | | ----------------------------- | | | --------- | | | | | i860XP | | | | | --------- -------- | | | | ^ | 2MB | | | | | |<------->| DRAM | | | | | | -------- | | | | v | | | | ------- | | | | | GEF | | | | | ------- | | | | | | | ----------------------------- | | Close-up of the GE | | | -----------------------------------------
Figure 1a. Reality Engine Architecture (GE Board)
---------------------------------------------- | RM Board | | | | | ----------------- | | | | | |-----| #--| | | | | |-->| #-#-#-#--| | |--->| | | T| | #--| | | P | | | ----------------- | | | B| | | B | | U| S 20 Spans | U | | S| | | S | | | ----------------- | | | | | |-----| #--| | | | | |-->| #-#-#-#--| | |--->| | | | | #--| | | | | | ----------------- | | | | | / \ | | / \ | | / \ | | / \ | | / \ | | --------------------------------------- | | | -------- | | | | ------------------- |IMP 0 |-->| | | | | | | -------- | | | | | --- --- --- --- | | | | | | |PG|--|TA|--|TD|--|IB|--> | | | | | --- --- --- --- | | | | | | | | | | | | | ------------ | | | | | | | 4MB DRAM | | | | | | ------------ | | | | | | ------- | | | | | |IMP 15|-->| | | | | ------- | | | --------------------------------------- | | Close-up of one span | | | ----------------------------------------------
Figure 1b. Reality Engine Architecture (RM Board)
---------------------------------------------------- | DG Board | | | | | ------- ------ | | | |--->| XMAP |--->| LUT |---> | ------- | | | -------- ------- |--|DAC's|====> | | | | | | |====> | | P| | ------- | | | | 10 XMAPS | --------- | | B| | |Digital| | | U| | |--| Video |--> | | S| | --------- | | | | | | | | -------- ------- | -------- | | |--->| XMAP |--->| LUT |---> |--|Comp. |---> | | | -------- ------- | |video | | | | -------- | | | ----------------------------------------------------
Figure 1c. Reality Engine Architecture (DG Board)
The ability of the GL to meet the requested modes is based upon the "depth" of its pixels, that is, the number of words that are available. To relate pixel depth to the ability to honor mode requests, consider the following example. If a framebuffer is 8 bit RGB, 8 bits times 3 channels is 24 bits, or 1.5 words. The normal buffer requires the use of 2 words whereas each multisample will actually only require the computed 1.5 words. If the framebuffer is double buffered, then 4 words are being utilized. RealityEngine provides for 12 bits per component as well. Using 12 bits per component, a single buffered RGB window requires 48 bits or 3 words. Putting the same window into double buffer mode now takes 6 words. Similarly the accumulation buffer can be configured to be either 12 or 24 bits per component, requiring 3 or 6 words respectively. The RealityEngine zbuffer is 32 bits- 2 more words. The stencil buffer requires an additional 1/2 word. When adding the total number of words, add 4 words for overhead (overlays, underlays, etc.).
-------------------------------------------------- | 8 Bit RGB, DBL Buf, 8 LoRes samples+ HW accbuf | | | | Add Words | | | | 4 w. overhead | | 2 w. Front Buffer | | 2 w. Back Buffer | | (1.5w.) 8 samples (color) | | (2 w.) 8 samples (Z) | | ____________________ | | 36 words (no room for HW accbub) | | | | * assume 1024x1280 | | | --------------------------------------------------
Figure 2. Word Requirement example
Using similar computations, the amount of memory required for multi-sampling can be computed. The multisample buffer can be configured to do 0, 4, 8, or 16 samples per pixel. To calculate the number of words per pixel for multisampling, multiply the number of samples requested by the number of words computed in the preceeding paragraph. To do 4 multisamples for a 12 bit RGB window requires 4 * (3 words RGBA + 2 words Z) + 3 words RGB normal buffer = 23 words. Add 3 more words if the window is doublebuffered. Similarly, an 8 bit RGB window requires 17 words for singlebuffer and 19 for doublebuffer. (Keep in mind the 4 words for overhead.) Notice in these examples no allocation of memory for stencil or accumulation buffers has been made. After calculating the number of words required, round up to 16, 32, or 64, as these are the number of words that are supported for pixel depths of small, medium, and large.
Using Tiles to Calculate Pixel Depth for VOF
The preceeding information shows how to calculate the pixel depth that is required for a group of GL mode requests. To determine how deep pixels can be for different VOFs, calculate the depth of the current VOF, by running /usr/gfx/gfxinfo which will return the current pixel depth. This depth can be altered by changing the VOF. The underlying mechanisms of adding depth to a pixel by changing the VOF have to do with the way the screen is tiled. A tile is a segment of screen space that is 80 pixels wide by 8 pixels high. Thus the default VOF of 1280x1024 is a screen that is 16x128 tiles. Putting the monitor into NTSC mode changes the screen resolution to 646x485, or 9x61 tiles. Notice that 646/80 = 8.075. Since all pixels must be covered and tiles come in integer quantities, we need to step up to get 9 tiles wide. Similarly PAL format is 768 x 575 (10 x 72 tiles) and HD TV is 1600 x 1200 (20 x 150 tiles).
--------------------------------- /| /| / | / | /__|____________________________/ | ^ | | | | | | | | | Width of VOF/80 * | | | | | X | | | | | Height of VOF/8 * Height | | |<- 80 -> | | | | |________ ^ | | | | / /| | 8 | | | | /|______/_|_V_________________|__| | |/_______/ / | / / | | / | / |/ 16 v |/_______|/_____________________/ / * Round up to nearest integer <-------------------------------> Width Figure 3. Tiles required by VOF
In addition to computing the number of tiles utilized by a given VOF, it is also necessary to compute how the memory from the RM boards can be distributed among the tiles, i.e., compute pixel depth. (For the purposes of this article and these computations, one word is 16 bits.) It is important to consider that you may be requesting more GL resources than are available, and how the VOF effects the request. For each RM board there are 12 80x1024X16 words. Using the default VOF of 1280x1024, with 1 RM board, there are only 16 words per pixel available. This is not enough memory to do the simple multisample example above. Either add an additional RM board to bring the total t o 32 words per pixel or we must change the VOF.
------------------------------------------------------------ | 12 bit RGBA (48 bits) 8 bit RGB (24 bits) | |Color Buffer 3 w (48 bits) 2 w (24 bits) | |Zbuffer 2 w (32 bits) 2 w (32 bits) | |Stencil 1 w ( 8 bits) 0.5 w (8 bits) | |AccBuf 3/6 w | |MS Color 3 w/sample 1.5 w/sample | |MSZ 2 w/sample 1 bit.sample | |Stencil .5 w/sample 1 bit.sample | | | |Overhead* 4 w 4 w | | | |* Overhead: WIDs, CIDs, PUP, Overlay, Underlay | | | ------------------------------------------------------------
Figure 4. HW Configuration Example
It may seem odd that changing the VOF could also change pixel depth. The previous tile examples showed how to compute the number of, tiles utilized by each VOF. In some of the examples, such as NTSC and PAL, fewer tiles are needed than are available. These extra tiles are then available to add to the pixel depth of the tiles that are used. The use of the extra tiles must be uniformly distributed over the screen area used, i.e. pixel depth for a given VOF must be uniformly 16, 32, or 64. To see if changing the VOF will increase pixel depth, take.the ratio of the total number of tiles (2048 per RM) to tiles required by the new VOF. Since this number must be 1, 2, or 4 (remember the GL only supports pixel depths of 16, 32 or 64), you need to floor the ratio to these numbers. Using the example of 1 RM board, the VOF can be changed to NTSC. Previously we calculated the number of tiles required by NTSC to be 549 tiles. The computed ratio is then 3.73. We must take the next lowest allowable integer value 2 to arrive at a pixel depth of 2*16, or 32 words per pixel. This is then sufficient to do the previous multisample example. Choosing a VOF that quartered the screen tiles exactly, would give a ratio 4. This would give a pixel depth of 4*16 or 64 words deep. Such a format could be 640x512 (8x64 tiles). Similarly, HDTV requires 3000 tiles. The ratio 2048/3000 < 1, hence HDTV can not be supported on a 1 RM system.
To predetermine whether your configuration request will be possible, do the following:
1) Use table 1 to calculate the number of words required by your application (ke ep in mind the 4 words of overhead).
2) Compute the available depth in words:
| # RMs * 2048 | floor(1,2,4) | ______________| * 16 | tiles in VOF |
3) Subtract the result of step 1 from step 2.
4) A positive result from step 3 is favorable. If the result is negative, you mu st:
A) back off on requested features (use getgconfig();)
B) add an RM board (or two)
C) lower VOF resolution even further.
There may be some configurations which will never be honored. This is the case anytime the required word count exceeds 64.
Calculating RealityEngine Pixel Depth
In September 1992, Silicon Graphics released another high performance graphics system known as RealityEngine. This graphics subsystem can be installed into DieHard or rack systems and is useable with both the R3000 and R4000 cpu family lines. During the design phase of the RealityEngine, two considerations were paramount: 1) antialiasing without penalty and 2) increased texture capabilities. This article will primarily address the topic of pixel depth, which impacts multi-sampling, RealityEngine's method of antialising.
In addition to these two items, other features have been added or enhanced. With the RealityEngine it is possible to have stereo on a per window basis. Another feature of this system is 12 bits per component of RGBA. In addition to increased textured performance, many capabilities have been added to the texture mapping set of functions, including three dimensional textures, fast hardware shadow algortihms and an increased number of texture filtering functions. There are also methods of sharpening textures for extreme magnification. Detail Texture is another method for looking at polygons up close. Texture lookup tables are available for greater control of the final output. For more information on texture mapping, see chapter 18 of the Graphics Library Programming Manual.
In the past, framebuffer* size and configurations have been fairly static. (*The term "framebuffer is often used inconsistently. It is best to think of each of the available bitplane sets as a seperate framebuffer, for example, overlay, underlay, popup, zbuffer, etc. The multisample buffer is another buffer assosciated with the normal buffer. For the purposes of this article, "framebuffer will refer to the normal buffer.) With the advent of the VGX, came increased flexibility in configuration. A bank of memory could be either used for accumulation buffering or additional texture memory. The RealityEngine introduces a framebuffer that is very flexible in attainable configurations. The GL programmer has more flexibility in making ordered and reasonable requests to the GL such that all requests will be honored. To fully utilize this flexibility, one must first understand the underlying concepts. (For a discussion on the multisample API, see the GL Programmers Guide, and the manual pages for mssize and multisample. Also see the Crimson and POWER Series technical reports for detailed information about the RE architecture. Also figure 1 below.)
Upon consulting these sources, you will notice that on occasion a requested configuration may not be granted. This is due to the amount GL resources that may be requested in contrast with the amount of hardware that is installed. When more resources are requested than are available, the GL will determine which requests will be honored. RealityEngine supports one, two, or four Raster Memory (RM) boards. Each RM board contains roughly 40MB of memory for framebuffer configurations. The final configuration of the framebuffer is determined by the video output Format (VOF) and GL resources such as multisampling, accumulation buffer, stencil, z-buffer, high resolution color, and buffer modes (single, double, stereo).
----------------------------------------- | GE Board | | | | ---- | | |-| |-| | | | | |--| | | | | MPG CP |-| |-| | T | | ___ ___ | |--| | | | |-->| |-->| |-->|-| |-|--->| | | --- --- | |--| | | B | | |-| |-| | U | | | |--| | | S | | |-| |-| | | | | |--| | | | | -| |- | | | ---- | | | | / \ | | / \ | | / \ | | / \ | | / \ | | | | ----------------------------- | | | --------- | | | | | i860XP | | | | | --------- -------- | | | | ^ | 2MB | | | | | |<------->| DRAM | | | | | | -------- | | | | v | | | | ------- | | | | | GEF | | | | | ------- | | | | | | | ----------------------------- | | Close-up of the GE | | | -----------------------------------------
Figure 1a. Reality Engine Architecture (GE Board)
---------------------------------------------- | RM Board | | | | | ----------------- | | | | | |-----| #--| | | | | |-->| #-#-#-#--| | |--->| | | T| | #--| | | P | | | ----------------- | | | B| | | B | | U| S 20 Spans | U | | S| | | S | | | ----------------- | | | | | |-----| #--| | | | | |-->| #-#-#-#--| | |--->| | | | | #--| | | | | | ----------------- | | | | | / \ | | / \ | | / \ | | / \ | | / \ | | --------------------------------------- | | | -------- | | | | ------------------- |IMP 0 |-->| | | | | | | -------- | | | | | --- --- --- --- | | | | | | |PG|--|TA|--|TD|--|IB|--> | | | | | --- --- --- --- | | | | | | | | | | | | | ------------ | | | | | | | 4MB DRAM | | | | | | ------------ | | | | | | ------- | | | | | |IMP 15|-->| | | | | ------- | | | --------------------------------------- | | Close-up of one span | | | ----------------------------------------------
Figure 1b. Reality Engine Architecture (RM Board)
---------------------------------------------------- | DG Board | | | | | ------- ------ | | | |--->| XMAP |--->| LUT |---> | ------- | | | -------- ------- |--|DAC's|====> | | | | | | |====> | | P| | ------- | | | | 10 XMAPS | --------- | | B| | |Digital| | | U| | |--| Video |--> | | S| | --------- | | | | | | | | -------- ------- | -------- | | |--->| XMAP |--->| LUT |---> |--|Comp. |---> | | | -------- ------- | |video | | | | -------- | | | ----------------------------------------------------
Figure 1c. Reality Engine Architecture (DG Board)
The ability of the GL to meet the requested modes is based upon the "depth" of its pixels, that is, the number of words that are available. To relate pixel depth to the ability to honor mode requests, consider the following example. If a framebuffer is 8 bit RGB, 8 bits times 3 channels is 24 bits, or 1.5 words. The normal buffer requires the use of 2 words whereas each multisample will actually only require the computed 1.5 words. If the framebuffer is double buffered, then 4 words are being utilized. RealityEngine provides for 12 bits per component as well. Using 12 bits per component, a single buffered RGB window requires 48 bits or 3 words. Putting the same window into double buffer mode now takes 6 words. Similarly the accumulation buffer can be configured to be either 12 or 24 bits per component, requiring 3 or 6 words respectively. The RealityEngine zbuffer is 32 bits- 2 more words. The stencil buffer requires an additional 1/2 word. When adding the total number of words, add 4 words for overhead (overlays, underlays, etc.).
-------------------------------------------------- | 8 Bit RGB, DBL Buf, 8 LoRes samples+ HW accbuf | | | | Add Words | | | | 4 w. overhead | | 2 w. Front Buffer | | 2 w. Back Buffer | | (1.5w.) 8 samples (color) | | (2 w.) 8 samples (Z) | | ____________________ | | 36 words (no room for HW accbub) | | | | * assume 1024x1280 | | | --------------------------------------------------
Figure 2. Word Requirement example
Using similar computations, the amount of memory required for multi-sampling can be computed. The multisample buffer can be configured to do 0, 4, 8, or 16 samples per pixel. To calculate the number of words per pixel for multisampling, multiply the number of samples requested by the number of words computed in the preceeding paragraph. To do 4 multisamples for a 12 bit RGB window requires 4 * (3 words RGBA + 2 words Z) + 3 words RGB normal buffer = 23 words. Add 3 more words if the window is doublebuffered. Similarly, an 8 bit RGB window requires 17 words for singlebuffer and 19 for doublebuffer. (Keep in mind the 4 words for overhead.) Notice in these examples no allocation of memory for stencil or accumulation buffers has been made. After calculating the number of words required, round up to 16, 32, or 64, as these are the number of words that are supported for pixel depths of small, medium, and large.
Using Tiles to Calculate Pixel Depth for VOF
The preceeding information shows how to calculate the pixel depth that is required for a group of GL mode requests. To determine how deep pixels can be for different VOFs, calculate the depth of the current VOF, by running /usr/gfx/gfxinfo which will return the current pixel depth. This depth can be altered by changing the VOF. The underlying mechanisms of adding depth to a pixel by changing the VOF have to do with the way the screen is tiled. A tile is a segment of screen space that is 80 pixels wide by 8 pixels high. Thus the default VOF of 1280x1024 is a screen that is 16x128 tiles. Putting the monitor into NTSC mode changes the screen resolution to 646x485, or 9x61 tiles. Notice that 646/80 = 8.075. Since all pixels must be covered and tiles come in integer quantities, we need to step up to get 9 tiles wide. Similarly PAL format is 768 x 575 (10 x 72 tiles) and HD TV is 1600 x 1200 (20 x 150 tiles).
--------------------------------- /| /| / | / | /__|____________________________/ | ^ | | | | | | | | | Width of VOF/80 * | | | | | X | | | | | Height of VOF/8 * Height | | |<- 80 -> | | | | |________ ^ | | | | / /| | 8 | | | | /|______/_|_V_________________|__| | |/_______/ / | / / | | / | / |/ 16 v |/_______|/_____________________/ / * Round up to nearest integer <-------------------------------> Width Figure 3. Tiles required by VOF
In addition to computing the number of tiles utilized by a given VOF, it is also necessary to compute how the memory from the RM boards can be distributed among the tiles, i.e., compute pixel depth. (For the purposes of this article and these computations, one word is 16 bits.) It is important to consider that you may be requesting more GL resources than are available, and how the VOF effects the request. For each RM board there are 12 80x1024X16 words. Using the default VOF of 1280x1024, with 1 RM board, there are only 16 words per pixel available. This is not enough memory to do the simple multisample example above. Either add an additional RM board to bring the total t o 32 words per pixel or we must change the VOF.
------------------------------------------------------------ | 12 bit RGBA (48 bits) 8 bit RGB (24 bits) | |Color Buffer 3 w (48 bits) 2 w (24 bits) | |Zbuffer 2 w (32 bits) 2 w (32 bits) | |Stencil 1 w ( 8 bits) 0.5 w (8 bits) | |AccBuf 3/6 w | |MS Color 3 w/sample 1.5 w/sample | |MSZ 2 w/sample 1 bit.sample | |Stencil .5 w/sample 1 bit.sample | | | |Overhead* 4 w 4 w | | | |* Overhead: WIDs, CIDs, PUP, Overlay, Underlay | | | ------------------------------------------------------------
Figure 4. HW Configuration Example
It may seem odd that changing the VOF could also change pixel depth. The previous tile examples showed how to compute the number of, tiles utilized by each VOF. In some of the examples, such as NTSC and PAL, fewer tiles are needed than are available. These extra tiles are then available to add to the pixel depth of the tiles that are used. The use of the extra tiles must be uniformly distributed over the screen area used, i.e. pixel depth for a given VOF must be uniformly 16, 32, or 64. To see if changing the VOF will increase pixel depth, take.the ratio of the total number of tiles (2048 per RM) to tiles required by the new VOF. Since this number must be 1, 2, or 4 (remember the GL only supports pixel depths of 16, 32 or 64), you need to floor the ratio to these numbers. Using the example of 1 RM board, the VOF can be changed to NTSC. Previously we calculated the number of tiles required by NTSC to be 549 tiles. The computed ratio is then 3.73. We must take the next lowest allowable integer value 2 to arrive at a pixel depth of 2*16, or 32 words per pixel. This is then sufficient to do the previous multisample example. Choosing a VOF that quartered the screen tiles exactly, would give a ratio 4. This would give a pixel depth of 4*16 or 64 words deep. Such a format could be 640x512 (8x64 tiles). Similarly, HDTV requires 3000 tiles. The ratio 2048/3000 < 1, hence HDTV can not be supported on a 1 RM system.
To predetermine whether your configuration request will be possible, do the following:
1) Use table 1 to calculate the number of words required by your application (ke ep in mind the 4 words of overhead).
2) Compute the available depth in words:
| # RMs * 2048 | floor(1,2,4) | ______________| * 16 | tiles in VOF |
3) Subtract the result of step 1 from step 2.
4) A positive result from step 3 is favorable. If the result is negative, you mu st:
A) back off on requested features (use getgconfig();)
B) add an RM board (or two)
C) lower VOF resolution even further.
There may be some configurations which will never be honored. This is the case anytime the required word count exceeds 64.
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:52:43 PDT