• No results found

Transfer of Pixel Rectangles

In document glspec31.20090324.pdf (Page 116-128)

3.7 Pixel Rectangles

3.7.2 Transfer of Pixel Rectangles

The process of transferring pixels encoded in buffer object or client memory is diagrammed in figure3.4. We describe the stages of this process in the order in which they occur.

Commands accepting or returning pixel rectangles take the following argu- ments (as well as additional arguments specific to their function):

formatis a symbolic constant indicating what the values in memory represent.

widthandheightare the width and height, respectively, of the pixel rectangle to be transferred.

data refers to the data to be drawn. These data are represented with one of several GL data types, specified bytype. The correspondence between thetype

3.7. PIXEL RECTANGLES 104

Unpack byte, short, int, float, or packed

pixel component data stream

Convert to Float

Expansion to RGBA RGBA pixel data out

Pixel Storage Operations

Figure 3.4. Transfer of pixel rectangles to the GL. Output is RGBA pixels. Depth and stencil pixel paths are not shown.

3.7. PIXEL RECTANGLES 105

Not all combinations of format and type are valid. If for-

mat is DEPTH STENCIL and type is not UNSIGNED INT 24 8 or

FLOAT 32 UNSIGNED INT 24 8 REV, then the error INVALID ENUM occurs. Ifformatis one of the integer component formats as defined in table3.3andtype

is FLOAT, the error INVALID ENUM occurs. Some additional constraints on the combinations of format and type values that are accepted are discussed below. Additional restrictions may be imposed by specific commands.

Unpacking

Data are taken from the currently bound pixel unpack buffer or client memory as a sequence of signed or unsigned bytes (GL data typesbyteandubyte), signed or unsigned short integers (GL data typesshortandushort), signed or unsigned integers (GL data typesint anduint), or floating point values (GL data types

halfandfloat). These elements are grouped into sets of one, two, three, or four values, depending on theformat, to form a group. Table3.3summarizes the format of groups obtained from memory; it also indicates those formats that yield indices and those that yield floating-point or integer components.

If a pixel unpack buffer is bound (as indicated by a non-zero value of

PIXEL UNPACK BUFFER BINDING),datais an offset into the pixel unpack buffer and the pixels are unpacked from the buffer relative to this offset; otherwise,datais a pointer to client memory and the pixels are unpacked from client memory relative to the pointer. If a pixel unpack buffer object is bound and unpacking the pixel data according to the process described below would access memory beyond the size of the pixel unpack buffer’s memory size, anINVALID OPERATIONerror results. If a pixel unpack buffer object is bound anddatais not evenly divisible by the number of basic machine units needed to store in memory the corresponding GL data type from table3.2for thetypeparameter, anINVALID OPERATIONerror results.

By default the values of each GL data type are interpreted as they would be specified in the language of the client’s GL binding. IfUNPACK SWAP BYTES is enabled, however, then the values are interpreted with the bit orderings modified as per table3.4. The modified bit orderings are defined only if the GL data type

ubytehas eight bits, and then for each specific GL data type only if that type is represented with 8, 16, or 32 bits.

The groups in memory are treated as being arranged in a rectangle. This rect- angle consists of a series ofrows, with the first element of the first group of the first row pointed to bydata. If the value ofUNPACK ROW LENGTHis not positive, then the number of groups in a row iswidth; otherwise the number of groups is

3.7. PIXEL RECTANGLES 106

typeParameter Corresponding Special

Token Name GL Data Type Interpretation

UNSIGNED BYTE ubyte No

BYTE byte No

UNSIGNED SHORT ushort No

SHORT short No

UNSIGNED INT uint No

INT int No

HALF FLOAT half No

FLOAT float No

UNSIGNED BYTE 3 3 2 ubyte Yes

UNSIGNED BYTE 2 3 3 REV ubyte Yes

UNSIGNED SHORT 5 6 5 ushort Yes

UNSIGNED SHORT 5 6 5 REV ushort Yes

UNSIGNED SHORT 4 4 4 4 ushort Yes

UNSIGNED SHORT 4 4 4 4 REV ushort Yes

UNSIGNED SHORT 5 5 5 1 ushort Yes

UNSIGNED SHORT 1 5 5 5 REV ushort Yes

UNSIGNED INT 8 8 8 8 uint Yes

UNSIGNED INT 8 8 8 8 REV uint Yes

UNSIGNED INT 10 10 10 2 uint Yes

UNSIGNED INT 2 10 10 10 REV uint Yes

UNSIGNED INT 24 8 uint Yes

UNSIGNED INT 10F 11F 11F REV uint Yes

UNSIGNED INT 5 9 9 9 REV uint Yes

FLOAT 32 UNSIGNED INT 24 8 REV n/a Yes

Table 3.2: Pixel datatypeparameter values and the corresponding GL data types. Refer to table 2.2 for definitions of GL data types. Special interpretations are described near the end of section3.5.

3.7. PIXEL RECTANGLES 107

Format Name Element Meaning and Order Target Buffer

STENCIL INDEX Stencil Index Stencil

DEPTH COMPONENT Depth Depth

DEPTH STENCIL Depth and Stencil Index Depth and Stencil

RED R Color GREEN G Color BLUE B Color RG R, G Color RGB R, G, B Color RGBA R, G, B, A Color BGR B, G, R Color BGRA B, G, R, A Color

RED INTEGER iR Color

GREEN INTEGER iG Color

BLUE INTEGER iB Color

RG INTEGER iR, iG Color

RGB INTEGER iR, iG, iB Color

RGBA INTEGER iR, iG, iB, iA Color

BGR INTEGER iB, iG, iR Color

BGRA INTEGER iB, iG, iR, iA Color

Table 3.3: Pixel data formats. The second column gives a description of and the number and order of elements in a group. Unless specified as an index, formats yield components. Components are floating-point unless prefixed with the letter ’i’, which indicates they are integer.

Element Size Default Bit Ordering Modified Bit Ordering

8 bit [7..0] [7..0]

16 bit [15..0] [7..0][15..8]

32 bit [31..0] [7..0][15..8][23..16][31..24]

Table 3.4: Bit ordering modification of elements when UNPACK SWAP BYTES is enabled. These reorderings are defined only when GL data typeubytehas 8 bits, and then only for GL data types with 8, 16, or 32 bits. Bit 0 is the least significant.

3.7. PIXEL RECTANGLES 108

SKIP_ROWS SKIP_PIXELS

ROW_LENGTH

subimage

Figure 3.5. Selecting a subimage from an image. The indicated parameter names are prefixed byUNPACK forTexImage*and byPACK forReadPixels.

the first row, then the first element of theNth row is indicated by

p+N k (3.14)

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

k=

nl s≥a,

a/sdsnl/ae s < a (3.15)

where nis the number of elements in a group, l is the number of groups in the row, ais the value ofUNPACK ALIGNMENT, andsis the size, in units of GL

ubytes, of an element. If the number of bits per element is not1,2,4, or8times the number of bits in a GLubyte, thenk=nlfor all values ofa.

There is a mechanism for selecting a sub-rectangle of groups from a larger containing rectangle. This mechanism relies on three integer parame- ters: UNPACK ROW LENGTH, UNPACK SKIP ROWS, and UNPACK SKIP PIXELS. Before obtaining the first group from memory, the data pointer is 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 bykelements. heightsets ofwidth

groups of values are obtained this way. See figure3.5. Special Interpretations

3.7. PIXEL RECTANGLES 109

typeParameter GL Data Number of Matching

Token Name Type Components Pixel Formats

UNSIGNED BYTE 3 3 2 ubyte 3 RGB

UNSIGNED BYTE 2 3 3 REV ubyte 3 RGB

UNSIGNED SHORT 5 6 5 ushort 3 RGB

UNSIGNED SHORT 5 6 5 REV ushort 3 RGB

UNSIGNED SHORT 4 4 4 4 ushort 4 RGBA,BGRA

UNSIGNED SHORT 4 4 4 4 REV ushort 4 RGBA,BGRA

UNSIGNED SHORT 5 5 5 1 ushort 4 RGBA,BGRA

UNSIGNED SHORT 1 5 5 5 REV ushort 4 RGBA,BGRA

UNSIGNED INT 8 8 8 8 uint 4 RGBA,BGRA

UNSIGNED INT 8 8 8 8 REV uint 4 RGBA,BGRA

UNSIGNED INT 10 10 10 2 uint 4 RGBA,BGRA

UNSIGNED INT 2 10 10 10 REV uint 4 RGBA,BGRA

UNSIGNED INT 24 8 uint 2 DEPTH STENCIL

UNSIGNED INT 10F 11F 11F REV uint 3 RGB

UNSIGNED INT 5 9 9 9 REV uint 4 RGB

FLOAT 32 UNSIGNED INT 24 8 REV n/a 2 DEPTH STENCIL

Table 3.5: Packed pixel formats.

A type matching one of the types in table 3.5 is a special case in which all the components of each group are packed into a single unsigned byte, unsigned short, or unsigned int, depending on the type. If type is

FLOAT 32 UNSIGNED INT 24 8 REV, the components of each group are contained within two 32-bit words; the first word contains the float component, and the sec- ond word contains a packed 24-bit unused field, followed by an 8-bit component. The number of components per packed pixel is fixed by the type, and must match the number of components per group indicated by theformatparameter, as listed in table3.5. The errorINVALID OPERATIONis generated by any command pro- cessing pixel rectangles if a mismatch occurs.

Bitfield locations of the first, second, third, and fourth components of each packed pixel type are illustrated in tables3.6- 3.9. Each bitfield is interpreted as an unsigned integer value. If the base GL type is supported with more than the minimum precision (e.g. a 9-bit byte) the packed components are right-justified in the pixel.

Components are normally packed with the first component in the most signif- icant bits of the bitfield, and successive component occupying progressively less

3.7. PIXEL RECTANGLES 110

significant locations. Types whose token names end with REVreverse the compo- nent packing order from least to most significant locations. In all cases, the most significant bit of each component is packed in the most significant bit location of its location in the bitfield.

UNSIGNED BYTE 3 3 2:

7 6 5 4 3 2 1 0

1st Component 2nd 3rd

UNSIGNED BYTE 2 3 3 REV:

7 6 5 4 3 2 1 0

3rd 2nd 1st Component

Table 3.6: UNSIGNED BYTEformats. Bit numbers are indicated for each compo- nent.

3.7. PIXEL RECTANGLES 111

UNSIGNED SHORT 5 6 5:

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

1st Component 2nd 3rd

UNSIGNED SHORT 5 6 5 REV:

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

3rd 2nd 1st Component

UNSIGNED SHORT 4 4 4 4:

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

1st Component 2nd 3rd 4th

UNSIGNED SHORT 4 4 4 4 REV:

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

4th 3rd 2nd 1st Component

UNSIGNED SHORT 5 5 5 1:

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

1st Component 2nd 3rd 4th

UNSIGNED SHORT 1 5 5 5 REV:

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

4th 3rd 2nd 1st Component

3.7. PIXEL RECTANGLES 112

UNSIGNED INT 8 8 8 8:

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

1st Component 2nd 3rd 4th

UNSIGNED INT 8 8 8 8 REV:

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

4th 3rd 2nd 1st Component

UNSIGNED INT 10 10 10 2:

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

1st Component 2nd 3rd 4th

UNSIGNED INT 2 10 10 10 REV:

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

4th 3rd 2nd 1st Component

UNSIGNED INT 24 8:

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

1st Component 2nd

UNSIGNED INT 10F 11F 11F REV:

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

3rd 2nd 1st Component

UNSIGNED INT 5 9 9 9 REV:

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

4th 3rd 2nd 1st Component

3.7. PIXEL RECTANGLES 113

FLOAT 32 UNSIGNED INT 24 8 REV:

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

1st Component

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Unused 2nd

3.7. PIXEL RECTANGLES 114

Format First Second Third Fourth

Component Component Component Component

RGB red green blue

RGBA red green blue alpha

BGRA blue green red alpha

DEPTH STENCIL depth stencil

Table 3.10: Packed pixel field assignments.

The assignment of component to fields in the packed pixel is as described in table3.10.

Byte swapping, if enabled, is performed before the components are extracted from each pixel. The above discussions of row length and image extraction are valid for packed pixels, if “group” is substituted for “component” and the number of components per group is understood to be one.

Atype ofUNSIGNED INT 10F 11F 11F REV andformatof RGBis a special case in which the data are a series of GLuintvalues. Each uint value specifies 3 packed components as shown in table3.8. The 1st, 2nd, and 3rd components are calledfred(11 bits),fgreen(11 bits), andfblue(10 bits) respectively.

fred andfgreen are treated as unsigned 11-bit floating-point values and con-

verted to floating-point red and green components respectively as described in sec- tion2.1.3.fblueis treated as an unsigned 10-bit floating-point value and converted

to a floating-point blue component as described in section2.1.4.

A type of UNSIGNED INT 5 9 9 9 REV andformat of RGB is a special case in which the data are a series of GLuintvalues. Eachuint value specifies 4 packed components as shown in table3.8. The 1st, 2nd, 3rd, and 4th components are called pred, pgreen, pblue, and pexp respectively and are treated as unsigned

integers. These are then used to compute floating-pointRGBcomponents (ignoring the ”Conversion to floating-point” section below in this case) as follows:

red=pred2pexp−B−N

green=pgreen2pexp−B−N

blue=pblue2pexp−B−N

In document glspec31.20090324.pdf (Page 116-128)