Method and tiling engine for tiling primitives in a graphics processing system

Abstract

Methods and tiling engines for tiling primitives in a graphics processing system are provided. A method includes receiving a plurality of primitive tiles, each primitive tile including one or more primitive sections, each primitive section including one or more primitives; determining, for each primitive section of a received primitive tile, which primitives of the primitive section fall at least partially within a boundary of a tile; adding, for each primitive tile that includes at least one primitive that falls at least partially within the boundary of a tile, information identifying the primitive tile to a display list of the tile; adding, for each identified primitive tile, information to the display list identifying each primitive section of the primitive tile that includes at least one primitive that falls at least partially within the boundary of a tile; and adding, for each identified primitive section, information to the display list identifying primitives of the primitive section that fall at least partially within the boundary of a tile.

Description

Technical Field

[0001] This application relates to graphics processing systems, and more specifically to methods and tiling engines for tiling primitives in graphics processing systems. Background Technology

[0002] A graphics processing system is configured to receive graphics data, for example, from an application (e.g., a game application) running on a computer system, and render an image from the graphics data to provide a rendered output. For example, the application may generate a 3D model of a scene and output geometric data representing objects in the scene. Specifically, the application may represent each object using one or more primitives (i.e., simple geometric shapes, such as, but not limited to, rectangles, triangles, lines, and points that can be textured), said primitives being defined by the positions of one or more vertices. In these cases, the geometric data output by the application may contain information identifying each vertex (e.g., the vertex's coordinates in world space) and information indicating the primitives formed by the vertices. The graphics processing system then converts the received geometric data into an image that can be displayed on a screen.

[0003] Graphics processing systems can implement, for example, instant-mode rendering (IMR) or tile-based rendering (TBR). In IMR, the entire scene is rendered as a whole. In contrast, in TBR, the scene is rendered using a rendering space divided into sub-segments called tiles, where at least a portion of the rendering process can be performed independently for each tile. Tiles can have any suitable shape, but are typically rectangular (where the term "rectangle" includes squares). The advantage of TBR is that fast, on-chip memory can be used during rendering for color, depth, and stencil buffer operations, which allows for a significant reduction in system memory bandwidth compared to IMR, without requiring sufficiently large on-chip memory to store data for the entire scene simultaneously.

[0004] TBR involves two key phases: a geometry processing phase and a rasterization phase. During the geometry processing phase, geometry data (e.g., vertices defining primitives) received from an application (e.g., a game application) is transformed from world-space coordinates to screen-space coordinates. A per-tile list of transformed primitives (e.g., triangles) that at least partially fall within the tile's boundaries is then created. During the rasterization phase, each tile is rendered individually (i.e., the transformed primitives are mapped to pixels and a color is assigned to each pixel within the tile). This may include identifying which primitive(s) are visible at each pixel. The color of the pixel can then be determined by the appearance of the visible primitives at each pixel, which may be defined by a texture applied to the pixel and / or a pixel shader program running on that pixel. The pixel shader program describes the operations to be performed for a given pixel. Rendering each tile individually allows the graphics processing system to retrieve only the transformed primitive data associated with that tile when rendering a particular tile during the rasterization phase, keeping bandwidth requirements for memory (e.g., intermediate buffers) low. Once a color value has been assigned to each pixel in a tile, the tile's color value is written to memory (e.g., a frame buffer). Once the entire scene has been rendered (i.e., once color values ​​have been determined for all the pixels in all tiles), the scene can be displayed on the screen, for example.

[0005] Figure 1 An example TBR graphics processing system 100 is shown. System 100 includes memories 1021, 1022, 1023, and 1024, geometry processing logic 104, and rasterization logic 106. Two or more of memories 1021, 1022, 1023, and 1024 can be implemented in the same physical memory unit.

[0006] The geometry processing logic 104 implements the geometry processing phase of TBR. The geometry processing logic 104 includes transformation logic 108, a primitive block generator 110, and a tiling engine 112. Transformation logic 108 receives geometry data (e.g., vertices, primitives, and / or patches) from an application (e.g., a game application) and transforms the geometry data into a rendering space (e.g., screen space). Transformation logic 108 may also perform functions such as clipping and culling to remove geometry data (e.g., primitives or patches) falling outside the view frustum, and / or apply lighting / attribute processing known to those skilled in the art.

[0007] Primitive block generator 110 groups transformed primitives (i.e., their associated transformed geometric data) into primitive blocks and stores these primitive blocks in memory 1022. A primitive block is a data structure in which one or more primitives (e.g., their associated transformed geometric data) are stored together. Storing primitives in primitive blocks allows for more efficient storage of the transformed geometric data of a set of primitives in memory 1022. Specifically, the transformed geometric data for primitives typically includes transformed vertex information for multiple vertices, where these vertices can be shared (or are common to multiple primitives). Therefore, in cases where multiple primitives in the same primitive block share vertices, the data associated with those vertices only needs to be stored once in the primitive block.

[0008] Transformed primitives can be grouped into primitive blocks using any suitable method or technique. For example, in some cases, transformed primitives can be grouped into primitive blocks based on the order in which they arrive at the primitive block generator 110. In these cases, each primitive block may have a maximum size (e.g., in bits or bytes), a maximum number of primitives that can belong to the primitive block, and / or a maximum number of vertices that can belong to the primitive block. The primitive block generator 110 can then be configured to add primitives to the current primitive block until one or more of the maximum values ​​are reached.

[0009] In other cases, primitives can be grouped into primitive blocks based on their position in the rendering space, such that primitives with spatially similar positions in the rendering space reside in the same primitive block. For example, the rendering space can be divided into multiple macroregions that can surround multiple tiles (e.g., a 1024×1024 rendering space divided into 1024 32×32 tiles can have 16 256×256 macroregions), and the primitive block generator 110 can be configured to maintain primitive blocks for each macroregion. Then, when the primitive block generator 110 receives a primitive, it determines which macroregion(s) the primitive at least partially falls within. If the primitive block generator 110 determines that the primitive at least partially falls within only one macroregion, the primitive block generator 110 can place the primitive (i.e., the transformed geometric data associated with the primitive) in a primitive block of that macroregion. If the primitive block generator 110 determines that a primitive falls within more than one macro region, the primitive block generator 110 can be configured to (i) select one of the macro regions in which the primitive falls (e.g., a first macro region) and place the primitive (i.e., the associated transformed geometric data) in a primitive block of the selected macro region; or (ii) place the primitive (i.e., the associated transformed geometric data) in a primitive block of each macro region in which the primitive falls at least partially.

[0010] The primitive blocks, along with information identifying their location in memory, are provided to the tiling engine 112. The tiling engine 112 generates a list of transformed primitives for each tile from the transformed geometry data, the transformed primitives at least partially falling within the tile. This list may be referred to as a display list or a transformed display list. In some cases, the transformed display list may include pointers or links to transformed geometry data (e.g., vertex data) associated with primitives at least partially falling within the tile. For example, Figure 2 An example display list 202 for tiles is shown, comprising primitive block entries 204, 206 for each primitive block, each primitive block comprising at least one primitive that at least partially falls within the boundary of the tile. Each primitive block entry 204, 206 includes information 208 identifying the location of the primitive block in memory (e.g., the address of the primitive block in memory) and information 210 identifying which primitives of the primitive block at least partially fall within the boundary of the tile. Figure 2 As shown, the information identifying which primitives of a primitive block at least partially fall within the block can be in the form of a mask, which includes bits of each primitive in the primitive block indicating whether the primitive falls at least partially within the boundary of the block.

[0011] return Figure 1 The rasterization logic 106 implements the rasterization stage of TBR. Specifically, the rasterization logic 106 obtains a display list of tiles from memory 1023, and then obtains the transformed geometric structure data of the primitives falling within the tiles and indicated by the display list of tiles from memory 1022, rendering the primitives in a tile-by-tile manner; and renders the primitives of the tiles based on the transformed geometric structure data.

[0012] In some cases, rasterization logic 106 may include rasterizer 114, hidden surface removal (HSR) logic 116, and texturing / shading logic 118. In these cases, rasterizer 114 retrieves each display list from memory 1023 and, for each display list, retrieves transformed geometric data from memory 1022 for primitives falling within tiles specified by the corresponding display list, converting each primitive into a set of primitive fragments. The term "fragment" is used herein to mean a sample of primitives at a sampling point that will be processed to render pixels of an image. In some examples, a one-to-one mapping from pixels to fragments may exist. However, in other examples, fragments may be more than pixels, and this oversampling may allow for higher-quality rendering of pixel values, for example, by facilitating anti-aliasing and other filters that can be applied to multiple fragments for rendering each pixel value.

[0013] The primitive fragments of a specific tile are then provided to HSR logic 116, which removes hidden (e.g., hidden by other primitive fragments) primitive fragments by performing a depth test on the primitive fragments. The remaining fragments (after the hidden surfaces are removed) are then passed to texturing / shading logic 118, which performs texturing and / or shading on the primitive fragments to determine the pixel values ​​of the rendered image. The rendered pixel values ​​of the tile are then stored in memory 1024 (e.g., a framebuffer).

[0014] Rasterization logic 106 processes each tile, and once the entire image has been rendered and stored in memory 1024 (e.g., a frame buffer), the image can be output from graphics processing system 100 and used in any suitable manner, such as displaying on a monitor, storing in memory, or transferring to another device. This is in the sense that the fragment is processed by HSR logic 116 before being processed by texturing / shading logic 118. Figure 1 The TBR graphics processing system 100 shown is a "deferred" rendering system. In other examples, the graphics processing system may not be a deferred rendering system, in which case texture / shading will be applied to fragments before HSR is applied to them.

[0015] Although geometry processing logic is shown as separate from rasterization logic in the diagram, in some implementations, geometry processing logic and rasterization logic may share some resources. For example, a graphics processing system may use a unified shading approach, where the same physical execution unit can be used to execute instructions used in the geometry processing stage (e.g., perform vertex processing) and instructions used in the rasterization stage (e.g., perform fragment processing).

[0016] The implementation schemes described below are provided by way of example only and do not limit the ways in which any or all of the shortcomings of known methods and systems for storing primitives in a graphics processing system can be addressed. Summary of the Invention

[0017] This summary is provided to introduce some concepts that are further described in the following detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0018] This document describes a method and a tiling engine for tiling primitives in a graphics processing system. The method includes: receiving a plurality of primitive blocks, each primitive block comprising one or more primitive segments, each primitive segment comprising one or more primitives; for each primitive segment of the received primitive blocks, determining which primitives in the primitive segment at least partially fall within a boundary of the block; for each primitive block including at least one primitive at least partially falling within the boundary of the block, adding information identifying the primitive block to a display list of the block; for each identified primitive block, adding information to the display list, the information identifying each primitive segment of the primitive block including at least one primitive at least partially falling within the boundary of the block; and for each identified primitive segment, adding information to the display list, the information identifying primitives in the primitive segment at least partially falling within the boundary of the block.

[0019] A first aspect provides a tiling engine for a graphics processing system, wherein a rendering space is divided into a plurality of tiles, the tiling engine comprising: tiling logic configured to: receive a plurality of primitive blocks, each primitive block comprising one or more primitive segments, each primitive segment comprising one or more primitives; and for each primitive segment of a received primitive block, determining whether primitives of the primitive segment at least partially fall within the boundary of a block among the plurality of tiles; and a display list generator configured to: for each primitive block comprising at least one primitive at least partially falling within the boundary of the tile, add information identifying the primitive block to a display list of the tile; for each identified primitive block, add information to the display list, the information identifying each primitive segment of the primitive block comprising at least one primitive at least partially falling within the boundary of the tile; and for each identified primitive segment, add information to the display list, the information identifying primitives in the primitive segment at least partially falling within the boundary of the tile.

[0020] The information identifying a primitive segment may include information identifying the location of the primitive segment in memory.

[0021] The display list generator can be configured to: if a first primitive segment of a primitive block includes at least one primitive that falls at least partially within the boundary of the primitive block, then add a primitive block entry of a first type to the display list, the first type of primitive block entry including information identifying the primitive block and information identifying the first primitive segment as a primitive segment including at least one primitive that falls at least partially within the boundary of the primitive block; and if the first primitive segment of the primitive block does not include at least one primitive that falls at least partially within the boundary of the primitive block, then add a primitive block entry of a second type to the display list, the second type of primitive block entry including information identifying the primitive block and information indicating that the first primitive segment does not include at least one primitive that falls at least partially within the boundary of the primitive block.

[0022] The first type of primitive block entry may have a set of tags, while the second type of primitive block entry may not have a set of tags.

[0023] The display list generator can be configured to add a primitive segment entry to the display list of a primitive block for each primitive segment, excluding the first primitive segment, that includes at least one primitive that at least partially falls within the boundary of the block.

[0024] The display list generator can be configured to add a primitive segment entry to the display list for each primitive segment of a primitive block that includes at least one primitive that falls at least partially within the boundary of the primitive block.

[0025] Each primitive segment entry may include information that identifies the location of the corresponding primitive segment in memory.

[0026] The information that identifies the location of the corresponding primitive segment in the memory can be the offset from the location of the primitive block in the memory.

[0027] The information identifying a primitive that falls at least partially within the boundary of the tile may include a primitive mask, the primitive mask including bits of each primitive in the primitive segment.

[0028] The information that identifies a primitive block can be its address in memory.

[0029] A second aspect provides a method for generating a display list of tiles for rendering space, the method comprising: receiving a plurality of primitive tiles, each primitive tile including one or more primitive segments, each primitive segment including one or more primitives; for each primitive segment of the received primitive tiles, determining which primitives of the primitive segment at least partially fall within a boundary of the tile; for each primitive tile including at least one primitive that falls at least partially within the boundary of the tile, adding information of the primitive tile for each primitive segment to a display list of the tile; for each identified primitive tile, adding information to the display list, the information identifying each primitive segment of the primitive tile including at least one primitive that falls at least partially within the boundary of the tile; and for each identified primitive segment, adding information to the display list, the information identifying primitives in the primitive segment that fall at least partially within the boundary of the tile.

[0030] The information identifying a primitive segment may include information identifying the location of the primitive segment in memory.

[0031] If a first primitive segment of a primitive block includes at least one primitive that falls at least partially within the boundary of the primitive block, a primitive block entry of a first type can be added to the display list. This first type of primitive block entry includes information identifying the primitive block and information identifying the first primitive segment as a primitive segment that includes at least one primitive that falls at least partially within the boundary of the primitive block. And if the first primitive segment of a primitive block does not include at least one primitive that falls at least partially within the boundary of the primitive block, a primitive block entry of a second different type can be added to the display list. This second different type of primitive block entry includes information identifying the primitive block and information indicating that the first primitive segment does not include at least one primitive that falls at least partially within the boundary of the primitive block.

[0032] The first type of primitive block entry may have a set of tags, while the second type of primitive block entry may not have a set of tags.

[0033] For each primitive segment that falls at least partially within the boundary of the primitive block, excluding the first primitive segment, a primitive segment entry can be added to the display list.

[0034] For each element segment that includes at least one element that falls at least partially within the boundary of the tile, an element segment entry can be added to the display list.

[0035] Each primitive segment entry may include information that identifies the location of the corresponding primitive segment in memory.

[0036] The information that identifies the location of the corresponding primitive segment in the memory can be the offset from the location of the primitive block in the memory.

[0037] The information identifying a primitive within a primitive segment that at least partially falls within the boundary of the tile may include a primitive mask comprising bits of each primitive within the primitive segment.

[0038] The information that identifies a primitive block can be its address in memory.

[0039] The third aspect provides a tiling engine configured to perform the methods described in the second aspect.

[0040] The fourth aspect provides a graphics processing system that includes the tiling engine described in the first or third aspect.

[0041] The primitive block generator, tiling engine, and graphics processing system described herein can be embodied in hardware on an integrated circuit. A method can be provided for manufacturing an integrated circuit embodying the primitive block generator, tiling engine, or graphics processing system described herein at an integrated circuit manufacturing system. An integrated circuit-defined dataset can be provided that, when processed in an integrated circuit manufacturing system, configures the system to manufacture an integrated circuit embodying the tiling engine, primitive block generator, or graphics processing system described herein. A non-transitory computer-readable storage medium can be provided storing a computer-readable description thereon of the primitive block generator, tiling engine, or graphics processing system described herein, which, when processed in an integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture an integrated circuit embodying the primitive block generator, tiling engine, or graphics processing system.

[0042] An integrated circuit manufacturing system may be provided, comprising: a non-transitory computer-readable storage medium storing a computer-readable description of a primitive block generator, tiling engine, or graphics processing system as described herein; a layout processing system configured to process the computer-readable description to generate a circuit layout description of an integrated circuit embodying the primitive block generator, tiling engine, or graphics processing system; and an integrated circuit generation system configured to manufacture an integrated circuit embodying the tiling engine or graphics processing system based on the circuit layout description.

[0043] Computer program code for performing the methods described herein may be provided. A non-transitory computer-readable storage medium having computer-readable instructions stored thereon may be provided, which, when executed at a computer system, cause the computer system to perform the methods described herein.

[0044] As will be apparent to those skilled in the art, the above features can be appropriately combined, and can be combined with any aspect of the examples described herein. Attached Figure Description

[0045] The example will now be described in detail with reference to the accompanying drawings, in which:

[0046] Figure 1 This is a block diagram of an example tile-based rendering graphics processing system;

[0047] Figure 2 This is a schematic diagram of the first example displaying the list;

[0048] Figure 3 It is a schematic diagram of a set of example primitive blocks, where each primitive block includes a single primitive segment;

[0049] Figure 4 It is a schematic diagram of an example primitive block with multiple primitive segments;

[0050] Figure 5 This is a schematic diagram of example graph data and vertex data sub-segments;

[0051] Figure 6 It is configured to be used for generation Figure 4 A block diagram of an example primitive block generator;

[0052] Figure 7 Is Figure 4 A flowchart of an example method for storing primitives in a primitive block;

[0053] Figure 8 It shows the basis Figure 7 A schematic diagram illustrating the processing of the first example primitive in the method;

[0054] Figure 9 It shows the basis Figure 7 A schematic diagram illustrating the processing of the second example primitive in the method;

[0055] Figure 10 It shows the basis Figure 7 A schematic diagram illustrating the processing of the third example primitive in the method;

[0056] Figure 11 This is a block diagram of an example tiling engine;

[0057] Figure 12 This is a schematic diagram illustrating the bounding box tiling method;

[0058] Figure 13 It is shown by Figure 11 The first example generated by the tiling engine is a schematic diagram of the display list;

[0059] Figure 14 It is shown by Figure 11 The second example generated by the tiling engine is a schematic diagram of the display list;

[0060] Figure 15 It is shown by Figure 11 The third example generated by the tiling engine is a schematic diagram of the display list;

[0061] Figure 16 This is a flowchart of an example method for generating a display list of tiles;

[0062] Figure 17 It includes Figure 6 primitive block generator and Figure 11 A block diagram of an example graphics processing system with a tiling engine;

[0063] Figure 18 This is a block diagram of an example computer system that can implement the primitive block generator, tiling engine, and / or graphics processing system described herein; and

[0064] Figure 19 This is a block diagram of an example integrated circuit manufacturing system used to generate integrated circuits that embody the primitive block generator, tiling engine, and / or graphics processing system described herein.

[0065] The accompanying drawings illustrate various examples. Those skilled in the art will understand that the element boundaries (e.g., boxes, groups of boxes, or other shapes) shown in the drawings represent one example of a boundary. In some examples, it may be that one element can be designed as multiple elements, or multiple elements can be designed as one element. Where appropriate, common reference numerals are used throughout the drawings to indicate similar features. Detailed Implementation

[0066] The following description is given by way of example to enable those skilled in the art to make and use the invention. The invention is not limited to the embodiments described herein, and various modifications to the disclosed embodiments will be readily apparent to those skilled in the art. Embodiments are described by way of example only.

[0067] As described above, in some TBR graphics processing systems, transformed primitives generated during the geometry processing stage are grouped into primitive blocks, which are stored in memory. The display list for each block can then include primitive block entries for each block, the primitive segments comprising at least one primitive falling within the boundary of the block. Each primitive block entry can identify the block and primitives associated with rendering the block (e.g., primitives in the block that at least partially fall within the block's boundary). During the rasterization stage, the blocks are rendered individually by retrieving the display list for each block and then retrieving and processing the transformed primitives identified in the display list as associated with rendering the block. This can include, for each block, acquiring each primitive block identified in the corresponding display list; and then processing the primitives of each acquired primitive block identified in the display list as associated with rendering the block.

[0068] In some cases, each transformed primitive is associated with state data specifying how the primitive will be rasterized during the rasterization stage. In these cases, primitives can be grouped into primitive blocks in any way, provided that (i) all primitives in a primitive block share the same state data; and (ii) the number of vertices in a primitive block does not exceed a vertex threshold and / or the number of primitives in a primitive block does not exceed a primitive threshold. The vertex threshold and / or primitive threshold can be based on the hardware limitations of the graphics processing system. For example, in some cases, the vertex threshold can be based on the maximum number of vertices that can be stored in temporary memory. Note that while such systems may be known to the applicant, this is not an admission that such systems are known to the public.

[0069] Now for reference Figure 3 It shows example primitive blocks 3020, 3021, and 3022 that can be generated in such systems. Each primitive block 3020, 3021, and 3022 includes a header segment 304, a status data segment 306, and a primitive segment 308.

[0070] Header section 304 includes information about primitive blocks, such as, but not limited to, the number of primitives in the primitive block and / or the number of vertices in the primitive block.

[0071] State data segment 306 includes state data for primitives within a primitive block. The state data can be described as a method used to render the primitives within the primitive block. For example, the state data may include, but is not limited to, information identifying depth comparison mode, blending state, texture state, and / or primitive type.

[0072] Primitive segment 308 includes geometrical data of one or more primitives. In some cases, primitive segment 308 may include a primitive data sub-segment 310 and a vertex data sub-segment 312. Primitive data sub-segment 310 may include a primitive entry for each primitive in a primitive block, identifying the vertices forming the primitive. In some cases, an index may be assigned to each vertex in vertex data sub-segment 312, and each primitive entry may include a list of vertex indices. The index may be a local index for the primitive block (which may be referred to herein as a local index). For example, if the primitive is a triangle and the first primitive in the primitive block is formed by vertices associated with indices 0, 1, and 3, then the primitive entry for the primitive may list vertex indices 0, 1, and 3. Each vertex index may act as a pointer to the portion of vertex data sub-segment 312 associated with the vertex.

[0073] Vertex data subsection 312 includes a vertex entry for each vertex used to form primitives in the primitive block. Each entry may include location data describing the corresponding vertex in rendering space (e.g., a set of coordinates in rendering space, such as X, Y, and Z coordinates). Each entry may also include a set of attributes describing the appearance of the vertex, such as texture coordinates (U, V) and / or a primary color applied to the vertex. Vertex data may be stored in a compressed or uncompressed format in vertex data subsection 312. Any suitable compression algorithm or technique may be used to compress vertex data.

[0074] If the vertex data can be stored in a compressed format in the vertex data sub-segment 312, the primitive section 308 may also include a vertex compression sub-segment 314, which identifies whether the vertex data has been compressed, and if so, identifies the parameters / configuration of the compression algorithm used to compress the vertex data.

[0075] In some graphics processing systems, especially low-budget systems with limited silicon area, the memory used to temporarily store primitives before they are stored in main memory has become smaller. This lowers the vertex threshold and / or primitive threshold, resulting in smaller primitive blocks. Smaller primitive blocks reduce the compression ratio of compressed vertex data. This also means that not all primitives from the same draw call can be placed in the same primitive block, resulting in multiple consecutive primitive blocks with the same state data.

[0076] Efforts have been made to reduce duplicate state data by storing different combinations of state data in memory (e.g., lookup tables) and storing information in memory indicating the location of related state data (e.g., an index to the lookup table). For example, state data may include information identifying the state of multiple parameters, each parameter being defined by multiple bits. Instead of explicitly including information for each parameter in the primitive block, each possible combination of state data can be stored in a state data table in memory, and the state data segment 306 of each primitive block may include an index or pointer to one of the entries in the state data table. While this reduces the amount of duplicate data stored, it does not eliminate duplicate data.

[0077] Therefore, this paper describes a primitive block structure, as well as methods and primitive block generators for storing primitives in such primitive blocks, wherein each primitive block comprises a single state data segment and one or more primitive segments, wherein each primitive segment comprises transformed geometric data for one or more primitives. Each primitive block segment can have a maximum number of primitives and / or vertices. The primitive block format described in this paper reduces state data duplication because it allows more primitives to share the same state data; and it also allows primitives to be compressed and stored in smaller groups.

[0078] Furthermore, in some cases, the texturing / shading logic 118 of the rasterization logic 106 can be implemented using one or more SIMD (Single Instruction Multiple Data) processors because the texturing / shading logic typically applies the same transformations (e.g., the same shaders) to multiple vertices / fragments. As those skilled in the art know, a SIMD processor comprises multiple processing elements, each performing the same operation on a different dataset. Each processing element that processes the input data set is referred to as a "channel" of the SIMD processor. The SIMD processor operates most efficiently when each channel is "full" (i.e., processing data). In some cases, the SIMD processor of the texturing / shading logic 118 may include 32 channels. Figure 3 The primitives in the structure shown are stored in primitive blocks, which often results in incomplete SIMD channels in the texturing / shading logic 118 and / or may take time to obtain the SIMD channel data and put it together. Since the primitive block format described herein allows each primitive block to include more primitives, it makes it easier to fill the SIMD channels with fragments of primitives from different primitive segments within a primitive block during the rasterization stage (e.g., during the texturing / shading stage).

[0079] Therefore, the primitive block structure described herein allows graphics processing systems to utilize smaller primitive / vertex groups when advantageous (e.g., when generating the icon blocks in the geometry processing stage) and to utilize the benefits of larger primitive / vertex groups when advantageous (e.g., when filling SIMD channels in the rasterization stage).

[0080] Now for reference Figure 4 This illustrates example primitive block 402 according to an implementation scheme. (The last part is incomplete and likely refers to a different concept.) Figure 3 Similar to primitive blocks 3020, 3021, and 3022, primitive block 402 includes a header segment 404 and a status data segment 406. However, although Figure 3 The primitive blocks 3020, 3021, and 3022 each contain only a single primitive segment 308, but Figure 4 The primitive block 402 may include multiple primitive segments 408 (e.g., N primitive segments, where N is an integer greater than or equal to one). All primitive segments 408 share the same state data.

[0081] Header section 404 includes information about primitive blocks, such as, but not limited to, the number of primitive sections in the block and the number of primitives and / or vertices in each primitive section. In some cases, header section 404 may also include the offset address of each primitive section.

[0082] and Figure 3 Similar to state data segment 306, state data segment 406 describes how primitives in a primitive block will be rendered. For example, state data may include, but is not limited to, information identifying depth comparison mode, blending state, texture state, and / or primitive type. In some cases, state data segment 406 may include information identifying the value of each of a plurality of state parameters. In other cases, different combinations of state parameters may be stored in memory (e.g., a lookup table), and state data segment 406 of primitive block 402 may include pointers or indices to specific combinations of state parameters. In some cases, storing pointers to specific combinations of state parameters in the state data segment, rather than storing the actual state parameter values, can significantly reduce the size of the state data segment.

[0083] Each graphic element segment is 4080, 4081...408 N Can correspond to Figure 3 The primitive segment is 308. For example, each primitive segment is 4080, 4081...408. NThis may include transformed geometric data of one or more transformed primitives sharing the same state data. The number of transformed primitives in each primitive segment may be limited by the maximum number of primitives in each primitive segment and / or the maximum number of vertices in each primitive segment. For example, each primitive segment may have a maximum of 64 primitives and / or a maximum of 32 or 64 vertices. The maximum number of primitives and / or vertices may be set based on the hardware limitations of the graphics processing system, specifically its primitive block generator. For example, the maximum number of primitives and / or vertices in each primitive segment may be based on the maximum number of primitives and / or vertices that the primitive block generator can temporarily store.

[0084] and Figure 3 The primitive segments are similar, each primitive segment is 4080, 4081... Figure 4 408 N This includes the graph data sub-segment 410 and the vertex data sub-segment 412, which can correspond to the above reference. Figure 3 The graph data sub-segment 410 and vertex data sub-segment 412 are described. Data relating to each primitive in the graph data sub-segment 410 can be added to the graph data sub-segment 410, and data relating to each vertex that forms or defines at least one primitive in the graph data sub-segment 412 can be added to the vertex data sub-segment 412.

[0085] An index from 0 to n-1 can be assigned to each vertex in a primitive segment, where n is the number of vertices in the primitive segment. For example, the first vertex added to the primitive segment can be assigned index 0, the second vertex added to the primitive segment can be assigned index 1, and so on. Since the index is local to the primitive segment, the index assigned to a vertex in the primitive segment can be called a local index. The local index can be used to identify the location of information related to the corresponding vertex in the vertex data sub-segment 412. It should be noted that the local index assigned to a vertex in the primitive segment may be different from the global index assigned to a vertex. For example, vertices in rendering can be assigned a global index that reflects the order of vertices in rendering, or reflects the order of vertices within a set of vertices in rendering. Now refer to Figure 5 It displays the primitive data and vertex data sub-segments 410 and 412 of example primitive segments including two triangular primitives 502 and 504. The first primitive 502 is defined by vertices with global indices V1, V2, and V3, and the second primitive 504 is defined by vertices with global indices V7, V8, and V9. These six vertices are added to the primitive block and can be assigned local indices V0, V1, V2, V3, V4, and V5, respectively.

[0086] Vertex data sub-segment 412 may include a vertex entry for each vertex, the vertex entries forming or defining primitive segments 4080, 4081…408.N primitives in the text. For example, in... Figure 5 In the primitive segment, there are six vertices (with global indices V1, V2, V3, V7, V8, V9 and local indices V0, V1, V2, V3, V4, V5 respectively). Therefore, the vertex data sub-segment 412 can contain six vertex entries 5060, 5061, 5062, 5063, 5064, and 5065.

[0087] like Figure 5 As shown, each vertex entry 5060, 5061, 5062, 5063, 5064, 5065 may contain information identifying the position or location of the corresponding vertex in rendering space (e.g., the X, Y, and Z coordinates of the vertex in rendering space). Each vertex entry 5060, 5061, 5062, 5063, 5064, 5065 may also include one or more attributes to describe the appearance of the vertex, such as texture coordinates (U, V) and / or the primary color applied to the vertex.

[0088] Vertex entries can be stored in compressed or uncompressed form within vertex data segments. Vertex entries from different primitive segments of the same primitive block can be compressed (or not compressed) in different ways. For example, vertex entries from the first primitive segment can be decompressed, vertex entries from the second primitive segment of the same primitive block can be compressed using a first compression algorithm, and vertex entries from the third primitive segment of the same primitive block can be compressed using a different second compression algorithm. This allows for the selection of the optimal compression algorithm for each primitive segment.

[0089] The metadata sub-segment 410 may include a primitive entry for each primitive in a primitive block. For example, in Figure 5 In the example, there are two primitives, 502 and 504, therefore there are two primitive entries, 5080 and 5081, one entry for each primitive. Figure 5 As shown, each primitive entry may include information identifying the vertices forming the primitive in the vertex data sub-segment 412. For example, in Figure 5 In the first primitive 502, primitive entry 5080 identifies vertices with local indices V0, V1, and V2, and primitive entry 5081 of the second primitive 504 identifies vertices with local indices V3, V4, and V5. When rendering primitives during the rasterization stage, vertex entries associated with the primitive are retrieved from the vertex data sub-segment and used to render the primitive. For example, in order to render... Figure 5 In the example, the first primitive 502 retrieves vertex entries with local indices V0, V1, and V2 from the vertex data sub-segment 412 and uses these vertex entries to render the primitive.

[0090] Where vertex entries can be stored in compressed form in vertex data sub-segment 412, each primitive segment may also include a vertex compression sub-segment 414, which identifies whether the vertex entry has been compressed, and optionally, identifies which compression algorithm or technique was used to compress the vertex entry, and / or other information about the compression of the vertex entries in vertex data sub-segment 412.

[0091] Each primitive segment 4080, 4081...408 of primitive block 402 N It can be written to and read from memory separately from other primitive segments of the primitive block 402. For example, as Figure 4 As shown, each primitive segment in the memory is 4080, 4081...408. N The start can be identified by a primitive segment offset from a point in the primitive block (e.g., from the beginning of header section 404 or from the end of status data segment 406). In some cases, primitive segments 4080, 4081…408 of primitive block 402 are... N They can be stored continuously or back-to-back in memory, such that each primitive segment 4080, 4081…408… N The start or offset can be determined from the size of the previous primitive segment in the primitive block. For example, the second primitive segment can be stored at the next addressable memory block following the first primitive segment. In other cases, primitive segments 4080, 4081…408… N Data can be stored in memory in a non-contiguous or back-to-back manner. For example, in some cases, other data may exist in memory between the first and second primitive segments of a primitive block.

[0092] primitive block generator

[0093] Now for reference Figure 6 It shows that it is configured to generate with Figure 4 Example primitive block generator 600 showing the structure or format of primitive blocks. Primitive block generator 600 includes data memory 602 and primitive block generation logic 604.

[0094] Data storage 602 is a storage device configured to temporarily store the current primitive segment 606, the current primitive block's state data 608, and the current primitive block's header 610. The current primitive segment 606 is configured to store one or more primitives. The current primitive segment 606 can have any of the formats described above. For example, the current primitive segment 606 may include primitive data sub-segments, vertex data sub-segments, and optional vertex compression sub-segments. As described above, the state data 608 describes how primitives will be rendered during the rasterization stage. When the first primitive in the set is received, the current primitive block's state data 608 can be initially set to an invalid value to initiate a new primitive block.

[0095] Primitive block generation logic 604 is configured to receive primitives associated with state data, which identifies how the primitives will be rendered during the rasterization stage. Primitive block generation logic 604 is configured to, for each received primitive, determine whether the primitive can be added to the current primitive block based on the primitive's state data and the current primitive block's state data 608. If primitive block generation logic 604 determines that the received primitive can be added to the current primitive block, then primitive block generation logic 604 is configured to determine whether the received primitive can be added to the current primitive block segment 606 of the current primitive block based on one or more size constraints (e.g., the maximum number of primitives and / or the maximum number of vertices). If primitive block generation logic 604 determines that the received primitive block can be added to the current primitive block segment 606 of the current primitive block, then primitive block generation logic 604 adds the received primitive block to the current primitive block segment 606. However, if the primitive block generation logic 604 determines that the received primitive cannot be added to the current primitive segment 606, the primitive block generation logic 604 is configured to cause the current primitive segment 606 to be output (e.g., stored in memory (e.g., external or off-chip memory)), cause the data storage device 602 to be reconfigured to store the new primitive segment of the current primitive block, and add the received primitive to the new primitive segment of the current primitive block.

[0096] The primitive block generation logic 604 may include state data comparison logic 612, primitive segment analysis logic 614, and controller 616. The state data comparison logic 612 is configured to compare state data associated with a received primitive with state data 608 of the current primitive block to determine if they match and to notify controller 616 of the comparison result. As described above, the state data describes how the primitive will be rendered. The state data may include multiple state parameters, each of which may have one of multiple values. In these cases, determining that the state data of the received primitive matches the state data 608 of the current primitive block may include determining whether each of the multiple state parameters of the received primitive has the same value as the corresponding state parameter of the current primitive block. In some cases, if the state data comparison logic 612 determines that the state data does not match, the state data comparison logic 612 may provide the state data of the received primitive to controller 616, as described below, whereby the state data can be used as state data for a new primitive block. In other cases, controller 616 or data storage 602 may receive basic state data directly or by other means.

[0097] Primitive segment analysis logic 614 is configured to determine whether a received primitive can be added to the current primitive segment 606 based on one or more primitive segment size constraints, and to notify the controller 616 of this determination. For example, primitive segment analysis logic 614 can be configured to determine that a received primitive can be added to the current primitive segment if adding the received primitive would not violate any of the one or more primitive segment size constraints. Size constraints can be based on the size of the data memory and / or the portion of the data memory allocated to store the current primitive segment 606. In some cases, one or more primitive size constraints may include the maximum number of primitives in a primitive segment and / or the maximum number of vertices in a primitive segment. In these cases, primitive segment analysis logic 614 can determine that a received primitive cannot be added to the current primitive segment if adding the primitive would result in exceeding either of the maximum values.

[0098] Determining whether adding the received primitive to the current primitive segment would violate the maximum number of primitives may include determining the number of primitives in the current primitive segment and comparing that number to the maximum number of primitives. If the number of primitives in the current primitive segment is less than the maximum number, then adding the primitive will not violate the size constraint.

[0099] Determining whether adding a received primitive to the current primitive segment would violate the maximum number of vertices in the current primitive segment may include identifying the number of new vertices of the received primitive relative to the current primitive segment. As mentioned above, primitives can share vertices. Therefore, if one or more vertices of a received primitive are shared by at least one primitive already in the current primitive segment, then one or more vertices of the received primitive may already be in the current primitive segment. Therefore, determining whether adding a received primitive to the current primitive segment would violate the maximum number of vertices in the current primitive segment may include identifying the number of new vertices of the received primitive by comparing the vertices of the received primitive with the vertices in the current primitive block, and then determining whether adding the identified number of new vertices to the current primitive segment would violate the maximum number of vertices in the current primitive segment.

[0100] In some cases, in addition to providing the determined results to the controller 616, the primitive segment analysis logic 614 can be configured to provide the received primitives to the controller 616. In other cases, the controller 616 or the data memory 602 can receive primitives directly or otherwise so as to be able to add primitives to the current primitive block.

[0101] The controller 616 can be configured to control the storage of received primitives in the data storage 602 and external memory based on notifications received from the state data comparison logic 612 and the primitive segment analysis logic 614. Specifically, the controller 616 can be configured to:

[0102] (i) Adding a primitive to the current primitive segment: If the state data comparison logic 612 indicates that the state data of the received primitive matches the state data of the current primitive block; the primitive segment analysis logic 614 indicates that the received primitive can be added to the current primitive segment without violating one or more primitive segment size constraints - such that the received primitive is added to the current primitive segment 606.

[0103] (ii) Starting a new primitive segment and adding primitives to the new primitive segment: If state data comparison logic 612 indicates that the state data of the received primitive matches the state data of the current primitive block; and primitive segment analysis logic 614 indicates that the received primitive cannot be added to the current primitive segment without violating one or more primitive segment size constraints ->: the current primitive segment stored in data memory 602 is output (e.g., stored in memory 620), data memory 602 is reconfigured to store the new primitive segment of the current primitive block (e.g., clear the contents of the current primitive segment 606), and the received primitive is added to the new primitive segment; and

[0104] (iii) Start a new primitive block and add primitives to its first primitive segment: If the state data comparison logic 612 indicates that the state data of the received primitives does not match the state data of the current primitive block -> Reason: The data in the data memory 602 is related to the current primitive block to be output (e.g., stored in memory 620), the data memory is reconfigured to store the new primitive segment of the new primitive block with the state data of the received primitives, and the received primitives to be added to the new primitive segment of the new primitive block.

[0105] In some cases, adding received primitives to the current primitive segment in the data memory may include, for each new vertex associated with the received primitive, adding a new vertex entry to the vertex data sub-segment of the current primitive segment; and adding a new primitive entry for the primitive to a primitive data sub-segment, the primitive entry identifying a vertex in the vertex data sub-segment associated with the primitive. Adding primitives to the current primitive segment may also include updating the header 610 for the current primitive block to reflect that additional primitives have been added to the current primitive segment, and, if one or more new vertices have been added, reflecting the number of new vertices.

[0106] In some cases, the primitive block generator 600 may also include a compression engine 618 configured to receive primitive segments output from the data storage 602 and compress all or part of the primitive segments before storing them in memory. For example, the compression engine 618 may be configured to compress vertex data sub-segments of the primitive segments. The compression algorithm used to compress all or part of the received primitive segments may be pre-configured or dynamically selected based on the data in the received primitive segments. The compression engine 618 may also be configured to update vertex compression sub-segments of the primitive segments to indicate that all or part of the primitive segments have been compressed, and optionally to indicate which compression algorithm was used to compress the relevant portion, and / or other information regarding the compression of the relevant portion.

[0107] Now for reference Figure 7 It illustrates an example method for storing transformed primitives in the memory of a graphics processing system so that they can be processed by... Figure 6 It is used in the rendering stage of the primitive block generator 600 implementation.

[0108] exist Figure 7 In method 700, a data memory is used to temporarily store headers, status data, and the current primitive segment of the current primitive block. If the received primitive has the same status data as the current primitive block, the received primitive is added to the current primitive segment in the data memory, and the received primitive can be stored in the current primitive segment without violating the primitive segment size constraint. If the status data matches, but storing the received primitive in the current primitive segment would violate the size constraint, the current primitive segment is output, and the data memory is reconfigured to store a new primitive segment of the current primitive block, and the received primitive is added to it. If the status data does not match, the data associated with the current primitive block in the data memory is output, and the data memory is reconfigured to store data associated with a new primitive block having the status data of the received primitive, and the received primitive is added to the first primitive segment of the new primitive block.

[0109] Method 700 begins at step 702, where a transformed primitive associated with state data is received. Receiving the transformed primitive may include receiving transformed geometric data (or information identifying the geometric data) that defines the primitive. In some cases, the transformed geometric data defining the transformed primitive may include information identifying the position of each vertex in rendering space (e.g., X, Y, and Z coordinates in rendering space) for defining each vertex of the primitive. For each vertex, the transformed geometric data may also include other information, such as, but not limited to, a set of properties describing the appearance of the vertex, such as texture coordinates (U, V) and / or a primary color applied to the vertex. Once the primitive is received, method 700 proceeds to step 704.

[0110] At step 704, it is determined whether the state data associated with the received primitive matches the state data associated with the current primitive block. As described above, the state data describes how the primitive will be rendered. The state data may include multiple state parameters, each of which may have one of multiple values. In these cases, determining that the state data of the received primitive matches the state data of the current primitive block may include determining whether each of the multiple state parameters forming the state data of the received primitive has the same value as the corresponding state parameter in the state data 608 of the current primitive block. If it is determined in step 704 that the state data of the received primitive matches the state data of the current primitive block, the method proceeds to step 706. However, if it is determined in step 704 that the state data of the received primitive does not match the state data of the current primitive block, method 700 proceeds to step 708.

[0111] At step 706, it is determined whether the received primitive can be added to the current primitive segment in the data memory without violating one or more primitive segment size constraints. As described above, one or more size constraints are configured to control the size of the primitive segment. One or more size constraints may be based on the size of the data storage used to temporarily store the transformed primitives before outputting them to memory. In some cases, the one or more size constraints may include the maximum number of primitives in a primitive segment and / or the maximum number of vertices in a primitive segment. The methods for determining whether adding a primitive to the current primitive block in the data memory would violate the maximum number of primitives, or whether adding a received primitive to the current primitive block in the data memory would violate the maximum number of vertices, have been described above. If it is determined at step 706 that adding the received primitive to the current primitive segment does not violate the primitive segment size constraint, then method 700 proceeds to step 710. However, if it is determined in step 706 that adding the received primitive to the current primitive segment in the data memory would violate one or more primitive segment size constraints, then method 700 proceeds to step 712.

[0112] At step 710, the received primitives are added to the current primitive segment. As described above, in some cases, adding the received primitives to the current primitive segment in the data memory may include: for each new vertex associated with the received primitive (e.g., each vertex of the received primitive that is not yet in the current primitive segment), adding a new vertex entry to the vertex data sub-segment of the current primitive segment; and adding a new primitive entry for the primitive to the primitive data sub-segment of the current primitive segment, the new primitive entry identifying a vertex in the vertex data sub-segment associated with the primitive. Adding primitives to the current primitive segment may also include updating the header 610 of the current primitive block to reflect that additional primitives have been added to the current primitive segment, and if one or more new vertices have been added, adding the number of new vertices to the primitive segment. Once the received primitives are added to the current primitive segment in the data memory, method 700 ends.

[0113] At step 712, after determining that the received primitive state data matches the current primitive block's state data, but storing the received primitive in the current primitive segment of the current primitive block would violate one or more primitive segment size constraints, the data in the data memory associated with the current primitive segment is output. In some cases, the data of the current primitive segment may be output to external memory (e.g., stored in external memory). In some cases, all or part of the primitive segment may be compressed before being stored in external memory. For example, in some cases, its vertex data sub-segments may be compressed before being stored in memory. Any suitable compression algorithm or technique may be used to compress all or part of the primitive segment. In the case of compressing the primitive segment before storing all or part of it in memory, the primitive segment may be modified to include information that all or part of the primitive segment has been compressed, and optionally include information about which compression algorithm was used to compress that part of the primitive segment, and / or other information about the compression of that part of the primitive segment. Once the data related to the current primitive segment has been output from the data storage, method 700 proceeds to step 714.

[0114] At step 714, the data memory is reconfigured to store the new primitive segment of the current primitive block. Reconfiguring the data memory to store the new primitive segment of the current primitive block may include clearing the contents of the current primitive segment in the data memory and updating header 610 to indicate that an additional primitive segment has been added to the current primitive block. Once the data memory is reconfigured to store the new primitive segment of the current primitive block, method 700 proceeds to step 710, in which the received primitive block is added to the current primitive segment 606 in the data memory.

[0115] At step 708, after determining that the received primitive status data does not match the status data of the current primitive block, the data related to the current primitive block in the data memory is output. The data related to the current primitive block in the data memory may include header 610, status data 608, and current primitive segment 606. The data related to the current primitive block in the data memory can be output to memory. As described above, regarding step 712, before storing the data related to the current primitive segment in memory, all or part of the primitive segment can be compressed. Any suitable compression method or technique can be used to compress all or part of the primitive segment. Preferably, a lossless compression method or technique is used. Once the data related to the current primitive block in data memory 602 is output, method 700 proceeds to step 716.

[0116] At step 716, the data memory is reconfigured to store the first primitive segment of a new primitive block, the primitive block having state data of the received primitive block. Reconfiguring the data memory to store the first primitive segment of the new primitive block may include clearing the contents of the current primitive segment 606 in the data memory, replacing the state data 608 in the data memory 602 with state data associated with the received primitive, and replacing the header 610 in the data memory with a header of the new primitive block (which may include information indicating that the primitive block includes a single primitive segment that currently does not have primitives or vertices). Once the data memory 602 has been reconfigured to store the first primitive segment of the new primitive block, method 700 proceeds to step 710, in which the received primitive is added to the current primitive segment (in this case, representing the first primitive segment of the new primitive block).

[0117] Now for reference Figures 8 to 10 It shows how to... Figure 7 An example of how to process primitives using this method. Specifically, Figure 8 This represents an example of storing a primitive in the current primitive section of the current primitive block. Figure 9 This represents an example of storing a primitive in a new primitive section of the current primitive block. Figure 10 This represents an example of storing primitives in a new primitive section of a new primitive block.

[0118] In particular, Figure 8A primitive 802 is shown, formed by vertices with global indices V0, V1, and V3. Primitive 802 is associated with state data 804 ABCD. As shown at 806, upon receiving primitive 802, data storage 808 includes the current primitive segment of the current primitive block associated with the state data ABCD. The current primitive segment includes one primitive (P0) and three vertices (with local indices V0, V1, and V2). In this example, the maximum number of primitives per primitive segment is three, and the maximum number of vertices per primitive segment is five. The state data 804 of primitive 802 matches the state data of the current primitive block, therefore primitive 802 can be added to the current primitive block. Furthermore, adding primitive 802 to the current primitive segment will not violate any of the primitive segment size constraints, because if primitive 802 is added to the current primitive segment, only two primitives and four vertices will exist, since two of the vertices (V0 and V1) of primitive 802 are already in the current primitive segment. Therefore, as shown in 810, primitive 802 is added to the current primitive segment. Specifically, vertex entries (V3 = X3, Y3, Z3, U3, V3) are added to the current primitive segment of primitive 802 for the new vertex (with local index V3), and primitive entries (P1 = V0, V1, V2) are added to the current primitive segment of primitive 802 that identifies the related vertex. In this case, the global index matches the local index; however, this may not be the case in other examples.

[0119] Figure 9A primitive 902 is shown, formed by vertices with global indices V3, V4, and V5. Primitive 902 is associated with state data 904 ABCD. As shown at 906, upon receiving primitive 902, data storage 908 includes the current primitive segment of the current primitive block associated with the state data ABCD. The current primitive segment includes one primitive (P0) and three vertices (with local indices V0, V1, and V2). In this example, the maximum number of primitives per primitive segment is three, and the maximum number of vertices per primitive segment is five. The state data 904 of primitive 902 matches the state data of the current primitive block, therefore primitive 902 can be added to the current primitive block. However, adding primitive 902 to the current primitive segment would violate the maximum number of vertices per primitive segment, because if primitive 902 is added to the current primitive segment, there will be six vertices in the primitive segment, since all three vertices of primitive 902 (the vertices with global indices V3, V4, and V5) are new (i.e., not yet in the current primitive segment). Therefore, the content or data of the current primitive segment is output (e.g., to memory), the current primitive segment is reconfigured to store the new primitive segment (i.e., the content is refreshed), and primitive 902 is added to the current primitive segment. As shown at 910, this results in the current primitive segment containing vertex entries for each vertex of primitive 902 (with global indices V3, V4, and V5 assigned local indices V0, V1, and V2) and primitive entries for primitive 902 identifying related vertices (vertices with local vertices V0, V1, and V2); and updating the header to indicate that the primitive block has a second primitive segment comprising one primitive and three vertices. It should be noted that in this example, the global vertex indices do not match the local vertex indices. Specifically, global vertices V3, V4, and V5 become local vertices V0, V1, and V2 in the new primitive segment, respectively.

[0120] Figure 10The diagram shows primitive 1002, formed by vertices with global indices V0, V1, and V3. Primitive 1002 is associated with state data 1004DEDE. As shown at 1006, upon receiving primitive 1002, data storage 1008 includes the current primitive segment of the current primitive block associated with state data ABCD. The current primitive segment includes one primitive (P0) and three vertices (with local vertices V0, V1, and V2). In this example, the maximum number of primitives per primitive segment is three, and the maximum number of vertices per primitive segment is five. The state data 1004 of primitive 1002 does not match the state data of the current primitive block, therefore primitive 1002 cannot be added to the current primitive block. Therefore, the state data, header, and current primitive segment are output (e.g., output to memory), and then data storage 1008 is reconfigured to store the new primitive block (i.e., the contents of the state data, header, and current primitive segment are refreshed). Then, the state data is set to state data 1004 for primitive 1002, primitive 1002 is added to the current primitive segment, and the header is modified to specify that the new primitive block comprises a primitive segment with one primitive and three vertices. As shown at 1010, this results in the state data being set to DEDE, and the current primitive segment comprising vertex entries for each vertex of primitive 1002 (with local indices V0, V1, V2) and primitive entries for primitive 1002 identifying the relevant vertices; and the header is set to indicate that the primitive block contains a primitive segment with one primitive and three vertices. Note that in this example, the global vertex indices do not match the local vertex indices. Specifically, global vertices V0, V1, and V3 become local vertices V0, V1, and V2 in the new primitive segment of the new primitive block, respectively.

[0121] exist Figure 6-10 In the example, primitives are grouped into primitive blocks based on state data and the order in which they are received (e.g., at primitive block generator 600). Specifically, if a primitive block has the same state data as the current primitive block, the primitive is added to the primitive block; otherwise, a new primitive block is created, and the received primitive is added to the primitive block. However, this is only an example, and in other examples, the primitive block generator can be configured to group primitives into primitive blocks in a different manner. For example, in some cases, before comparing the state data of the received primitives with the state data of the current primitive block, the primitive block generator can be configured to use other criteria to determine whether to add the received primitive to the current primitive block (e.g., based on the distance between the spatial location of the received primitive and the spatial locations of primitives in the primitive block), and the state data is compared only if the other criteria are met.

[0122] Similarly, in Figure 6-10In the example, primitives are grouped into primitive segments based on the order of received primitives and primitive segment size constraints (multiple). Specifically, if a primitive has the same state data as primitives in the primitive segment and there is sufficient space for the primitive in the primitive segment (based on primitive segment size constraints), then the primitive is added to the primitive segment. However, this is only an example, and in other examples, before determining whether there is sufficient space for the primitive in the primitive segment (based on primitive segment size constraints), the primitive block generator can be configured to use other criteria to determine whether a received primitive should be added to the current primitive segment (e.g., based on the distance between the spatial location of the received primitive and the spatial location of primitives in the primitive segment), and only if this other criterion is met, the size constraint of the current primitive segment is analyzed.

[0123] exist Figure 6-10 In the example, the data storage is configured to store data for a single primitive block. However, in other cases, the data storage can be configured to store data for multiple primitive blocks. For example, the data storage can be configured to store headers, status data, and current primitive segments for multiple primitive blocks. In these cases, one of the multiple primitive blocks can be selected as the current primitive block before determining whether the status data of the received primitive matches the status data of the current primitive block. For example, in some cases, the rendering space can be divided into multiple regions (which may be larger than a block), and the data storage device can be configured to store primitive block data for each of the multiple regions. In these cases, before determining whether the status data of the received primitive matches the status data of the current primitive block, the primitive block generator can be configured to determine which region the received primitive falls into and select one or more primitive blocks associated with those regions as the current primitive block.

[0124] Tiling engine

[0125] When the transformed primitives are stored in primitive blocks in the above structure and / or format, where each primitive block may include one or more primitive segments, the tiling engine can be configured to generate a display list for each block, the display list having a reference... Figure 1 and Figure 2 The described formats are different. Specifically, Figure 1 The tiling engine in the code is configured to generate a display list for each tile, such as... Figure 2As shown, the display list for each primitive block that includes at least one primitive that at least partially falls within the boundary of a tile includes information identifying the primitive block (e.g., the address of the primitive block in memory) and information identifying the primitives to be used to render the tile (e.g., a primitive mask). In contrast, when primitives are stored in primitive blocks with the above structure, the tiling engine can be configured to generate a display list for each tile, which for each primitive block that includes at least one primitive that at least partially falls within the boundary of a tile, includes: information identifying the primitive block (e.g., the address of the primitive block in memory); information identifying each primitive segment that includes at least one primitive that at least partially falls within the tile (e.g., the offset of the primitive segment in memory); and information identifying the primitives associated with rendering the segment within the tile for each identified primitive segment. This allows the rasterization logic to capture only those primitive segments of the primitive block that are associated with rendering the tile, rather than capturing the entire primitive block.

[0126] Now for reference Figure 11 The illustration shows an example tiling engine 1100 configured to generate a display list of tiles, the display list identifying primitives used to render the tiles (e.g., primitives that at least partially fall within the boundaries of the tiles). The tiling engine 1100 includes tiling logic 1102 and a display list generator 1104.

[0127] Tiling logic 1102 is configured to (i) receive a plurality of primitive blocks, wherein each primitive block comprises one or more primitive segments, the primitive segment comprising one or more primitives (e.g., transformed geometric data associated therewith); (ii) determine, for each received primitive segment, which primitives of the primitive segment at least partially fall within the boundary of the block; and (iii) output the determined result. In some cases, the output may be in the form of a primitive mask for each primitive segment. Each primitive mask may include bits for each primitive in the primitive segment, the bits indicating whether the primitive at least partially falls within the boundary of the block.

[0128] Tiling logic 1102 can use any suitable method to determine whether a primitive falls at least partially within the boundaries of a tile. For example, in some situations, tiling logic 1102 can use simple, less accurate methods (such as simple bounding box tiling methods) to determine whether a primitive falls at least partially within a tile in order to quickly classify the primitive into tiles. As known to those skilled in the art, in bounding box methods, the bounding box surrounding the primitive is identified (e.g., the smallest axis-aligned bounding box surrounding the primitive vertices). Any suitable method can be used to generate the bounding box. For example, tiling logic 1102 can generate the bounding box by finding the minimum and maximum X and Y coordinates of the primitive vertices and forming an axis-aligned bounding box based on these coordinates. The bounding box can be generated at any granularity or resolution. For example, in some situations, the bounding box can be at the X and Y coordinate resolution (i.e., the bounding box can be defined by the maximum and minimum X and Y coordinates of the vertices). In other situations, the bounding box can be at the tile resolution (i.e., the nearest tile edge surrounding the primitive). Once the tiling logic 1102 has identified the bounding box of an element, it can determine that the element is at least partially within the tile if the bounding box at least partially overlaps or intersects with the tile. In other words, if the bounding box of an element is at least partially within the boundary of a tile, it can be determined that the element is at least partially within the tile. While the bounding box method can be used to quickly and efficiently determine whether an element is at least partially within a tile, it is not a "perfect" tiling method because the bounding box is often larger than the element, which can lead to elements that are not actually within the tile being identified as being within it.

[0129] For example, Figure 12An example rendering space 1200 is shown, divided into four tiles 1202, 1204, 1206, and 1208. If a simple axis-aligned bounding box method is used to determine which tiles 1210 at least partially fall within, among these tiles 1202, 1204, 1206, and 1208, a bounding box 1212 is generated around the primitive 1210. Since the bounding box 1212 at least partially overlaps with all tiles 1202, 1204, 1206, and 1208, it can be determined that the primitive at least partially falls within each of the four tiles 1202, 1204, 1206, and 1208, even if the primitive 1210 actually falls within or overlaps with only three tiles 1204, 1206, and 1208. However, determining that a primitive falls within a tile when it does not actually fall within one does not result in an error, and the primitive is simply discarded during the rasterization stage. However, determining that a primitive does not fall within a block when it actually does can lead to errors in the rasterization stage. Therefore, conservative block representation is advantageous. In other words, it is better to indicate that a primitive falls within a block, even if it does not, than to exclude primitives that actually fall within the block.

[0130] However, in other situations, the tile logic 1102 may use more sophisticated and / or precise methods (such as perfect tiling or near-perfect tiling methods) to determine whether a primitive falls within a tile. An example of a perfect tiling method that may be used by the tiling logic 1102 is described in the applicant’s published UK patent application No. 2549789, the entire contents of which are incorporated herein by reference.

[0131] Display list generator 1104 receives the tiling result (e.g., primitive mask) output by tiling logic 1102, the address of each primitive block in memory, and the position (e.g., offset) of each primitive segment in memory, and generates a display list from there. Specifically, display list generator 1104 is configured to add a primitive block entry to the display list for each primitive block that includes at least one primitive that falls at least partially within the boundary of a tile, the primitive block entry identifying the primitive block. In some cases, the primitive block entry may include the address of the primitive block in memory. Display list generator 1104 is then configured to include information about the primitive segment that identifies the position of the primitive segment in memory and the primitive segment that is associated with rendering the tile in the display list for each primitive segment that includes at least one primitive block that falls at least partially within the boundary of a tile.

[0132] In some cases, the display list generator 1104 may be configured to, for each primitive segment including at least one primitive that at least partially falls within the boundary of a tile: (i) add a primitive segment entry identifying the location of the primitive segment in memory to the display list of the tile, and (ii) add a related primitive entry identifying the primitive segment associated with rendering the tile (i.e., the primitive that at least partially falls within the boundary of the tile) to the display list. In some cases, each primitive segment entry may include an offset from the end of the header and state data of the primitive block identifying the start of the primitive segment in memory.

[0133] For example, such as Figure 13 As shown, if a primitive block comprises six primitive segments numbered 0 to 5, and the 0th, 3rd, and 5th primitive segments comprise at least one primitive that falls at least partially within the boundary of the block, then the display list 1302 of the block may include a primitive block entry 1304 identifying the primitive block (e.g., the address of the primitive block in memory), primitive segment entries 1306, 1308, and 1310 identifying the location (e.g., offset) of each of the 0th, 3rd, and 5th primitive segments in memory, and associated primitive entries 1312, 1314, and 1316 identifying the primitives (e.g., primitive masks) associated with the block by the primitive segments.

[0134] In some cases, the position of the first primitive segment of a primitive block can be known (e.g., the offset can be zero). In these cases, instead of adding a primitive segment entry for the first primitive segment to the block's display list, two types of primitive block entries can exist: one specifying that the first primitive segment (i.e., primitive segment 0) is associated with the block, and another specifying that the first primitive segment (i.e., primitive segment 0) is not associated with the block. In some cases, each primitive block entry can include a flag or bit that is set if the first primitive segment (i.e., primitive segment 0) is associated with the block, and not set if the first primitive segment (i.e., primitive segment 0) is not associated with the block, and vice versa. This eliminates the need to include the position (e.g., offset) of the first primitive segment in the display list.

[0135] For example, such as Figure 14As shown, if a primitive block comprises six primitive segments numbered 0 to 5, and the 0th, 3rd, and 5th primitive segments comprise at least one primitive that at least partially falls within the block boundary, then the display list 1402 of the block may include primitive block entries 1404 that identify the primitive block (e.g., the address of the primitive block in memory) and indicate the primitive block entry associated with the 0th primitive segment, primitive segment entries 1406 and 1408 that identify the location (e.g., offset) of each of the 3rd and 5th primitive segments in memory, and associated primitive entries 1410 and 1414 that identify each of the 0th, 3rd, and 5th primitive segments associated with the primitive segment 1412 (e.g., a primitive mask). Therefore, with Figure 13 The example shows a list compared to Figure 14 The display list 1402 does not include the primitive segment entry for primitive segment 0.

[0136] Figure 15 Another example is shown. In this example, the primitive block comprises five primitive segments numbered 0 to 4, and the 3rd and 4th primitive segments comprise at least one primitive that falls at least partially within the boundary of the block. In this example, the display list 1502 of the block may include a primitive block entry 1504 that identifies the primitive block (e.g., the address of the primitive block in memory) and indicates that the 0th primitive segment is not associated with the current segment, primitive segment entries 1506, 1508 that identify the location (e.g., and offset) of the primitive segment in memory for each of the 3rd and 4th primitive segments, and associated primitive entries 1510, 1512 that identify the primitives (e.g., primitive masks) associated with the segment of the primitive segment for each of the 3rd and 4th primitive segments.

[0137] Now for reference Figure 16 It shows that it can be generated by Figure 11 Example method 1600 for generating a display list of tiles, implemented by the tiling engine 1100. Method 1600 begins at step 1602, in which primitive blocks are received. The primitive blocks comprise one or more primitive segments, each primitive segment comprising one or more primitives. Once primitive blocks have been received, method 1600 proceeds to step 1604.

[0138] At step 1604, the first primitive segment of the primitive block is selected, and method 1600 proceeds to step 1606.

[0139] At step 1606, it is determined which primitives in the selected primitive segment fall at least partially within the boundary of the tile. Any method (such as the method described above) can be used to determine whether a primitive falls at least partially within the boundary of the tile. If a primitive falls at least partially within the boundary of the tile, then the primitive is considered relevant to rendering the tile. Once it has been determined which primitives in the selected primitive segment fall at least partially within the boundary of the tile, method 1600 proceeds to step 1608.

[0140] At step 1608, it is determined whether there exists at least one primitive in the selected primitive segment that is related to rendering the tile (i.e., whether there exists at least one primitive that at least partially falls within the boundary of the tile). If it is determined that there are no primitives in the primitive segment that are related to rendering the tile, method 1600 proceeds to step 1616. However, if it is determined that there are at least one primitive in the primitive segment related to rendering the puzzle, method 1600 proceeds to step 1610.

[0141] At step 1610, it is determined whether this is the first primitive segment of the current primitive block, the primitive segment including primitives associated with rendering the block. If it is determined that this is the first primitive segment including primitives associated with rendering the block, method 1600 proceeds to step 1612. However, if it is determined that this is not the first primitive segment including primitives associated with rendering the block, method 1600 proceeds directly to step 1614.

[0142] At step 1612, information identifying the primitive block can be added to the display list of the block. As described above, adding the information identifying the primitive block to the display list can include adding a primitive block entry to the display list, the primitive block entry identifying the location of the primitive block in memory (e.g., the primitive block entry can include the address of the primitive block in memory). Once the information identifying the primitive block is added to the display list, method 1600 proceeds to step 1614.

[0143] At step 1614, information identifying the selected primitive segment, along with information about primitives associated with the selected primitive segment and the rendered tile, is added to a display list. As described above, adding information identifying the selected primitive segment to the display list may include adding a primitive segment entry identifying the location of the primitive segment in memory to the display list. The location of the primitive segment in memory may be represented as an offset (e.g., an offset from the end of the header and primitive block state data). In some cases, if the selected primitive segment is the first primitive segment in a primitive block, adding information identifying the selected primitive segment to the display list may include modifying the primitive block entry to indicate that the first primitive segment is associated. As described above, adding information about primitives identifying primitive segments associated with the rendered tile to the display list of the tile may include adding associated primitive entries for the primitive segment to the display list. Associated primitive entries may include a primitive mask including bits for each primitive in the primitive segment indicating whether the primitive at least partially falls within the boundary of the tile. Once the information about the primitive segment has been added to the display list, method 1600 proceeds to step 1616.

[0144] At step 1616, it is determined whether there is at least one remaining primitive segment in the primitive block. If it is determined that there is at least one remaining primitive segment in the primitive block, method 1600 proceeds to step 1618, in which the next primitive segment is selected. However, if it is determined that there are no more primitive segments in the primitive block, method 1600 proceeds to step 1620.

[0145] At step 1620, it is determined whether there is at least one more primitive block. If it is determined that there is at least one more primitive block, method 1600 returns to step 1602, where the next primitive block is received. However, if it is determined that there are no more primitive blocks, method 1600 terminates.

[0146] Graphics processing system

[0147] Now for reference Figure 17 It illustrates an example of a tile-based rendering graphics processing system 1700, which includes... Figure 6 Primitive Block Generator 600 and Figure 11 The tiling engine 1100. Figure 17 The graphics processing system 1700 and Figure 1 The graphics processing system 100 is similar in that it includes geometry processing logic 1704 and rasterization logic 1706; the geometry processing logic 1704 includes logic corresponding to... Figure 1 Transformation logic 108 includes transformation logic 1708; and rasterization logic 1706 includes rasterizer 1714, HSR logic 1716, and texturing / shading logic 1718 (each of which serves as the above-mentioned transformation logic 1708). Figure 1(Corresponding components). However, the geometry processing logic does not include a primitive generator to store the transformed primitives generated by the transformation logic 1708 in primitives having a single primitive segment, but instead includes a primitive generator 600 for storing the transformed primitives generated by the transformation logic 1708 in primitives that may include more than one primitive segment. The geometry processing logic 1704 also includes a tiling engine 1100 configured to generate a display list that identifies the relevant primitive blocks used for rendering tiles, and their primitive segments associated with the rendered tiles.

[0148] Figure 18 A computer system is shown that can implement the primitive block generator, tiling engine, and / or graphics processing system described herein. The computer system includes a CPU 1802, a GPU 1804, memory 1806, and other devices 1814, such as a display 1816, a speaker 1818, and a camera 1820. A processing block 1810 (which may correspond to the primitive block generator, tiling engine, and / or graphics processing system described herein) is implemented on the GPU 1804. In other examples, the processing block 1810 may be implemented on the CPU 1802. Components of the computer system can communicate with each other via a communication bus 1822.

[0149] Figure 1 , 6 The primitive block generators, tiling engines, and graphics processing systems in 11 and 17 are shown as comprising multiple functional blocks. This is merely illustrative and not intended to define a strict division between different logical elements of such entities. Each functional block can be provided in any suitable manner. It should be understood that the intermediate values ​​formed by the primitive block generator, tiling engine, or graphics processing system described herein do not need to be physically generated by the primitive block generator, tiling engine, or graphics processing system at any point, and may merely represent logical values ​​that conveniently describe the processing performed by the primitive block generator, tiling engine, or graphics processing system between its inputs and outputs.

[0150] The primitive block generator, tiling engine, and graphics processing system described herein can be embodied in hardware on an integrated circuit. The primitive block generator, tiling engine, and graphics processing system described herein can be configured to perform any of the methods described herein. Generally, any of the functions, methods, techniques, or components described above can be implemented in software, firmware, hardware (e.g., a fixed logic circuit system), or any combination thereof. The terms “module,” “function,” “component,” “element,” “cell,” “block,” and “logic” are used herein to generally denote software, firmware, hardware, or any combination thereof. In the case of a software implementation, a module, function, component, element, cell, block, or logic represents program code that, when executed on a processor, performs a specified task. The algorithms and methods described herein can be executed by one or more processors that execute code that causes the processor to perform the algorithm / method. Examples of computer-readable storage media include random access memory (RAM), read-only memory (ROM), optical disk, flash memory, hard disk storage, and other memory devices that can use magnetic, optical, and other techniques to store instructions or other data and can be accessed by a machine.

[0151] As used herein, the terms computer program code and computer-readable instructions refer to any kind of executable code for a processor, comprising code expressed in machine language, interpreted language, or scripting language. Executable code includes binary code, machine code, bytecode, code defining integrated circuits (e.g., hardware description languages ​​or netlists), and code expressed in programming languages ​​such as C, Java, or OpenCL. Executable code can be, for example, any kind of software, firmware, script, module, or library that, when properly executed, processed, interpreted, compiled, or run in a virtual machine or other software environment, causes the processor of a computer system that supports the executable code to perform tasks specified by said code.

[0152] A processor, computer, or computer system can be any kind of device, machine, or special-purpose circuit, or a collection or part thereof, that has the processing power to execute instructions. A processor can be any kind of general-purpose or special-purpose processor, such as a CPU, GPU, system-on-a-chip, state machine, media processor, application-specific integrated circuit (ASIC), programmable logic array, field-programmable gate array (FPGA), etc. A computer or computer system may include one or more processors.

[0153] This invention also intends to encompass software, such as hardware description language (HDL) software, that defines the configuration of hardware as described herein, for designing integrated circuits or for configuring programmable chips to perform desired functions. That is, a computer-readable storage medium on which computer-readable program code in the form of an integrated circuit definition dataset is encoded may be provided, which, when processed (i.e., run) in an integrated circuit manufacturing system, configures the system to manufacture a primitive block generator, tiling engine, or graphics processing system configured to perform any of the methods described herein, or to manufacture a primitive block generator, tiling engine, or graphics processing system including any of the means described herein. The integrated circuit definition dataset may be, for example, an integrated circuit description.

[0154] Therefore, a method for manufacturing a primitive block generator, tiling engine, or graphics processing system as described herein can be provided at an integrated circuit manufacturing system. Furthermore, an integrated circuit-defined dataset can be provided, which, when processed in an integrated circuit manufacturing system, causes the manufacturing method of the primitive block generator, tiling engine, or graphics processing system to be executed.

[0155] Integrated circuit definition datasets can be in the form of computer code, such as netlists, code for configuring programmable chips, or hardware description languages ​​suitable for manufacturing at any level in integrated circuits, including register-transfer level (RTL) code, high-level circuit representations (such as Verilog or VHDL), and low-level circuit representations (such as OASIS(RTM) and GDSII). Higher-level representations (such as RTL) that logically define hardware suitable for manufacturing in integrated circuits can be processed on a computer system configured to generate manufacturing definitions of integrated circuits within the context of a software environment that includes definitions of circuit elements and rules for combining these elements to generate the manufacturing definitions of the integrated circuits defined by that representation. As is typically the case where software executes at a computer system to define a machine, one or more intermediate user steps (e.g., providing commands, variables, etc.) may be required to configure the computer system to generate the manufacturing definitions of the integrated circuits, executing code that defines the integrated circuits in order to generate the manufacturing definitions of the integrated circuits.

[0156] Now refer to Figure 19 Describe an example of processing integrated circuit-defined datasets at an integrated circuit manufacturing system in order to configure the system as a primitive block generator, tiling engine, or graphics processing system.

[0157] Figure 19An example of an integrated circuit (IC) manufacturing system 1902 is shown, configured to manufacture a primitive block generator, tiling engine, or graphics processing system as described in any of the examples herein. Specifically, the IC manufacturing system 1902 includes a layout processing system 1904 and an integrated circuit generation system 1906. The IC manufacturing system 1902 is configured to receive an IC definition dataset (e.g., defining a primitive block generator, tiling engine, or graphics processing system as described in any of the examples herein), process the IC definition dataset, and generate ICs based on the IC definition dataset (e.g., its implementation of a primitive block generator, tiling engine, or graphics processing system as described in any of the examples herein). The processing of the IC definition dataset configures the IC manufacturing system 1902 to manufacture integrated circuits embodying the primitive block generator, tiling engine, or graphics processing system as described in any of the examples herein.

[0158] The layout processing system 1904 is configured to receive and process an IC definition dataset to determine a circuit layout. Methods for determining a circuit layout based on an IC definition dataset are known in the art and may involve, for example, synthesizing RTL code to determine a gate-level representation of the circuit to be generated, for example, in relation to logic components (e.g., NAND, NOR, AND, OR, MUX, and FLIP-FLOP components). By determining the location information of the logic components, the circuit layout can be determined based on the gate-level representation of the circuit. This can be done automatically or with user intervention to optimize the circuit layout. When the layout processing system 1904 has determined the circuit layout, it can output the circuit layout definition to the IC generation system 1906. The circuit layout definition may be, for example, a circuit layout description.

[0159] As is known in the art, IC generation system 1906 generates ICs according to a circuit layout definition. For example, IC generation system 1906 can implement a semiconductor device manufacturing process for generating ICs, which may involve a multi-step sequence of photolithography and chemical processing steps, during which electronic circuits are gradually formed on a wafer made of semiconductor material. The circuit layout definition may be in the form of a mask, which can be used in the photolithography process to generate ICs according to the circuit definition. Alternatively, the circuit layout definition provided to IC generation system 1906 may be in the form of computer-readable code, which IC generation system 1906 can use to form a suitable mask for generating ICs.

[0160] The various processes performed by the IC manufacturing system 1902 can all be implemented in one location, for example, by one party. Alternatively, the IC manufacturing system 1902 can be a distributed system, allowing some processes to be performed in different locations and by different parties. For example, some of the following stages can be performed in different locations and / or by different parties: (i) synthesizing RTL code representing an IC definition dataset to form a gate-level representation of the circuit to be generated; (ii) generating a circuit layout based on the gate-level representation; (iii) forming a mask based on the circuit layout; and (iv) using the mask to manufacture the integrated circuit.

[0161] In other examples, processing of an IC-defined dataset in an IC manufacturing system can configure the system to manufacture primitive block generators, tiling engines, or graphics processing systems without processing the IC-defined dataset to determine circuit layout. For example, an IC definition dataset can define the configuration of a reconfigurable processor, such as an FPGA, and processing of said dataset can configure the IC manufacturing system (e.g., by loading configuration data into the FPGA) to generate a reconfigurable processor with said defined configuration.

[0162] In some implementations, when processed in an integrated circuit manufacturing system, an integrated circuit manufacturing definition dataset can enable the integrated circuit manufacturing system to generate devices as described herein. For example, using an integrated circuit manufacturing definition dataset, with reference to the above... Figure 19 The configuration of the integrated circuit manufacturing system described herein enables the manufacture of devices as described in this article.

[0163] In some examples, an integrated circuit definition dataset may include software running on hardware defined at the dataset, or software running in combination with hardware defined at the dataset. Figure 19 In the example shown, the IC generation system can also be further configured by the integrated circuit definition dataset to load firmware onto the integrated circuit according to the program code defined in the integrated circuit definition dataset during the manufacturing of the integrated circuit, or otherwise provide the integrated circuit with program code to be used with the integrated circuit.

[0164] Compared to known implementations, the implementation of the concepts set forth in this application in devices, apparatuses, modules, and / or systems (and in the methods implemented herein) can lead to performance improvements. Performance improvements may include one or more of increased computational performance, reduced latency, increased throughput, and / or reduced power consumption. During the manufacture of such devices, apparatuses, modules, and systems (e.g., in integrated circuits), trade-offs can be made between performance improvements and physical implementation methods, thereby improving manufacturing methods. For example, a trade-off can be made between performance improvements and layout area to match the performance of known implementations but using less silicon. This can be accomplished, for example, by reusing functional blocks serially or sharing functional blocks among elements of a device, apparatus, module, and / or system. Conversely, the concepts set forth in this application that lead to improvements in the physical implementation of devices, apparatuses, modules, and systems (such as reduced silicon area) can be traded off for performance improvements. This can be accomplished, for example, by manufacturing multiple instances of a module within a predefined area budget.

[0165] The applicant has independently disclosed each individual feature described herein, as well as any combination of two or more such features, to the extent that such features or combinations can be implemented based on the specification as a whole, in accordance with the common knowledge of those skilled in the art, regardless of whether such features or combinations of features solve any problem disclosed herein. In view of the foregoing description, those skilled in the art will understand that various modifications can be made within the scope of this invention.

Claims

1. A tiling engine (1100) for a graphics processing system, wherein the rendering space is divided into multiple tiles, the tiling engine (1100) comprising: Tiling logic (1102), which is configured to perform the following method: Receives a plurality of primitive blocks, each primitive block comprising one or more primitive segments and state data shared by the one or more primitive segments, each primitive segment comprising transformed geometric structure data of one or more primitives, at least one of the plurality of primitive blocks comprising at least two primitive segments, wherein at least one of the at least two primitive segments comprises transformed geometric structure data of at least two primitives, and each primitive segment in a primitive block can be read from memory separately from the other primitive segments of that primitive block; and For each primitive segment of the received primitive block, determine whether the primitive of the primitive segment at least partially falls within the boundary of a block among the plurality of primitive blocks; and Display list generator (1104), the display list generator being configured to: For each element block that includes at least one element that falls at least partially within the boundary of the tile, information identifying the element block is added to the display list of the tile; For each identified primitive block, information about each primitive segment of the primitive block that identifies at least one primitive that falls at least partially within the boundary of the primitive block is added to the display list; For each identified primitive segment, information identifying the primitive that at least partially falls within the boundary of the tile is added to the display list; If a first primitive segment of a primitive block includes at least one primitive that falls at least partially within the boundary of the primitive block, then a primitive block entry of a first type is added to the display list. This first type of primitive block entry includes the information identifying the primitive block and the information identifying the first primitive segment as a primitive segment that includes at least one primitive that falls at least partially within the boundary of the primitive block. If the first primitive segment of the primitive block does not include at least one primitive that falls at least partially within the boundary of the primitive block, then a second type of primitive block entry is added to the display list. The second type of primitive block entry includes the information identifying the primitive block and information indicating that the first primitive segment does not include at least one primitive that falls at least partially within the boundary of the primitive block.

2. The tiling engine (1100) according to claim 1, wherein the information identifying primitive segments in the display list includes information identifying the location of the primitive segment in the memory.

3. The tiling engine (1100) according to claim 1 or 2, wherein the first type of primitive block entry has a set of flags, and the second different type of primitive block entry does not have a set of flags.

4. The tiling engine (1100) according to claim 1 or 2, wherein the display list generator (1104) is configured to add a primitive segment entry to the display list of the primitive block for each primitive segment of the primitive block, excluding the first primitive segment, which includes at least one primitive that at least partially falls within the boundary of the primitive block.

5. The tiling engine (1100) according to claim 1 or 2, wherein the display list generator (1104) is configured to add a primitive segment entry to the display list for each primitive segment of a primitive block that includes at least one primitive that falls at least partially within the boundary of the tile.

6. The tiling engine (1100) of claim 4, wherein each primitive segment entry includes information identifying the location of the corresponding primitive segment in the memory.

7. The tiling engine (1100) of claim 6, wherein the information identifying the position of the corresponding primitive segment in the memory is an offset from the position of the primitive block in the memory.

8. The tiling engine (1100) according to claim 1 or 2, wherein the information identifying the primitives in a primitive segment that at least partially falls within the boundary of the tile includes a primitive mask, the primitive mask including bits of each primitive in the primitive segment.

9. The tiling engine (1100) according to claim 1 or 2, wherein the information identifying the primitive block in the display list of the tiles is the address of the primitive block in memory.

10. The tiling engine (1100) according to claim 1 or 2, wherein the tiling engine (1100) is embodied in hardware on an integrated circuit.

11. A method (1600) for generating a display list of tiles for rendering space, the method (1600) comprising: Receive multiple primitive blocks, each primitive block including one or more primitive segments and state data shared by the one or more primitive segments, each primitive segment including transformed geometric structure data of one or more primitives, at least one of the multiple primitive blocks including at least two primitive segments, wherein at least one of the at least two primitive segments includes transformed geometric structure data of at least two primitives, and each primitive segment in a primitive block can be read from memory separately from the other primitive segments of the primitive block; For each primitive segment of the received primitive block, determine which primitives in the primitive segment at least partially fall within the boundary of the block; For each element block that includes at least one element that falls at least partially within the boundary of the tile, information identifying the element block is added to the display list of the tile; For each identified primitive block, information identifying each primitive segment of the primitive block, which includes at least one primitive that at least partially falls within the boundary of the primitive block, is added to the display list; and For each identified element segment, information identifying the element in the element segment that at least partially falls within the boundary of the block is added to the display list; Wherein, if a first primitive segment of a primitive block includes at least one primitive that falls at least partially within the boundary of the primitive block, then a primitive block entry of a first type is added to the display list. The first type of primitive block entry includes the information identifying the primitive block and the information identifying the first primitive segment as a primitive segment including at least one primitive that falls at least partially within the boundary of the primitive block; and If the first primitive segment of the primitive block does not include at least one primitive that falls at least partially within the boundary of the primitive block, then a second type of primitive block entry is added to the display list. The second type of primitive block entry includes the information identifying the primitive block and information indicating that the first primitive segment does not include at least one primitive that falls at least partially within the boundary of the primitive block.

12. The method (1600) according to claim 11, wherein the information identifying the primitive segment in the display list includes information identifying the location of the primitive segment in the memory.

13. The method (1600) according to claim 11 or 12, wherein the first type of primitive block entry has a set of flags, and the second different type of primitive block entry does not have a set of flags.

14. The method (1600) according to claim 11 or 12, wherein for each primitive segment, other than the first primitive segment of the primitive block, which includes at least one primitive that at least partially falls within the boundary of the primitive block, a primitive segment entry is added to the display list.

15. The method (1600) of claim 11 or 12, wherein for each element segment comprising at least one element that falls at least partially within the boundary of the tile, an element segment entry is added to the display list.

16. The method (1600) of claim 14, wherein each primitive segment entry includes information identifying the location of the corresponding primitive segment in the memory.

17. The method (1600) of claim 16, wherein the information identifying the position of the corresponding primitive segment in the memory is an offset from the position of the primitive block in the memory.

18. The method (1600) of claim 11 or 12, wherein the information identifying the primitives in a primitive segment that at least partially falls within the boundary of the tile includes a primitive mask, the primitive mask including bits of each primitive in the primitive segment.

19. The method (1600) according to claim 11 or 12, wherein the information identifying the primitive block in the display list of the blocks is the address of the primitive block in memory.

20. A tiling engine configured to perform the method (1600) according to claim 11 or 12.

21. A graphics processing system (1700) comprising a tiling engine (1100) according to claim 1 or 2.

22. A computer-readable storage medium having stored thereon computer-readable instructions that, when executed at a computer system, cause the computer system to perform the method according to claim 11 or 12.

23. A computer-readable storage medium storing a computer-readable description of a tiling engine (1100) as claimed in claim 1 or 2, the computer-readable description causing the integrated circuit manufacturing system to manufacture an integrated circuit embodying the tiling engine (1100) when processed in an integrated circuit manufacturing system.

Images