US7324115B2 - Display list compression for a tiled 3-D rendering system - Google Patents
Display list compression for a tiled 3-D rendering system Download PDFInfo
- Publication number
- US7324115B2 US7324115B2 US10/860,335 US86033504A US7324115B2 US 7324115 B2 US7324115 B2 US 7324115B2 US 86033504 A US86033504 A US 86033504A US 7324115 B2 US7324115 B2 US 7324115B2
- Authority
- US
- United States
- Prior art keywords
- data
- vertex
- display list
- memory
- computer graphics
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000009877 rendering Methods 0.000 title claims abstract description 34
- 238000007906 compression Methods 0.000 title claims description 26
- 230000006835 compression Effects 0.000 title claims description 15
- 239000000872 buffer Substances 0.000 claims description 43
- 238000000034 method Methods 0.000 claims description 35
- 239000003086 colorant Substances 0.000 claims description 5
- 230000001174 ascending effect Effects 0.000 claims description 2
- 230000008569 process Effects 0.000 description 20
- 230000009466 transformation Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 5
- 230000000694 effects Effects 0.000 description 3
- 238000002156 mixing Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000015572 biosynthetic process Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000013144 data compression Methods 0.000 description 1
- 230000006837 decompression Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 238000003786 synthesis reaction Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T15/00—3D [Three Dimensional] image rendering
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T9/00—Image coding
- G06T9/001—Model-based coding, e.g. wire frame
Definitions
- This invention relates to a 3-dimensional computer graphics rendering system and in particular to a system of the type in which a scene to be rendered is subdivided into a plurality of rectangular areas or tiles, each of which is processed in turn for all the objects which intersect it.
- FIG. 1 shows a prior art 3-D rendering system.
- the system takes a three-dimensional description of a scene 100 and generates a two-dimensional representation of the scene 105 that can be displayed on an output device such as a computer monitor.
- the system subdivides the two dimensional representation of the scene into regions referred to as tiles.
- the objects in the three-dimensional scene are processed by a Tile Accelerator 101 and data defining then is stored in a display list 102 .
- the display list contains all the vertex and control data required to render the scene.
- the vertex data is typically stored as vertex strips.
- an Image Synthesis Processor (ISP) 103 For each tile comprising the scene space, an Image Synthesis Processor (ISP) 103 reads the display list corresponding to that tile and determines which parts of scene are visible. This information is then passed on to a Texturing and Shading processor (TSP) 104 to be rendered.
- ISP Image Synthesis Processor
- a further refinement is to group regions of tiles together into macrotiles. Instead of generating a display list for the entire scene, the tile accelerator generates a display list for each macrotile. This has the advantage that if all the display list memory has been consumed, then a macrotile can be rendered and the display list memory associated with it reclaimed for use by the system. The disadvantage is that when objects in the scene span multiple macrotiles they may have vertex data replicated in each macrotile display list.
- Immediate mode rendering does not need to store a description of the entire scene in the display list, and instead primitives are rendered as they are presented to the system. Immediate mode rendering has the advantage of avoiding the storage requirements of the display list, but it precludes the considerable optimisations that are possible with tiled architectures, such as deferred texturing and translucency sorting.
- Embodiments of the present invention provide a method and apparatus for reducing the size and memory bandwidth required for the display list, which will allow tiled rendering systems to be implemented at lower cost.
- Specific embodiments of the invention collect blocks of screen space vertex data in the Tile Accelerator and reduce the amount of storage and bandwidth required to store the data by exploiting the spatial relationships between them. This is done determining a set of origin values and storing the attributes of the vertices as delta (or difference) values relative to the origin values.
- Preferred embodiments also use a scheme for compactly describing indexed primitives in the display list that improves the number of times a vertex can be reused in a scene over traditional methods, such as strips, while preserving locality of reference.
- FIG. 1 is the prior art rendering system described above
- FIG. 2 is a block diagram of a tile accelerator embodying the invention
- FIG. 3 shows the input data organisation inside the embodiment of FIG. 3 ;
- FIG. 4 shows a flow diagram of the processing of indices by tiling in an embodiment of the invention
- FIG. 5 shows a structure of vertex buffer organisation within the tile accelerator of FIG. 2 ;
- FIG. 6 shows schematically the organisation of the display list in the embodiment of the invention.
- FIG. 7 is a flow diagram showing how attributes are compressed
- FIG. 8 is a more detailed diagram of vertex organisation
- FIG. 9 shows a flow diagram for the retrieval and decompression of vertex data.
- FIG. 2 illustrates the processing stages and data flow of a tile accelerator with vertex data compression in an embodiment of the invention.
- Input data 100 contains a description of scene to be rendered. This includes the vertices that define the scene, a description or how vertices should be assembled into primitive objects such as lines and triangles, and state information describing the manner in which they should be rendered.
- the state information includes information about how to rasterise, texture and shade the primitive objects.
- the state information includes the state specified by OpenGL and Direct X both of which are industry standard application programming interfaces
- the Tile Accelerator 101 reads and processes vertices according to a list of rendering commands in the input data.
- FIG. 3 shows a possible configuration of the input data.
- the rendering commands 300 indicate that two triangles are to be drawn and the state information defines how they are to be rendered.
- the application derives two triplets of indices 301 and 302 each of which describes which of the vertices 303 comprises its respective triangle.
- indices permits individual vertices to be referenced by a greater number of primitives in the scene than would otherwise be possible with strips.
- the system allows indices to be stored compactly in the display list.
- sets of indices are used throughout the system to describe how primitives are formed.
- the system reads vertices and passes them to a transform processor 200 for conversion into clip space coordinates.
- This can be implemented as a fixed function transformation and lighting logic or as a programmable logic taking a sequence of operations that are the applied to the vertices.
- the transformation process is programmable and includes vertex blending and the tessellation of high order surfaces into primitive objects.
- the input data supplied to the rendering system may already be in screen space and so no transformation needs to be applied to the data.
- transformation may always be performed prior to the vertex data being supplied to the rendering system and the transform function may not be required at all.
- Clipping and culling 201 takes transformed vertices and index information and performs clipping against front, rear or arbitrary clip planes and culling of primitives based on whether they are front or rear facing. In the embodiment, the final transformation of vertices to screen space is performed here.
- Tiling Unit 202 receives indices and vertices from the clipping and culling process.
- the transformed and clipped vertices are placed into a vertex buffer 203 and the indices placed in an index buffer 204 .
- the tiling process then uses the indices to fetch the corresponding vertices' screen coordinates from the buffer and determines which tiles the data contained in the buffer effects.
- the vertex buffer can store up to 16 vertices and the index buffer up to 96 indices. When these buffers are full, the contents of the vertex buffer are sent to the compression process 207 and the indices sent to the control portion 205 of the display list.
- FIG. 4 shows the process used to add vertices and indices into these buffers.
- the process of FIG. 4 receives new indices for the next primitive at 500 and at 501 determines whether or not the new indices will fit into the index buffer. If they will not, the contents of the index buffer are flushed to the display list and the contents of the vertex buffer to the compression unit 207 at step 502 . The process then passes to step 503 which can also be reached directly from step 501 if the new indices do fit into the index buffer. At this stage the new indices are compared with the contents of the index buffer and a determination made as to which vertices referred to by the new indices are currently not present in the vertex buffer. After this a determination is made at 504 as to whether the new vertices determined at 503 will fit into the vertex buffer.
- step 506 which is also passed to from step 504 if the new vertices do fit into the vertex buffer, and the new indices are then added to the index buffer.
- step 507 the new vertices are fetched and added to the vertex buffer.
- Each vertex in the vertex buffer can have a number of attributes associated with it.
- each vertex has 45 IEEE floating point format attribute values consisting of four position attributes (X, Y, Z, W), two groups of colour attributes (R, G, B, A) referred to as base and offset colours, eight groups of texture coordinates (U, V, S, T) and a fog value.
- FIG. 5 illustrates the organisation of the vertex buffer.
- the vertex position 400 indicates the screen space coordinates of the vertex. This data is required to rasterise the scene and determine the visibility of objects. The remaining data, including the base and offset colours 401 , texture coordinates 402 and fog value 403 are used during texturing and shading.
- system can be configured so that Z represents the distance from the eye to the point represented by the vertex or so that Z is the distance from the front plane.
- the tiling process examines the indices of the remaining primitives and determines which vertices are still referenced. This information is forwarded to the compression process in the form of a mask. Note that if macrotiling is used, this information can be passed to the compression module on a per macrotile basis for each macrotile that the contents of the vertex buffer effects.
- the contents of the vertex buffer are flushed and sent to the compression process and the indices describing the primitives are written into the control portion of the display list 205 .
- the state information is placed in the control portion of the display list by the tiling process.
- state information in the input data to the system is tagged with a tag between 1 and 63.
- the tiling process records the current tag and the tag of the last state written into each tile. When it is determined that a primitive effects a particular tile, the last tag written into that tile is compared against the current tag. If the numbers do not match, the state information is inserted into the control data of that tile and the record of the last tag for that tile is updated. At the beginning of each frame or after 63 tags have been submitted to the system, the record of the last tag written to each tile is cleared to zero.
- FIG. 6 illustrates the organisation of the display list.
- Each tile in the display list has its own steam or control data.
- a region array 706 holds a pointer to the start of the control data for each tile.
- the part of the display list containing control and vertex data is divided into memory blocks 700 which are typically memory page sized.
- the per-tile control data 706 are written into ascending addresses in memory blocks and blocks of vertex data 703 are written into descending memory addresses.
- a new memory block is allocated. In this manner, locality of reference is improved because vertex data can be stored in the same memory block as the control data that refers to it.
- a memory array is used to record the location in the display list of the memory blocks where control data for each tile should be appended. If macrotiling, there is one memory block being filled per macrotile.
- the control data includes state information 701 , vertex block pointers 702 , indices 704 and stream pointers 705 .
- state information that is only required by the ISP is stored directly in the control data.
- State information that is required by the TSP is written once into the display list and a reference to it is placed in the control data.
- TSP state information To reduce the amount of display list storage required for TSP state information it is split into three portions: object state that is shared across a large number of objects, texture state that typically changes frequently, and blending state that is typically large but shared across many objects. In this manner, the texture state can change frequency without it being necessary to replicate the large blending state each time.
- Vertex block pointers identify the block of vertex data that will be subsequently used to draw primitives. In the preferred embodiment this includes a description of the type of primitives to be drawn from the buffer. This includes lines, points, filled triangles and outline triangles.
- indices written into the control data are mapped by means of an associative memory into a range between zero and the number of vertices stored in the vertex buffer.
- the indices written into the control data are 4-bit values.
- the control data for a tile is written into memory blocks in sequential memory addresses. Each memory block may contain control data for multiple tiles, and the control data for a tile may span multiple memory blocks. At the end of each sequence of control data, the tiling process inserts a stream pointer either to identify the address in the display list where the control data continues or to indicate the end of the control data for a tile.
- Compression unit 207 in FIG. 2 examines the attributes of the vertices stored in the vertex buffer and attempts to exploit the spatial relationships between them to reduce their storage and memory bandwidth requirements.
- blocks of attributes are compressed by storing them as delta or difference values relative to an origin value.
- the origin value and the delta values for all vertices in the block are stored in the vertex data in the display list.
- FIG. 7 illustrates the process of compressing vertex attributes.
- the process is performed for each attribute for each vertex that is to be compressed.
- each set of attributes is either written out in compressed format as a set of delta values and an origin value or in raw “uncompressed” format as a set of 32-bit IEEE floating point values (for all attributes expect R, G, B and A attributes) and 8-bit integers (for R, G, B and A attributes).
- the tile accelerator can be configured to process only a subset of possible attributes.
- fog values are not compressed, however they could be processed in a similar manner as for the other attributes.
- a set of attributes is received from the vertex buffer along with a set of mask bits from tiling, indicating which of the attributes should be processed.
- attributes that do not have the corresponding mask bit are discarded from further processing.
- the mask is not used and all attributes are always processed.
- the attribute values are reduced to some amount of fractional accuracy, which is referred to as snapping.
- the amount of precision retained depends on the attribute type and on how the compression process has been configured.
- Table 1 shows the attributes that are truncated and the number of fractional or mantissa bits preserved.
- the number of fractional bits preserved for X, Y can be relatively small because the position in screen space is typically sampled at integer coordinates and because of inaccuracies introduces during transformation. Sufficient Z accuracy must be maintained for Z artefacts not to occur.
- the number of fractional bits preserved is configurable.
- the compressor is typically configured to preserve log2(dim)+8 fractional bits, where dim is the maximum dimension in texels of texture maps associated with that attribute and log2 is the logarithm in base 2.
- dim is the maximum dimension in texels of texture maps associated with that attribute
- log2 is the logarithm in base 2.
- the number of fractional bits preserved can be reduced to improve the compression ratio at the expense of accuracy.
- floating point colour values between 0 and 1.0 are converted to unsigned 8-bit integer values multiplying by 255 or by multiplying by 250 and clamping.
- the compression process can be configured to disable the compression of particular attributes. This forces the attribute to be stored in raw format and no snapping is performed.
- the minimum and maximum values of the set of snapped attributes is determined.
- the minimum value is selected as an origin value.
- Texture maps are frequently sampled so that only the fractional part and sometimes the odd/even value of the texture coordinate is significant.
- the compression process can be configured to discard the most significant bits of the origin values, equivalent to adding or subtracting a multiple of 1 or 2, and thus move it closer to zero. Reducing the magnitude of the texture coordinate origin values in this manner can reduce the amount of storage required for the texture coordinate origins.
- the X and Y attributes can have the macrotile corner closest to the origin of the macrotile subtracted from them.
- texture coordinate origin values are restricted to values between ⁇ 2 16 and +2 16 and Z, W and T origin values are restricted to being positive.
- the compression process determines if the origin value can be represented. If the texture coordinate origin value is outside the range that can be represented, the attributes are not compressed and the “raw” 32-bit IEEE format float value of the attributes are stored in the display list at 611 .
- the decision to store an attribute in raw format can force related attributes to also be stored in raw format. For example, if the compression process decides to store any of X, Y or Z in raw format, then all attributes in the set could be stored in raw format. Similarly, for each group of texture coordinates, if any of U, V, S or T is stored in raw format, then all texture coordinate attributes for that group could be stored in raw format.
- the maximum delta or difference value of each attribute is calculated by subtracting the minimum value from the maximum.
- the magnitude of the maximum delta value for each attribute is examined and it is determined whether the delta value exceeds the maximum value that can be represented in compressed form.
- the compressed format delta values for all X, Y, U, V and S attributes are stored as fixed-point delta values.
- Table 2 shows the magnitude at which deltas can no longer be represented in the compressed format.
- the colour delta values R, G, B and A are integer quantities in the range 0 to 255. In the preferred embodiment, groups of colour delta values are stored in a single 16-bit block. If the A attributes are not all 255, the magnitude at which the R, G, B and A delta values can no longer be represented is 2 4 . If the A attributes are all 255, the values for R and B are 2 6 and 2 6 for B.
- the Z, W and T attributes are stored as floating point values.
- the delta values are stored as a mantissa value relative to the exponent of the origin.
- the number of mantissa bits preserved in the delta values is the same as the number used when snapping. Note that as the origin is the minimum value, storing mantissa values relative to this exponent preserves all possible mantissa accuracy.
- the magnitude of the maximum delta value is used to determine the size of the attribute deltas to be stored in the compressed format.
- the compressed format for all attributes in each set have the same delta size, which can be. 0, 8 or 16-bits for X, Y, Z, W, U, V, S and T and 16-bits for groups of colours. Note that this means that each vertex in a block has the same size.
- the delta values for each attribute is calculated by subtracting the origin value from the value of each attribute.
- the number of bits preserved is as described previously.
- the set of attributes are written into the display list in compressed format as a set of delta values and an origin value.
- the set of attributes are written into the display list in raw format as a set of 32-bit IEEE float values.
- FIG. 8 illustrates how the compression processes organises the vertex data for each vertex data block in display list memory.
- the first part of the vertex data is the Vertex Format 700 .
- This describes some of the vertex data format.
- this contains: a flag indicating whether the X, Y and Z attribute are stored in raw or compressed format; three fields indicating whether the compressed formats Delta X 704 , Delta Y 705 and Delta Z 706 are 8- or 16-bit delta values; three flags indicating whether the W Origin 707 , Base Colour Origin 708 , Offset Colour Origin 709 are present; a field indicating the number of Texture Coordinate Formats 710 present; a field indicating whether W Delta 715 values are 0, 8- or 16-bit delta or 32-bit raw values; two fields indicating whether Base Delta 716 and Offset Delta 717 are 0, 8- or 16-bit delta or 32-bit raw values; and a flag indicating whether Fog 719 values are present.
- the second part of the vertex data 750 contains the position information for the vertices.
- the Vertex Format is followed by the X Origin 701 , Y Origin 702 and Z Origin 703 values as determined at 604 .
- the vertex data then contains the X Delta, Y Delta, and Z Delta values for all of the vertices in the block as determined at 609 .
- X Origin, Y Origin and Z Origin are in raw format the X Origin, Y Origin and Z Origin values are not used and the Vertex Format is followed by the raw format X, Y and Z attribute values for all vertices in the block. In some implementations, X Origin, Y Origin and Z Origin may always be present.
- the third part of the vertex data 751 contains data required for texturing and shading of the vertices. In some implementations this may not be present if the vertices do not require texturing or shading.
- the W Origin 707 , Base Colour Origin 708 , Offset Colour Origin 709 contain the origin values for W and the R, G, B and A origin values for Base Colour and Offset Colour as determined at 604 . These origin values are only present if the corresponding flags in the Vertex Format are set.
- Zero or more Texture Coordinate Formats may be present. Each describes the format for a group of U, V, S and T attributes. In the preferred embodiment this contains: a flag indicating whether the U, V and S attributes for this group are stored in raw or compressed format; three fields indicating whether U Delta, V Delta and S Delta values for this group are 8- or 16-bit; two flags indicating whether the S and T attributes are present; two fields indicating whether S Delta and T Delta values are 8- or 16-bit.
- Each Texture Coordinate Format is followed by U Origin 711 , V Origin 712 , S Origin 713 and T Origin 614 values as determines in 604 .
- the U Origin, V Origin and S Origin values are stored as 16-bit floating point numbers with one sign bit, four exponent bits and 11 mantissa bits, and the T Origin is stored as a 32-bit IEEE format floating point number.
- Vertex position data is decompressed as the ISP fetches the per-tile control data from the display list.
- FIG. 9 illustrates the process performed for each tile in the scene.
- a control stream data pointer is initialised to the start of the control stream data from an address stored in a Region Array.
- the item pointed to by the control stream pointer is read and the pointer incremented to point to the next item.
- the item read is examined to determine if the end of the control stream has been reached. If it has, the ISP data fetch for this tile is complete and either the next tile in the scene should be processed or the scene render is complete. If the end of the stream has not been reached, then at 902 the item is examined to determine whether it is a stream pointer.
- control stream data pointer is updated to the address indicated and control is returned to step 901 . If the item is not a stream pointer it is examined at 904 to determine whether it is sate. If it is state, the state data is recorded at 905 and control is returned to step 901 . If the item is not state, it is examined at 906 to determine if it is a Vertex Block Pointer. If it is then the origin data is read from the vertex block at 907 and control is returned to step 901 . If the item is not a Vertex Block Pointer then the item must be indices. In this case, the delta values corresponding to the indices are fetched from the vertex block. The attributes of the vertex are reconstructed by adding the delta values to the origin values.
- the data required to decompress a vertex consists of the origin values and the delta values for that vertex. In this way, a single vertex can be fetched without having to fetch the data form all the other vertices in the block.
- Z, W, and T origin values are restricted to being positive.
- the sign of the sets of Z, W and T attributes is recorded and the compression process is performed on the absolute values of the attributes as described about. For each of these attributes, if the compressed format is selected an additional bit containing the original attribute's sign is recorded along with each attribute delta value in the vertex data. Note that this allows compressed floating point values to maintain their sign. If the raw format is selected, the value written into the vertex data includes the original sign.
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer Graphics (AREA)
- Multimedia (AREA)
- Image Generation (AREA)
Abstract
A 3-dimensional computer graphics rendering system receives object data for a scene to be rendered. This includes vertex data and index data. The scene is subdivided into priority of rectangular areas (202). Object 8 of each rectangular area in the scene is assembled (203) and subsequently compressed (207). This data can subsequently be retrieved and decompressed and used for producing a properly shaded and texted image for display.
Description
This invention relates to a 3-dimensional computer graphics rendering system and in particular to a system of the type in which a scene to be rendered is subdivided into a plurality of rectangular areas or tiles, each of which is processed in turn for all the objects which intersect it.
The system takes a three-dimensional description of a scene 100 and generates a two-dimensional representation of the scene 105 that can be displayed on an output device such as a computer monitor.
For the purposes of efficient operation, the system subdivides the two dimensional representation of the scene into regions referred to as tiles.
The objects in the three-dimensional scene are processed by a Tile Accelerator 101 and data defining then is stored in a display list 102. The display list contains all the vertex and control data required to render the scene. The vertex data is typically stored as vertex strips.
For each tile comprising the scene space, an Image Synthesis Processor (ISP) 103 reads the display list corresponding to that tile and determines which parts of scene are visible. This information is then passed on to a Texturing and Shading processor (TSP) 104 to be rendered.
A further refinement is to group regions of tiles together into macrotiles. Instead of generating a display list for the entire scene, the tile accelerator generates a display list for each macrotile. This has the advantage that if all the display list memory has been consumed, then a macrotile can be rendered and the display list memory associated with it reclaimed for use by the system. The disadvantage is that when objects in the scene span multiple macrotiles they may have vertex data replicated in each macrotile display list.
The majority of non-tiled 3D graphics systems have an immediate mode rendering architecture. Immediate mode rendering does not need to store a description of the entire scene in the display list, and instead primitives are rendered as they are presented to the system. Immediate mode rendering has the advantage of avoiding the storage requirements of the display list, but it precludes the considerable optimisations that are possible with tiled architectures, such as deferred texturing and translucency sorting.
The complexity of scenes to be rendered is increasing as powerful, low-cost rendering systems become more prevalent. This presents a problem for tiled renderers because the display list storage and bandwidth requirements also increase.
Embodiments of the present invention provide a method and apparatus for reducing the size and memory bandwidth required for the display list, which will allow tiled rendering systems to be implemented at lower cost.
Specific embodiments of the invention collect blocks of screen space vertex data in the Tile Accelerator and reduce the amount of storage and bandwidth required to store the data by exploiting the spatial relationships between them. This is done determining a set of origin values and storing the attributes of the vertices as delta (or difference) values relative to the origin values.
Preferred embodiments also use a scheme for compactly describing indexed primitives in the display list that improves the number of times a vertex can be reused in a scene over traditional methods, such as strips, while preserving locality of reference.
The invention is defined in its various aspects with more precision in the appended claims to which reference should now be made.
Specific embodiments of the invention will now be described in detail by way of example with reference to the accompanying drawings in which:
The Tile Accelerator 101 reads and processes vertices according to a list of rendering commands in the input data.
Other configurations for describing how primitives should be assembled from a list of vertices, such as lists of indices describing triangle strips or fans are also possible. The description of other types of primitives, such as quads and lines is also possible by using fewer or additional index values. In some configurations, the list of indices may be implied and generated internally by the system.
It can be seen that the use of indices permits individual vertices to be referenced by a greater number of primitives in the scene than would otherwise be possible with strips. As will be shown below, the system allows indices to be stored compactly in the display list. In the preferred embodiment, sets of indices are used throughout the system to describe how primitives are formed.
As instructed by the rendering commands, in FIG. 2 the system reads vertices and passes them to a transform processor 200 for conversion into clip space coordinates. This can be implemented as a fixed function transformation and lighting logic or as a programmable logic taking a sequence of operations that are the applied to the vertices. In the embodiment, the transformation process is programmable and includes vertex blending and the tessellation of high order surfaces into primitive objects. In some situations, the input data supplied to the rendering system may already be in screen space and so no transformation needs to be applied to the data. In some implementations, transformation may always be performed prior to the vertex data being supplied to the rendering system and the transform function may not be required at all.
Clipping and culling 201 takes transformed vertices and index information and performs clipping against front, rear or arbitrary clip planes and culling of primitives based on whether they are front or rear facing. In the embodiment, the final transformation of vertices to screen space is performed here.
In the embodiment, the vertex buffer can store up to 16 vertices and the index buffer up to 96 indices. When these buffers are full, the contents of the vertex buffer are sent to the compression process 207 and the indices sent to the control portion 205 of the display list. FIG. 4 shows the process used to add vertices and indices into these buffers.
The process of FIG. 4 receives new indices for the next primitive at 500 and at 501 determines whether or not the new indices will fit into the index buffer. If they will not, the contents of the index buffer are flushed to the display list and the contents of the vertex buffer to the compression unit 207 at step 502. The process then passes to step 503 which can also be reached directly from step 501 if the new indices do fit into the index buffer. At this stage the new indices are compared with the contents of the index buffer and a determination made as to which vertices referred to by the new indices are currently not present in the vertex buffer. After this a determination is made at 504 as to whether the new vertices determined at 503 will fit into the vertex buffer. If they will not the contents of the index buffer are flushed to the display list and the contents of the vertex buffer to the compression unit 207 at step 505. The process then passes to step 506, which is also passed to from step 504 if the new vertices do fit into the vertex buffer, and the new indices are then added to the index buffer. The process is completed at step 507 where the new vertices are fetched and added to the vertex buffer.
Each vertex in the vertex buffer can have a number of attributes associated with it. In the preferred embodiment, each vertex has 45 IEEE floating point format attribute values consisting of four position attributes (X, Y, Z, W), two groups of colour attributes (R, G, B, A) referred to as base and offset colours, eight groups of texture coordinates (U, V, S, T) and a fog value. FIG. 5 illustrates the organisation of the vertex buffer.
The vertex position 400 indicates the screen space coordinates of the vertex. This data is required to rasterise the scene and determine the visibility of objects. The remaining data, including the base and offset colours 401, texture coordinates 402 and fog value 403 are used during texturing and shading.
Note that the system can be configured so that Z represents the distance from the eye to the point represented by the vertex or so that Z is the distance from the front plane.
During the tiling process, it is possible for primitives to be culled because they are entirely off screen or do not cover any of the points where pixels are to be sampled. After culling primitives, the tiling process examines the indices of the remaining primitives and determines which vertices are still referenced. This information is forwarded to the compression process in the form of a mask. Note that if macrotiling is used, this information can be passed to the compression module on a per macrotile basis for each macrotile that the contents of the vertex buffer effects.
When the limit of the number of vertices that can be stored in the vertex buffer or the number of indices that can be buffered in tiling is or the last vertex of a primitive, or the end of the scene is reached, the contents of the vertex buffer are flushed and sent to the compression process and the indices describing the primitives are written into the control portion of the display list 205.
The state information is placed in the control portion of the display list by the tiling process. In the preferred embodiment, state information in the input data to the system is tagged with a tag between 1 and 63. The tiling process records the current tag and the tag of the last state written into each tile. When it is determined that a primitive effects a particular tile, the last tag written into that tile is compared against the current tag. If the numbers do not match, the state information is inserted into the control data of that tile and the record of the last tag for that tile is updated. At the beginning of each frame or after 63 tags have been submitted to the system, the record of the last tag written to each tile is cleared to zero.
The part of the display list containing control and vertex data is divided into memory blocks 700 which are typically memory page sized. During the tiling process, the per-tile control data 706 are written into ascending addresses in memory blocks and blocks of vertex data 703 are written into descending memory addresses. When all space in a memory block has been used, a new memory block is allocated. In this manner, locality of reference is improved because vertex data can be stored in the same memory block as the control data that refers to it.
During the tiling process, a memory array is used to record the location in the display list of the memory blocks where control data for each tile should be appended. If macrotiling, there is one memory block being filled per macrotile.
The control data includes state information 701, vertex block pointers 702, indices 704 and stream pointers 705.
In the embodiment, state information that is only required by the ISP is stored directly in the control data. State information that is required by the TSP is written once into the display list and a reference to it is placed in the control data.
To reduce the amount of display list storage required for TSP state information it is split into three portions: object state that is shared across a large number of objects, texture state that typically changes frequently, and blending state that is typically large but shared across many objects. In this manner, the texture state can change frequency without it being necessary to replicate the large blending state each time.
Vertex block pointers identify the block of vertex data that will be subsequently used to draw primitives. In the preferred embodiment this includes a description of the type of primitives to be drawn from the buffer. This includes lines, points, filled triangles and outline triangles.
To reduce the amount of display list storage, indices written into the control data are mapped by means of an associative memory into a range between zero and the number of vertices stored in the vertex buffer. In the, embodiment, the indices written into the control data are 4-bit values.
The control data for a tile is written into memory blocks in sequential memory addresses. Each memory block may contain control data for multiple tiles, and the control data for a tile may span multiple memory blocks. At the end of each sequence of control data, the tiling process inserts a stream pointer either to identify the address in the display list where the control data continues or to indicate the end of the control data for a tile.
At 600, a set of attributes is received from the vertex buffer along with a set of mask bits from tiling, indicating which of the attributes should be processed.
At 601, attributes that do not have the corresponding mask bit are discarded from further processing. In some implementations of the system, the mask is not used and all attributes are always processed.
At 602 the attribute values are reduced to some amount of fractional accuracy, which is referred to as snapping. The amount of precision retained depends on the attribute type and on how the compression process has been configured. For the embodiment, Table 1 shows the attributes that are truncated and the number of fractional or mantissa bits preserved.
TABLE 1 | ||||
Position | X, Y | 4 fractional bits | ||
Z | 24 mantissa bits | |||
W | 20 mantissa bits | |||
Texture Coordinate | U, V, S | 8-23 fractional bits | ||
T | 20 mantissa bits | |||
The number of fractional bits preserved for X, Y can be relatively small because the position in screen space is typically sampled at integer coordinates and because of inaccuracies introduces during transformation. Sufficient Z accuracy must be maintained for Z artefacts not to occur.
Note that for texture coordinates, the number of fractional bits preserved is configurable. The compressor is typically configured to preserve log2(dim)+8 fractional bits, where dim is the maximum dimension in texels of texture maps associated with that attribute and log2 is the logarithm in base 2. The number of fractional bits preserved can be reduced to improve the compression ratio at the expense of accuracy.
In the embodiment, floating point colour values between 0 and 1.0 are converted to unsigned 8-bit integer values multiplying by 255 or by multiplying by 250 and clamping.
The compression process can be configured to disable the compression of particular attributes. This forces the attribute to be stored in raw format and no snapping is performed.
At 603 the minimum and maximum values of the set of snapped attributes is determined.
At 604 the minimum value is selected as an origin value.
Texture maps are frequently sampled so that only the fractional part and sometimes the odd/even value of the texture coordinate is significant. For texture coordinates that are used in this manner, the compression process can be configured to discard the most significant bits of the origin values, equivalent to adding or subtracting a multiple of 1 or 2, and thus move it closer to zero. Reducing the magnitude of the texture coordinate origin values in this manner can reduce the amount of storage required for the texture coordinate origins.
If macrotiling is being performed, the X and Y attributes can have the macrotile corner closest to the origin of the macrotile subtracted from them.
Some attributes may have restrictions on the magnitude of the origin values that can be represented in the compressed format. In the preferred embodiment, texture coordinate origin values are restricted to values between −216 and +216 and Z, W and T origin values are restricted to being positive.
At 605 the compression process determines if the origin value can be represented. If the texture coordinate origin value is outside the range that can be represented, the attributes are not compressed and the “raw” 32-bit IEEE format float value of the attributes are stored in the display list at 611.
To simplify the encoding and decoding of the compressed memory format, the decision to store an attribute in raw format can force related attributes to also be stored in raw format. For example, if the compression process decides to store any of X, Y or Z in raw format, then all attributes in the set could be stored in raw format. Similarly, for each group of texture coordinates, if any of U, V, S or T is stored in raw format, then all texture coordinate attributes for that group could be stored in raw format.
Note that if a set of attributes is stored in raw format, the origin value is not used.
At 606 the maximum delta or difference value of each attribute is calculated by subtracting the minimum value from the maximum.
At 607 the magnitude of the maximum delta value for each attribute is examined and it is determined whether the delta value exceeds the maximum value that can be represented in compressed form.
In the preferred embodiment, the compressed format delta values for all X, Y, U, V and S attributes are stored as fixed-point delta values. Table 2 shows the magnitude at which deltas can no longer be represented in the compressed format.
TABLE 2 | |||||
Position | X, Y | Fixed point | 212 | ||
Z | Floating point | 16 mantissa bits | |||
W | Floating point | 16 mantissa bits | |||
Colour | R, | Integer | 24 or 25 | ||
| Integer | 24 or 26 | |||
A | |
24 or 0 | |||
Texture | U, V, S | Fixed point | 8-23 fractional | ||
Coordinate | bits | ||||
T | Floating point | 16 mantissa bits | |||
The colour delta values R, G, B and A are integer quantities in the range 0 to 255. In the preferred embodiment, groups of colour delta values are stored in a single 16-bit block. If the A attributes are not all 255, the magnitude at which the R, G, B and A delta values can no longer be represented is 24. If the A attributes are all 255, the values for R and B are 26 and 26 for B.
The Z, W and T attributes are stored as floating point values. The delta values are stored as a mantissa value relative to the exponent of the origin. The number of mantissa bits preserved in the delta values is the same as the number used when snapping. Note that as the origin is the minimum value, storing mantissa values relative to this exponent preserves all possible mantissa accuracy.
At 608 the magnitude of the maximum delta value is used to determine the size of the attribute deltas to be stored in the compressed format. In the preferred embodiment, the compressed format for all attributes in each set have the same delta size, which can be. 0, 8 or 16-bits for X, Y, Z, W, U, V, S and T and 16-bits for groups of colours. Note that this means that each vertex in a block has the same size.
At 609 the delta values for each attribute is calculated by subtracting the origin value from the value of each attribute. The number of bits preserved is as described previously.
At 610 the set of attributes are written into the display list in compressed format as a set of delta values and an origin value.
At 611 the set of attributes are written into the display list in raw format as a set of 32-bit IEEE float values.
The first part of the vertex data is the Vertex Format 700. This describes some of the vertex data format. In the preferred embodiment this contains: a flag indicating whether the X, Y and Z attribute are stored in raw or compressed format; three fields indicating whether the compressed formats Delta X 704, Delta Y 705 and Delta Z 706 are 8- or 16-bit delta values; three flags indicating whether the W Origin 707, Base Colour Origin 708, Offset Colour Origin 709 are present; a field indicating the number of Texture Coordinate Formats 710 present; a field indicating whether W Delta 715 values are 0, 8- or 16-bit delta or 32-bit raw values; two fields indicating whether Base Delta 716 and Offset Delta 717 are 0, 8- or 16-bit delta or 32-bit raw values; and a flag indicating whether Fog 719 values are present.
The second part of the vertex data 750 contains the position information for the vertices.
If the X, Y and Z attributes are stored in compressed format, the Vertex Format is followed by the X Origin 701, Y Origin 702 and Z Origin 703 values as determined at 604. Following the origin values the vertex data then contains the X Delta, Y Delta, and Z Delta values for all of the vertices in the block as determined at 609.
If the X, Y and Z attributes are in raw format the X Origin, Y Origin and Z Origin values are not used and the Vertex Format is followed by the raw format X, Y and Z attribute values for all vertices in the block. In some implementations, X Origin, Y Origin and Z Origin may always be present.
The third part of the vertex data 751 contains data required for texturing and shading of the vertices. In some implementations this may not be present if the vertices do not require texturing or shading.
The W Origin 707, Base Colour Origin 708, Offset Colour Origin 709 contain the origin values for W and the R, G, B and A origin values for Base Colour and Offset Colour as determined at 604. These origin values are only present if the corresponding flags in the Vertex Format are set.
Zero or more Texture Coordinate Formats may be present. Each describes the format for a group of U, V, S and T attributes. In the preferred embodiment this contains: a flag indicating whether the U, V and S attributes for this group are stored in raw or compressed format; three fields indicating whether U Delta, V Delta and S Delta values for this group are 8- or 16-bit; two flags indicating whether the S and T attributes are present; two fields indicating whether S Delta and T Delta values are 8- or 16-bit.
Each Texture Coordinate Format is followed by U Origin 711, V Origin 712, S Origin 713 and T Origin 614 values as determines in 604. In the preferred embodiment, The U Origin, V Origin and S Origin values are stored as 16-bit floating point numbers with one sign bit, four exponent bits and 11 mantissa bits, and the T Origin is stored as a 32-bit IEEE format floating point number.
Following the Texture Coordinate Formats and U Origin, V Origin, S Origin and T Origin data, is the per-vertex data for the remaining attributes. This includes: W Delta 715, Base Colour Delta 716, Offset Colour Delta 717, Fog 718, and for each group of texture coordinate attributes present U Delta 719, V Delta 720, S Delta 721 and T Delta 722. In some implementations, these values are only present if the corresponding bits in the Vertex Format or Layer Format are set.
Vertex position data is decompressed as the ISP fetches the per-tile control data from the display list. FIG. 9 illustrates the process performed for each tile in the scene. To commence fetching the control stream, a control stream data pointer is initialised to the start of the control stream data from an address stored in a Region Array. At 900 the item pointed to by the control stream pointer is read and the pointer incremented to point to the next item. At 901 the item read is examined to determine if the end of the control stream has been reached. If it has, the ISP data fetch for this tile is complete and either the next tile in the scene should be processed or the scene render is complete. If the end of the stream has not been reached, then at 902 the item is examined to determine whether it is a stream pointer. If it is, then at 903 the control stream data pointer is updated to the address indicated and control is returned to step 901. If the item is not a stream pointer it is examined at 904 to determine whether it is sate. If it is state, the state data is recorded at 905 and control is returned to step 901. If the item is not state, it is examined at 906 to determine if it is a Vertex Block Pointer. If it is then the origin data is read from the vertex block at 907 and control is returned to step 901. If the item is not a Vertex Block Pointer then the item must be indices. In this case, the delta values corresponding to the indices are fetched from the vertex block. The attributes of the vertex are reconstructed by adding the delta values to the origin values.
Note that the data required to decompress a vertex consists of the origin values and the delta values for that vertex. In this way, a single vertex can be fetched without having to fetch the data form all the other vertices in the block.
In the embodiment, Z, W, and T origin values are restricted to being positive. In an alternative implementation of the compression process, the sign of the sets of Z, W and T attributes is recorded and the compression process is performed on the absolute values of the attributes as described about. For each of these attributes, if the compressed format is selected an additional bit containing the original attribute's sign is recorded along with each attribute delta value in the vertex data. Note that this allows compressed floating point values to maintain their sign. If the raw format is selected, the value written into the vertex data includes the original sign.
Claims (31)
1. A 3-dimensional computer graphics rendering system comprising:
means for receiving object data for a scene to be rendered, the object data including vertex data and index data pointing to the vertex data to define object primitives;
means for sub-dividing the whole scene to be rendered into a plurality of rectangular areas;
means for assembling object data for each rectangular area in the scene;
means for compressing the object data for each rectangular area in the scene;
means for storing the compressed data in a display list memory;
means for retrieving and decompressing the object data; and
means for shading and texturing the object data for display.
2. A 3-dimensional computer graphics rendering system according to claim 1 in which the compression means comprises means for deriving difference data relative to an origin for each vertex and the display list memory stores the origin and difference data.
3. A 3-dimensional computer graphics rendering system according to claim 2 including means for deriving difference data determining a plurality of origins and for each vertex derives the difference relative to an origin.
4. A 3-dimensional computer graphics rendering system according to claim 1 in which the means for assembling object data comprises an index buffer into which index data is stored and a vertex buffer into which vertex data is stored.
5. A 3-dimensional computer graphics rendering system according to claim 4 including means to send the contents of the vertex buffer to the compression means and to send the contents of the index buffer and compressed vertex data to the display list memory.
6. A 3-dimensional computer graphics rendering system according to claim 5 in which the data is sent to the compression means and the display list memory in dependence on the amount of data stored in the index buffer.
7. A 3-dimensional computer graphics rendering system according to claim 5 in which the data is sent to the compression means and the display list memory in dependence on the amount of data stored in the vertex buffer.
8. A 3-dimensional computer graphics rendering system according to claim 1 in which the display list memory comprises a plurality of memory blocks and the means for storing data in the display list memory comprises means for writing control data associated with each vertex in each rectangular area from one end of the memory block and writing vertex data associated with the control data for the same rectangular area in the same memory block from the opposite end of the memory block.
9. A 3-dimensional computer graphics rendering system according to claim 8 in which the memory blocks each comprise a memory page.
10. A 3-dimensional computer graphics rendering system according to claim 1 in which each vertex has a plurality of image attributes associated with it and the compression means comprises means to compress data defining these attributes.
11. A 3-dimensional computer graphics rendering system according to claim 10 in which the attributes comprise position data which is compressed to an origin and difference value.
12. A 3-dimensional computer graphics rendering system according to claim 10 in which the attributes comprise at least on of: texture attributes; vertex positions, colours and; fog values.
13. A 3-dimensional computer graphics rendering system according to claim 11 in which only some of the attributes are compressed.
14. A 3-dimensional computer graphics rendering system according to claim 12 in which the compressed texture attributes are stored as floating point values.
15. A 3-dimensional computer graphics rendering system according to claim 1 including means for associating a plurality of tag values to each rectangular area.
16. A 3-dimensional computer graphics rendering system according to claim 15 including means for updating the tags.
17. A 3-dimensional computer graphics rendering system according to claim 15 wherein data is inserted into a rectangular area if tag values associated with the incoming data do not match tag value currently associated with that area.
18. A method for rendering a 3-dimensional computer graphics image comprising the steps of:
receiving object data for a scene to be rendered, the object data including vertex data and index data pointing to the vertex data to define object primitives;
subdividing the whole scene to be rendered into a plurality of rectangular areas;
assembling object data for each rectangular area in the scene;
compressing the object data for each rectangular area;
storing the compressed object data for each rectangular area in a display list memory;
retrieving and decompressing the object data; and shading and texturing the object data for display.
19. A method according to claim 18 in which the compressing step comprises deriving difference data relative to an origin for each vertex and the storing step comprises storing the origin and difference data in the display list memory.
20. A method according to claim 18 in which the step of assembling object data for each rectangular area comprises the steps of writing index data to an index buffer and writing vertex data into a vertex buffer.
21. A method according to claim 20 including the steps of sending the contents of the index buffer for compression and sending the contents of the index buffer and compressed vertex data to the display list memory.
22. A method according to claim 21 in which the data sent for compression and the data sent to the display list memory is sent in dependence on the amount of data stored in the index buffer.
23. A method according to claim 21 in which the data sent for compression and to the display list memory is sent in dependence on the amount of data stored in the vertex buffer.
24. A method according to claim 20 in which the display list memory comprises a plurality of memory blocks and the step of storing data in the display list memory comprises writing control data associated with each vertex in each rectangular area from one end of a memory block in the display list memory and writing the corresponding vertex data associated with the control data for the same rectangular area in the same memory block from the opposite end of the block.
25. A method according to claim 20 in which each vertex has a plurality of image attributes associated with it and the compressing step comprises compressing data defining these attributes.
26. A method according to claim 25 in which the attributes comprise position data which is compressed to an origin and difference value.
27. A method according to claim 25 in which the attributes comprise at least one of: texture coordinates; vertex positions; colours; and, fog values.
28. A method according to claim 25 in which only some of the attributes are compressed.
29. A method according to claim 27 in which the compressed texture attributes are stored as floating point values.
30. A method for storing vertex and index data representing object primitives in a scene to be rendered comprising the steps of:
subdividing the whole scene into a plurality of rectangular areas;
storing the vertex data and associated control data for object primitives in each rectangular area in memory blocks in a display list memory, wherein the control data associated with the vertexes in each rectangular area is stored in memory addresses commencing at one end of a memory block while the associated vertex data in the same rectangular area is stored in the same memory block commencing with memory addresses from the opposite end of the memory block, wherein one set of memory addresses is an ascending set of memory addresses and the other set of memory addresses is a descending set of memory addresses.
31. A 3-dimensional computer graphics rendering system, comprising:
means for receiving object data for a scene to be rendered, the object data including vertex data and index data pointing to the vertex data to define object primitives;
means for sub-dividing the entire scene to be rendered into a plurality of rectangular areas independent of object data;
means for assembling object data for each rectangular area in the entire scene;
means for compressing the object data for each rectangular area in the entire scene;
means for storing the compressed data in a display list memory;
means for retrieving and decompressing the object data; and
means for shading and texturing the object data for display.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/860,335 US7324115B2 (en) | 2002-03-26 | 2004-06-03 | Display list compression for a tiled 3-D rendering system |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
GB0207152A GB2387094B (en) | 2002-03-26 | 2002-03-26 | 3-D Computer graphics rendering system |
GB0207152.0 | 2002-03-27 | ||
US10/171,304 US20030184555A1 (en) | 2002-03-26 | 2002-06-12 | Display list compression for a tiled 3-D rendering system |
US10/860,335 US7324115B2 (en) | 2002-03-26 | 2004-06-03 | Display list compression for a tiled 3-D rendering system |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/171,304 Continuation US20030184555A1 (en) | 2002-03-26 | 2002-06-12 | Display list compression for a tiled 3-D rendering system |
Publications (2)
Publication Number | Publication Date |
---|---|
US20040222996A1 US20040222996A1 (en) | 2004-11-11 |
US7324115B2 true US7324115B2 (en) | 2008-01-29 |
Family
ID=9933761
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/171,304 Abandoned US20030184555A1 (en) | 2002-03-26 | 2002-06-12 | Display list compression for a tiled 3-D rendering system |
US10/860,335 Expired - Lifetime US7324115B2 (en) | 2002-03-26 | 2004-06-03 | Display list compression for a tiled 3-D rendering system |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/171,304 Abandoned US20030184555A1 (en) | 2002-03-26 | 2002-06-12 | Display list compression for a tiled 3-D rendering system |
Country Status (4)
Country | Link |
---|---|
US (2) | US20030184555A1 (en) |
EP (1) | EP1351195A3 (en) |
JP (1) | JP4564718B2 (en) |
GB (2) | GB2416100B (en) |
Cited By (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060177122A1 (en) * | 2005-02-07 | 2006-08-10 | Sony Computer Entertainment Inc. | Method and apparatus for particle manipulation using graphics processing |
US20070146378A1 (en) * | 2005-11-05 | 2007-06-28 | Arm Norway As | Method of and apparatus for processing graphics |
US20080025646A1 (en) * | 2006-07-31 | 2008-01-31 | Microsoft Corporation | User interface for navigating through images |
US20080027985A1 (en) * | 2006-07-31 | 2008-01-31 | Microsoft Corporation | Generating spatial multimedia indices for multimedia corpuses |
US20080186318A1 (en) * | 2006-09-29 | 2008-08-07 | Jonathan Redshaw | Memory management for systems for generating 3-dimensional computer images |
US20100177105A1 (en) * | 2009-01-15 | 2010-07-15 | Arm Limited | Methods of and apparatus for processing graphics |
US20110227921A1 (en) * | 2010-03-19 | 2011-09-22 | Jonathan Redshaw | Processing of 3D computer graphics data on multiple shading engines |
US8319783B1 (en) | 2008-12-19 | 2012-11-27 | Nvidia Corporation | Index-based zero-bandwidth clears |
US20120300229A1 (en) * | 2011-05-24 | 2012-11-29 | Chung-Hui Kuo | Depositing texture on receiver |
US8330766B1 (en) * | 2008-12-19 | 2012-12-11 | Nvidia Corporation | Zero-bandwidth clears |
US20140176589A1 (en) * | 2012-12-20 | 2014-06-26 | Nvidia Corporation | Technique for storing shared vertices |
US20140333620A1 (en) * | 2013-05-09 | 2014-11-13 | Yong-Ha Park | Graphic processing unit, graphic processing system including the same and rendering method using the same |
US8990275B2 (en) | 2009-09-14 | 2015-03-24 | Thomson Licensing | Method for encoding floating-point data, method for decoding floating-point data, and corresponding encoder and decoder |
US20150091929A1 (en) * | 2012-04-18 | 2015-04-02 | Suzhou Superengine Graphics Software Technology Development Co., Ltd. | Relevant method and device for compression, decompression and progressive transmission of spatial data |
US9013473B2 (en) | 2011-02-09 | 2015-04-21 | Samsung Electronics Co., Ltd. | Graphic processing unit and method for decompressing data |
US20150109288A1 (en) * | 2010-09-10 | 2015-04-23 | Imagination Technologies, Ltd. | Random Accessible Lossless Parameter Data Compression for Tile Based 3D Computer Graphics Systems |
US9122368B2 (en) | 2006-07-31 | 2015-09-01 | Microsoft Technology Licensing, Llc | Analysis of images located within three-dimensional environments |
US9293109B2 (en) | 2012-12-20 | 2016-03-22 | Nvidia Corporation | Technique for storing shared vertices |
US9317948B2 (en) | 2012-11-16 | 2016-04-19 | Arm Limited | Method of and apparatus for processing graphics |
US9336623B2 (en) | 2008-12-19 | 2016-05-10 | Imagination Technologies Limited | Multilevel display control list in tile based 3D computer graphics system |
US9384584B2 (en) | 2008-12-23 | 2016-07-05 | Imagination Technologies Limited | Display list control stream grouping in tile based 3D computer graphics system |
US9424685B2 (en) | 2012-07-31 | 2016-08-23 | Imagination Technologies Limited | Unified rasterization and ray tracing rendering environments |
US9704283B2 (en) | 2013-03-15 | 2017-07-11 | Imagination Technologies Limited | Rendering with point sampling and pre-computed light transport information |
US9805500B2 (en) | 2012-12-20 | 2017-10-31 | Imagination Technologies Limited | Hidden culling in tile-based computer generated images |
US9928563B2 (en) | 2013-04-02 | 2018-03-27 | Imagination Technologies Limited | Tile-based graphics |
US10204391B2 (en) | 2013-06-04 | 2019-02-12 | Arm Limited | Method of and apparatus for processing graphics |
US10417787B2 (en) | 2017-02-15 | 2019-09-17 | Microsoft Technology Licensing, Llc | Index buffer block compression |
US11010959B2 (en) | 2016-04-29 | 2021-05-18 | Arm Limited | Graphics processing systems |
US11610368B2 (en) * | 2010-04-30 | 2023-03-21 | Imagination Technologies Limited | Tessellation of patches of surfaces in a tile based rendering system |
US11748839B2 (en) * | 2020-04-16 | 2023-09-05 | Samsung Electronics Co., Ltd. | Efficient fast random access enabled geometry attribute compression mechanism |
Families Citing this family (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2378108B (en) | 2001-07-24 | 2005-08-17 | Imagination Tech Ltd | Three dimensional graphics system |
US7382368B1 (en) * | 2004-06-28 | 2008-06-03 | Nvidia Corporation | Planar z representation for z compression |
US20060022990A1 (en) * | 2004-07-30 | 2006-02-02 | Silicon Graphics, Inc. | Generating subdivision surfaces on a graphics hardware with floating-point fragment shaders |
US20060061577A1 (en) * | 2004-09-22 | 2006-03-23 | Vijay Subramaniam | Efficient interface and assembler for a graphics processor |
JP4646712B2 (en) * | 2005-07-05 | 2011-03-09 | パナソニック株式会社 | Computer graphics drawing method and drawing apparatus |
GB2439129B (en) * | 2006-06-12 | 2008-11-12 | Imagination Tech Ltd | Parameter compaction in a tile based rendering system |
US7804499B1 (en) | 2006-08-28 | 2010-09-28 | Nvidia Corporation | Variable performance rasterization with constant effort |
US9965886B2 (en) | 2006-12-04 | 2018-05-08 | Arm Norway As | Method of and apparatus for processing graphics |
US20080198166A1 (en) * | 2007-02-16 | 2008-08-21 | Via Technologies, Inc. | Multi-threads vertex shader, graphics processing unit, and flow control method |
GB2452731B (en) | 2007-09-12 | 2010-01-13 | Imagination Tech Ltd | Methods and systems for generating 3-dimensional computer images |
GB0723536D0 (en) * | 2007-11-30 | 2008-01-09 | Imagination Tech Ltd | Multi-core geometry processing in a tile based rendering system |
JP4955596B2 (en) * | 2008-03-21 | 2012-06-20 | 富士フイルム株式会社 | Image output method, apparatus and program |
US9639963B2 (en) * | 2008-12-08 | 2017-05-02 | Microsoft Technology Licensing, Llc | Command remoting techniques |
US20110043518A1 (en) * | 2009-08-21 | 2011-02-24 | Nicolas Galoppo Von Borries | Techniques to store and retrieve image data |
US8810592B2 (en) * | 2009-10-09 | 2014-08-19 | Nvidia Corporation | Vertex attribute buffer for inline immediate attributes and constants |
KR101609266B1 (en) | 2009-10-20 | 2016-04-21 | 삼성전자주식회사 | Apparatus and method for rendering tile based |
US8619085B2 (en) * | 2010-03-08 | 2013-12-31 | Broadcom Corporation | Method and system for compressing tile lists used for 3D rendering |
GB201004675D0 (en) | 2010-03-19 | 2010-05-05 | Imagination Tech Ltd | Memory management system |
KR101681056B1 (en) | 2010-10-01 | 2016-12-01 | 삼성전자주식회사 | Method and Apparatus for Processing Vertex |
JP5670723B2 (en) * | 2010-12-27 | 2015-02-18 | 株式会社ディジタルメディアプロフェッショナル | Image processing device |
CN103999043B (en) * | 2011-12-15 | 2017-06-27 | 英特尔公司 | Technology for strengthening multi views performance in three-dimensional streamline |
US9153058B2 (en) * | 2012-02-29 | 2015-10-06 | Adobe Systems Incorporated | Dynamic splitting of content |
JP5910310B2 (en) * | 2012-05-22 | 2016-04-27 | 富士通株式会社 | Drawing processing apparatus and drawing processing method |
GB2511817A (en) * | 2013-03-14 | 2014-09-17 | Imagination Tech Ltd | Rendering in computer graphics systems |
GB2524121B (en) * | 2014-06-17 | 2016-03-02 | Imagination Tech Ltd | Assigning primitives to tiles in a graphics processing system |
US10235338B2 (en) | 2014-09-04 | 2019-03-19 | Nvidia Corporation | Short stack traversal of tree data structures |
US10600142B2 (en) * | 2017-11-02 | 2020-03-24 | Advanced Micro Devices, Inc. | Compression and decompression of indices in a graphics pipeline |
WO2021002657A1 (en) * | 2019-07-04 | 2021-01-07 | 엘지전자 주식회사 | Point cloud data transmission device, point cloud data transmission method, point cloud data reception device, and point cloud data reception method |
EP4002277A4 (en) * | 2019-08-14 | 2023-02-22 | LG Electronics Inc. | Point cloud data transmission device, point cloud data transmission method, point cloud data reception device and point cloud data reception method |
CN115668938A (en) * | 2020-03-18 | 2023-01-31 | Lg电子株式会社 | Point cloud data transmitting device, point cloud data transmitting method, point cloud data receiving device, and point cloud data receiving method |
US12014527B2 (en) * | 2020-06-22 | 2024-06-18 | Advanced Micro Devices, Inc. | Delta triplet index compression |
CN114140569B (en) * | 2022-01-27 | 2022-04-26 | 山东捷瑞数字科技股份有限公司 | Three-dimensional scene serialization compression method |
Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5729672A (en) * | 1993-07-30 | 1998-03-17 | Videologic Limited | Ray tracing method and apparatus for projecting rays through an object represented by a set of infinite surfaces |
GB2343603A (en) | 1998-11-06 | 2000-05-10 | Videologic Ltd | Shading 3-dimensional computer generated images |
WO2001095257A1 (en) | 2000-06-08 | 2001-12-13 | Imagination Technologies Limited | Tiling and compression for rendering 3d images |
US20010055032A1 (en) | 2000-06-23 | 2001-12-27 | Yasuhiko Saito | Data processing method, recording medium and data processing apparatus |
US20020118188A1 (en) * | 2000-04-04 | 2002-08-29 | Natalia Zviaguina | Method and system for determining visible parts of transparent and nontransparent surfaces of three-dimensional objects |
US6466217B1 (en) * | 1999-12-22 | 2002-10-15 | Intel Corporation | Method and apparatus for ensuring backward compatibility in a bucket rendering system |
US20020171644A1 (en) * | 2001-03-31 | 2002-11-21 | Reshetov Alexander V. | Spatial patches for graphics rendering |
WO2003010717A2 (en) | 2001-07-24 | 2003-02-06 | Imagination Technologies Limited | Three dimensional graphics systems |
US6747649B1 (en) * | 2002-03-19 | 2004-06-08 | Aechelon Technology, Inc. | Terrain rendering in a three-dimensional environment |
US6897858B1 (en) * | 2000-02-16 | 2005-05-24 | Enroute, Inc. | Partial image decompression of a tiled image |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5621430A (en) * | 1994-08-29 | 1997-04-15 | Software Garden, Inc. | Method and apparatus for navigating multiple independent windowed images |
JP2000165634A (en) * | 1994-10-28 | 2000-06-16 | Seiko Epson Corp | Device and method for storing picture data in memory |
US6266733B1 (en) * | 1998-11-12 | 2001-07-24 | Terarecon, Inc | Two-level mini-block storage system for volume data sets |
JP2001209821A (en) * | 2000-01-27 | 2001-08-03 | Mitsubishi Electric Corp | Device and method for processing three-dimensional graphics |
-
2002
- 2002-03-26 GB GB0520082A patent/GB2416100B/en not_active Expired - Lifetime
- 2002-03-26 GB GB0207152A patent/GB2387094B/en not_active Expired - Lifetime
- 2002-06-12 US US10/171,304 patent/US20030184555A1/en not_active Abandoned
-
2003
- 2003-02-04 EP EP03250715A patent/EP1351195A3/en not_active Ceased
- 2003-02-06 JP JP2003068879A patent/JP4564718B2/en not_active Expired - Lifetime
-
2004
- 2004-06-03 US US10/860,335 patent/US7324115B2/en not_active Expired - Lifetime
Patent Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5729672A (en) * | 1993-07-30 | 1998-03-17 | Videologic Limited | Ray tracing method and apparatus for projecting rays through an object represented by a set of infinite surfaces |
GB2343603A (en) | 1998-11-06 | 2000-05-10 | Videologic Ltd | Shading 3-dimensional computer generated images |
US6466217B1 (en) * | 1999-12-22 | 2002-10-15 | Intel Corporation | Method and apparatus for ensuring backward compatibility in a bucket rendering system |
US6897858B1 (en) * | 2000-02-16 | 2005-05-24 | Enroute, Inc. | Partial image decompression of a tiled image |
US20020118188A1 (en) * | 2000-04-04 | 2002-08-29 | Natalia Zviaguina | Method and system for determining visible parts of transparent and nontransparent surfaces of three-dimensional objects |
WO2001095257A1 (en) | 2000-06-08 | 2001-12-13 | Imagination Technologies Limited | Tiling and compression for rendering 3d images |
US20010055032A1 (en) | 2000-06-23 | 2001-12-27 | Yasuhiko Saito | Data processing method, recording medium and data processing apparatus |
US20020171644A1 (en) * | 2001-03-31 | 2002-11-21 | Reshetov Alexander V. | Spatial patches for graphics rendering |
WO2003010717A2 (en) | 2001-07-24 | 2003-02-06 | Imagination Technologies Limited | Three dimensional graphics systems |
US6747649B1 (en) * | 2002-03-19 | 2004-06-08 | Aechelon Technology, Inc. | Terrain rendering in a three-dimensional environment |
Non-Patent Citations (7)
Title |
---|
"Distributed Rendering for Scalable Displays", Greg Humphreys, et al., Conference on high performance networking and computing, Proceedings of the 2000 ACM Conference on Supercomputing Article No. 30, 2000, pp. 1-8 (8 pages). |
"Geometry Compression", Michael Deering, Computer Graphics Proceedings, Aug. 6-11, 1995, pp. 13-20 (8 pages). |
"Optimized Geometry Compression for Real-time Rendering", Mike M. Chow, Proceedings Visualization '97, Oct. 19-24, 1997, Annual IEEE Conference on Visualization (pp. 347-354) (8 pages). |
"Tracking Graphics State for Networked Rendering", Ian Buck, et al., Proceedings of the 2000 Eurographic Workshop on Graphics Hardware, 2000, pp. 87-95 (9 pages). |
European Search Report dated Sep. 21, 2005 (2 pages). |
Search Report dated Aug. 27, 2002 in GB 0207152.0 (3 pages). |
United Kingdom Examination Report dated Feb. 24, 2005 (3 pages). |
Cited By (65)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060177122A1 (en) * | 2005-02-07 | 2006-08-10 | Sony Computer Entertainment Inc. | Method and apparatus for particle manipulation using graphics processing |
US20070146378A1 (en) * | 2005-11-05 | 2007-06-28 | Arm Norway As | Method of and apparatus for processing graphics |
US10657681B2 (en) | 2005-12-05 | 2020-05-19 | Arm Norway As | Method of and apparatus for processing graphics |
US10019820B2 (en) | 2005-12-05 | 2018-07-10 | Arm Norway As | Method of and apparatus for processing graphics |
US20080025646A1 (en) * | 2006-07-31 | 2008-01-31 | Microsoft Corporation | User interface for navigating through images |
US20080027985A1 (en) * | 2006-07-31 | 2008-01-31 | Microsoft Corporation | Generating spatial multimedia indices for multimedia corpuses |
US9122368B2 (en) | 2006-07-31 | 2015-09-01 | Microsoft Technology Licensing, Llc | Analysis of images located within three-dimensional environments |
US7764849B2 (en) * | 2006-07-31 | 2010-07-27 | Microsoft Corporation | User interface for navigating through images |
US20100278435A1 (en) * | 2006-07-31 | 2010-11-04 | Microsoft Corporation | User interface for navigating through images |
US7983489B2 (en) | 2006-07-31 | 2011-07-19 | Microsoft Corporation | User interface for navigating through images |
US20080186318A1 (en) * | 2006-09-29 | 2008-08-07 | Jonathan Redshaw | Memory management for systems for generating 3-dimensional computer images |
US8669987B2 (en) | 2006-09-29 | 2014-03-11 | Imagination Technologies, Ltd. | Memory management for systems for generating 3-dimensional computer images |
US8319783B1 (en) | 2008-12-19 | 2012-11-27 | Nvidia Corporation | Index-based zero-bandwidth clears |
US8330766B1 (en) * | 2008-12-19 | 2012-12-11 | Nvidia Corporation | Zero-bandwidth clears |
US9336623B2 (en) | 2008-12-19 | 2016-05-10 | Imagination Technologies Limited | Multilevel display control list in tile based 3D computer graphics system |
US9384584B2 (en) | 2008-12-23 | 2016-07-05 | Imagination Technologies Limited | Display list control stream grouping in tile based 3D computer graphics system |
US20100177105A1 (en) * | 2009-01-15 | 2010-07-15 | Arm Limited | Methods of and apparatus for processing graphics |
US8681168B2 (en) | 2009-01-15 | 2014-03-25 | Arm Limited | Methods of and apparatus for processing graphics |
US8990275B2 (en) | 2009-09-14 | 2015-03-24 | Thomson Licensing | Method for encoding floating-point data, method for decoding floating-point data, and corresponding encoder and decoder |
US20110227921A1 (en) * | 2010-03-19 | 2011-09-22 | Jonathan Redshaw | Processing of 3D computer graphics data on multiple shading engines |
US8743117B2 (en) * | 2010-03-19 | 2014-06-03 | Imagination Technologies, Limited | Processing of 3D computer graphics data on multiple shading engines |
US11610368B2 (en) * | 2010-04-30 | 2023-03-21 | Imagination Technologies Limited | Tessellation of patches of surfaces in a tile based rendering system |
US11861792B2 (en) | 2010-04-30 | 2024-01-02 | Imagination Technologies Limited | Tessellation of patches of surfaces in a tile based rendering system |
US20160163086A1 (en) * | 2010-09-10 | 2016-06-09 | Imagination Technologies Limited | Random Accessible Lossless Parameter Data Compression for Tile Based 3D Computer Graphics Systems |
CN107103629B (en) * | 2010-09-10 | 2021-02-09 | 想象技术有限公司 | Method and apparatus for compressing vertex parameter data in 3D computer graphics system |
US9292960B2 (en) * | 2010-09-10 | 2016-03-22 | Imagination Technologies Limited | Random accessible lossless parameter data compression for tile based 3D computer graphics systems |
US11043016B2 (en) | 2010-09-10 | 2021-06-22 | Imagination Technologies Limited | Random accessible lossless parameter data compression for tile based 3D computer graphics systems |
US20150109288A1 (en) * | 2010-09-10 | 2015-04-23 | Imagination Technologies, Ltd. | Random Accessible Lossless Parameter Data Compression for Tile Based 3D Computer Graphics Systems |
US10380781B2 (en) | 2010-09-10 | 2019-08-13 | Imagination Technologies Limited | Random accessible lossless parameter data compression for tile based 3D computer graphics systems |
US20190318524A1 (en) * | 2010-09-10 | 2019-10-17 | Imagination Technologies Limited | Random Accessible Lossless Parameter Data Compression for Tile Based 3D Computer Graphics Systems |
US11625883B2 (en) | 2010-09-10 | 2023-04-11 | Imagination Technologies Limited | Random accessible lossless parameter data compression for tile based 3D computer graphics systems |
CN107103629A (en) * | 2010-09-10 | 2017-08-29 | 想象技术有限公司 | The method and apparatus of vertex parameter data is compressed in 3D computer graphics systems |
US9013473B2 (en) | 2011-02-09 | 2015-04-21 | Samsung Electronics Co., Ltd. | Graphic processing unit and method for decompressing data |
US20120300229A1 (en) * | 2011-05-24 | 2012-11-29 | Chung-Hui Kuo | Depositing texture on receiver |
US8605333B2 (en) * | 2011-05-24 | 2013-12-10 | Eastman Kodak Company | Depositing texture on receiver |
US9754384B2 (en) * | 2012-04-18 | 2017-09-05 | Suzhou Superengine Graphics Software Technology Development Co., Ltd. | Relevant method and device for compression, decompression and progressive transmission of spatial data |
US20150091929A1 (en) * | 2012-04-18 | 2015-04-02 | Suzhou Superengine Graphics Software Technology Development Co., Ltd. | Relevant method and device for compression, decompression and progressive transmission of spatial data |
US9424685B2 (en) | 2012-07-31 | 2016-08-23 | Imagination Technologies Limited | Unified rasterization and ray tracing rendering environments |
US10217266B2 (en) | 2012-07-31 | 2019-02-26 | Imagination Technologies Limited | Unified rasterization and ray tracing rendering environments |
US11587281B2 (en) | 2012-07-31 | 2023-02-21 | Imagination Technologies Limited | Unified rasterization and ray tracing rendering environments |
US10909745B2 (en) | 2012-07-31 | 2021-02-02 | Imagination Technologies Limited | Unified rasterization and ray tracing rendering environments |
US9317948B2 (en) | 2012-11-16 | 2016-04-19 | Arm Limited | Method of and apparatus for processing graphics |
US9418616B2 (en) * | 2012-12-20 | 2016-08-16 | Nvidia Corporation | Technique for storing shared vertices |
US20140176589A1 (en) * | 2012-12-20 | 2014-06-26 | Nvidia Corporation | Technique for storing shared vertices |
US11657565B2 (en) | 2012-12-20 | 2023-05-23 | Imagination Technologies Limited | Hidden culling in tile-based computer generated images |
US10366530B2 (en) | 2012-12-20 | 2019-07-30 | Imagination Technologies Limited | Hidden culling in tile-based computer generated images |
US9293109B2 (en) | 2012-12-20 | 2016-03-22 | Nvidia Corporation | Technique for storing shared vertices |
US9805500B2 (en) | 2012-12-20 | 2017-10-31 | Imagination Technologies Limited | Hidden culling in tile-based computer generated images |
US11182952B2 (en) | 2012-12-20 | 2021-11-23 | Imagination Technologies Limited | Hidden culling in tile-based computer generated images |
US10665009B2 (en) | 2012-12-20 | 2020-05-26 | Imagination Technologies Limited | Hidden culling in tile-based computer generated images |
US11574434B2 (en) | 2013-03-15 | 2023-02-07 | Imagination Technologies Limited | Producing rendering outputs from a 3-D scene using volume element light transport data |
US11861786B2 (en) | 2013-03-15 | 2024-01-02 | Imagination Technologies Limited | Determining lighting information for rendering a scene in computer graphics using illumination point sampling |
US9704283B2 (en) | 2013-03-15 | 2017-07-11 | Imagination Technologies Limited | Rendering with point sampling and pre-computed light transport information |
US10453245B2 (en) | 2013-03-15 | 2019-10-22 | Imagination Technologies Limited | Query resolver for global illumination of 3-D rendering |
US11288855B2 (en) | 2013-03-15 | 2022-03-29 | Imagination Technologies Limited | Determining lighting information for rendering a scene in computer graphics using illumination point sampling |
US11551326B2 (en) | 2013-04-02 | 2023-01-10 | Imagination Technologies Limited | Tile-based graphics |
US9934549B2 (en) | 2013-04-02 | 2018-04-03 | Imagination Technologies Limited | Tile-based graphics |
US11954759B2 (en) | 2013-04-02 | 2024-04-09 | Imagination Technologies Limited | Tile-based graphics |
US9928563B2 (en) | 2013-04-02 | 2018-03-27 | Imagination Technologies Limited | Tile-based graphics |
US9830729B2 (en) * | 2013-05-09 | 2017-11-28 | Samsung Electronics Co., Ltd. | Graphic processing unit for image rendering, graphic processing system including the same and image rendering method using the same |
US20140333620A1 (en) * | 2013-05-09 | 2014-11-13 | Yong-Ha Park | Graphic processing unit, graphic processing system including the same and rendering method using the same |
US10204391B2 (en) | 2013-06-04 | 2019-02-12 | Arm Limited | Method of and apparatus for processing graphics |
US11010959B2 (en) | 2016-04-29 | 2021-05-18 | Arm Limited | Graphics processing systems |
US10417787B2 (en) | 2017-02-15 | 2019-09-17 | Microsoft Technology Licensing, Llc | Index buffer block compression |
US11748839B2 (en) * | 2020-04-16 | 2023-09-05 | Samsung Electronics Co., Ltd. | Efficient fast random access enabled geometry attribute compression mechanism |
Also Published As
Publication number | Publication date |
---|---|
US20040222996A1 (en) | 2004-11-11 |
JP2003296747A (en) | 2003-10-17 |
GB2387094A (en) | 2003-10-01 |
GB2416100B (en) | 2006-04-12 |
GB0520082D0 (en) | 2005-11-09 |
JP4564718B2 (en) | 2010-10-20 |
EP1351195A2 (en) | 2003-10-08 |
US20030184555A1 (en) | 2003-10-02 |
EP1351195A3 (en) | 2005-11-16 |
GB2416100A (en) | 2006-01-11 |
GB0207152D0 (en) | 2002-05-08 |
GB2387094B (en) | 2005-12-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7324115B2 (en) | Display list compression for a tiled 3-D rendering system | |
US7202872B2 (en) | Apparatus for compressing data in a bit stream or bit pattern | |
US20230245372A1 (en) | Random Accessible Lossless Parameter Data Compression for Tile Based 3D Computer Graphics Systems | |
US6243081B1 (en) | Data structure for efficient retrieval of compressed texture data from a memory system | |
EP1074945B1 (en) | Method and apparatus for controlling compressed Z information in a video graphics system | |
US8681168B2 (en) | Methods of and apparatus for processing graphics | |
US7944441B2 (en) | Compression and decompression of data using plane equations | |
US6157743A (en) | Method for retrieving compressed texture data from a memory system | |
US8004521B2 (en) | Graphic rendering method and system comprising a graphic module | |
US5886701A (en) | Graphics rendering device and method for operating same | |
US6326964B1 (en) | Method for sorting 3D object geometry among image chunks for rendering in a layered graphics rendering system | |
WO2000019377B1 (en) | Graphics processor with deferred shading | |
US7764833B2 (en) | Method and apparatus for anti-aliasing using floating point subpixel color values and compression of same | |
US20090091577A1 (en) | Compression of Multiple-Sample-Anti-Aliasing Title Data in a Graphics Pipeline | |
US9619937B2 (en) | Methods and apparatus for processing computer graphics primitives in tile-based graphics rendering system | |
WO1990013876A1 (en) | Method and apparatus for manipulating digital video data | |
US20050057564A1 (en) | Mechanism for reducing Z buffer traffic in three-dimensional graphics processing | |
US8736627B2 (en) | Systems and methods for providing a shared buffer in a multiple FIFO environment | |
US20230306661A1 (en) | Graphics processing | |
EP1139291A2 (en) | Method for visualization of time sequences of 3D optical flurescence microscopy images | |
US6285373B1 (en) | Method and apparatus for texture transmission and storage | |
US6768493B1 (en) | System, method and article of manufacture for a compressed texture format that is efficiently accessible | |
JP3104643B2 (en) | Image processing apparatus and image processing method | |
US20040196284A1 (en) | Method and apparatus for improving depth information communication bandwidth in a computer graphics system | |
US20030123089A1 (en) | Graphics state bandwidth reduction for zone rendering |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
FPAY | Fee payment |
Year of fee payment: 8 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 12 |