Primitive block generator for graphics processing systems

Abstract

The present application relates to a primitive block generator for a graphics processing system. A method and a primitive block generator for generating a primitive block in a graphics processing system. The method includes: receiving transformed position data for a current primitive, the transformed position data indicating the position of the current primitive in a rendering space; determining the distance between the position of the current primitive and the position of a current primitive block based on the transformed position data for the current primitive; determining whether to add the current primitive to the current primitive block based on the distance and the fullness of the current primitive block; in response to determining that the current primitive will be added to the current primitive block, adding the current primitive to the current primitive block; and in response to determining that the current primitive will not be added to the current primitive block, clearing the current primitive block and adding the current primitive to a new current primitive block.

Description

Technical Field

[0001] The present application relates to graphics processing systems, and more particularly, to methods, systems, and primitive block generators for generating primitive blocks from primitives in a graphics processing system. Background Art

[0002] The 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, an application may generate a 3D model of a scene and output geometry data representing objects in the scene. Specifically, the application may divide each object into a plurality of primitives (i.e., simple geometric shapes, such as, but not limited to, rectangles, triangles, lines, and points to which textures may be applied), the plurality of primitives being defined by the positions of one or more vertices. Under these conditions, the geometry data output by the application may include information identifying each vertex (e.g., the coordinates of the vertex in world space) and information indicating the primitives formed by the vertices. The graphics processing system then converts the received geometry data into an image that may be displayed on a screen.

[0003] The graphics processing system may, for example, implement immediate 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 that is 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 (wherein the term "rectangular" includes square). An 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 on-chip memory that is large enough to store data for the entire scene simultaneously.

[0004] TBR involves two key stages: the geometry processing stage; and the rasterization stage. During the geometry processing stage, 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 fall at least partially within the boundaries of the tile is then created. During the rasterization stage, each tile is rendered separately (i.e., the transformed primitives are mapped to pixels and colors are identified for each pixel in 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 can be defined by the texture applied to the pixel and / or the pixel shader program running on the pixel. The pixel shader program describes the operations to be performed for a given pixel. Rendering each tile individually enables the graphics processing system to retrieve only the transformed primitive data associated with a particular tile when rendering the tile in the rasterization stage, which keeps bandwidth requirements for memory (e.g., intermediate buffers) to a minimum. Once a color value has been identified for each pixel, the color value is written out to memory (e.g., a frame buffer) until the entire scene has been rendered. Once the entire scene has been rendered, the scene can be displayed, for example, on a screen.

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

[0006] The geometry processing logic 104 implements the geometry processing stage of TBR. The geometry processing logic 104 includes a transformation logic 108 and a tiling engine 110. The 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). The transformation logic 108 may also perform functions such as clipping and culling to remove geometry data (e.g., primitives or patches) that fall outside the viewing cone, and / or apply lighting / attribute processing known to those skilled in the art. The transformed geometry data (e.g., vertices, primitives, and / or patches) is (i) stored in the memory 1022 and (ii) provided to the tiling engine 110. The tiling engine 110 generates a list of transformed primitives for each tile from the transformed geometry data, the transformed primitives at least partially falling within the tile. The list may be referred to as a display list or a transformed display list. In some cases, the transformed display list includes pointers or links to transformed geometry data (eg, vertex data) associated with primitives that fall at least partially within the tile.

[0007] The rasterization logic 106 implements the rasterization stage of TBR. Specifically, the rasterization logic 106 renders primitives in a tile-by-tile manner by: fetching a display list for a tile from the memory 1023, and then fetching transformed geometry data from the memory 1022 for primitives that fall within the tile as indicated by the display list for the tile; and rendering the primitives for the tile based on the transformed geometry data.

[0008] In some cases, the rasterization logic 106 may include fetch logic 112, hidden surface removal (HSR) logic 114, and texturing / shading logic 116. In these cases, the fetch logic 112 fetches each display list from the memory 1023, and for each display list, fetches the transformed geometry data from the memory 1022 for primitives that fall within the tile as specified by the corresponding display list. The transformed geometry data for a particular tile is then provided to the HSR logic 114, which removes primitive fragments that are hidden (e.g., hidden by other primitive fragments). The term "fragment" is used herein to mean a sample of a primitive at a sampling point that is to be processed to render a pixel of an image. In some examples, there may be a one-to-one mapping of pixels to fragments. However, in other examples, there may be more fragments than pixels, and this oversampling may allow for higher quality rendering of pixel values, such as by facilitating anti-aliasing and other filters that may be applied to multiple fragments for rendering each pixel value.

[0009] The remaining fragments (after hidden surface removal) are then passed to the texturing / shading logic 116, which performs texturing and / or shading on the primitive fragments to determine pixel values ​​for the rendered image. The rendered pixel values ​​for the tile are then stored in a memory 1024 (e.g., a frame buffer).

[0010] The rasterization logic 106 processes each tile, and when the entire image has been rendered and stored in the memory 1024 (e.g., a frame buffer), the image can be output from the graphics processing system 100 and used in any suitable manner, such as displayed on a display, stored in memory, or transmitted to another device, etc. In the sense that fragments are processed by the HSR logic 114 before being processed by the texturing / shading logic 116, 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 texturing / shading would be applied to fragments before HSR is applied to those fragments.

[0011] In many cases, the transformed geometry data may be quite large. This is particularly true if there is a large expansion ratio between the untransformed geometry data and the transformed geometry data (eg, when tessellation is performed by the transformation logic 108).

[0012] Therefore, as described in UK published patent applications GB2458488 and GB2542133, some TBR graphics processing systems use an "untransformed display list" which indicates which untransformed primitives, once transformed, will at least partially fall within the bounds of each tile. Thus, the untransformed display list refers to untransformed primitives rather than transformed primitives. For example, the untransformed display list may include pointers or links to untransformed geometry data (e.g., vertex data) associated with untransformed primitives that will at least partially fall within a tile when transformed. This means that the transformed geometry data does not need to be provided from the geometry processing logic 104 to the memory 1022, or stored in the memory 1022. However, in these systems, the untransformed geometry data referred to in the untransformed display list is transformed again in the rasterization stage. Although this means that the geometry data is transformed twice in some cases, the benefits of avoiding the latency and memory usage of transferring and storing the transformed geometry data to memory may outweigh the processing cost of performing the transformation in the rasterization stage.

[0013] Figure 2An example TBR graphics processing system 200 using an untransformed display list is shown. The TBR graphics processing system 200 is similar to the graphics processing systems described in GB2458488 and GB2542133 and may be referred to as an untransformed display list (UDL) graphics processing system. The system 200 is similar to Figure 1 The system 100 is similar to the system 100 of claim 1, except that: (i) transformed geometry data is not written to memory by geometry processing logic; (ii) instead of identifying transformed primitives that fall within each tile, display lists identify untransformed primitives that would fall within each tile data if transformed; and (iii) rasterization logic includes transformation logic to transform untransformed primitives referenced in untransformed display lists. Figure 1 , system 200 includes memories 2021 , 2023 , 2024 , geometry processing logic 204 , and rasterization logic 206 .

[0014] Similar to Figure 1 The geometry processing logic 104 and the geometry processing logic 204 implement the geometry processing stage of TBR. Figure 2 The geometry processing logic 204 includes transformation logic 208 and tiling engine 210. The transformation logic 208 receives geometry data (e.g., vertices and primitives) from an application (e.g., a game application) and transforms the geometry data into a rendering space (e.g., screen space). The transformation logic 208 may also perform functions such as clipping and culling to remove geometry data (e.g., primitives) that fall outside the viewing frustum. Figure 1 The transformation logic 108 is compared, Figure 2 The transformation logic 208 may not apply lighting / attribute processing because the geometry processing logic 204 uses only position information. The transformed geometry data (e.g., vertices and primitives) is provided to the tiling engine 210. The tiling engine 210 generates a list of untransformed primitives for each tile from the transformed geometry data that, when transformed, would at least partially fall within the tile. Figure 2 The list generated by the tiling engine 201 may be referred to as an untransformed display list because it refers to untransformed geometry data rather than transformed geometry data.

[0015] Similar to Figure 1 The rasterization logic 106 shown, Figure 2The illustrated rasterization logic 206 implements the rasterization stage of the TBR. Specifically, the rasterization logic 206 renders primitives in a tile-by-tile manner by extracting untransformed geometry data for primitives that fall within a tile as indicated by an untransformed display list for the tile, transforming the untransformed geometry data for the tile, and rendering the primitives for the tile based on the transformed geometry data.

[0016] In some cases, the rasterization logic 206 may include fetch logic 212, transform logic 213, hidden surface removal (HSR) logic 214, and texturing / shading logic 216. In these cases, the fetch logic 212 fetches each untransformed display list from the memory 2023 and, for each display list, fetches the untransformed geometry data identified in the display list from the memory 2021. The untransformed geometry data for a particular tile is then provided to the transform logic 213, which transforms the untransformed geometry data (e.g., primitives) into a rendering space (e.g., screen space). The transformed geometry data for a particular tile is then provided to the HSR logic 214, which removes primitive fragments that are hidden (e.g., hidden by other primitive fragments). The remaining fragments (after hidden surfaces are removed) are then passed to the texturing / shading logic 216, which performs texturing and / or shading on the primitive fragments to determine pixel values ​​for the rendered image, which may be passed to the memory 2024 (e.g., a frame buffer) for storage.

[0017] The embodiments described below are provided by way of example only and are not limiting of implementations that address any or all of the shortcomings of known UDL graphics processing systems. Summary of the invention

[0018] This Summary is provided to introduce a selection of concepts that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0019] A method and a primitive block generator for generating primitive blocks in a graphics processing system are described herein. The method includes: receiving transformed position data for a current primitive, the transformed position data indicating a position of the current primitive in a rendering space; determining a distance between the position of the current primitive and a position of a current primitive block based on the transformed position data for the current primitive; determining whether to add the current primitive to the current primitive block based on the distance and the fullness of the current primitive block; in response to determining that the current primitive will be added to the current primitive block, adding the current primitive to the current primitive block; and in response to determining that the current primitive will not be added to the current primitive block, clearing the current primitive block and adding the current primitive to a new current primitive block.

[0020] A first aspect provides a method for generating a primitive block at a primitive block generator in a graphics processing system, the primitive block generator comprising a data storage area for storing a current primitive block to which a primitive can be added, the method comprising: receiving transformed position data for a current primitive, the transformed position data indicating a position of the current primitive in a rendering space; determining a distance between the position of the current primitive and a position of the current primitive block based on the transformed position data for the current primitive; determining whether to add the current primitive to the current primitive block based on (i) the distance and (ii) a fullness of the current primitive block; in response to determining that the current primitive will be added to the current primitive block, adding the current primitive to the current primitive block; and in response to determining that the current primitive will not be added to the current primitive block, clearing the current primitive block and adding the current primitive to a new current primitive block.

[0021] A second aspect provides a primitive block generator in a graphics processing system for generating primitive blocks from a plurality of primitives, the primitive block generator comprising: a data storage area configured to store a current primitive block to which a primitive may be added; and a block allocation logic comprising: a distance calculation logic configured to: receive transformed position data for a current primitive indicating a position of the current primitive in a rendering space; and determine a distance between the position of the current primitive and a position of the current primitive block based on the transformed position data for the primitive; a comparison logic configured to: determine whether to add the current primitive to the current primitive block based on (i) the distance and (ii) a fullness of the current primitive block; in response to determining that the current primitive is to be added to the current primitive block, cause the current primitive to be added to the current primitive block; and in response to determining that the current primitive is not to be added to the current primitive block, cause the current primitive block to be cleared and cause the current primitive to be added to a new current primitive block.

[0022] A third aspect provides a graphics processing system, which includes a primitive block generator of the second aspect.

[0023] The graphics processing system, primitive block generator, and cache described herein may be embodied in hardware on an integrated circuit. A method of manufacturing the graphics processing system, primitive block generator, and cache described herein at an integrated circuit manufacturing system may be provided. An integrated circuit definition data set may be provided, which, when processed in the integrated circuit manufacturing system, configures the system to manufacture the graphics processing system, primitive block generator, and cache described herein. A non-transitory computer-readable storage medium may be provided, having stored thereon a computer-readable description of the graphics processing system, primitive block generator, or cache described herein, which, when processed in the integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture an integrated circuit embodying the graphics processing system, primitive block generator, or cache.

[0024] An integrated circuit manufacturing system may be provided, comprising: a non-transitory computer-readable storage medium having stored thereon a computer-readable description of a graphics processing system, a primitive block generator, or a cache 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 graphics processing system, the primitive block generator, or the cache; and an integrated circuit generation system configured to manufacture the graphics processing system, the primitive block generator, or the cache based on the circuit layout description.

[0025] Computer program code for performing the method as 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 causes the computer system to perform the method as described herein.

[0026] The above-described features may be combined where appropriate, as will be apparent to those skilled in the art, and may be combined with any aspects of the examples described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Examples will now be described in detail with reference to the accompanying drawings, in which:

[0028] Figure 1 is a block diagram of a known tile-based rendering graphics processing system;

[0029] Figure 2 is a block diagram of a known untransformed display list graphics processing system;

[0030] Figure 3 is a block diagram of an untransformed display list graphics processing system based on primitive blocks;

[0031] Figure 4 is a schematic diagram showing an example of an untransformed display list, a primitive block, and untransformed geometry data;

[0032] Figure 5 is used in Figure 3 A flowchart of an example method for rendering data in a graphics processing system;

[0033] Figure 6 is a schematic diagram of a plurality of primitives in an example rendering space divided into a plurality of tiles;

[0034] Figure 7 is a flow chart of an example method of generating a primitive block;

[0035] Figure 8 is a schematic diagram showing an example bounding box for using primitive sets of different granularities;

[0036] Fig. 9 is a schematic diagram showing an example of calculating the distance between a primitive and a primitive block based on a rendering order;

[0037] Fig.10 is a block diagram of an example primitive block generator;

[0038] Fig.11 is a block diagram of an example transformed geometry data cache;

[0039] Fig.12 is a schematic diagram showing an example transformed primitive block;

[0040] Fig.13 is a schematic diagram showing an example transformed geometry data cache that has been partitioned into a plurality of sub-memory blocks;

[0041] Fig.14 is a flow chart of an example method for storing a transformed primitive block in a transformed geometry data cache;

[0042] Fig.15 is a block diagram of an example implementation of HSR logic and texturing / shading logic;

[0043] Fig.16 is a block diagram of an example computer system in which the graphics processing system, primitive block generator, and transformed geometry data cache described herein may be implemented; and

[0044] Fig.17is a block diagram of an example integrated circuit manufacturing system that may be used to produce an integrated circuit embodying any of the graphics processing systems, primitive block generators, and transformed geometry data caches described herein.

[0045] The accompanying drawings illustrate various examples. It will be appreciated by those skilled in the art that the element boundaries (e.g., boxes, groups of boxes, or other shapes) shown in the accompanying drawings represent one example of boundaries. In some examples, one element may be designed as multiple elements, or multiple elements may be designed as one element. Where appropriate, common reference numerals are used throughout the accompanying drawings to indicate similar features. DETAILED DESCRIPTION

[0046] The following description is presented as an example to enable a person 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 apparent to a person skilled in the art. The embodiments are described only as examples.

[0047] As described above, an untransformed display list (UDL) graphics processing system, such as Figure 2 The graphics processing system 200 does not store the transformed geometry data generated in the geometry processing stage, but instead generates a display list for each tile that mentions untransformed primitives, and then the untransformed geometry data corresponding to the untransformed primitives identified in each display list is transformed in the rasterization stage. Such a system does not require memory to store the transformed geometry data generated in the geometry processing stage, and avoids delays in storing and retrieving the transformed geometry data from memory. These memory-based benefits can provide significant improvements in the performance of TBR graphics processing systems, especially when used to render scenes for complex games.

[0048] exist Figure 2In the UDL graphics processing system 200 of FIG. 1 , the rasterization logic 206 is configured to extract primitives associated with a particular tile based on primitives and render them. Specifically, the rasterization logic 206 (e.g., the extraction logic 212 and the transformation logic 213) is configured to extract the untransformed geometry data for each primitive identified in the untransformed display list for the tile (e.g., the untransformed geometry data for each vertex forming the primitive) from the memory 2021, and then transform the extracted geometry data. However, primitives often fall within more than one tile, which may require the same primitive to be extracted and transformed multiple times. Therefore, a cache system may be used to cache the results of the extraction and / or transformation. However, the geometry transformation may contain multiple stages, such as but not limited to clipping, vertex shading, geometry shading, hull shading, and domain shading for tessellation, and caching the results from each geometry transformation stage for primitives (e.g. vertices) used in a tile would require a complex caching system, such as the caching system described in UK published patent application No. GB2542133.

[0049] In addition, in some cases, the transformation logic 213 of the rasterization logic 206 can be implemented using one or more single instruction multiple data (SIMD) processors, because the transformation logic typically applies the same transformation (e.g., the same shader) to multiple vertices. As known to those skilled in the art, a SIMD processor includes multiple processing elements, each of which performs the same operation on a different set of data. Each processing element that processes an input data set is referred to as a "channel" of a SIMD processor. When each channel is "full" (i.e., processing data), the SIMD processor operates most efficiently. In some cases, the SIMD processor of the transformation logic 213 may include 32 channels. Extracting and processing primitives of tiles based on each primitive may often cause the SIMD channels of the transformation logic 213 to be not full, and / or may take time to obtain data for the SIMD channels and put them together.

[0050] The inventors have recognized that geometry data transformations in the rasterization stage can be performed efficiently without a complex cache system by transforming not only untransformed primitives that fall within a tile when transformed, but also untransformed primitives that are close to primitives in the tile when transformed. Not only does this allow the SIMD lanes of the transformation logic 213 to be full (or substantially full), but if additional untransformed primitives are close to primitives in a tile, then it is likely that one of the next few tiles to be rasterized will require the transformed geometry data associated with the primitive. Therefore, the transformed geometry data for the additional untransformed primitives can be stored in a simple cache based on the likelihood that the primitive will be used to rasterize one of the next few tiles to be processed.

[0051] Thus, an untransformed display list (UDL) graphics processing system is described herein, wherein geometry processing logic is configured to group untransformed primitives into untransformed primitive blocks based on corresponding transformed geometry data; and rasterization logic is configured to extract and transform untransformed geometry data for each untransformed primitive in the same untransformed primitive block as the associated untransformed primitive when a particular untransformed primitive is identified in the untransformed display list, and cache the transformed geometry data associated with the primitive in a cache system. If it is assumed that primitives received from an application tend to be spatially grouped (e.g., received in a substantially spatial position order), then grouping the untransformed primitives into untransformed primitive blocks may simply include grouping the untransformed primitives based on the order in which the untransformed primitives were received. However, a more complex mechanism for grouping the untransformed primitives into untransformed primitive blocks may further improve the efficiency of the graphics processing system. Transforming all untransformed primitives in the same untransformed primitive block as the untransformed primitives mentioned in the display list may be referred to herein as a primitive block-based transformation. A UDL graphics processing system implementing a primitive block-based transformation has the memory-based advantages of a UDL that does not require a complex cache system (no memory is required to store the transformed geometry data generated in the geometry processing stage, and there is no delay in storing / retrieving the transformed geometry data to / from the memory).

[0052] Reference now Figure 3 , which shows an example untransformed display list (UDL) graphics processing system 300 that implements primitive block-based transformations in the rasterization stage. Figure 3 System 300 with Figure 2is similar to system 200 in that it includes memories 3021, 3023, 3024, geometry processing logic 304, and rasterization logic 306. Figure 2 Compared with the system 200, Figure 3 The geometry processing logic 304 is configured to group untransformed primitives into untransformed primitive blocks based on corresponding transformed geometry data and store the untransformed primitive blocks in the memory 3022; and the rasterization logic 306 is configured to extract and transform the untransformed geometry data of each untransformed primitive in the same untransformed primitive block as the untransformed primitive when the untransformed display list mentions a specific untransformed primitive and store the transformed geometry data in a cache.

[0053] Memories 3021, 3022, 3023, 3024 may be implemented as one or more blocks of memory. Memories 3021, 3022, 3023, 3024 may be located "off chip" (i.e., not on the same chip as geometry processing logic 304 and rasterization logic 306). Geometry processing logic 304 and rasterization logic 306 may communicate with memories 3021, 3022, 3023, 3024 via one or more communication buses as known in the art.

[0054] As described above, the application generates geometry data describing the objects in the scene to be rendered, and the geometry data is stored in the memory 3021. The geometry data generated by the application is referred to as untransformed geometry data in this article. Untransformed geometry data may include vertex data, primitive data, and / or patch data. Vertex data may include position data for vertices (e.g., X, Y, and Z coordinates describing the position of vertices in world space). Vertex data may also include a set of attributes for describing the appearance of vertices, such as texture coordinates (U, V) and / or base colors to be applied to vertices. In some cases, vertex data may be stored in a vertex buffer of the memory 3021. Primitive data may include information indicating which vertices form each primitive. For example, in the case where the primitive is a triangle, primitive data may indicate which three vertices form the primitive. In some cases, the information identifying a specific vertex in the primitive data may be an index or pointer to a specific portion of the vertex buffer associated with the vertex. For example, if the vertices are numbered from 0 to 127, the portion of the vertex buffer associated with vertex 0 may be identified by index or pointer 0, and the portion of the vertex buffer associated with vertex 20 may be identified by index or pointer 20. In some cases, primitive data may be stored in an index buffer. Patch data includes control points that define patches to be tessellated into primitives for rendering.

[0055] Similar to Figure 2 The illustrated geometry processing logic 204 , geometry processing logic 304 implements the geometry processing stage of TBR. Figure 3 The illustrated geometry processing logic 304 includes transformation logic 308, a primitive block generator 309, and a tiling engine 310. The transformation logic 308 receives untransformed geometry data for a plurality of untransformed primitives and generates transformed position data in a rendering space (e.g., screen space) for each of those untransformed primitives. As described above, the untransformed geometry data for the untransformed primitives includes position data indicating the position of the untransformed primitives in world space. In some cases, generating the transformed position data for the untransformed primitives may include transforming the position data from world space to rendering space. However, in other cases, generating the transformed position data may include first generating one or more sub-primitives from the original untransformed primitives (e.g., by performing tessellation and / or geometry shading on the untransformed primitives), and transforming the position data for the sub-primitives into rendering space.

[0056] In the case where a primitive is a triangle defined by three vertices, the position data for the untransformed primitive (or sub-primitive) may include position data (e.g., X, Y, Z coordinates) for each of the three vertices forming the primitive. In these cases, transforming the position data for the untransformed primitive (or sub-primitive) may include transforming the coordinates of the vertices forming the primitive (or sub-primitive) into a rendering space (e.g., screen space). The transformation logic 208 may also perform functions such as clipping and culling to remove primitives that fall outside the viewing frustum.

[0057] The primitive block generator 309 divides the plurality of untransformed primitives into groups based on transformed position data for the plurality of untransformed primitives, and generates, for each group, primitive blocks identifying portions of untransformed geometry data associated with those untransformed primitives. For example, the primitive block generator 309 may receive transformed position data for the plurality of untransformed primitives and divide the untransformed primitives into groups such that untransformed primitives with similar transformed positions (e.g., similar positions in the rendering space) are in the same group; and generate untransformed primitive blocks for each group, wherein each untransformed primitive block identifies untransformed geometry data associated with those untransformed primitives stored in the memory 3021. The primitive block generator 309 may use any suitable criteria for determining how to group the untransformed primitives based on the transformed position data of the untransformed primitives. Preferably, the untransformed primitives are grouped such that untransformed primitives with spatially similar positions in the rendering space are grouped together. In some examples, the untransformed primitives are grouped into untransformed primitive blocks in the order in which they arrive at the primitive block generator 309. Figures 6 to 10 Example implementations of the primitive block generator 309 and methods that may be implemented by the primitive block generator 309 are described.

[0058] An untransformed primitive block is a data construct used to link groups or sets of untransformed primitives. Figure 4 Examples of untransformed primitive blocks 4021, 4022 are shown. Figure 4The example untransformed primitive blocks 4021, 4022 include a header 404, state data 406, and primitive index data 408. The header 404 includes information describing the untransformed primitive block. For example, the header 404 may include, but is not limited to, the number of vertices mentioned in the untransformed primitive block and / or the number of primitives mentioned in the untransformed primitive block. The state data 406 includes information describing how the untransformed primitives in the untransformed primitive block 4021 or 4022 will be rendered by the rendering logic. The state data may be described as identifying a recipe for rendering the primitives described in the untransformed primitive block. For example, the state data may include, but is not limited to, information identifying a depth comparison mode, a blending state, a texture state, and / or a primitive type. The primitive index data 408 includes a set of indices for each untransformed primitive, the indices identifying the vertices that form the untransformed primitive. For example, in the case where the primitive is a triangle, the primitive index data 408 may include a set of three indices identifying the three vertices that form the triangle. The indices are indices of the vertices sent from the application (which may be referred to herein as global indices). Each index acts as a pointer to a portion of the untransformed geometry data 410 stored in the memory 3021 that defines a particular vertex or is related thereto.

[0059] For example, if Figure 4 As shown, the primitive index data 408 for the first untransformed primitive block 4021 includes three untransformed primitives—P0, P1, and P2—and each untransformed primitive is formed by three vertices. Specifically, the first untransformed primitive P0 is formed by vertices V0, V1, and V2, the second untransformed primitive P1 is formed by vertices V1, V2, and V3, and the third untransformed primitive P2 is formed by vertices V2, V3, and V4. Each vertex index or identifier serves as a pointer to a portion of the untransformed geometry data 410 that defines a particular vertex or is related thereto (e.g., a portion of a vertex buffer). For example, the identification of vertex 0 (V0) serves as a pointer to a portion 412 of the untransformed geometry data 410 that defines vertex 0 (V0) or is related thereto. As described above, the untransformed geometry data for a particular vertex may include position data describing the position of the vertex in world space (e.g., a set of coordinates in world space, such as X, Y, and Z coordinates). The untransformed geometry data for a particular vertex may also include a set of attributes describing the appearance of the vertex, such as texture coordinates (U, V) and / or base colors to be applied to the vertex. In some cases, primitive index data may be generated by copying or writing out a portion of an index buffer associated with the associated untransformed primitive. The primitive index data 408 in the untransformed primitive block may be compressed according to any suitable compression technique.

[0060] In some cases, the state data may be large (e.g., 5 double words or larger) even if there are only a few possible combinations of the state data. For example, the state data may include information identifying the state of multiple parameters, where each parameter is defined by multiple bits. In these cases, instead of explicitly including information for each parameter, each possible combination of state data may be stored in a state data table in memory, and the state data 406 portion of the untransformed primitive block may include only an index or pointer to one entry of the state data table.

[0061] Back to Figure 3 , the untransformed primitive blocks generated by the primitive block generator 309 are stored in the memory 3022, and the transformed position data for the untransformed primitives together with information indicating which untransformed primitive block each untransformed primitive belongs to are provided to the tiling engine 310. The tiling engine 310 determines which untransformed primitives, when transformed, fall at least partially within the boundaries of each tile based on the transformed position data. The tiling engine 310 then generates an untransformed display list for each tile, indicating which untransformed primitives, when transformed, are at least partially within the boundaries of the tile and in which untransformed primitive block each of those untransformed primitives is located.

[0062] In some cases, the untransformed display list for a tile may include information identifying untransformed primitive blocks containing associated untransformed primitives, and a primitive mask for each identified untransformed primitive block identifying which untransformed primitives within the untransformed primitive block are at least partially within the boundaries of the tile when transformed. The information identifying a particular untransformed primitive block may be an address of the untransformed primitive block in a memory, or any other suitable identifier that uniquely identifies the untransformed primitive block. The primitive mask may include, for example, a bit for each untransformed primitive (or each possible untransformed primitive) in the untransformed primitive block, and may be set to one value (e.g., "1") when the untransformed primitive is in the tile and set to another value (e.g., "0") when the untransformed primitive is not in the tile. For example, if each untransformed primitive block may include a maximum of 32 untransformed primitives, then each primitive mask may include 32 bits.

[0063] Figure 4An example untransformed display list 414 for a tile is shown in FIG. 4 . In this example, there are six untransformed primitives (P0, P1, P2, P3, P4, P5) numbered from 0 to 5, and untransformed primitives 0 to 2 (P0, P1, P2) are in untransformed primitive block 0 (UPB0), and untransformed primitives 3 to 5 (P3, P4, P5) are in untransformed primitive block 1 (UPB1). If the tiling engine 310 determines from the transformed position data for these untransformed primitives that untransformed primitives 0, 3, and 4 fall within a particular tile (e.g., tile 0) when transformed, the tiling engine 310 may generate Figure 4 The untransformed display list 414 is shown. Specifically, the tiling engine 310 can generate an untransformed display list 414, which includes: (i) information identifying untransformed primitive blocks 0 and 1 as containing untransformed primitives that, when transformed, at least partially fall within the boundaries of tile 0; and (ii) a primitive mask (e.g., "100") for untransformed primitive block 0, which indicates that the first untransformed primitive (e.g., primitive 0) of the untransformed primitive block, when transformed, at least partially falls within the boundaries of tile 0; and (iii) a primitive mask (e.g., "110") for untransformed primitive block 1 (UPB1), which indicates that the second and third untransformed primitives (e.g., primitives 3 and 4) of the untransformed primitive block, when transformed, at least partially fall within the boundaries of tile 1.

[0064] Each untransformed display list generated by the tiling engine 310 is stored in memory 3023 .

[0065] Similar to Figure 2 The rasterization logic 206, Figure 3 The rasterization logic 306 of the TBR implements the rasterization stage of the TBR. Specifically, the rasterization logic 306 renders primitives in a tile-by-tile manner by: retrieving an untransformed display list for a tile and retrieving untransformed geometry data for untransformed primitives that, when transformed, at least partially fall within the tile as indicated by the untransformed display list for the tile; transforming the untransformed geometry data for the tile; and rendering the primitives for the tile based on the transformed geometry data. However, unlike Figure 2 Instead of extracting and transforming only the untransformed geometry data for untransformed primitives that, when transformed, fall at least partially within a particular tile, the rasterization logic 206 of Figure 3The rasterization logic 306 extracts and transforms all untransformed geometry data for any untransformed primitive blocks identified in the untransformed display list for the tile. This can be described as primitive block based rasterization. In other words, the rasterization logic 306 extracts and transforms untransformed geometry data for any untransformed primitives that are in the same untransformed primitive block as untransformed primitives that fall at least partially within the bounds of the tile when transformed. Once the transformed geometry data for the untransformed primitive block has been generated, the transformed geometry data is stored in a cache (e.g., as a transformed primitive block) for use in rendering the tile that caused its generation, and potentially for rendering one or more subsequent tiles.

[0066] like Figure 3 As shown, the rasterization logic 306 may include fetch logic 312, transform logic 313, cache 315, hidden surface removal (HSR) logic 314, and texturing / shading logic 316. When the rasterization logic 306 wants to (or is ready to) process a particular tile, the fetch logic 312 fetches the untransformed display list for that tile from the memory 3023. The fetch logic 312 then determines whether the cache 315 includes transformed geometry data for all untransformed primitive blocks mentioned in the untransformed display list. For example, if the untransformed display list mentions untransformed primitive block 0 and untransformed primitive block 1, the fetch logic 312 determines whether the cache 315 includes transformed geometry data for untransformed primitive block 0 and untransformed primitive block 1. If the cache 315 does not include transformed geometry data for at least one untransformed primitive block mentioned in the untransformed display list for the tile, then the fetch logic 312 fetches the untransformed geometry data for those uncached untransformed primitive blocks.

[0067] Extracting the untransformed geometry data for the untransformed primitive block may include extracting the untransformed primitive block from the memory 3022, and using information in the untransformed primitive block identifying the untransformed geometry data associated therewith (e.g., information identifying the vertices of the untransformed primitives forming the untransformed primitive block) to extract the associated untransformed geometry data from the memory 3021. Any untransformed geometry data extracted from the memory 3021 is provided to the transformation logic 313, which transforms the untransformed geometry data (e.g., primitives) to generate transformed geometry data. Transforming the untransformed geometry data for the untransformed primitives includes generating at least transformed position data in a rendering space (e.g., screen space) for the untransformed primitives. Transforming the untransformed geometry data may also include performing functions such as clipping and culling to clip or remove primitives that fall partially or completely outside the viewing frustum, and / or performing lighting / attribute processing on the primitives. Any transformed geometry data generated by the transformation logic 313 is stored in the cache 315.

[0068] Once the transformed geometry data for the untransformed primitive blocks identified in the display list for the tile is stored in the cache 315, the fetch logic 312 and / or transform logic 313 informs the HSR logic 314 that the HSR logic 314 can begin processing the tile and which primitives in the primitive blocks form the tile. The HSR logic 314 removes primitive fragments that are hidden (e.g., hidden by other primitive fragments). Methods for performing hidden surface removal are known in the art. The remaining fragments (after hidden surface removal) are then passed to the texturing / shading logic 316, which performs texturing and / or shading on the primitive fragments to determine pixel values ​​for the rendered image, which can be passed to memory for storage in the frame buffer. Although Figure 3 3, but the texturing / shading logic 316 may receive texture data from memory in order to apply texturing to the primitive fragments, as known to those skilled in the art. The texturing / shading logic 316 may apply further processing to the primitive fragments (e.g., alpha blending and other processes), as known to those skilled in the art, in order to determine the rendered pixel values ​​of the image.

[0069] Reference now Figure 5 , which illustrates an example method 500 that may be performed by, for example Figure 3The UDL graphics processing system 300 of the UDL graphics processing system 500 is implemented for rendering a scene based on untransformed geometry data received from an application. The method 500 can be divided into a geometry processing stage (boxes 502 to 510) and a rasterization stage (boxes 512 to 526). The method 500 starts in the geometry processing stage at box 502, where untransformed geometry data describing an object in a scene to be rendered is received. The untransformed geometry data includes position data for each of a plurality of untransformed primitives. As described above, each untransformed primitive can be defined by one or more vertices, and the untransformed geometry data for the untransformed primitives can include vertex data (e.g., X, Y, and Z coordinates) describing the position of one or more vertices in world space, and primitive data describing which vertices form the primitive.

[0070] At block 504, transformed position data for each of the plurality of untransformed primitives is generated. As described above, in some cases, generating transformed position data for the untransformed primitives may include transforming the position data for the untransformed primitives from a world space to a rendering space (e.g., a screen space). In other cases, generating transformed position data for the untransformed primitives may include generating one or more sub-primitives from the untransformed primitives, and transforming the position data for the sub-primitives from a world space to a rendering space (e.g., a screen space). Transforming the position data for the untransformed primitives or sub-primitives may involve transforming the positions (e.g., X, Y, Z coordinates) of the vertices forming the primitives or sub-primitives from a world space to a rendering space (e.g., a screen space). The process of transforming the positions (e.g., X, Y, Z coordinates) of the vertices from a world space to a rendering space (e.g., a screen space) may be referred to as a viewport transform. Methods for performing a viewport transform are known to those skilled in the art. Once the transformed position data for the untransformed primitives has been generated, the method 500 may proceed to block 506 or the method 500 may proceed directly to block 508 .

[0071] At optional block 506, untransformed primitives are clipped or culled (e.g., by transformation logic 308 or a culling module) based on the transformed position data to remove any redundant primitives in order to reduce the workload in the remaining blocks of the method. There are many different methods that can be used to identify that untransformed primitives are redundant and can therefore be removed. Any suitable method or combination of methods can be used to identify redundant primitives. For example, in some cases, if the untransformed primitive is facing away from the user, completely off the screen, completely outside the clipping plane, has a bounding box that does not cover any sample points, and / or does not cover any sample points according to the transformed position data, then the untransformed primitive can be considered redundant. Once the untransformed primitives have been culled based on the transformed position data, the method 500 proceeds to block 508.

[0072] At block 508, after transformed position data has been generated for the untransformed primitives (and optionally after primitives have been culled), the untransformed primitives are sorted into groups based on the transformed position data and untransformed primitive blocks are generated for each group. As described above, each untransformed primitive block includes information identifying the untransformed primitives that form the untransformed primitive block, and information indicating portions of geometry data associated with each of those untransformed primitives. For example, Figure 4 As shown, each untransformed primitive block may include a primitive index section that identifies, for each untransformed primitive in the primitive block, which vertices form the primitive. In some cases, the information identifying the vertex may be an index into a vertex buffer that may be used to obtain geometry data associated with the vertex from the vertex buffer. The untransformed primitive block may also include other information that may assist in processing the primitive block in the rasterization stage, such as information indicating the manner in which the untransformed primitives in the block are to be rasterized.

[0073] The untransformed primitives are preferably grouped so that the untransformed primitives in the same untransformed primitive block are spatially close (i.e., have spatially similar positions) in the rendering space (e.g., screen space) when transformed. In situations where the untransformed primitives are expected to be received or processed in an order in which spatially similar primitives are received or processed in close proximity, the untransformed primitives may be grouped simply based on the order in which the untransformed primitives are received or processed (e.g., in the submission order in which the untransformed primitives are received from the application). For example, every K untransformed primitives may be grouped to form an untransformed primitive block, where K is an integer greater than 2. However, more complex methods of grouping untransformed primitives based on transformed position data may improve the efficiency of the rasterization stage. The following discussion of grouping untransformed primitives in the rasterization stage describes an example of a method of grouping untransformed primitives based on transformed position data. Figures 6 to 10An example method and primitive block generator for grouping untransformed primitives based on transformed position data is described. Once the untransformed primitives have been grouped into untransformed primitive blocks, the method 500 proceeds to block 510 .

[0074] At block 510, for each tile, untransformed primitives that at least partially fall within the bounds of the tile when transformed are determined based on the transformed position data for the untransformed primitives, and an untransformed display list is generated for the tile, which identifies the untransformed primitives that at least partially fall within the tile when transformed and the untransformed primitive blocks to which the untransformed primitives belong. Methods for determining which untransformed primitives at least partially fall within the bounds of a tile when transformed are known to those skilled in the art. As described above, each untransformed display list may include information identifying which untransformed primitive blocks include untransformed primitives that fall within the corresponding tile when transformed, and for each identified untransformed primitive block, may include information identifying which untransformed primitives in the block at least partially fall within the bounds of the tile when transformed. The information identifying the untransformed primitive block may be an address of the untransformed primitive block in a memory or any other suitable identifier that uniquely identifies the untransformed primitive block. The information identifying which untransformed primitives in the untransformed primitive block at least partially fall within the bounds of the tile when transformed may be a primitive mask. The primitive mask may include a bit for each untransformed primitive in the untransformed primitive block, and the bit may be set to one value (e.g., "1") when the corresponding untransformed primitive is in the tile when transformed, and set to another value (e.g., "0") when the corresponding untransformed primitive is not in the tile when transformed. Once the untransformed display list has been generated, the method 500 proceeds to block 512 where the rasterization stage begins.

[0075] At block 512, the untransformed display list for the tile generated in block 510 is received (e.g., at the rasterization logic 306 or the fetch logic 312 from the memory 3023). Once the display list is received, the method 500 proceeds to block 513. At block 513, the first untransformed primitive block identified in the untransformed display is selected and the method 500 proceeds to block 514.

[0076] At block 514, it is determined whether transformed geometry data for the selected untransformed primitive block is present in the cache. As will be described in more detail in block 518, after the untransformed geometry data for the untransformed primitive block (i.e., the untransformed geometry data associated with the untransformed primitives in the untransformed primitive block) is transformed in the rasterization stage, the transformed geometry data for the untransformed primitive block is temporarily stored in the cache. If the transformed geometry data for the selected untransformed primitive block is not present in the cache, the method 500 proceeds to block 516. However, if the cache includes transformed geometry data for the selected untransformed primitive block, the method 500 proceeds to block 520.

[0077] At block 516, untransformed geometry data for the selected untransformed primitive block is retrieved (e.g., by the retrieval logic 312) from a memory (e.g., the memory 3021). The untransformed geometry data for the untransformed primitive block may be retrieved from the memory based on information in the untransformed primitive block. For example, as described above, each untransformed primitive block may include vertices indicating each of the untransformed primitives that form the block. The identified vertices may be used to obtain geometry data associated with those vertices, which together form the untransformed geometry data for the untransformed primitive block. In some cases, the information identifying the vertex may be an index into a vertex buffer that may be used to obtain untransformed geometry data associated with the vertex in the vertex buffer. Once the untransformed geometry data for the selected untransformed primitive block has been retrieved, the method 500 proceeds to block 518.

[0078] At block 518, the untransformed geometry data extracted in block 516 is transformed to generate transformed geometry data, and the transformed geometry data is stored in a cache. Transforming the untransformed geometry data for the untransformed primitive includes generating transformed position data for the untransformed primitive in a rendering space (e.g., screen space). As described above, in some cases, generating the transformed position data for the untransformed primitive may include transforming the position of the untransformed primitive into a position in the rendering space. In other cases, generating the transformed position data for the untransformed primitive may include generating one or more sub-primitives from the untransformed primitive (by tessellation or geometric shading) and transforming the positions of those sub-primitives into positions in the rendering space. As described above, in the case where a primitive is defined by one or more vertices, transforming the position of the primitive (or sub-primitive) into a position in the rendering space may include transforming the coordinates of the vertices into rendering space (e.g., screen space) coordinates. Transforming the geometry data may also include performing one or more other operations on the untransformed geometry data, such as, but not limited to, clipping or culling irrelevant primitives, as described above with respect to block 506. Once the untransformed geometry data extracted in block 516 has been transformed and stored in the cache, the method 500 proceeds to block 520.

[0079] At block 520, transformed geometry data for untransformed primitives identified in the untransformed display list (i.e., those untransformed primitives to be used for rendering the tile) is obtained from the cache and used to render those primitives. As described above, rendering the primitives may include performing hidden surface removal to remove fragments of the primitives that are hidden in the scene, and / or performing texturing and / or shading on the fragments to determine pixel values ​​for the rendered image. Once the pixel values ​​for the tile have been determined, the method 500 proceeds to block 522.

[0080] At block 522, the pixel values ​​are passed to memory 3024 for storage in a frame buffer. The method 500 then proceeds to block 524, where it is determined whether the untransformed display list identifies another untransformed primitive block. If the untransformed display list identifies another untransformed primitive block, the method 500 proceeds to block 526, where the next untransformed primitive block identified in the untransformed display list is selected and blocks 514 to 522 are then repeated for the untransformed primitive block.

[0081] Blocks 512 to 522 (ie, the rasterization phase) may be repeated for each untransformed display list (ie, for each tile), at which point the entire image has been rendered and stored in memory. At this point, the image may be output and displayed, for example, on a display.

[0082] Primitive Block Generator

[0083] As described above, the primitive block generator 309 is configured to divide a plurality of untransformed primitives into groups based on transformed position data for the plurality of untransformed primitives, and to generate an untransformed primitive block for each group that identifies a portion of untransformed geometry data associated with those untransformed primitives. The primitive block generator 309 may use any suitable criteria for determining how to group the untransformed primitives based on the transformed positions of the untransformed primitives. Preferably, the untransformed primitives are grouped so that untransformed primitives that are in close proximity in rendering space (e.g., screen space) when transformed are grouped together. As described above, all untransformed geometry data associated with the untransformed primitive blocks mentioned in the untransformed display list for the tile are extracted and transformed, regardless of whether all or only a portion of the untransformed primitives in the untransformed primitive block fall at least partially within the tile when transformed. This transformation may be efficiently performed using a SIMD processing unit to process different items of geometry data from the untransformed primitive block in parallel. All transformed geometry data for the untransformed primitive block is then stored in the cache. Thus, if an "extra" untransformed primitive (i.e., an untransformed primitive in the same untransformed primitive block as the untransformed primitive that was in the tile when transformed but does not itself fall within the tile) that is fetched and transformed is spatially close to the untransformed primitive in the tile when transformed, then it is likely that the transformed geometry data associated with the extra untransformed primitive will be needed to render one of the nearby tiles (which is likely to be processed quickly), which increases the likelihood that the transformed geometry data associated with the "extra" untransformed primitive will be in the cache again when it is needed.

[0084] The untransformed primitives (and the untransformed geometry data associated therewith) may be provided to the geometry processing logic 304 in a particular order or sequence. In these cases, the transformation logic 308 may be configured to process the untransformed primitives (i.e., transform the position data associated with the untransformed primitives) in the order so that the primitive block generator 309 receives the transformed position data associated with the untransformed primitives in the same order. It will be apparent to those skilled in the art that the order of the untransformed primitives can affect the way a scene is rendered. For example, if multiple overlapping primitives are semi-transparent, the order in which the multiple overlapping primitives are processed may affect the way the primitives are blended to form the rendered scene. Therefore, in order to maintain the sequential order of the untransformed primitives, the primitive block generator 309 may be configured to group the untransformed primitives (i.e., the transformed position data associated therewith) based on the order in which they are received ("submission order") so as to preserve their order. For example, the primitive block generator 309 may be configured to continue placing received untransformed primitives in the same group until the group is full, at which point the primitive block generator creates and outputs an untransformed primitive block for the group of primitives. Any other untransformed primitives received are placed in the next group until the group is full, and so on. In this way, the order of the untransformed primitives is maintained in the untransformed primitive block. A group may be considered "full" if the number of vertices in the group is greater than or equal to the maximum number of vertices (e.g., the maximum number of vertices in a primitive block may be 64 or 128 to give two examples) and / or if the number of primitives in the group is greater than or equal to the maximum number of primitives (e.g., the maximum number of primitives in a primitive block may be 64 or 128 to give two examples). If there is a state change, a new group may be started because, in the examples described herein, primitives grouped together into untransformed primitive blocks share the same state.

[0085] In the case where untransformed primitives that are close in order are also close in space (i.e., in rendering space (e.g., screen space)) when transformed, the untransformed primitives are grouped based on the order in which the primitives (i.e., the transformed position data associated therewith) are received. Figure 3306. However, this method of grouping untransformed primitives may not allow the rasterization logic 306 to operate efficiently in situations where untransformed primitives that are close in order are likely to be spatially far apart in rendering space (e.g., screen space). This is because in these situations it is likely that this method will produce an untransformed primitive block containing untransformed primitives that are spatially far apart when transformed. If the untransformed primitive block includes untransformed primitives that are spatially far apart when transformed, then the rasterization logic 306 is unlikely to use the transformed geometry data associated with the "extra" untransformed primitives in the untransformed primitive block before retrieving the transformed geometry data from the cache.

[0086] For example, Figure 6 The exhibition will be presented by Figure 3 A simple example of a scene 600 rendered by the graphics processing system 300 of FIG. The scene 600 contains two similar objects 6021 and 6022, which are spatially separated from each other in the scene 600. As described above, in a TBR graphics processing system, the rendering space (eg, screen space) is divided into a plurality of tiles. Figure 6 In the example shown in , the rendering space (e.g., screen space) is divided into a 4×6 array of rectangular tiles. In other examples, the rendering space (e.g., screen space) can be divided into different numbers and / or arrangements of tiles. In one example, each tile includes 32×32 sample positions, and there can be many tiles (e.g., hundreds of tiles) in the rendering space (e.g., screen space), depending on the size and resolution of the image being rendered. In other examples, the tiles can be non-rectangular (e.g., triangular or hexagonal), or can vary in size depending on their position.

[0087] Figure 6 Two primitives 6041, 6042 of a first object 6021 and two similar primitives 6043, 6044 of a second object 6022 are shown. Figure 6 In the example of , the primitive is a triangle that may be defined by vertex data at three vertices, but in other examples other types of primitives may be used, where the primitive may be other shapes such as quadrilaterals or hexagons, or may be lines or points. The primitives may be received at the geometry processing logic 304 in an order that may be deemed suitable, and the primitives may, for example, place similar primitives together in the order such that primitives 6041, 6042 are received consecutively at the geometry processing logic 304. As an example, primitives may be "similar" and therefore placed together in the order if they have similar states, where the state is information that describes the way the primitive is to be rendered.

[0088] If the untransformed primitives are placed in that order so that "similar" primitives are placed together in that order, then primitives 6041, 6042, 6043, 6044 may be placed together in that order and other primitives of the first object may be placed further away in that order. This means that if the primitive block generator places the untransformed primitives in the primitive block based on the order in which the primitives are received, then primitives 6041, 6042, 6043, 6044 will likely be placed in the same untransformed primitive block, while other primitives of the first object 6021 may be placed in one or more different untransformed primitive blocks. This means that when the rasterization logic 306 processes the tile in the first row of the sixth column, it will extract and transform the untransformed geometry data for all untransformed primitives in the untransformed primitive block that contains primitives 6043, 6044 (i.e., it will also extract and transform the untransformed geometry data for primitives 6041, 6042). However, because the tiles in the third row of the second column are far away from the tiles in the first row of the sixth column, it is unlikely that the transformed geometry data for primitives 6041, 6042 will be in the cache again when the tiles in the third row of the second column are processed by the rasterization logic 306. This would mean that the untransformed geometry data for the untransformed primitive blocks would have to be fetched and transformed again. Retransforming the untransformed geometry data for the untransformed primitives may be time and processing resource intensive where the process of transforming the geometry data includes executing one or more shader programs, such as, but not limited to, vertex shader programs; geometry shader programs; hull shader programs, and domain shader programs. In addition, in the case where the process of transforming the geometry data includes executing one or more shader programs, such as, but not limited to, vertex shader programs; geometry shader programs; hull shader programs, and domain shader programs, the transformed geometry data for the untransformed primitives may be time and processing resource intensive. Figure 3 When the graphics processing system 300 of the present invention processes untransformed primitives, writing data to and reading data from the memory 3021, 3022, 3023 is a relatively slow process, especially when the memory is "off chip", that is, not on the same chip as the geometry processing logic 304 and / or the rasterization logic 306. The rasterization logic 306 may be able to process primitives more efficiently if the untransformed primitives are grouped based on their spatial location to increase the likelihood that the transformed geometry data associated with "extra" untransformed primitives in the untransformed primitive block (i.e., those untransformed primitives in the untransformed primitive block that, when transformed, would not fall at least partially within the tile being processed) will be in the cache when the tile associated with the "extra" untransformed primitive is processed.

[0089] Therefore, in other cases, the primitive block generator 309 may be configured to group the untransformed primitives according to their transformed spatial positions, as described by the transformed position data. An example method for grouping primitives according to their spatial positions is described in UK Published Patent Application No. GB2526598 and is incorporated herein by reference. Specifically, GB2526598 describes a method in which, when a primitive is received at a primitive block generator, the primitive block generator compares the spatial position of the received primitive with the spatial position of one or more 'open' primitive blocks and allocates the received primitive to a primitive block based on the result of the comparison. GB2526598 describes that in one example, if the spatial position of the primitive coincides with the spatial position of the primitive block or is at a minimum distance from the spatial position of the primitive block (the spatial position of the primitive block is based on the spatial position of the primitive in the primitive block), then the primitive is allocated to the primitive block. GB2526598 describes several mechanisms for determining the spatial position of a primitive, the spatial position of a primitive block, and the distance between the spatial position of a primitive and the spatial position of a primitive block.

[0090] The inventors have recognized that the performance and efficiency of the rasterization stage can be further improved if the decision on whether to add a primitive to a primitive block is based on the distance between the spatial position of the primitive and the spatial position of the primitive block and the fullness of the primitive block. This provides a good trade-off between having sufficient primitive blocks (which will fill the SIMD lanes) and having primitive blocks with primitives that are too far apart. Therefore, a primitive block generator is described below that is configured to place primitives in a primitive block based on (i) the distance between the spatial position of the primitive and the spatial position of the primitive block and (ii) the fullness of the primitive block. For example, in some cases, if the distance between the spatial position of the primitive and the spatial position of the primitive block is less than a distance threshold, then the primitive can be placed in the primitive block, where the distance threshold is dynamically selected based on the "fullness" of the primitive block. In some cases, the lower the fullness of the primitive block, the greater the threshold distance, and the higher the fullness of the primitive block, the smaller the threshold distance.

[0091] Reference now Figure 7 , which illustrates an example method 700 for generating a primitive block, which may be Figure 3 The method 700 is implemented in a primitive block generator 309 of the embodiment of the present invention, wherein the decision on whether to place a primitive in a primitive block is based on the distance between the spatial position of the primitive and the spatial position of the primitive block and the fullness of the primitive block. Figure 3The method 700 may be used in a UDL TBR graphics processing system of the graphics processing system 300 of the embodiment of the present invention to generate an untransformed primitive block (i.e., a primitive block referring to an untransformed primitive), or the method 700 may be used in a non-UDL TBR graphics processing system to generate a transformed primitive block (i.e., a primitive block referring to a transformed primitive). As described above, in some cases, an untransformed primitive may be transformed into a plurality of transformed primitives (i.e., a plurality of sub-primitives may be generated therefrom, and the sub-primitives may be transformed into transformed primitives). In these cases, the transformed primitives may be classified into the untransformed primitive blocks based on the transformed primitives or based on the untransformed primitives.

[0092] In the case where transformed primitives are sorted into primitive blocks based on untransformed primitives, all transformed primitives corresponding to a single untransformed primitive are considered a single primitive for the purpose of making a decision as to whether to add a primitive to a primitive block. In these cases, the current primitive is a collection of transformed primitives associated with the untransformed primitive. In these cases, each untransformed primitive will only be identified in a single untransformed primitive block, which may mean that the untransformed primitive block only has to be retransformed once. However, when each untransformed primitive block is transformed, the transformed geometry data associated with that each untransformed primitive block may be stored in the transformed primitive block. If an untransformed primitive produces many transformed primitives, all the transformed geometry data associated with the untransformed primitives may not be stored in a single transformed primitive block (due to size limitations) and may have to be stored in a hierarchy of transformed primitive blocks, which may make the retrieval of the transformed geometry data more complicated.

[0093] In contrast, in cases where transformed primitives are sorted into primitive blocks based on transformed primitives, the decision as to whether to add a primitive to a primitive block is based solely on the transformed position data for the transformed primitive. In these cases, the current primitive is a single transformed primitive. This means that different transformed primitives corresponding to the same untransformed primitive may be associated with different untransformed primitive blocks. Thus, an untransformed primitive may be identified in multiple untransformed primitive blocks. In these cases, additional information may be added to the untransformed primitive block to specify which transformed primitives associated with the untransformed primitive identified in the untransformed primitive block are associated with the primitive block. Then, when the untransformed primitive block is transformed, only the transformed geometry data associated with the identified transformed primitives will be stored in the transformed primitive block. This allows the system to know in advance how many transformed primitives will be in the corresponding transformed primitive block, thereby allowing one transformed primitive block per untransformed primitive block. However, this may cause the same untransformed primitive to be retransformed multiple times in the rasterization stage - once for each untransformed primitive block to which the untransformed primitive belongs.

[0094] The method 700 begins at block 702, where a primitive block generator receives transformed position data for a current primitive. As described above, the current primitive may be a single transformed primitive (i.e., a primitive output by the transformation logic) or a primitive formed by a set of transformed primitives associated with the same untransformed primitive. In the case where the current primitive is a single transformed primitive, the transformed position data includes information indicating the position of the primitive in a rendering space (e.g., screen space). In the case where a primitive is defined by one or more vertices, the transformed position data may include position data (e.g., X, Y, Z coordinates) for the vertices forming the primitive. However, in the case where the current primitive is a primitive formed by a set of transformed primitives associated with the same untransformed primitive, the transformed position data may include information indicating the position of each of the one or more transformed primitives in the rendering space. However, it will be apparent to a person skilled in the art that the position data may include other and / or different information. Once the transformed position data for the current primitive has been received, the method 700 proceeds to block 704.

[0095] At block 704, the primitive block generator determines whether there are any primitives in the current primitive block. In other words, the primitive block generator determines whether the current primitive block is empty. The current primitive block is the primitive block to which new primitives can be added. If the primitive block generator determines that there is at least one primitive in the current primitive block, then the method 700 proceeds to block 706. However, if the primitive block generator determines that there are no primitives in the current primitive block, then the method 700 proceeds directly to block 712.

[0096] At block 706, the primitive block generator determines the distance between the spatial position of the current primitive and the spatial position of the current primitive block. The distance is a quantitative measure or set of measures indicating how 'close' the current primitive is to the primitives in the current primitive block. The distance may be determined in any suitable manner.

[0097] In some cases, the distance between the spatial position of the current primitive and the spatial position of the current primitive block is determined by the bounding box of the current primitive block without the current primitive (i.e., the bounding box for the primitives in the current primitive block) and the bounding box of the current primitive block with the current primitive (i.e., the bounding box for the primitives in the current primitive block and the current primitive). A "bounding box" for a set of one or more primitives is the smallest bounding box or enclosing box in which all primitives are placed. The bounding box can be an axis-aligned bounding box. The bounding box can be determined based on the maximum and minimum x and y positions of the primitives in the set. In the case where each primitive is defined by one or more vertices, the maximum and minimum x and y positions of the primitives can be the maximum and minimum x and y coordinates, respectively, of the vertices that form the primitives in the set. In some cases, the resolution of the bounding box can be a per-sample resolution (i.e., the resolution of the sampling grid) or a per-tile resolution. For example, Figure 8 An example rendering space 800 is shown that is divided into a 4×5 matrix of tiles. If the primitives in the collection form an object 802, then a bounding box for the primitives may be shown at 804 if at a per-sample resolution. In contrast, a bounding box for the primitives may be shown at 806 if at a per-tile resolution.

[0098] In some cases, the distance between the spatial position of the current primitive and the spatial position of the current primitive block is based on the size of the bounding box of the primitive block without the current primitive and the size of the bounding box of the primitive block with the current primitive in terms of one or more dimensions. For example, in some cases, the distance may be equal to the difference between the sizes of the bounding boxes for the primitive blocks with and without the current primitive in terms of one or more dimensions. Specifically, the distance may be equal to: the difference in the x-size of the bounding boxes; the difference in the y-size of the bounding boxes; the difference in the areas (e.g., x*y) of the bounding boxes; or a combination of one or more of these differences. For example, the distance may be represented by any combination of the listed difference metrics. For example, the distance may be represented by a single difference metric or multiple difference metrics. For example, in some cases, the distance may be represented by a triple array (a, b, c), where a is the difference in the x-size of the bounding boxes, b is the difference in the y-size of the bounding boxes, and c is the difference in the areas of the bounding boxes.

[0099] In other examples, the distance may be equal to the ratio between the sizes of the bounding boxes for the current primitive blocks with and without the current primitive, for one or more dimensions. For example, the distance may be equal to: a ratio of the x-dimensions of the bounding boxes; a ratio of the y-dimensions of the bounding boxes; a ratio of the areas (e.g., x*y) of the bounding boxes; or a combination of one or more of these ratios. For example, the distance may be represented by a single ratio metric or multiple ratio metrics. For example, in some cases, the distance may be represented by a triple array (a, b, c), where a is the ratio of the x-dimensions of the bounding boxes, b is the ratio of the y-dimensions of the bounding boxes, and c is the ratio of the areas of the bounding boxes.

[0100] In other examples, the distance may be a combination of distance and ratio metrics.

[0101] In other cases, instead of determining the distance based on the bounding box of the current primitive block with and without the current primitive, the distance may be determined based on the order in which the tiles are rendered. The tile rendering order may not be fixed (e.g., it may be dynamically selected), but if it is fixed or at least estimated, the tile rendering order may be used to determine how 'close' the current primitive is to the current primitive block. Specifically, the tile rendering order may be used to estimate how long it will take to process the current primitive after processing the tile associated with the current primitive block. In general, if the untransformed geometry data associated with the current primitive and the untransformed geometry data for the current primitive block are transformed at the same time, then based on the tile rendering order, the more tiles the current primitive is away from the current primitive block, the lower the probability that the transformed geometry data associated with the current primitive and the current primitive block will still be in the cache.

[0102] For example, Fig. 9 An example rendering space 900 is shown that is divided into a 4×5 matrix of tiles, with the rendering order shown by arrows 902 (i.e., starting from the top row, one row of tiles is rendered at a time, and each row is rendered from left to right). In this example, the primitives in the current primitive block form an object 904 that is located in a tile in the first column and first row, and the current primitive 906 is located in a tile in the third row and first column. In this example, the spatial distance between the current primitive 906 and the current primitive block 904 is relatively close (e.g., 2 tiles apart), but the distance between the current primitive 906 and the current primitive block 904 based on the tile rendering order is much greater (e.g., 10 tiles apart).

[0103] Although this is a simple example where primitives of the current primitive block fall within a single tile and the current primitive also falls within a single tile, the same principles may apply in situations where primitives of the current primitive block fall within multiple tiles and / or the current primitive falls within multiple tiles. For example, more generally, the bounding box of the current primitive and the bounding box for the current primitive block may be mapped to tiles in the rendering space. In some cases, the distance between the bounding boxes may be the distance (e.g., in units of tiles) between the two closest tiles (according to the tile rendering order) of the two bounding boxes. For example, if the current primitive block is mapped to Fig. 9 The 2×2 array of tiles in the upper left corner of the rendering space shown in and the current primitive is located as Fig. 9 , then the distance would be 4 tiles. In other cases, the distance between the bounding box for the current primitive and the bounding box for the current primitive block may be determined as the distance between the centers of the two bounding boxes (e.g., in units of tiles) according to the tile rendering order.

[0104] Once the distance between the current primitive and the current primitive block has been determined, the method 700 proceeds to block 708 .

[0105] At block 708, the primitive block generator determines whether to add the current primitive to the current primitive block based on a comparison of the distance determined in block 706 with one or more distance thresholds, wherein the one or more distance thresholds are dynamically determined based on the fullness of the current primitive block. Ideally, the primitive block is full (e.g., has a maximum number of primitives or vertices (or close to the maximum number)) and includes primitives with spatially similar positions in the rendering space (e.g., they are close together). However, in many cases, fullness and spatial locality are competing criteria. Specifically, in many cases, in order to make the primitive block full, the spatial distance between primitives in the primitive block must be increased so that the primitive block includes primitives that are far away in the rendering space. Similarly, in many cases, in order to ensure that the spatial distance between primitives is small, the primitive block becomes smaller. In addition to the fact that small primitive blocks (i.e., primitive blocks with a small number of primitives) cannot fill the SIMD channel, there are additional items associated with each primitive block. Therefore, it is necessary to find a balance between the spatial distance between primitives in the primitive block and the fullness of the primitive block.

[0106] The inventors have identified that a good balance can be achieved by adjusting the threshold based on the fullness of the current primitive block. Specifically, in some cases, if the current primitive block is less full, then the distance threshold is higher, and if the current primitive block is more full, then the distance threshold is lower. This means that when there are only a few primitives in the primitive block, the current primitive is relatively likely to be added to the current primitive block in order to fill the primitive block, even when the current primitive is far away from primitives that are already in the current primitive block. In contrast, when there are many primitives in the current primitive block, the current primitive is only likely to be added to the current primitive block if the current primitive is close to primitives that are already in the current primitive block. Thus, when a primitive block is rather empty (e.g., comprises a small number of primitives and / or vertices), the size criterion is more important than the spatial similarity criterion—i.e., adding more primitives to the primitive block is more important than bringing the primitives close in space; and when a primitive block is rather full (e.g., comprises a large number of primitives and / or vertices), the spatial similarity criterion is more important than the size criterion—i.e., it is not worth adding primitives that are spatially far away, since the primitive block already has a large number of primitives that are spatially close together.

[0107] In some cases, one or more distance thresholds may be dynamically determined according to a formula based on the fullness of the current primitive block. For example, one or more distance thresholds may be inversely proportional to the fullness of the current primitive block. In other cases, there may be a predetermined set of one or more distance thresholds associated with certain ranges of fullness. For example, there may be a first set of one or more distance thresholds used when the current primitive block is less than one quarter full, a second set of one or more distance thresholds used when the current primitive block is at least one quarter full but less than one half full, a third set of one or more distance thresholds used when the current primitive block is at least one half full but less than three quarters full, and a fourth set of one or more distance thresholds used when the current primitive block is at least three quarters full. It will be apparent to those skilled in the art that these are merely examples and there may be different numbers of sets of distance thresholds and / or predetermined sets of distance thresholds that may match different ranges of fullness. In some cases, predetermined sets of distance thresholds associated with different ranges may be stored in a lookup table.

[0108] Regardless of whether the distance threshold is dynamically determined according to a formula or predetermined for certain ranges of full scale, in the case where there are multiple distance thresholds per full scale / full scale range, the distance threshold may not increase / decrease by the same amount for each distance threshold. For example, if the set of distance thresholds for a first full scale range includes a first distance threshold of 10 and a second distance threshold of 20, then the set of distance thresholds for a second full scale range may include a first distance threshold of 5 and a second distance threshold of 15.

[0109] The fullness of the current primitive block may be based on (i) the number of primitives in the current primitive block, and / or (ii) the number of vertices in the current primitive block, if the primitives are formed by one or more vertices. For example, there may be a maximum number of primitives and / or a maximum number of vertices in the primitive block. The fullness of the primitive block may be equal to, for example, the ratio of the number of primitives in the current primitive block to the maximum number of primitives; the ratio of the number of vertices in the current primitive block to the maximum number of vertices; the maximum of the two ratios; or another combination of the two ratios. It will be apparent to those skilled in the art that these are merely examples and that the 'fullness' of the current primitive block may be determined in any suitable manner.

[0110] In the case where the method 700 is used to generate a transformed primitive block, the transformed primitive block will include transformed primitives, so the number of primitives in the current primitive block is the number of transformed primitives in the current primitive block, and the number of vertices in the current primitive block is the number of transformed vertices in the current primitive block. In contrast, in the case where the method 700 is used to generate an untransformed primitive block, the untransformed primitive block will include untransformed primitives, so the number of primitives in the current primitive block is the number of untransformed primitives in the current primitive block. In the case where the method 700 is used to generate an untransformed primitive block, each untransformed primitive block may be associated with one or more transformed primitives and one or more transformed vertices. In the case where the transformed primitives are processed based on the untransformed primitives, this is all the transformed primitives associated with the untransformed primitives in the untransformed primitive block. In the case where the transformed primitives are processed based on the transformed primitives, this may be a transformed primitive related to an untransformed primitive in an untransformed primitive block that is explicitly associated with the untransformed primitive block. Likewise, a transformed primitive block may be associated with multiple transformed vertices. In these cases, the fullness may also or alternatively be based on the number of transformed primitives or transformed vertices associated with the current primitive block. The number of transformed primitives or transformed vertices associated with the untransformed primitive block may be limited to limit the size of the corresponding transformed primitive block when it is generated in the rasterization stage.

[0111] In the case where the distance includes a single metric, such as a ratio of the areas of the bounding boxes or a difference between the x dimensions of the bounding boxes, there may be a single distance threshold. In these cases, the primitive block generator may determine to add the current primitive to the current primitive block if the distance is less than the distance threshold, otherwise not to add it to the current primitive block. In the case where the distance includes multiple metrics, such as a three-dimensional array (a, b, c), there may be a single distance threshold or multiple distance thresholds. For example, in some cases, multiple distance metrics may be combined in a certain way, and the combined metric may be compared with a single distance threshold. In other cases, there may be multiple distance thresholds that are compared with different distance metrics. For example, if the distance includes a three-dimensional array (a, b, c), where a is the ratio of the x dimensions of the bounding boxes, b is the ratio of the y dimensions of the bounding boxes, and c is the ratio of the areas of the bounding boxes, then there may be three distance thresholds that are compared with one of the distance metrics. In these cases, the primitive block generator may be configured to determine not to add the current primitive to the current primitive block if only a subset of the distance thresholds (eg, only one distance threshold) is exceeded, or only if all distance thresholds are exceeded.

[0112] If the comparison of the distance with the one or more distance thresholds determines not to add the current primitive to the current primitive block, the method 700 proceeds to block 710. However, if the comparison of the distance with the one or more distance thresholds determines to add the current primitive to the current primitive block, the method 700 proceeds directly to block 712.

[0113] At block 710, after determining not to add the current primitive to the current primitive block, the primitive block generator clears the current primitive block. Clearing the current primitive block includes outputting the contents of the current primitive block (e.g., information identifying the primitives in the primitive block) and clearing the current primitive block. Outputting the primitive block may include writing the current primitive block to a memory (e.g., memory 3022). Thus, at the end of clearing, the current primitive block contents have been output (e.g., for use in the rasterization stage of the TBR) and the (new) current primitive block is empty. Once the current primitive block has been cleared, the method 700 proceeds to block 712.

[0114] At box 712, the primitive block generator adds the current primitive to the current primitive block. In the case where the method 700 is used to generate an untransformed primitive block, adding the current primitive to the current primitive block may include adding information to the current primitive block, the information identifying the untransformed primitive associated with the current primitive. As described above, in the case where the primitive is defined by one or more vertices, the information identifying the primitive may include information identifying the vertices forming the primitive, which allows the retrieval of untransformed geometry data associated with the vertices. For example, in the case where the primitive is a triangle defined by three vertices, the information identifying the primitive may include information identifying the three vertices forming the primitive. In some cases, the information identifying a particular vertex may be an index of a vertex sent from an application, the index pointing to a portion of a memory (e.g., a vertex buffer) storing untransformed geometry data associated with the vertex. In the case where a transformed primitive is added to a primitive block based on a transformed primitive, in addition to adding information identifying the untransformed primitive block associated with the current primitive, information identifying a particular transformed primitive may also be added. Where the method 700 is used to generate a transformed primitive block, adding the current primitive to the current primitive block may include adding transformed geometry data associated with the current primitive to the current primitive block.

[0115] In the case where block 712 is executed directly after block 710 or block 704, the current primitive block will be empty, causing the current primitive to become the first primitive in the current primitive block. However, if block 712 is executed directly after block 708, the current primitive block will already include one or more primitives and the current primitive is added to those primitives. Once the current primitive has been added to the current primitive block, the method 700 proceeds to block 714.

[0116] At block 714, the primitive block generator determines whether the current primitive block is now full. As described above, in some cases, there may be a maximum number of primitives and / or a maximum number of vertices in a primitive block. In these cases, the primitive block generator may determine that the current primitive block is full if the number of primitives and / or the number of vertices in the primitive block is equal to the maximum number of primitives or the maximum number of vertices, respectively. If it is determined that the current primitive block is now full, then the method 700 proceeds to block 716, where the primitive block is cleared (as described above with respect to block 710). However, if it is determined that the current primitive is not full, then the method 700 proceeds to block 718.

[0117] At block 718, the primitive block generator determines whether there are any more primitives to be processed. If there is at least one additional primitive to be processed, then the method 700 returns to block 702. However, if there are no more primitives to be processed (as long as the current primitive block is not empty), then the current primitive block is cleared (as described above with respect to block 710) and the method 700 ends.

[0118] In other examples, where primitives are formed by one or more vertices, after determining at block 708 that the current primitive is not to be added to the current primitive block based on a comparison of the distance between the current primitive and the current primitive block with one or more distance thresholds, the primitive block generator may be configured to determine whether the current primitive shares at least one vertex with one of the primitives in the current primitive block before proceeding to block 710 of emptying the current primitive block. If the primitive block generator determines that the current primitive shares at least one vertex with a primitive in the current primitive block, the primitive block generator may determine that the current primitive is to be added to the current primitive block despite not meeting the distance threshold, or may determine that the current primitive is to be added to the current primitive block if certain conditions are met. For example, if the current primitive shares at least one vertex with a primitive in the current primitive block, the distance may be compared to a different set of one or more distance thresholds or different criteria may be used to determine whether the current primitive should be added to the current primitive block. For example, if the current primitive shares at least one vertex with a primitive in the current primitive block, the current primitive may be added to the current primitive block if the area of ​​the bounding box of the current primitive block with the current primitive is less than a threshold (eg, less than a predetermined number of tiles).

[0119] In some cases, it may be advantageous for all primitives in a primitive block to share the same rendering state data (e.g., the same depth comparison mode and primitive type). In these cases, the primitive block generator may determine whether the rendering state data for the current primitive is the same as (or matches) the rendering state data for the primitives in the current primitive block before executing block 704. If the primitive block generator determines that the rendering state data for the current primitive is different from the rendering state data for the primitives in the current primitive block, the current primitive block may be cleared before the method 700 proceeds to block 704. However, if the primitive block generator determines that the rendering state data for the current primitive is the same as (or matches) the rendering state data for the primitives in the current primitive block, the method 700 may proceed directly to block 704.

[0120] although Figure 7 The method 700 of describes how to generate a primitive block by determining whether to add a received primitive to a single pending primitive block based on the distance between the received primitive and the primitive block and the fullness of the primitive block, but in other examples, the primitive block generator may maintain multiple pending primitive blocks and may determine whether to add the received primitive to one of the pending primitive blocks based on the distance between the received primitive and each of the pending primitive blocks and the fullness of the pending primitive blocks. For example, the received primitive may be added to one of the pending primitive blocks by comparing the distance for each pending primitive block with a set of one or more distance thresholds for the pending primitive block, wherein the set of one or more distance thresholds is based on the fullness of the pending primitive block. If the comparison of the distance with the distance threshold indicates that the received primitive can be added to one of the pending primitive blocks, then the received primitive may be added to the pending primitive block. However, if the comparison of the distance to the distance threshold indicates that the received primitive may be added to multiple pending primitive blocks, then the received primitive block may be added to one of those pending primitive blocks or the related pending primitive blocks may be merged.

[0121] Despite Figure 7 In the method 700 of FIG. 7 , the current primitive may only form part of a single primitive block (e.g., the primitive is added to the current primitive block as is, or the current primitive block is cleared and then the primitive is added to the current primitive block), but in other example methods, the current primitive may be added to multiple primitive blocks. For example, if the distance for the current primitive meets a distance threshold to be added to the current primitive block, but the distance is close to the threshold, then the current primitive may be added to the current primitive block, then the current primitive block may be cleared and the same primitive may be added to the (new) current primitive block after clearing.

[0122] Reference now Fig.10 , which illustrates an example implementation of a primitive block generator 1000 that can be used to implement Figure 7Method 700. Fig.10 The primitive block generator 1000 includes: a data storage area 1002, which is used to store a current primitive block 1004 to which a new primitive can be added; and a block allocation logic 1006, which is used to determine whether a new primitive should be added to the current primitive block based on the distance between the primitive and the current primitive block and the fullness of the current primitive block.

[0123] The block allocation logic 1006 may include distance calculation logic 1008, fullness determination logic 1010, distance threshold selection logic 1012, and comparison logic 1014. The distance calculation logic 1008 is configured to receive transformed position data for the current primitive and determine the distance between the spatial position of the current primitive and the spatial position of the current primitive block 1004 based on the transformed position data. The transformed position data describes the position of the primitive in a rendering space (e.g., screen space). As described above, where each primitive is defined by one or more vertices, the transformed position data may include information indicating the positions (e.g., X, Y, and Z coordinates) of the vertices that form the primitive. The transformed position data for the primitive may have been Figure 3 The transformation logic 308 of the system 300 is generated.

[0124] The distance is a measure or set of measures that describes how 'close' the current primitive (i.e., the primitives that form the primitive block) is to the current primitive block. The distance calculation logic 1008 may be configured to determine the distance between the current primitive and the current primitive block in any suitable manner based on the transformed position data. Specifically, the distance calculation logic 1008 may be configured to calculate the distance between the current primitive and the current primitive block based on the transformed position data. Figure 7 The distance may be determined by any of the methods described in block 706 of method 700 of FIG. 1008 . For example, the distance calculation logic 1008 may be configured to determine the distance (i) by comparing the bounding box of the current primitive block without the current primitive to the bounding box of the current primitive block with the current primitive; and / or (ii) according to the tile rendering order. For example, in some cases, the distance calculation logic 1008 may be configured to determine the distance as: the difference or ratio between the x-dimensions of the bounding boxes; the difference or ratio of the y-dimensions of the bounding boxes; the difference or ratio of the areas of the bounding boxes; or any combination thereof. The distance may include a single metric (e.g., a ratio of the x-dimensions of the bounding boxes) or multiple metrics (e.g., a triplet (a, b, c), where a is the ratio of the x-dimensions of the bounding boxes; b is the ratio of the y-dimensions of the bounding boxes; and c is the ratio of the areas of the bounding boxes).

[0125] The fullness determination logic 1010 is configured to generate a fullness metric for the current primitive block 1004, which indicates the fullness of the current primitive block. The fullness of the current primitive block 1004 can be determined in any suitable manner. For example, as described above, in some cases, the primitive block may have a maximum number of primitives and / or a maximum number of vertices. In these cases, the fullness determination logic 1010 can be configured to determine the fullness metric based on comparing the number of primitives in the current primitive block and / or the number of vertices in the current primitive block with the maximum number of primitives and vertices, respectively. For example, the fullness metric may be equal to: the ratio of the number of primitives in the current primitive block to the maximum number of primitives; the ratio of the number of vertices in the current primitive block to the maximum number of vertices; the larger of the two ratios; or a combination of the two ratios.

[0126] The distance threshold selection logic 1012 is configured to dynamically select a set of one or more distance thresholds based on the fullness metric (generated by the fullness determination logic 1010) that will be used to determine whether the current primitive will be added to the current primitive block. As described above, the inventors have recognized that a good balance between having full primitive blocks and having primitive blocks that include primitives that are close together can be achieved by adjusting the distance thresholds used to determine whether new primitives will be added to the current primitive block based on the fullness of the current primitive block. Specifically, the distance thresholds are dynamically adjusted so that when the fullness of the current primitive block is low, primitives that are farther away from primitives in the current primitive block can be added to the current primitive block, and when the fullness of the current primitive block is high, only primitives that are close to primitives in the current primitive block can be added to the current primitive block.

[0127] The set of distance thresholds for a particular full-scale metric may be determined in any suitable manner. Figure 7The method 700 of FIG. 100 can be used to determine a set of distance thresholds for a particular fullness metric using any of the methods described in block 708 of the method 700. As described above, in some cases, the set of distance thresholds for a particular fullness metric can be dynamically determined according to a formula. For example, the set of distance thresholds can be inversely proportional to the fullness of the current primitive block. In other cases, there can be a predetermined set of one or more distance thresholds associated with each of a plurality of ranges of fullness metric. The distance threshold selection logic 1012 can then be configured to select a set of one or more distance thresholds from a predetermined set of one or more distance thresholds based on the fullness metric. For example, there can be a set of one or more distance thresholds used when the fullness metric indicates that the current primitive block is less than one-quarter full, a second set of one or more distance thresholds used when the fullness metric indicates that the current primitive block is at least one-quarter full but less than one-half full, a third set of one or more distance thresholds used when the fullness metric indicates that the current primitive block is at least one-half full but less than three-quarters full, and a fourth set of one or more distance thresholds used when the fullness metric indicates that the current primitive block is at least three-quarters full. Where there is a predetermined set of one or more distance thresholds, the predetermined set of one or more distance thresholds may be stored in a lookup table 1016 or similar structure.

[0128] The number of distance thresholds in a set may be based on the number of metrics used for distance and / or one or more other criteria. For example, where the distance comprises a single metric (e.g., the distance is equal to the ratio of the area of ​​the bounding box), the set of distance thresholds may include a single distance threshold that is compared to the single distance metric. Where the distance comprises multiple metrics (e.g., the distance comprises a triplet (a, b, c), where a is the ratio of the x-dimensions of the bounding box, b is the ratio of the y-dimensions of the bounding box, and c is the ratio of the area of ​​the bounding box), the set of distance thresholds may include one or more distance thresholds. For example, there may be a single distance threshold that is compared to a combination of distance metrics, or there may be a distance threshold for each distance metric that is compared to the corresponding distance metric.

[0129] The comparison logic 1014 is configured to: determine whether the current primitive is to be added to the primitive block based on a comparison between the distance (such as calculated by the distance calculation logic 1008) and the distance threshold (such as generated by the distance threshold selection logic 1012); and output one or more control signals to control the current primitive block based on the determination. Specifically, if the comparison logic 1014 determines that the current primitive is to be added to the current primitive block based on the comparison, then the comparison logic 1014 may output one or more control signals that cause the current primitive to be added to the current primitive block. In some cases, causing the current primitive to be added to the primitive block may include causing information to identify an untransformed primitive, the current primitive being associated with the current primitive block. In other cases, causing the current primitive to be added to the primitive block may include causing transformed geometry data associated with the current primitive to be added to the current primitive block. In contrast, if the comparison logic 1014 determines, based on the comparison, that the current primitive is not to be added to the current primitive block, then the comparison logic 1014 may output one or more control signals that cause the current primitive block to be cleared (e.g., the contents are output (e.g., written out to memory) and then cleared) and then cause the current primitive to be added to the empty current primitive block.

[0130] Transformed geometry data cache

[0131] As described above, once the transformation logic 313 has transformed the untransformed geometry data for a primitive block, the transformed geometry data for the primitive block (which may be referred to herein as a transformed primitive block) is stored in a cache 315 (which may be referred to herein as a transformed geometry data cache), where the transformed geometry data may be accessed by subsequent modules of the rasterization stage (e.g., the HSR logic 314 and the texturing / shading logic 316). Since the transformed geometry cache 315 is typically not large enough to store every transformed primitive block needed to render an image, it is desirable to have a mechanism for determining which transformed primitive blocks to evict from the cache 315 when the transformed geometry cache 315 becomes full. In other words, it is desirable to have a mechanism for knowing when it is safe to evict a transformed primitive block from the cache 315.

[0132] In e.g. Figure 3In some graphics processing systems of the graphics processing system 300 of FIG. 1 , processing of transformed geometry data for tiles in the rasterization stage is performed in multiple stages. For example, hidden surface removal may be performed in a first stage, and texturing and shading may be performed in a second stage. As described in more detail below, in some cases, the hidden surface removal stage may be further divided into multiple sub-stages. The hidden surface removal stage and the texturing and shading stage typically both access the transformed geometry data associated with the tile being processed. Therefore, it is not possible to safely remove the transformed primitive blocks associated with the tile until both stages have access to the transformed primitive blocks. However, not all primitives associated with a particular tile may be targeted in all stages. For example, although hidden surface removal may be performed on all primitives associated with the tile, not all of those primitives may be targeted from the hidden surface removal stage to the texturing and shading stage (e.g., some primitives may be hidden). Thus, there may be some transformed primitive blocks associated with a tile that may be evicted after the hidden surface removal stage (or a sub-stage of the hidden surface removal stage as described below) because all of their related primitives are hidden, while other transformed primitive blocks associated with the tile may not be evicted until the texturing and shading stages are completed.

[0133] Furthermore, in some graphics processing systems, it may be possible to process transformed geometry data for multiple tiles simultaneously because multiple stages of transformed geometry data processing may be pipelined (e.g., at any time, transformed geometry data associated with one tile may be processed at each of the stages) and / or there may be multiple parallel logics (e.g., pipelines) for processing the transformed geometry data.

[0134] Therefore, the inventors have determined that an efficient mechanism for recording which transformed primitive blocks can be evicted is recording (via a counter) the number of tiles currently being processed in the rasterization stage that require the transformed primitive block, where the tile can be considered to no longer require the transformed primitive block after any of the multiple stages of transformed geometry data processing. In other words, if the transformed primitive block is no longer needed after, for example, the first stage of transformed geometry data processing, then the transformed primitive block can be considered available for eviction, even if the tiles associated with the transformed primitive block are still being processed. This mechanism ensures that the transformed primitive block will not be evicted when it is known that the transformed primitive block will be used again, but once the transformed primitive block is no longer needed, it is made available for eviction. Making the transformed primitive block available for eviction does not mean that another tile will not need the transformed primitive block later, but that any of the tiles currently being processed in the rasterization stage do not need the transformed primitive block and it can therefore be safely evicted. If a subsequent tile needs to access a transformed primitive block that was evicted, the untransformed geometry data for that primitive block will have to be fetched and transformed again.

[0135] Reference now Fig.11 , which illustrates an example transformed geometry data cache 1100 that can be used to implement Figure 3 The system 300 of the present invention is a transformed geometry data cache 315. The transformed geometry cache 1100 includes: a memory 1102 (e.g., a buffer) for temporarily storing transformed geometry data (e.g., transformed primitive blocks); a lookup table 1104 for storing, for each primitive block, information indicating the location of the transformed geometry data associated with the primitive block and a counter indicating whether the transformed geometry data can be safely retrieved; and control logic 1106 for storing the transformed primitive blocks in the memory 1102 and maintaining the counter so that it reflects the number of tiles that need to access the transformed primitive blocks that are currently being processed by the rasterization logic.

[0136] The memory 1102 is configured to temporarily store transformed geometry data for processing in the rasterization stage. Figure 3 In the graphics processing system of the graphics processing system 300 , untransformed geometry data is extracted and transformed based on the primitive block, so that the transformed geometry data related to the primitive block can be stored together as a transformed primitive block. Fig.12An example format for a transformed primitive block 1200 is shown in FIG. In this example, the transformed primitive block 1200 includes a header 1204, state data 1206, transformed vertex data 1207, and primitive index data 1208. Similar to Figure 4 The header 404 of the untransformed primitive block 4021, 4022 includes information describing the primitive block, such as but not limited to the number of vertices in the primitive block and / or the number of primitives in the primitive block. Figure 4 The state data 406 for the untransformed primitive blocks 4021, 4022 includes information describing how the primitives in the primitive blocks are to be rendered. The state data may be described as identifying a recipe for rendering the primitives described in the primitive blocks. For example, the state data may include, but is not limited to, information identifying a depth comparison mode, a blending state, a texture state, and / or a primitive type.

[0137] The transformed vertex data 1207 includes transformed geometry data for each vertex associated with a primitive in the primitive block. The transformed geometry data for each vertex may include, for example, a set of coordinates (e.g., X, Y, Z coordinates) in a rendering space (e.g., screen space) to describe the position of the vertex and a set of attributes to describe the appearance of the vertex, such as texture coordinates (e.g., U, V coordinates) and / or a base color applied to the vertex. Each vertex in the primitive block may be identified by a vertex index, which is local to the primitive block. For example, where the maximum number of vertices per primitive block is 64, each vertex may be assigned a local index between 0 and 63.

[0138] Similar to Figure 4 The primitive index data 1208 of the untransformed primitive blocks 4021, 4022 includes a set of indices for each primitive identifying the vertices forming the primitive. For example, in the case where the primitive is a triangle formed by three vertices, the primitive index data 1208 may include information for each primitive identifying the three vertices forming the primitive. However, although Figure 4 The index in the primitive index data 408 is the index of the vertex sent from the application, but Fig.12 The indices in the primitive index data 1208 of are local indices. In this way, each vertex index acts as a pointer to the portion of the transformed geometry in the transformed primitive block associated with that vertex.

[0139] As described above, each primitive block may be referred to by (or associated with) multiple tiles. In other words, the primitives of a primitive block may fall at least partially within multiple tiles. In some cases, the tiling engine 310 may be configured to record the number of tiles that refer to (or are associated with) each primitive block, and this information may be provided to the extraction logic 312 when the primitive block is extracted from the memory 3022. For example, the number of tiles that refer to (or are associated with) a particular primitive block may be stored in, for example, a header portion of the primitive block, or the number of tiles that refer to (or are associated with) a particular primitive block may be provided to the extraction logic 312 as sideband data. In these cases, the memory 1102 (e.g., a buffer) may be divided into multiple sub-memory blocks and the control logic 1106 may be configured to determine which sub-memory blocks will store the new transformed primitive block based on the number of tiles that refer to (or are associated with) the primitive block.

[0140] For example, Fig.13 An example of a partition of the memory 1102 into three sub-blocks 1302, 1304, and 1306 of memory is illustrated. In this example, the first sub-block 1302 is used to store transformed primitive blocks associated with only 1 tile; the second sub-block 1304 is used to store transformed primitive blocks associated with 2 to 4 tiles; and the third sub-block 1306 is used to store transformed primitive blocks associated with more than 4 tiles. It will be apparent to those skilled in the art that this is merely an example and that there may be a different number of sub-blocks of memory and / or they may be associated with different ranges of tiles. Since the transformed primitive blocks associated with a smaller number of tiles are likely to be available for eviction soon, a larger block of 'idle' memory may be obtained more quickly than if the transformed primitive blocks associated with a small number of tiles (e.g., 1 tile) were not stored together. This may be advantageous in situations where the memory 1102 is partitioned into pages and only entire pages may be freed or deallocated at a time. The sub-memory blocks may all be the same size or two or more of the sub-memory blocks may have different sizes.

[0141] The lookup table 1104 is configured to store, for each transformed primitive block stored in the memory 1102, information identifying the location of the transformed primitive block in the memory 1102 (e.g., a buffer) and a counter indicating whether the transformed primitive block can be evicted from the memory 1102 (e.g., a buffer). Fig.11As shown in , in some cases, the information identifying the location of the transformed primitive block can be the address of the transformed primitive block in the memory. However, it will be apparent to those skilled in the art that this is merely an example and other information can be stored in the lookup table 1104 to identify the location of the transformed primitive block in the memory. For example, in other cases, the information identifying the location of the transformed primitive block in the memory can be an index that can be used to generate the address of the transformed primitive block in the memory. When the transformed primitive block is written to the memory (e.g., by the transformation logic 313), the entry in the lookup table can be added to the lookup table.

[0142] In some cases, when the memory 1102 does not include a transformed primitive block, the lookup table may not have an entry for the transformed primitive block. For example, when a transformed primitive block is evicted from the memory 1102 (e.g., a buffer), the corresponding entry in the lookup table 1104 may be removed. This allows the cache 1100 to determine whether it includes a particular transformed primitive block based on the lookup table.

[0143] The counter for the untransformed primitive block is used to indicate whether the transformed primitive block can be evicted from the cache (i.e., from the memory 1102). In some cases, the counter for the transformed primitive block can be set to a first predetermined value (e.g., 0) when the transformed primitive block can be evicted (i.e., when none of the tiles currently being processed in the rasterization stage need to access the transformed primitive block), and can be set to one of one or more second predetermined values ​​(e.g., an integer > 0) when the transformed primitive block cannot be evicted (i.e., when at least one of the tiles currently being processed in the rasterization stage needs to access the transformed primitive block).

[0144] The control logic 1106 is configured to store the transformed primitive blocks (e.g., received from the transformation logic 313) in the memory 1102 and maintain a counter in the lookup table 1104 to indicate which transformed primitive blocks can be reclaimed from the memory 1102 and which cannot be reclaimed therefrom. Specifically, the control logic 1106 is configured to maintain a counter in the lookup table 1104 (e.g., dynamically adjust the counter) so that it indicates how many tiles currently being processed by the rasterization logic 306 need to access the corresponding transformed primitive block. When the counter indicates that none of the tiles currently being processed by the rasterization logic 306 need to access a particular transformed primitive block, the transformed primitive block can be reclaimed. In these examples, when any of the stages of the transformed geometry data processing (e.g., after the HSR stage or after the texturing / shading stage) indicates that the transformed geometry block is no longer needed, the tile currently being processed by the rasterization logic can be considered to no longer need to access the primitive. When the control logic 1106 receives a new transformed primitive block (e.g., from the transformation logic 313) for storage in the cache 1100 and the cache 1100 is full (e.g., the memory 1102 is full), the control logic 1106 selects to evict one of the transformed primitive blocks based on the counter. Fig.14 Method 1400 describes the operation of control logic 1106 in more detail.

[0145] Reference now Fig.14 , which illustrates a method 1400 that may be performed by the control logic 1106 to manage the cache 1100. The method 1400 begins at block 1402, where the control logic 1106 stores a plurality of transformed primitive blocks in a memory 1102 (e.g., a buffer) of the cache 1100. As each of the transformed primitive blocks is stored in the memory, the lookup table 1104 may have been updated to include information (e.g., an address) indicating the location of the transformed primitive block in the memory 1102 (e.g., a buffer).

[0146] At block 1404, the control logic 1106 maintains (e.g., dynamically updates) a counter (e.g., a counter in the lookup table 1104) for each of the transformed primitive blocks stored in the cache 1100 (e.g., the memory 1102 (e.g., the buffer)) to indicate the number of tiles that are currently being processed by the rasterization logic 306 and that require the transformed primitive block. The control logic 1106 may be configured to adjust (e.g., increment) the counter for the transformed primitive block to indicate that additional tiles are being processed by the rasterization logic that require access to the transformed primitive block when the control logic 1106 detects that the rasterization logic has begun processing a new tile associated with the primitive block. The control logic 1106 may also be configured to adjust (e.g., decrement) a counter for a transformed primitive block when the control logic 1106 detects from any of the plurality of stages that the tiles associated with the transformed primitive block no longer require the transformed primitive block to indicate that one less tile is being processed by the rasterization logic that requires access to the transformed primitive block. As described above, by adjusting the counter after any of the stages of the rasterization phase, the transformed primitive block may be marked for eviction earlier. Specifically, for the transformed primitive block to be marked for eviction, the processing of rasterization of the tiles associated with the transformed primitive block does not have to be comprehensive. This allows for more efficient use of the cache 1100 memory 1102.

[0147] A transformed primitive block is considered to be associated with a tile if at least one primitive in the transformed primitive block at least partially falls within the bounds of the tile. Figure 3 As described, the tiling module determines which primitives (when transformed) fall at least partially within the bounds of the tile and generates a display list for each tile, the display list identifying the primitives that fall at least partially within the bounds of the tile and the primitive blocks in which the primitives are located. When the rasterization stage begins processing a tile, the extraction module extracts the display list for the tile. The extraction module then determines, for each untransformed primitive block identified in the untransformed display list, whether the cache 1100 includes transformed geometry data (e.g., a transformed primitive block) for the untransformed primitive block (e.g., by sending a query to the control logic 1106). Then, if the cache 1100 does not include transformed geometry data (e.g., a transformed primitive block) for the untransformed primitive block, the extraction module obtains the untransformed geometry data corresponding to the untransformed primitive block and provides the untransformed geometry data to the transformation logic 313 for transformation. The transformed geometry data for the untransformed primitive block is then stored in the cache.

[0148] Thus, in some cases, the control logic may be configured to detect that the rasterization logic 306 has started processing new tiles associated with a particular transformed primitive block (i) when the control logic (e.g., from the transformation logic 313) receives a request to add the transformed primitive block to the cache 1100; or (ii) when the control logic (e.g., from the fetch logic) receives a request to know whether the cache 1100 includes the transformed primitive block and whether the transformed primitive block is already in the cache 1100. It will be apparent to those skilled in the art that this is merely an example and that the control logic 1106 may detect that the rasterization logic 306 has started processing new tiles associated with a particular transformed primitive block in another manner.

[0149] As described above, the control logic 1106 may be configured to adjust (e.g., decrement) a counter for a transformed primitive block when any of the multiple stages indicates that the tile associated with the transformed primitive block no longer requires the transformed primitive block to indicate that there is one less tile being processed by the rasterization logic that requires access to the transformed primitive block. For example, where the rasterization stage includes two transformed geometry data processing stages—a hidden surface removal stage and a texturing / shading stage—the control logic 1106 may be configured to adjust (e.g., decrement) a counter for a transformed primitive block when any stage (e.g., the HSR stage or the texturing / shading stage) indicates that the tile no longer requires the transformed primitive block to indicate that there is one less tile being processed by the rasterization logic that requires access to the transformed primitive block.

[0150] As described above, the hidden surface removal stage is configured to remove hidden primitive fragments. The HSR stage (e.g., the output of the HSR logic 314) may indicate that a tile no longer needs to access a transformed primitive block when the HSR stage does not output any fragments associated with a primitive in the transformed primitive block. In some cases, the HSR stage may be configured to receive an indication of which transformed primitive blocks are associated with it when it receives a set of primitive fragments. If the HSR stage determines that primitive fragments from a transformed primitive block are received but none are output, then the HSR stage may notify the control logic 1106. For example, the HSR stage may receive primitive fragments to process as a data stream, and there may be markers inserted in the data stream to separate primitives and separate primitive blocks. The HSR stage may be configured to determine that a primitive block is no longer needed when it outputs two primitive block markers without outputting any primitive fragments in between.

[0151] In some cases, the HSR stage may include two sub-stages—a first sub-stage in which depth testing is performed on primitive fragments in a tile and a second sub-stage in which primitive fragments that have undergone depth testing are stored in a tag buffer. Fig.15 Illustrate example HSR logic 1502 (which may be used to implement Figure 3 1504 and a tag buffer 1506. The depth test logic 1504 receives a primitive fragment and compares a depth value (e.g., a Z value or Z coordinate) of the primitive fragment to a corresponding depth value in a depth buffer for a tile. Specifically, the depth buffer stores a 'best' depth value for each sample of the tile (e.g., a depth value that is closest to the screen). If the received primitive fragment has a depth value that is 'worse' than the corresponding depth value in the depth buffer (e.g., a depth value indicating that it is farther from the screen), then the primitive fragment will be hidden by another primitive and therefore the primitive fragment 'fails' the depth test and is not output to the tag buffer. However, if the received primitive fragment has a depth value that is 'better' than the corresponding depth value in the depth buffer (i.e., a depth value indicating that it is closer to the screen), then the primitive fragment 'passes' the depth test. The primitive fragment is then output to the tag buffer 1506, and the corresponding depth value in the depth buffer is updated to indicate that there is a new 'best' depth value.

[0152] The tag buffer 1506 receives primitive fragments that have passed the depth test stage, and for each primitive fragment received, updates the tag buffer 1506 to identify that the received primitive fragment is a primitive fragment that is visible at its sample position. For example, if the tag buffer 1506 receives primitive fragment x at sample position a, then the tag buffer 1506 stores information indicating that primitive fragment x is visible at sample position a. If the tag buffer 1506 subsequently receives primitive fragment y at sample position a, then the tag buffer updates the information for sample position a to indicate that it is actually primitive fragment y that is visible. Thus, in the simple case where all primitives are opaque, after the depth test logic 1504 has processed all primitives in the tile, the tag buffer 1506 includes an identification of the primitive fragments that are visible at each sample position. At this point, the tag buffer 1506 is flushed to the texturing / shading logic 1508, where texturing and shading are performed on the visible primitive fragments. By performing texturing and shading after hidden surface removal, time and resources are not wasted on texturing and shading primitives / primitive fragments that are not visible in the final image.

[0153] Thus, it is possible for a primitive (a primitive fragment) to fail at either the depth test sub-stage or the tag buffer sub-stage. Specifically, a primitive may fail the depth test and therefore not be output by the depth test logic 1504, or it may pass the depth test because it had the 'best' depth when the depth test was performed, but on a primitive fragment at the same sample location, a better depth may occur and therefore the primitive is overwritten in the tag buffer 1506 and therefore it is never output from the tag buffer 1506. In these cases, in addition to updating the counters for transformed primitive blocks in the cache based on the output of the HSR stage, the efficiency of the transformed geometry cache 1100 may be further improved by updating the counters for transformed primitive blocks based on the output of the tag buffer stage. This will allow transformed primitive blocks that fail the depth test or tag buffer stage and therefore are not further needed by the HSR logic 1502 or texturing / shading logic 1508 to become eligible for earlier eviction.

[0154] In these cases, the depth test logic 1504 may be configured to notify the control logic 1106 when it detects that a primitive block has failed the depth test stage. If none of the primitives of the primitive block that falls within the tile being processed pass the depth test, then the primitive block is considered to have failed the depth test. In other words, if the depth test indicates that none of the primitives of the primitive block that falls within the tile being processed are visible, then the primitive block will not pass the depth test. In response to receiving an indication from the depth test logic 1504 that the primitive block has failed the depth test, the control logic 1106 may update a counter associated with the primitive block (e.g., decrement it) to indicate that one less tile is currently being processed by the rasterization logic, and the one less tile needs to access the corresponding transformed primitive block.

[0155] Similarly, the tag buffer 1506 may be configured to notify the control logic 1106 when it detects that a primitive block has failed the tag buffer stage. A primitive block is considered to have failed the tag buffer stage if the tag buffer 1506 receives at least one primitive fragment for a primitive in the primitive block but none of the primitive fragments for the primitive block are output from the tag buffer 1506 to the next module (e.g., texturing / shading logic 1508). In order to be able to determine when a primitive block has failed the tag buffer stage, it is necessary for the tag buffer 1506 to have a mechanism for tracking which primitive fragments have been received since the entry in the tag buffer itself may be overwritten. Therefore, in some cases, the tag buffer 1506 may have a lookup table or similar structure with an entry for each primitive block indicating whether the primitive block has received a primitive fragment for that primitive block from the depth test logic 1504. Then when the tag buffer 1506 is emptied (e.g., its contents are sent to the next stage—e.g., texturing / shading logic 1508), the contents of the tag buffer 1506 are compared to the lookup table, and if there are any primitive blocks whose primitive fragments are received but whose associated primitive fragments are not output, then the tag buffer 1506 notifies the control logic 1106 that those primitive blocks are ineligible at the tag buffer stage and are therefore no longer needed. The notification may take any suitable form. For example, the notification may take the form of a control signal.

[0156] As described above, the texturing / shading stage is configured to perform texturing and / or shading on the primitive fragments received from the HSR stage to determine the pixel values ​​of the rendered image. The rendered pixel values ​​for the tile are then stored in a memory (e.g., a frame buffer). Therefore, the control logic 1106 may be configured to determine that the tile associated with the primitive block no longer needs to access the corresponding transformed primitive block when the texturing / shading stage (e.g., the texturing / shading logic 1508) indicates that it has completed processing the primitives of the primitive block. For example, when the texturing / shading logic has completed processing the primitive fragments of the primitive block, the texturing / shading logic may notify the control logic 1106. In response to receiving this notification, the control logic 1106 may update the counter for the primitive block (e.g., decrement it) to indicate that there is one less tile currently being processed by the rasterization logic, and the one less tile needs to access the transformed primitive block. In other cases, the control logic 1106 may be configured to determine that the tiles associated with a primitive block no longer need to access the corresponding transformed primitive block once the texturing / shading stage has accessed the transformed primitive block (and extracted all associated transformed geometry data.) In this way, the transformed primitive block may be eligible for eviction from the cache 1100 earlier, which may improve the efficiency of the cache 1100.

[0157] In the case where there may be multiple tiles 'in-flight' (i.e., being processed by the rasterization logic) in the rasterization logic 306 at any point in time, it is possible for the counter to be updated (e.g., incremented) multiple times to indicate that there are additional 'in-flight' tiles that need to access the corresponding transformed primitive block before the counter for the primitive block is updated (e.g., decremented) to indicate that there are one less tile 'in-flight' that needs to access the corresponding transformed primitive block. For example, the rasterization logic 306 may begin processing a first tile associated with a particular primitive block, causing the control logic to increment the counter to 1 for the primitive block, and the rasterization logic 306 may begin processing a second tile also associated with the particular primitive block, causing the control logic to increment the counter to 2 for the primitive block, before the control logic 1106 has determined that the first tile no longer needs to access the transformed primitive block. Thus, when the control logic detects that the first tile no longer needs access to the transformed primitive block (e.g., because it failed the depth test stage, it failed the tag buffer stage, or its texturing / shading is complete), the transformed primitive block does not become eligible for eviction because there is still one tile in progress that needs access to the transformed primitive block. Thus, updating the counter (e.g., decrementing it) to indicate that there is one less tile currently being processed by the rasterization logic 306 that needs access to the transformed primitive block may not automatically make the transformed primitive block eligible for eviction.

[0158] Return to Fig.14 In the method 1400 of FIG. 1406 , at block 1406 , the control logic 1106 receives a new transformed primitive block (e.g., from the transformation logic 313) for storage in the cache. At block 1408 , it is determined whether the cache 1100 is full. If there is enough free memory in the cache to store the new transformed primitive block, then it can be determined that the cache is full. If it is determined that the cache is full, then the method 1400 proceeds to block 1410. However, if it is determined that the cache is not full, then the method 1400 proceeds directly to block 1414.

[0159] At block 1410, one of the transformed primitive blocks stored in the cache 1100 (e.g., memory 1102) is selected for eviction based on a counter associated with the transformed primitive block. As described above, the counter indicates the number of tiles currently being processed (e.g., 'in-flight') by the rasterization logic 306 that require access to the transformed primitive block. Generally, it is not safe to eviction a transformed primitive block from the cache 1100 unless there are no tiles currently being processed by the rasterization logic that require access to the transformed primitive block. Therefore, in some cases, one of the transformed primitive blocks associated with a counter is selected for eviction, the counter indicating that there are no tiles currently being processed by the rasterization logic that require access to the transformed primitive block. As described above, in some cases, the counter will have a value of zero when there are no tiles currently being processed by the rasterization logic that require access to the corresponding transformed primitive block. In these cases, one of the transformed primitive blocks in the cache having a counter having a value of zero may be selected for eviction.

[0160] When there is more than one transformed primitive block with a counter (e.g., a counter with a value of zero) indicating that there are no tiles currently being processed that require access to the transformed primitive block, one of those transformed primitive blocks may be selected for eviction in any suitable manner. For example, one of those transformed primitive blocks may be randomly selected for eviction.

[0161] As described above, each primitive block may be referred to by (or associated with) multiple tiles. In other words, the primitives of a primitive block may fall at least partially within multiple tiles. In some cases, the tiling engine 310 may be configured to record the number of tiles that refer to (or are associated with) each primitive block, and this information may be provided to the extraction logic 312 when the primitive block is extracted from the memory 3022. For example, the number of tiles that refer to (or are associated with) a particular primitive block may be stored in, for example, a header portion of the primitive block, or the number of tiles that refer to (or are associated with) a particular primitive block may be provided to the extraction logic 312 as sideband data. In these cases, the control logic 1106 may be configured to maintain an auxiliary counter (e.g., in the LUT 1104) for each primitive block that indicates the number of tiles that still need to access the primitive block. Auxiliary counters for a primitive block may be initially set to refer to the number of tiles of the primitive block (or associated therewith) received from the tiling engine, and the control logic 1106 may be configured to update the counters (e.g., decrement them) while the primary counters are also updated (e.g., decremented) to indicate that there is one less tile currently being processed by the rasterization logic that requires access to the transformed primitive block. The control logic 1106 may then use these auxiliary counters to select which transformed primitive blocks to evict that have counters indicating that there are no tiles currently being processed by the rasterization logic that require access to the transformed primitive block. For example, the control logic may select the transformed primitive block (or one of the) with the smallest auxiliary counter.

[0162] If there is no associated counter for it indicating that there is no transformed primitive block that is currently being processed by the rasterization logic and that requires access to the tiles of the transformed primitive block, then the control logic 1106 may wait until one of the counters is adjusted to indicate that there is no tile that is currently being processed by the rasterization logic and that requires access to the corresponding transformed primitive block (e.g., until the counter is set to zero). Alternatively, in the case of having a tag buffer, where the clearing of the tag buffer causes the tag buffer to notify the control logic 1106 that the primitive block failed at the tag buffer stage, the control logic 1106 may be configured to cause the clearing of the tag buffer. In some cases, the control logic 1106 may initiate the clearing of the entire rasterization pipeline or multiple rasterization pipelines by sending a flag down the rasterization pipeline. The flag will eventually reach the tag buffer and trigger a tag buffer refresh. However, when the flag reaches the tag buffer, it may have already been cleared, so before performing a refresh, the tag buffer may first check whether the cache 1100 is still full. If the cache is still not full, the tag buffer may not be cleared. However, if the cache is still full, the tag buffer may be flushed. While this may cause the tag buffer to be flushed before HSR processing for the entire tile is complete, this will generally not cause problems for downstream components, as downstream components (e.g. texturing / shading logic) will be able to know which primitives are visible. This may simply cause downstream components to perform operations (e.g. texturing and shading) on ​​primitives that are not visible and would have been culled at the tag buffer stage if the tag buffer had not been flushed previously.

[0163] At block 1412, the transformed primitive block selected in block 1410 is evicted from the cache 1100 (e.g., from the memory 1102) to make room for the new transformed primitive block. Once the selected transformed primitive block is evicted from the cache (e.g., from the memory 1102), the method 1400 may proceed to block 1414, where the new transformed primitive block is stored in the cache 1100 (e.g., in the memory 1102).

[0164] Fig.16 A computer system is shown in which the graphics processing system, primitive block generator, and / or cache described herein may be implemented. The computer system includes a CPU 1602, a GPU 1604, a memory 1606, and other devices 1614, such as a display 1616, a speaker 1618, and a camera 1620. Block 1610 (corresponding to the graphics processing system 300, the primitive block generator 1000, or the cache 1100) is implemented on the GPU 1604. In other examples, block 1610 may be implemented on the CPU 1602. The components of the computer system may communicate with each other via a communication bus 1622.

[0165] Figure 1 , 2 , 3, 10 and 11, the graphics processing systems 100, 200, 300, primitive block generators 1000 and caches 1100 are shown as including a plurality of functional blocks. This is merely illustrative and is not intended to define a strict division between different logical elements of such entities. Each functional block may be provided in any suitable manner. It should be understood that intermediate values ​​described herein as being formed by a graphics processing system, primitive block generator or cache need not be physically generated by the graphics processing system, primitive block generator or cache at any point, and may simply represent logical values ​​that conveniently describe the processing performed by the graphics processing system, primitive block generator or cache between its input and output.

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

[0167] As used herein, the terms computer program code and computer readable instructions refer to any kind of executable code for a processor, including code expressed in machine language, interpreted language, or scripting language. Executable code includes binary code, machine code, byte code, code defining an integrated circuit (e.g., hardware description language or netlist), and code expressed in programming language code 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 in a virtual machine or other software environment, causes a processor of a computer system supporting the executable code to perform the tasks specified by the code.

[0168] A processor, computer or computer system may be any kind of device, machine or special purpose circuit, or a collection or part thereof, having processing capabilities that enable it to execute instructions. A processor may be any kind of general 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.

[0169] The present invention is also intended to include software that defines a hardware configuration as described herein, such as hardware description language (HDL) software, for designing an integrated circuit or for configuring a programmable chip to perform a desired function. That is, a computer-readable storage medium may be provided having encoded thereon a computer-readable program code in the form of an integrated circuit definition data set that, when processed (i.e., run) in an integrated circuit manufacturing system, configures the system to manufacture a graphics processing system configured to perform any of the methods described herein, or to manufacture a computing device that includes any of the apparatus described herein. The integrated circuit definition data set may be, for example, an integrated circuit description.

[0170] Thus, a method of manufacturing a graphics processing system, a primitive block generator, or a cache as described herein at an integrated circuit manufacturing system may be provided. In addition, an integrated circuit definition data set may be provided, which, when processed in an integrated circuit manufacturing system, enables the method of manufacturing a graphics processing system, a primitive block generator, or a cache as described herein to be performed.

[0171] The integrated circuit definition data set may be in the form of computer code, for example, as a netlist, code for configuring a programmable chip, as a hardware description language that defines hardware suitable for fabrication at any level in an integrated circuit, including as register transfer level (RTL) code, as a high-level circuit representation, such as Verilog or VHDL, and as a low-level circuit representation, such as OASIS (RTM) and GDSII. A higher-level representation (such as RTL) that logically defines hardware suitable for fabrication in an integrated circuit may be processed on a computer system configured to generate a manufacturing definition of the integrated circuit in the context of a software environment that includes definitions of circuit elements and rules for combining those elements to generate a manufacturing definition of the integrated circuit defined by the representation. As is common for software to be executed at a computer system in order to define the state of a machine, one or more intermediate user steps (e.g., providing commands, variables, etc.) may be required in order for the computer system to be configured to generate a manufacturing definition of the integrated circuit to execute code that defines the integrated circuit in order to generate the manufacturing definition of the integrated circuit.

[0172] Now about Fig.17 Examples are described of processing an integrated circuit definition data set at an integrated circuit manufacturing system to configure the system to manufacture a graphics processing system, a primitive block generator, or a cache as described herein.

[0173] Fig.17 An example of an integrated circuit (IC) manufacturing system 1702 is shown, which is configured to manufacture a graphics processing system, a primitive block generator, or a cache as described in any of the examples in this document. Specifically, the IC manufacturing system 1702 includes a layout processing system 1704 and an integrated circuit generation system 1706. The IC manufacturing system 1702 is configured to receive an IC definition data set (e.g., defining a graphics processing system, a primitive block generator, or a cache as described in any of the examples in this document), process the IC definition data set, and generate an IC (e.g., which embodies a graphics processing system, a primitive block generator, or a cache as described in any of the examples in this document) according to the IC definition data set. The processing of the IC definition data set configures the IC manufacturing system 1702 to manufacture an integrated circuit, which embodies a graphics processing system, a primitive block generator, or a cache as described in any of the examples in this document.

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

[0175] As is known in the art, IC generation system 1706 generates an IC according to the circuit layout definition. For example, IC generation system 1706 may implement a semiconductor device manufacturing process to generate the IC, 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 that may be used in a photolithography process to generate the IC according to the circuit definition. Alternatively, the circuit layout definition provided to IC generation system 1706 may be in the form of a computer readable code that IC generation system 1706 may use to form a suitable mask for generating the IC.

[0176] The different processes performed by the IC manufacturing system 1702 may all be implemented at one location, such as by one party. Alternatively, the IC manufacturing system 1702 may be a distributed system such that some processes may be performed at different locations and may be performed by different parties. For example, some of the following stages may be performed at different locations and / or by different parties: (i) synthesizing RTL code representing an IC definition data set to form a gate-level representation of a 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.

[0177] In other examples, processing an integrated circuit definition data set at an integrated circuit manufacturing system may configure the system to manufacture a graphics processing system, a primitive block generator, or a cache as described herein without processing the IC definition data set to determine a circuit layout. For example, an integrated circuit definition data set may define a configuration of a reconfigurable processor (e.g., an FPGA), and processing the data set may configure the IC manufacturing system to generate a reconfigurable processor having the defined configuration (e.g., by loading the configuration data into the FPGA).

[0178] In some embodiments, when processed in an integrated circuit manufacturing system, the integrated circuit manufacturing definition data set may cause the integrated circuit manufacturing system to generate a device as described herein. Fig.17 The configuration of an integrated circuit manufacturing system in the described manner can be used to manufacture the devices described herein.

[0179] In some examples, the integrated circuit definition data set may include software that runs on, or in combination with, the hardware defined at the data set. Fig.17 In the example shown in , the IC generation system may 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 when manufacturing the integrated circuit, or to otherwise provide the integrated circuit with program code for use with the integrated circuit.

[0180] Compared to known implementations, the implementation of the concepts set forth in this application in devices, equipment, modules and / or systems (and in the methods implemented herein) may result in performance improvements. The performance improvements may include one or more of improved computing performance, reduced latency, increased throughput and / or reduced power consumption. During the manufacture of such devices, equipment, modules and systems (e.g., in integrated circuits), a trade-off may be made between performance improvements and physical implementations to improve the manufacturing methods. For example, a trade-off may be made between performance improvements and layout area to match the performance of known implementations, but using less silicon. For example, this may be accomplished by reusing functional blocks in a serial manner or sharing functional blocks between elements of devices, equipment, modules and / or systems. In contrast, the concepts set forth in this application that result in improvements to the physical implementations of devices, equipment, modules and systems (e.g., reduced silicon area) may be weighed against performance improvements. For example, this may be accomplished by manufacturing multiple instances of a module within a predefined area budget.

[0181] Applicants hereby independently disclose each individual feature described herein and any combination of two or more such features, to the extent that such feature or combination can be implemented according to the common general knowledge of a person skilled in the art based on the specification as a whole, regardless of whether such feature or combination of features solves any problem disclosed herein. It will be apparent to those skilled in the art in view of the foregoing description that various modifications can be made within the scope of the invention.

Claims

1. A method (700) of generating a primitive block at a primitive block generator in a graphics processing system, the primitive block generator comprising a data storage area for storing a current primitive block to which primitives can be added, the method (700) comprising: Receiving transformed position data for a current primitive, the transformed position data indicating a spatial position of the current primitive in a rendering space (702); determining a distance between the spatial position of the current primitive in the rendering space and a spatial position of the current primitive block in the rendering space based on the transformed position data for the current primitive (706), the spatial position of the current primitive block in the rendering space being based on spatial positions of primitives forming the current primitive block; determining whether to add the current primitive to the current primitive block based on (i) the distance and (ii) the fullness of the current primitive block (708); In response to determining that the current primitive is to be added to the current primitive block, adding the current primitive to the current primitive block (712); as well as In response to determining that the current primitive is not to be added to the current primitive block, outputting the current primitive block and adding the current primitive to a new current primitive block (710, 712); Wherein determining whether to add the current primitive to the current primitive block based on the distance and the fullness of the current primitive block comprises dynamically determining a set of one or more distance thresholds based on the fullness of the current primitive block, and comparing the distance with the set of one or more distance thresholds.

2. The method (700) of claim 1, wherein determining a set of one or more distance thresholds based on the fullness of the current primitive block comprises: When the current primitive block has a first fullness level, selecting a first set of one or more distance thresholds; And when the current primitive block has a second fullness level higher than the first fullness level, selecting a second set of one or more distance thresholds that may be lower than the first set of one or more distance thresholds.

3. The method (700) according to claim 1, wherein there are multiple predetermined sets of one or more distance thresholds each associated with a different range of fullness levels, and determining the set of one or more distance thresholds based on the fullness of the current primitive block includes selecting a predetermined set of one or more distance thresholds associated with the fullness level of the current primitive block from the multiple predetermined sets of one or more distance thresholds.

4. The method (700) of claim 3, wherein the plurality of predetermined sets of one or more distance thresholds include a first predetermined set of one or more distance thresholds for when the current primitive block is less than one quarter full, a second predetermined set of one or more distance thresholds for when the current primitive block is at least one quarter full and less than one half full, a third predetermined set of one or more distance thresholds for when the current primitive block is at least one half full and less than three quarters full, and a fourth predetermined set of one or more distance thresholds for when the current primitive block is at least three quarters full.

5. The method (700) according to any one of claims 1 to 4, wherein in the case where the distance exceeds at least one of the one or more distance thresholds in the set of one or more distance thresholds, it is determined that the current primitive will not be added to the current primitive block.

6. The method (700) according to any one of claims 1 to 4, wherein the one or more distance thresholds include multiple distance thresholds, and only if the distance exceeds all of the distance thresholds in the set of one or more distance thresholds, is it determined that the current primitive will not be added to the current primitive block.

7. The method (700) according to any one of claims 1 to 4, wherein the distance between the spatial position of the current primitive in the rendering space and the spatial position of the current primitive block in the rendering space is based on a bounding box for the current primitive block to which the current primitive is added, and a bounding box for the current primitive block to which the current primitive is not added.

8. The method (700) of claim 7, wherein the distance between the spatial position of the current primitive in the rendering space and the spatial position of the current primitive block in the rendering space is based on at least one of: (i) a ratio of a first size of the bounding box for the current primitive block to which the current primitive is added to a first size of the bounding box for the current primitive block to which the current primitive is not added; (ii) a ratio of a second size of the bounding box for the current primitive block to which the current primitive is added to a second size of the bounding box for the current primitive block to which the current primitive is not added; and (iii) a ratio of an area of ​​the bounding box for the current primitive block to which the current primitive is added to an area of ​​the bounding box for the current primitive block to which the current primitive is not added.

9. The method (700) of claim 7, wherein the rendering space is divided into a plurality of tiles and the bounding box has a per-tile resolution.

10. The method (700) according to any one of claims 1 to 4, wherein the rendering space is divided into a plurality of tiles, and the distance between the spatial position of the current primitive in the rendering space and the spatial position of the current primitive block in the rendering space is based on a rendering order of the plurality of tiles.

11. A method (700) according to any one of claims 1 to 4, wherein the fullness of the current primitive block is based on at least one of the following: (i) the number of primitives in the current primitive block compared to the maximum number of primitives; and (ii) the number of vertices in the current primitive block compared to the maximum number of vertices when each primitive is defined by one or more vertices.

12. The method (700) of any one of claims 1 to 4, wherein the distance comprises a single distance metric.

13. The method (700) of any one of claims 1 to 4, wherein the distance comprises a plurality of distance metrics.

14. The method (700) according to any one of claims 1 to 4, further comprising: After adding the current primitive to the current primitive block, determining whether the current primitive block is full; as well as In response to determining that the current primitive block is full, the current primitive block is output.

15. The method (700) of any one of claims 1 to 4, wherein each primitive is defined by one or more vertices, and in response to determining that the current primitive will not be added to the current primitive block, determining whether the current primitive shares at least one vertex with the current primitive block, and outputting the current primitive block only if it is determined that the current primitive block does not share at least one vertex with the current primitive block.

16. A primitive block generator (1000) for a graphics processing system for generating primitive blocks from a plurality of primitives, the primitive block generator (1000) comprising: a data storage area (1002) configured to store a current primitive block (1004) to which primitives can be added; as well as Block allocation logic (1006), which includes: The distance calculation logic (1008) is configured to: receiving transformed position data for a current primitive, the transformed position data indicating a spatial position of the current primitive in a rendering space; and determining, based on the transformed position data for the primitive, a distance between the spatial position of the current primitive in the rendering space and a position of the current primitive block in the rendering space, the spatial position of the current primitive block in the rendering space being based on spatial positions of primitives forming the current primitive block; Comparison logic (1014) configured to: determining whether to add the current primitive to the current primitive block based on (i) the distance and (ii) the fullness of the current primitive block; In response to determining that the current primitive is to be added to the current primitive block, causing the current primitive to be added to the current primitive block; and In response to determining that the current primitive is not to be added to the current primitive block, causing the current primitive block to be output and causing the current primitive to be added to a new current primitive block; The comparison logic (1014) is configured to determine whether to add the current primitive to the current primitive block based on the distance and the fullness of the current primitive block in the following manner: dynamically determining a set of one or more distance thresholds based on the fullness of the current primitive block, and comparing the distance to the set of one or more distance thresholds.

17. A graphics processing system comprising the primitive block generator according to claim 16.

18. A computer-readable storage medium having stored thereon computer-readable instructions, which when executed at a computer system cause the computer system to perform the method according to any one of claims 1 to 4.

19. A computer-readable storage medium having stored thereon a computer-readable description of the primitive block generator of claim 16, said computer-readable description, when processed in an integrated circuit manufacturing system, causing said integrated circuit manufacturing system to manufacture an integrated circuit embodying said primitive block generator.

Images