xref: /third_party/openGLES/extensions/SGIX/SGIX_pixel_tiles.txt (revision 5bd8dead)

XXX - Not complete yet!!!

Name

    SGIX_pixel_tiles

Name Strings

    GL_SGIX_pixel_tiles

Version

    $Date: 1995/07/27 17:34:55 $ $Revision: 1.3 $

Number

    46

Dependencies

    EXT_texture3D affects the definition of this extension
    EXT_subtexture affects the definition of this extension
    EXT_convolution is required
    EXT_texture4D affects the definition of this extension

Overview

    This extension deals with the interaction of existing GL functions that
    read pixels from memory, applications that use grids of tiles of pixels, 
    and convolution.

    Applications that deal with large multi-dimensional images sometimes
    break the image into a grid of rectangular tiles of pixels. Such an
    approach can help control memory use and expedite roaming through an 
    image that is large with respect to the available memory. 

    GL functions that cause pixels to be read from memory (e.g., DrawPixels 
    and TexImage2D) assume the pixels are stored as a single series of rows
    of pixels. The grid of tiles is essentially a sequence of the structures
    that the pixel reading functions assume. When an application that uses
    tiling uses a GL function such as DrawPixels, it must iterate
    through the tiles, either coalescing the tiles into a single tile in
    preparation for a single GL call or calling the GL function for each tile.

    The convolution operation imposes strict ordering on the way pixels
    in a subimage that crosses tile boundaries must be transferred: the rows 
    of pixels transferred must span the entire subimage. Applications 
    that use tiles of pixels and convolution must copy the subimage to be 
    transferred from the grid of tiles to a contiguous region, then pass the
    now-contiguous rows of pixels to the convolution function. If the
    coalescing of tiles is not needed for some other reason or is not a 
    side effect of some necessary operation, it is just redundant movement 
    of the pixels.

    This extension seeks to eliminate the extra copy of data by extending the 
    existing GL functions to accept, as a source of pixels in memory, a 
    grid of tiles of pixels in addition to the current sequence of rows 
    of pixels.

    
Issues

    * This extension is currently defined for 1 to 4 dimensions. Convolution 
      is the driving force for this extension, yet is defined for only 1 and 
      2 dimensions. Should we remove support in this extension for 3 and 4
      dimensions (until it exists in a convolution extension)? Should we
      consider confining the extension to only 2 dimensions?

    * We anticipate accelerators for moving pixels around in various
      implementations. What is the right way to communicate information
      between an application and the underlying acceleration
      code/hardware? We believe that memory alignment will be important, 
      as will some sort of caching. What else should be considered?
      Are there better ways to express the information?

    * gluScaleImage, gluBuild1DMipmaps, and gluBuild2DMipmaps could be
      handled similarly in an associated extension. Should this happen?

    * Should EXT_color_table affect this extension? It does have some
      DrawPixel-like semantics.

Reasoning

    * It is desirable to try to accelerate the GL pixel transfer operations 
      with special hardware or highly optimized code. Imaging applications 
      tend to lose the intended benefit of these optimizations in cases where 
      tiles of pixels are used; significant amounts of time are spent 
      repackaging data to correspond to the GL model and comply with the 
      constraints of convolution. Since support for imaging applications was 
      a primary impetus for the convolution extension, it seems appropriate 
      to extend the model of pixel storage to also support imaging 
      applications.

    * For symmetry in the GL interface it would be reasonable to have 
      this extension cover the storage layout of both source and destination
      pixels. The assymmetry exists because we are only concerned with 
      sources that will be undergoing convolution. A tiled destination 
      that results from convolution can be filled tile by tile.
    
    * All the state in this extension is located in the client side. This
      helps constrain the scope of the extension. No GLX protocol or server
      side changes need to be made.

New Procedures and Functions

    None

New Tokens

    Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
    GetFloatv, and GetDoublev:

        PIXEL_TILE_BEST_ALIGNMENT_SGIX
        PIXEL_TILE_CACHE_INCREMENT_SGIX

    Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
    GetFloatv, GetDoublev, PixelStoref, and PixelStorei:

        PIXEL_TILE_WIDTH_SGIX
        PIXEL_TILE_HEIGHT_SGIX
        PIXEL_TILE_GRID_WIDTH_SGIX
        PIXEL_TILE_GRID_HEIGHT_SGIX
        PIXEL_TILE_GRID_DEPTH_SGIX
        PIXEL_TILE_CACHE_SIZE_SGIX

Additions to Chapter 2 of the 1.0 Specification (OpenGL Operation)

    None

Additions to Chapter 3 of the 1.0 Specification (Rasterization)

    The pixel storage modes are augmented to support 3D and 4D image formats 
    in memory as well as this extension. Table 3.1 is replaced with the table 
    below:

        Parameter Name               Type        Initial Value   Valid Range
        --------------               ----        -------------   -----------
        UNPACK_SWAP_BYTES            boolean     FALSE           TRUE/FALSE
        UNPACK_LSB_FIRST             boolean     FALSE           TRUE/FALSE
        UNPACK_ROW_LENGTH            integer     0               [0, infinity]
        UNPACK_SKIP_ROWS             integer     0               [0, infinity]
        UNPACK_SKIP_PIXELS           integer     0               [0, infinity]
        UNPACK_ALIGNMENT             integer     4               1, 2, 4, 8
        UNPACK_IMAGE_HEIGHT_EXT      integer     0               [0, infinity]
        UNPACK_SKIP_IMAGES_EXT       integer     0               [0, infinity]
        UNPACK_IMAGE_DEPTH_SGIS      integer     0               [0, infinity]
        UNPACK_SKIP_VOLUMES_SGIS     integer     0               [0, infinity]
        PIXEL_TILE_WIDTH_SGIX        integer     0               [0, infinity]
        PIXEL_TILE_HEIGHT_SGIX       integer     0               [0, infinity]
        PIXEL_TILE_GRID_WIDTH_SGIX   integer     0               [0, infinity]
        PIXEL_TILE_GRID_HEIGHT_SGIX  integer     0               [0, infinity]
        PIXEL_TILE_GRID_DEPTH_SGIX   integer     0               [0, infinity]
        PIXEL_TILE_CACHE_SIZE_SGIX   integer     impl. dep.      [0, infinity]

        Table 3.1: PixelStore parameters pertaining to one or more of
        DrawPixels, TexImage1D, TexImage2D, TexImage3DEXT, TexImage4DSGIS,
        TexSubImage1DEXT, TexSubImage2DEXT, TexSubImage3DEXT, and
        TexSubImage4DSGIS.

    Section 3.6.3, starting with the third paragraph in the UNPACKING
    section and continuing to the paragraph beginning with "Calling 
    DrawPixels with a type of BITMAP" is changed to read:

    Groups held in memory as the source for a transfer operation can
    be in one of two formats: as groups arranged in a single rectangle, or 
    as groups arranged in a grid of rectangles (or tiles). The method of
    storage is indicated by the state of PIXEL_TILE_GRID_WIDTH_SGIX. If 
    PIXEL_TILE_GRID_WIDTH_SGIX is greater than 0, the image is contained in 
    a grid of tiles. If less than or equal to 0, the source is a single 
    rectangle.

    UNPACKING A SINGLE RECTANGLE
    ============================

    When groups in memory are treated as being arranged in a rectangle, the
    rectangle consists of a series of rows, with the first element of the
    first group of the first row pointed to by the pointer passed to
    DrawPixels. If the value of UNPACK_ROW_LENGTH is not positive, then the
    number of groups in a row is width; otherwise the number of groups is
    UNPACK_ROW_LENGTH. If the first element of a row is at location p in 
    memory, then the location of the first element of the Nth row is obtained
    by skipping

                              p + Nk

    where N is the row number (counting from zero) and k is defined as

                             / nl                   s>=a,
                        k = <
                             \ a/s ceiling(snl/a)   s<a

    where n is the number of elements in a group, l is the number of groups 
    in the row, a is the value of UNPACK_ALIGNMENT, and s is the size, in
    units of GL ubytes, of an element. If the number of bits per element
    is not 1, 2, 4, or 8 times the number of bits in a GL ubyte, then 
    k = nl for all values of a.

    There is a mechanism for selecting a subrectangle of groups from a 
    larger containing rectangle. This mechanism relies on three integer
    parameters: UNPACK_ROW_LENGTH, UNPACK_SKIP_ROWS, and UNPACK_SKIP_PIXELS.
    Before obtaining the first group from memory, the pointer supplied to 
    DrawPixels is effectively advanced by (UNPACK_SKIP_PIXELS)n + 
    (UNPACK_SKIP_ROWS)k elements. Then width groups are obtained from 
    contiguous elements in memory (without advancing the pointer), after
    which the pointer is advanced by k elements. height sets of width groups
    of values are obtained this way. See Figure 3.8.


    UNPACKING PIXEL TILES
    =====================

                    |<- TW ->|
                    |<---------- Grid Width ----------->|

            --  --  +--------+--------+--------+--------+
            G       |        |        |        |        |
            r   TH  |      +-+--------+--------+--+     |
            i       |t8    | |t9      |t10     |t11     |
            d   --  +------+-+--------+--------+--+-----+
                    |      | |        |        |  |     |
            H       |      | |        |        |  |     |
            e       |t4    | |t5      |t6      |t7|     |
            i       +------+-+--------+--------+--+-----+
            g       |      | |        |        |  |     |
            h   --  |<-SP->+-+--------+--------+--+     |
            t   SR  |t0      |t1      |t2      |t3      |
            --  --  +--------+--------+--------+--------+

      Figure 3.8.a???. Selecting a subimage from a tiled image source.
                  TW -> PIXEL_TILE_WIDTH_SGIX
                  TH -> PIXEL_TILE_HEIGHT_SGIX
                  SR -> UNPACK_SKIP_ROWS
                  SP -> UNPACK_SKIP_PIXELS
                  Grid Width  -> PIXEL_TILE_GRID_WIDTH_SGIX
                  Grid Height -> PIXEL_TILE_GRID_HEIGHT_SGIX


    When groups are held in memory as a grid of tiles, the image rectangle 
    consists of a series of rows of rectangular tiles. See Figure 3.8.a???. 
    Each tile consists of a series of tile rows. A row of the image will
    cross all tiles in a row of the grid. Unlike the single rectangle 
    method for holding groups in memory, the number of groups in a row of 
    the tiled image is defined as PIXEL_TILE_WIDTH_SGIX * 
    PIXEL_TILE_GRID_WIDTH_SGIX, where PIXEL_TILE_WIDTH_SGIX is the number
    of groups in a row of a single tile and PIXEL_TILE_GRID_WIDTH_SGIX is
    the number of tiles in the width of the image. UNPACK_ROW_LENGTH is 
    ignored when using pixel tiles.

    Groups are arranged within a single tile exactly as described above for
    groups arranged in a single rectangle. The computation of the 
    starting address of a row within a tile is also the same. The method
    for computing the starting address of a row in the image is to first 
    establish the row of tiles in the grid containing the row of groups in 
    the image, then to locate the address of the row within the tile. The 
    index of the first tile that contains the row can be computed as:

                             index = n * floor(r/h)

    where index is the (0-based) index of the tile, n is the number of tiles
    across the image, PIXEL_TILE_GRID_WIDTH_SGIX, r is the (0-based) group
    row number, and h is the number of rows per tile, PIXEL_TILE_HEIGHT_SGIX.
    The starting address within each of the tiles in the row across the 
    image is computed as defined in the simple rectangle case, but using a 
    row number that is the original row number modulo the number of rows 
    per tile, PIXEL_TILE_HEIGHT_SGIX.
    
    That groups are being held in memory as a grid of tiles is indicated 
    by PIXEL_TILE_GRID_WIDTH_SGIX containing a value greater than 0.
    The <pixels> parameter of DrawPixels, TexImage1D, TexImage2D, 
    TexImage3DEXT, TexImage4DSGIS, TexSubImage1DEXT, TexSubImage2DEXT, 
    TexSubImage3DEXT, or TexSubImage4DSGIS is a pointer to a vector of 
    starting addresses for each of the tiles. 

    When transferring a subimage from the grid of tiles, a complete row of
    groups crossing the entire subimage is transferred before the first
    group of the next subimage row is transferred. Thus, for a subimage that
    crosses tiles, the sequence of groups transferred will be 
    indistinguishable from the sequence that would have occurred had the 
    subimage been taken from a simple rectangular image. 
 
    For 1-dimensional transfers, such as those of TexImage1D, and
    TexSubImage1DEXT, PIXEL_TILE_GRID_WIDTH_SGIX must be set to a non-zero
    positive value indicating pixel tiles are being used and
    PIXEL_TILE_WIDTH_SGIX must be set to a positive value indicating the 
    tile width.

    For 2-dimensional transfers, such as those of DrawPixels, TexImage2D, and
    TexSubImage2DEXT, PIXEL_TILE_GRID_WIDTH_SGIX must be set to a non-zero
    positive value indicating both that pixel tiles are being used and the 
    number of tiles in width of the image. PIXEL_TILE_WIDTH_SGIX and 
    PIXEL_TILE_HEIGHT_SGIX must be set to positive values indicating 
    the tile width and height (in groups), respectively.

    3-dimensional transfers, such as those of TexImage3DEXT and 
    TexSubImage3DEXT, additionally require the specification of a 
    positive value for PIXEL_TILE_GRID_HEIGHT_SGIX. The value of 
    UNPACK_IMAGE_HEIGHT_EXT is ignored. A 3-dimensional space is stored as
    a series of 2-dimensional images. The index of the first tile in the
    Nth image is N * PIXEL_TILE_GRID_WIDTH_SGIX * 
    PIXEL_TILE_GRID_HEIGHT_SGIX.

    4-dimensional transfers, such as those of  TexImage4DSGIS and
    TexSubImage4DSGIS, additionally require the specification of a 
    positive value for PIXEL_TILE_GRID_DEPTH_SGIX. The value of 
    UNPACK_IMAGE_DEPTH_SGIS is ignored. The 4-dimensional space is stored as
    a series of 3-dimensional volumes. The index of the first tile in the
    Nth volume is N * PIXEL_TILE_GRID_WIDTH_SGIX * 
    PIXEL_TILE_GRID_HEIGHT_SGIX * PIXEL_TILE_GRID_DEPTH_SGIX.

    Some implementation-dependent pixel storage state is included to help
    accelerate pixel transfers. PIXEL_TILE_BEST_ALIGNMENT_SGIX provides
    the optimal memory alignment for the starting address of pixel tiles. 
    Anticipated acceleration schemes depend on the caching of information
    from previous transfers to try to accelerate new transfers. The
    particular resource needed to accelerate the transfer (e.g., locked
    user memory) may be limited or particularly valuable to a user.
    Two pixel store values, PIXEL_TILE_CACHE_INCREMENT_SGIX and 
    PIXEL_TILE_CACHE_SIZE_SGIX, are provided to give the user some control
    over the amount of the resource in use. PIXEL_TILE_CACHE_SIZE_SGIX is
    a variable that indicates the current amount of the caching resource in 
    use. It is settable to some set of discrete values. If the user attempts 
    to set PIXEL_TILE_CACHE_SIZE_SGIX to some value that is not in the set, 
    the variable will actually be set to the nearest acceptable value. Setting
    the variable to 0 will turn any caching off and release the resource.
    PIXEL_TILE_CACHE_INCREMENT_SGIX is a gettable value that indicates the
    approximate change in cache size from the current value to the next 
    larger acceptable value.    

    BITMAP
    ======

Additions to Chapter 4 of the 1.0 Specification (Per-Fragment Operations
and the Framebuffer)

    None

Additions to Chapter 5 of the 1.0 Specification (Special Functions)

    None

Additions to Chapter 6 of the 1.0 Specification (State and State Requests)

    None

Additions to the GLX Specification

    None

Dependencies on EXT_texture3D

    If EXT_texture3D is not supported, this extension does not support 3
    and 4 dimensions, all discussion of 3 and 4 dimensions is void, references
    to the function TexImage3DEXT are removed, and the following tokens are 
    no longer defined:

        PIXEL_TILE_GRID_HEIGHT_SGIX
        PIXEL_TILE_GRID_DEPTH_SGIX

Dependencies on EXT_subtexture

    If EXT_subtexture is not supported, references to TexSubImage1DEXT, 
    TexSubImage2DEXT, and TexSubImage3DEXT are removed from this extension.

Dependencies on EXT_convolution

    This extension requires EXT_convolution. If the EXT_convolution is
    not supported, this extension is unnecessary.

Dependencies on EXT_texture4D

    If EXT_texture4D is not supported, this extension does not support 4
    dimensions, all discussion of 4 dimensions is void, references to the
    functions TexImage4DSGIS and TexSubImage4DSGIS are removed, and the 
    following token is no longer defined:

        PIXEL_TILE_GRID_DEPTH_SGIX

GLX Protocol

    None

Errors

    GL_INVALID_OPERATION is generated by DrawPixels, TexImage1D, TexImage2D, 
    TexImage3DEXT, TexImage4DSGIS, TexSubImage1DEXT, TexSubImage2DEXT, 
    TexSubImage3DEXT, or TexSubImage4DSGIS if the groups are to be read from
    pixel tiles and the specified size of the grid of pixel tiles is 
    insufficient to hold the specified subimage.

New State

    Get Value                           Get Command     Type    Value   Attrib
    ---------                           -----------     ----    ------- ------
    PIXEL_TILE_WIDTH_SGIX		GetIntegerv     Z+      0       client
    PIXEL_TILE_HEIGHT_SGIX		GetIntegerv     Z+      0       client
    PIXEL_TILE_GRID_WIDTH_SGIX		GetIntegerv     Z+      0       client
    PIXEL_TILE_GRID_HEIGHT_SGIX		GetIntegerv     Z+      0       client
    PIXEL_TILE_GRID_DEPTH_SGIX		GetIntegerv     Z+      0       client
 
New Implementation Dependent State

    Get Value                           Get Command     Type    Attrib
    ---------                           -----------     ----    ------
    PIXEL_TILE_BEST_ALIGNMENT_SGIX      GetIntegerv     Z+      client
    PIXEL_TILE_CACHE_INCREMENT_SGIX     GetIntegerv     Z+      client
    PIXEL_TILE_CACHE_SIZE_SGIX          GetIntegerv     Z+      client