Primitive block generator for graphics processing system

Abstract

The invention relates to a primitive block generator for a graphics processing system. A method and primitive block generator for generating primitive blocks in a graphics processing system. The method comprises: 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 a full scale of the current primitive block; 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; and in response to determining that the current primitive is not added to the current primitive block, emptying the current primitive block and adding the current primitive to a new current primitive block.

Description

[0001] Division Application Instructions

[0002] This application is a divisional application of a Chinese patent application with an application date of December 20, 2019, an application number of 201911327664.8, and a title of "Primitive Block Generator for Graphics Processing System". Technical Field

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

[0004] A graphics processing system is configured to receive, for example, graphics data from an application (such as 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 can generate a 3D model of a scene and output geometric structure data representing objects in the scene. Specifically, the application can 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 can be applied), where the plurality of primitives are defined by the positions of one or more vertices. In these situations, the geometric structure data output by the application can include information identifying each vertex (such as the coordinates of the vertex in world space) and information indicating the primitive formed by the vertices. The graphics processing system then converts the received geometric structure data into an image that can be displayed on a screen.

[0005] A graphics processing system can implement, for example, 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 divided into sub-sections called tile blocks, where at least a part of the rendering process can be independently executed for each tile block. Tile blocks can have any suitable shape, but are typically rectangular (where the term "rectangle" includes squares). The advantage of TBR is that fast, on-chip memory can be used during rendering for color, depth, and stencil buffer operations, which allows a significant reduction in system memory bandwidth compared to IMR without requiring on-chip memory large enough to store data for the entire scene at the same time.

[0006] TBR involves two key stages: a geometry processing stage; and a rasterization stage. During the geometry processing stage, geometry data (such as vertices defining primitives) received from an application (such as a game application) is transformed from world space coordinates into screen space coordinates. A per-tile list of transformed primitives (such as triangles) that at least partially fall within the bounds of a tile is then created. During the rasterization stage, each tile is rendered individually (i.e., the transformed primitives are mapped to pixels and a color is identified for each pixel in the tile). This can 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 primitive(s) at the pixel, which can be defined by a texture applied at the pixel and / or a 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 the tile when rendering a particular tile during the rasterization stage, which keeps the bandwidth requirements for memory (such as an intermediate buffer) to a minimum. Once a color value has been identified for each pixel, the color values are written out to memory (such as 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.

[0007] Figure 1 Shows an example TBR graphics processing system 100. System 100 includes a memory 102 1、 102 2、 102 3、 102 4 , geometry processing logic 104, and rasterization logic 106. Two or more of memories 102 1 , 102 2 , 102 3 and 102 4 can be implemented in the same physical unit of memory.

[0008] The geometry processing logic 104 implements the geometry processing stage of TBR. The geometry processing logic 104 includes transformation logic 108 and a tiling engine 110. The transformation logic 108 receives geometry data (such as vertices, primitives, and / or patches) from an application (such as a game application) and transforms the geometry data into a rendering space (such as screen space). The transformation logic 108 can also perform functions such as culling and clipping to remove geometry data (such as primitives or patches) that fall outside the view frustum, and / or apply lighting / attribute processing known to those skilled in the art. The transformed geometry data (such as vertices, primitives, and / or patches) (i) is stored in the memory 1022 in, and (ii) provided to the tiling engine 110. The tiling engine 110 generates a list of transformed primitives for each tile block from the transformed geometric data, where the transformed primitives at least partially fall within the tile block. The list may be referred to as a display list or a transformed display list. In some situations, the transformed display list includes pointers or links to the transformed geometric data (such as vertex data) associated with the primitives that at least partially fall within the tile block.

[0009] The rasterization logic 106 implements the rasterization stage of the TBR. Specifically, the rasterization logic 106 renders primitives in a per-tile-block manner by 3 extracting the display list for the tile block and then, for the primitives that fall within the tile block as indicated by the display list for the tile block, from the memory 102 2 extracting the transformed geometric data; and rendering the primitives for the tile block based on the transformed geometric data.

[0010] In some situations, the rasterization logic 106 may include extraction logic 112, hidden surface removal (HSR) logic 114, and texturing / shading logic 116. In these situations, the extraction logic 112 extracts each display list from the memory 102 3 and, for each display list, extracts the transformed geometric data for the primitives that fall within the tile block as specified by the corresponding display list from the memory 102 2 The transformed geometric data for a particular tile block is then provided to the HSR logic 114, which removes hidden (e.g., hidden by other primitive fragments) primitive fragments. The term "fragment" is used herein to mean a sample of a primitive at a sampling point, and the sample will be processed to render the pixels of the 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 can be applied to multiple fragments for rendering each pixel value.

[0011] 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 the pixel values of the rendered image. The rendered pixel values for the tile block are then stored in the memory 102 4 (such as a frame buffer).

[0012] The rasterization logic 106 processes each tile block, and when the entire image has been rendered and stored in the memory 102 4 (such as a frame buffer), the image can be output from the graphics processing system 100 and used in any suitable manner, such as being displayed on a display, stored in a memory, or transmitted to another device, etc. In the sense that the fragments are processed by the HSR logic 114 before being processed by the texturing / shading logic 116, Figure 1 the illustrated TBR graphics processing system 100 is a "deferred" rendering system. In other examples, the graphics processing system may not be a deferred rendering system, in which case the texturing / shading will be applied to the fragments before applying the HSR to the fragments.

[0013] In many cases, the transformed geometry data can be quite large. This is especially true when there is a large expansion ratio between the untransformed geometry data and the transformed geometry data (such as when tessellation is performed by the transformation logic 108).

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

[0015] Figure 2 An example TBR graphics processing system 200 that uses 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 can be referred to as an untransformed display list (UDL) graphics processing system. System 200 is similar to Figure 1System 100, with the differences that: (i) the transformed geometry data is not written to the memory by the geometry processing logic; (ii) instead of identifying the transformed primitives that fall within each tile block, the display list identifies the untransformed primitives that will fall within each tile block data when transformed; and (iii) the rasterization logic includes transformation logic for transforming the untransformed primitives mentioned in the untransformed display list. Similar to Figure 1 System 100, system 200 includes a memory 202 1 、202 3 、202 4 、a geometry processing logic 204 and a rasterization logic 206.

[0016] Similar to Figure 1 the geometry processing logic 104, the geometry processing logic 204 implements the geometry processing stage of TBR. Figure 2 The geometry processing logic 204 of Figure 1 includes a transformation logic 208 and a tiling engine 210. The transformation logic 208 receives geometry data (such as vertices and primitives) from an application (such as a game application) and transforms the geometry data into a rendering space (such as screen space). The transformation logic 208 can also perform functions such as culling and clipping to remove geometry data (such as primitives) that fall outside the view frustum. Compared with Figure 2 the transformation logic 108, Figure 2 the transformation logic 208 may not apply lighting / attribute processing because the geometry processing logic 204 only uses position information. The transformed geometry data (such as vertices and primitives) is provided to the tiling engine 210. The tiling engine 210 generates a list of untransformed primitives for each tile block from the transformed geometry data, and the untransformed primitives at least partially fall within the tile block when transformed. The list generated by

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

[0018] In some situations, the rasterization logic 206 can include extraction logic 212, transformation logic 213, hidden surface removal (HSR) logic 214, and texturing / shading logic 216. In these situations, the extraction logic 212 extracts each untransformed display list from the memory 202 3 and for each display list extracts the untransformed geometry data identified in the display list from the memory 202 1 The untransformed geometry data for a particular tile block is then provided to the transformation logic 213, which transforms the untransformed geometry data (e.g., primitives) into the rendering space (e.g., screen space). The transformed geometry data for a particular tile block is then provided to the HSR logic 214, which removes hidden (e.g., hidden by other primitive fragments) primitive fragments. The remaining fragments (after hidden surface removal) are then passed to the texturing / shading logic 216, which performs texturing and / or shading on the primitive fragments to determine the pixel values of the rendered image, and the pixel values can be passed to the memory 202 4 (e.g., frame buffer) for storage.

[0019] The embodiments described below are provided only as examples and do not limit the implementation, which addresses any one or all of the disadvantages of known UDL graphics processing systems. SUMMARY OF THE INVENTION

[0020] This summary is provided to introduce a series of concepts that are further described in the detailed description below. 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.

[0021] Methods and primitive block generators 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 the position of the current primitive in the rendering space; determining a 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; adding the current primitive to the current primitive block in response to determining that the current primitive is to be added to the current primitive block; and emptying the current primitive block and adding the current primitive to a new current primitive block in response to determining that the current primitive is not to be added to the current primitive block.

[0022] A first aspect provides a method of generating a primitive block at a primitive block generator in a graphics processing system, the primitive block generator including a data store for storing a current primitive block to which primitives can be added, the method including: receiving transformed position data for a current primitive, the transformed position data indicating the position of the current primitive in a rendering space; determining a distance between the position of the current primitive and the 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) the fullness of the current primitive block; 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; and in response to determining that the current primitive is not to be added to the current primitive block, clearing the current primitive block and adding the current primitive to a new current primitive block.

[0023] 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 including: a data store configured to store a current primitive block to which primitives can be added; and block allocation logic including: distance calculation logic configured to: receive transformed position data for a current primitive indicating the position of the current primitive in a rendering space; and determine a distance between the position of the current primitive and the position of the current primitive block based on the transformed position data for the primitive; comparison logic configured to: determine 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, 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.

[0024] A third aspect provides a graphics processing system including the primitive block generator of the second aspect.

[0025] The graphics processing systems, primitive block generators, and caches described herein can be embodied in hardware on an integrated circuit. A method of manufacturing the graphics processing systems, primitive block generators, and caches described herein can be provided at an integrated circuit manufacturing system. An integrated circuit definition data set can be provided that configures the system to manufacture the graphics processing systems, primitive block generators, and caches described herein when processed in an integrated circuit manufacturing system. A non-transitory computer-readable storage medium can be provided having stored thereon a computer-readable description of the graphics processing systems, primitive block generators, or caches described herein, the computer-readable description causing an integrated circuit manufacturing system to manufacture an integrated circuit embodying the graphics processing systems, primitive block generators, or caches when processed in the integrated circuit manufacturing system.

[0026] An integrated circuit manufacturing system can be provided that includes: a non-transitory computer-readable storage medium having stored thereon a computer-readable description of the graphics processing systems, primitive block generators, or caches 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 systems, primitive block generators, or caches; and an integrated circuit generation system configured to manufacture the graphics processing systems, primitive block generators, or caches according to the circuit layout description.

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

[0028] The above features can be combined as appropriate, as will be apparent to those skilled in the art, and can be combined with any aspect of the examples described herein. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

[0032] Figure 3 is a block diagram of a primitive block-based untransformed display list graphics processing system;

[0033] Figure 4is a schematic diagram showing examples of an untransformed display list, primitive blocks, and untransformed geometry data;

[0034] Figure 5 is an example method flowchart for rendering data in a Figure 3 graphics processing system;

[0035] Figure 6 is a schematic diagram of multiple primitives divided into multiple tile blocks in an example rendering space;

[0036] Figure 7 is a flowchart of an example method for generating primitive blocks;

[0037] Figure 8 is a schematic diagram showing example bounding boxes for using sets of primitives with different granularities;

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

[0039] Figure 10 is a block diagram of an example primitive block generator;

[0040] Figure 11 is a block diagram of an example transformed geometry data cache;

[0041] Figure 12 is a schematic diagram showing an example of a transformed primitive block;

[0042] Figure 13 is a schematic diagram showing an example transformed geometry data cache that has been divided into multiple sub - memory blocks;

[0043] Figure 14 is a flowchart of an example method for storing transformed primitive blocks in a transformed geometry data cache;

[0044] Figure 15 is a block diagram of an example implementation of HSR logic and texturing / shading logic;

[0045] Figure 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 can be implemented; and

[0046] Figure 17 is a block diagram of an example integrated circuit manufacturing system that can be used to generate an integrated circuit embodying any of the graphics processing system, primitive block generator, and transformed geometry data cache described herein.

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

[0048] The following description is presented as an example to enable those skilled in the art to make and use the present invention. The present invention is not limited to the embodiments described herein, and various modifications to the disclosed embodiments will be apparent to those skilled in the art. The embodiments are described only as examples.

[0049] 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 geometric data generated in the geometry processing stage, but generates a display list for each tile block that mentions the untransformed primitives, and then, the untransformed geometric data corresponding to the untransformed primitives identified in each display list is transformed again in the rasterization stage. Such a system does not require memory to store the transformed geometric data generated in the geometry processing stage and avoids the latency of storing and retrieving the transformed geometric data from memory. These memory-based benefits can provide a significant improvement in the performance of the TBR graphics processing system, especially when used to render scenes of complex games.

[0050] In Figure 2 the UDL graphics processing system 200, the rasterization logic 206 is configured to extract and render the primitives related to a specific tile block based on the primitives. Specifically, the rasterization logic 206 (e.g., the extraction logic 212 and the transformation logic 213) is configured to retrieve from the memory 202 for each primitive identified in the untransformed display list for the tile block 1Extract the untransformed geometric structure data for the primitive (e.g., the untransformed geometric structure data for each vertex used to form the primitive), and then transform the extracted geometric structure data. However, a primitive often falls within more than one tile block, which would require the same primitive to be extracted and transformed multiple times. Therefore, a cache system can be used to cache the results of the extraction and / or transformation. However, geometric structure transformation may involve multiple stages, such as but not limited to clipping, vertex shading, geometric structure shading, hull shading, and domain shading for tessellation, and caching the results from each geometric structure transformation stage for the primitives (e.g., vertices) in a tile block would require a complex cache system, such as the cache system described in UK Patent Application Publication No. GB2542133.

[0051] In addition, in some situations, 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 is known to those skilled in the art, an SIMD processor includes multiple processing elements, each of which performs the same operation on a different set of data. Each processing element that processes a set of input data is referred to as a "lane" of the SIMD processor. An SIMD processor operates most efficiently when each lane is "full" (i.e., is processing data). In some situations, the SIMD processor of the transformation logic 213 can include 32 lanes. Processing the primitives of a tile block based on each primitive extraction may often cause the SIMD lanes of the transformation logic 213 to not be full, and / or may take time to obtain the data for the SIMD lanes and put them together.

[0052] The inventors have recognized that geometric structure data transformation in the rasterization stage can be efficiently performed without a complex cache system by transforming not only the untransformed primitives that fall within a tile block when being transformed, but also the untransformed primitives of the primitives that are close to the tile block when being transformed. This not only allows the SIMD lanes of the transformation logic 213 to be filled (or substantially filled), but also if additional untransformed primitives are close to the primitives in a tile block, then it is likely that one of the next few tile blocks to be rasterized will require the transformed geometric structure data associated with the primitive. Therefore, the transformed geometric structure 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 tile blocks to be processed.

[0053] Accordingly, a non-transformed display list (UDL) graphics processing system is described herein, where the geometry processing logic is configured to group non-transformed primitives into non-transformed primitive blocks based on corresponding transformed geometry data; and the rasterization logic is configured to extract and transform the non-transformed geometry data of each non-transformed primitive in the same non-transformed primitive block as the associated non-transformed primitive when identifying a particular non-transformed primitive in the non-transformed display list, and cache the transformed geometry data associated with the primitive in a cache system. If it is assumed that the primitives received from an application tend to be spatially grouped (e.g., received in substantially spatial position order), then grouping the non-transformed primitives into non-transformed primitive blocks can simply include grouping the non-transformed primitives based on the order in which the non-transformed primitives are received. However, a more complex mechanism for grouping non-transformed primitives into non-transformed primitive blocks can further improve the efficiency of the graphics processing system. Transforming all non-transformed primitives in the same non-transformed primitive block as the non-transformed primitive mentioned in the display list can be referred to herein as primitive-block-based transformation. A UDL graphics processing system implementing primitive-block-based transformation has the memory-based advantages of a UDL without 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 from memory).

[0054] Now refer to Figure 3 , which shows an example non-transformed display list (UDL) graphics processing system 300 that implements primitive-block-based transformation in the rasterization stage. Figure 3 System 300 is similar to Figure 2 system 200 in that it includes a memory 302 1 、302 3 、302 4 、geometry processing logic 304, and rasterization logic 306. However, compared to Figure 2 system 200, Figure 3 the geometry processing logic 304 is configured to group non-transformed primitives into non-transformed primitive blocks based on corresponding transformed geometry data and store the non-transformed primitive blocks in the memory 302 2in; and the rasterization logic 306 is configured to extract and transform the untransformed geometric structure 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 geometric structure data in the cache.

[0055] Memory 302 1 、302 2 、302 3 、302 4 may be implemented as one or more blocks of memory. Memory 302 1 、302 2 、302 3 、302 4 may be located "off-chip" (i.e., not on the same chip as the geometry processing logic 304 and the rasterization logic 306). The geometry processing logic 304 and the rasterization logic 306 may communicate with the memory 302 1 、302 2 、302 3 、302 4 via one or more communication buses known in the art.

[0056] As described above, an application generates geometric structure data that describes the objects in the scene to be rendered, and the geometric structure data is stored in the memory 302 1 . The geometric structure data generated by the application is referred to herein as untransformed geometric structure data. The untransformed geometric structure data may include vertex data, primitive data, and / or patch data. The vertex data may include position data for the vertices (e.g., the X, Y, and Z coordinates that describe the position of the vertices in world space). The vertex data may also include a set of attributes that describe the appearance of the vertices, such as texture coordinates (U, V) and / or base color to be applied to the vertices. In some cases, the vertex data may be stored in the vertex buffer of the memory 302 1 . The primitive data may include information indicating which vertices form each primitive. For example, in the case where the primitive is a triangle, the primitive data may indicate which three vertices form the primitive. In some cases, the information in the primitive data that identifies a specific vertex 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, then the portion of the vertex buffer associated with vertex 0 may be identified by the index or pointer 0, and the portion of the vertex buffer associated with vertex 20 may be identified by the index or pointer 20. In some cases, the primitive data may be stored in an index buffer. The patch data includes control points that define the patches to be tessellated into the primitives for rendering.

[0057] Similar to Figure 2 Similar to the geometric structure processing logic 204 shown, the geometric structure processing logic 304 implements the geometric structure processing phase of the TBR. Figure 3 The geometric structure processing logic 304 shown includes transformation logic 308, a primitive block generator 309, and a tiling engine 310. The transformation logic 308 receives untransformed geometric structure 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 geometric structure data for the untransformed primitives includes position data indicating the position of the untransformed primitives in world space. In some cases, generating transformed position data for the untransformed primitives may include transforming the position data from world space to the rendering space. However, in other cases, generating transformed position data may include first generating one or more sub-primitives from the original untransformed primitives (e.g., by performing tessellation and / or geometric shading on the untransformed primitives), and transforming the position data for the sub-primitives into the rendering space.

[0058] In the case where the primitive is a triangle defined by three vertices, the position data for the untransformed primitive (or sub-primitive) may include position data for each of the three vertices forming the primitive (e.g., X, Y, Z coordinates). 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 the 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 view frustum.

[0059] The primitive block generator 309 groups the plurality of untransformed primitives based on the transformed position data for the plurality of untransformed primitives and generates a primitive block for each group that identifies the portion of the untransformed geometric structure data associated with those untransformed primitives. For example, the primitive block generator 309 may receive the transformed position data for the plurality of untransformed primitives and group the untransformed primitives such that untransformed primitives with similar transformed positions (e.g., similar positions in the rendering space) are in the same group; and generate an untransformed primitive block for each group, where each untransformed primitive block identifies the storage in the memory 302 1The untransformed geometric structure data associated with those untransformed primitives. The primitive block generator 309 can 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 having 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. The example implementation of the primitive block generator 309 and the methods that can be implemented by the primitive block generator 309 are described below with reference to Figures 6 to 10 and the methods that can be implemented by the primitive block generator 309 are described below with reference to

[0060] An untransformed primitive block is a data structure for linking groups or sets of untransformed primitives. Figure 4 An example of an untransformed primitive block 402 is shown 1 、402 2 is shown. Figure 4 An example untransformed primitive block 402 1 、402 2 includes a header 404, status data 406, and primitive index data 408. The header 404 contains information describing the untransformed primitive block. For example, the header 404 can 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 status data 406 contains information describing how the untransformed primitives in the untransformed primitive block 402 1 or 402 2 will be rendered by the rendering logic. The status data can be described as identifying the recipe for rendering the primitives described in the untransformed primitive block. For example, the status data can include, but is not limited to, information identifying the depth comparison mode, blend state, texture state, and / or 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 can include a set of three indices identifying the three vertices that form the triangle. The indices are indices of vertices sent from the application (which can be referred to herein as global indices). Each index serves as a pointer to the untransformed geometric structure data 410 stored in the memory 302 1 that defines a particular vertex or a portion associated therewith.

[0061] For example, as Figure 4 shown, for the first untransformed primitive block 402 1The primitive index data 408 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 associated therewith (e.g., a portion of a vertex buffer). For example, the identifier of vertex 0 (V0) serves as a pointer to portion 412 of the untransformed geometry data 410 that defines vertex 0 (V0) or is associated therewith. As described above, the untransformed geometry data for a particular vertex can include position data that describes 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 can also include a set of attributes for describing the appearance of the vertex, such as texture coordinates (U, V) and / or base color to be applied to the vertex. In some cases, the primitive index data can be generated by copying or writing out the portion of the index buffer associated with the relevant untransformed primitives. The primitive index data 408 in the untransformed primitive block can be compressed according to any suitable compression technique.

[0062] In some cases, the state data can 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 can include information identifying the state of multiple parameters, where each parameter is defined by multiple bits. In these cases, instead of explicitly including the information for each parameter, each possible combination of the state data can be stored in a state data table in memory, and the state data portion 406 of the untransformed primitive block can include only an index or pointer to an entry in the state data table.

[0063] Returning to Figure 3 , the untransformed primitive block generated by the primitive block generator 309 is stored in the memory 302 2 whereas the transformed position data for the untransformed primitives, along with information indicating which untransformed primitive block each untransformed primitive belongs to, will be provided to the tiling engine 310. The tiling engine 310 determines, based on the transformed position data, which untransformed primitives will at least partially fall within the bounds of each tile block when transformed. The tiling engine 310 then generates an untransformed display list for each tile block, which indicates which untransformed primitives will at least partially be within the bounds of the tile block when transformed and in which untransformed primitive block each of those untransformed primitives is located.

[0064] In some situations, the untransformed display list for a tiled block can include information identifying untransformed primitive blocks that contain relevant untransformed primitives, and a primitive mask for each identified untransformed primitive block that identifies which of the untransformed primitives within the untransformed primitive block are at least partially within the bounds of the tiled block when transformed. The information identifying a particular untransformed primitive block can be the address of the untransformed primitive block in memory, or any other suitable identifier that uniquely identifies the untransformed primitive block. The primitive mask can contain, for example, bits for each untransformed primitive (or each possible untransformed primitive) in the untransformed primitive block, and can be set to one value (e.g., "1") when the untransformed primitive is within the tiled block and to another value (e.g., "0") when the untransformed primitive is not within the tiled block. For example, if each untransformed primitive block can include up to 32 untransformed primitives, then each primitive mask can include 32 bits.

[0065] Figure 4 FIG. 4 shows an example untransformed display list 414 for a tiled block. 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, based on the transformed position data for these untransformed primitives, that untransformed primitives 0, 3, and 4 are within a particular tiled block (e.g., tiled block 0) when transformed, then the tiling engine 310 can generate Figure 4 the untransformed display list 414 shown. Specifically, the tiling engine 310 can generate an untransformed display list 414 that includes: (i) information identifying untransformed primitive blocks 0 and 1 as containing untransformed primitives that are at least partially within the bounds of tiled block 0 when transformed; and (ii) a primitive mask (e.g., "100") for untransformed primitive block 0 that indicates that the first untransformed primitive (e.g., primitive 0) of the untransformed primitive block is at least partially within the bounds of tiled block 0 when transformed; and (iii) a primitive mask (e.g., "110") for untransformed primitive block 1 (UPB1) that indicates that the second and third untransformed primitives (e.g., primitives 3 and 4) of the untransformed primitive block are at least partially within the bounds of tiled block 1 when transformed.

[0066] Each untransformed display list generated by the tiling engine 310 is stored in the memory 302 3 .

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

[0068] As Figure 3 shown, the rasterization logic 306 can include extraction logic 312, transformation logic 313, cache 315, hidden surface removal (HSR) logic 314, and texturing / shading logic 316. When the rasterization logic 306 wants (or is ready) to process a particular tile, the extraction logic 312 retrieves from the memory 302 3Extract the untransformed display list for the tiled block. The extraction logic 312 then determines whether the cache 315 includes transformed geometry data for all of the 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, then the extraction 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 of the untransformed primitive blocks mentioned in the untransformed display list for the tiled block, then the extraction logic 312 extracts the untransformed geometry data for those uncached untransformed primitive blocks.

[0069] Extracting the untransformed geometry data for the untransformed primitive blocks can include retrieving from the memory 302 2 the untransformed primitive blocks, and using the identification in the untransformed primitive blocks to retrieve information about the associated untransformed geometry data (e.g., information identifying the vertices of the untransformed primitives forming the untransformed primitive block) to retrieve the associated untransformed geometry data from the memory 302 1 The untransformed geometry data retrieved from the memory 302 1 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 at least generating transformed position data for the untransformed primitives in the rendering space (e.g., screen space). Transforming the untransformed geometry data can also include performing functions such as clipping and culling to clip or remove primitives that partially or fully fall outside the view 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.

[0070] Once the transformed geometric structure data of the untransformed primitive blocks identified in the display list for tiled blocks is stored in the cache 315, the extraction logic 312 and / or the transformation logic 313 notify the HSR logic 314 that the HSR logic 314 can start processing the tiled blocks and which primitives in the primitive blocks form the tiled blocks. 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 the pixel values of the rendered image, and the pixel values can be passed to memory for storage in the frame buffer. Although Figure 3 not shown in

[0071] Now refer to Figure 5 , which shows an example method 500 that can be implemented by, for example Figure 3 the UDL graphics processing system 300 of the UDL graphics processing system to render a scene based on the untransformed geometric structure data received from an application. The method 500 can be divided into a geometric processing stage (blocks 502 to 510) and a rasterization stage (blocks 512 to 526). The method 500 begins in the geometric processing stage at block 502, where untransformed geometric structure data describing the objects in the scene to be rendered is received. The untransformed geometric structure 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 geometric structure data for the untransformed primitive can include vertex data (e.g., X, Y, and Z coordinates) describing the positions of the one or more vertices in world space, and primitive data describing which vertices form the primitive.

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

[0073] At optional block 506, the untransformed primitives are culled or clipped (by, e.g., transform 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 an untransformed primitive is redundant and can therefore be removed. Any suitable method or combination of methods can be used to identify redundant primitives. For example, in some situations, an untransformed primitive can be considered redundant if, based on the transformed position data, the untransformed primitive is facing away from the user, is completely outside the screen, is completely outside a clipping plane, has a bounding box that does not cover any sample points, and / or does not cover any sample points. Once the untransformed primitives have been culled based on the transformed position data, method 500 proceeds to block 508.

[0074] At block 508, after transformed position data has been generated for the untransformed primitives (and optionally after the primitives have been culled), the untransformed primitives are grouped based on the transformed position data and an untransformed primitive block is generated for each group. As described above, each untransformed primitive block contains information identifying the untransformed primitives forming the untransformed primitive block, and information indicating the portions of the geometry data associated with each of those untransformed primitives. For example, as Figure 4As shown, each untransformed primitive block can 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 vertices can be an index into a vertex buffer, which can be used to obtain geometric data associated with the vertices from the vertex buffer. The untransformed primitive block can also contain other information that can assist in processing the primitive block during the rasterization stage, such as information indicating how the untransformed primitives in the block will be rasterized.

[0075] The untransformed primitives are preferably grouped such 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 cases where it is expected that untransformed primitives will be received or processed in an order in which spatially similar primitives are received or processed closely together, the untransformed primitives can be simply grouped based on the order in which the untransformed primitives are received or processed (e.g., the submission order in which the untransformed primitives are received from an application). For example, every K untransformed primitives can be grouped to form an untransformed primitive block, where K is an integer greater than 2. However, more complex methods of grouping the untransformed primitives based on the transformed position data can improve the efficiency of the rasterization stage. Examples of methods and primitive block generators for grouping untransformed primitives based on the transformed position data are described below. Once the untransformed primitives have been grouped into untransformed primitive blocks, method 500 proceeds to block 510. Figures 6 to 10 Examples of methods and primitive block generators for grouping untransformed primitives based on the transformed position data are described below. Once the untransformed primitives have been grouped into untransformed primitive blocks, method 500 proceeds to block 510.

[0076] At block 510, for each tile, the untransformed primitives that, when transformed, at least partially fall within the bounds of the tile are determined based on the transformed position data for the untransformed primitives, and an untransformed display list is generated for the tile that identifies the untransformed primitives that, when transformed, at least partially fall within the tile and the untransformed primitive blocks to which the untransformed primitives belong. Methods for determining which untransformed primitives, when transformed, at least partially fall within the bounds of a tile 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, when transformed, fall within the corresponding tile, and for each identified untransformed primitive block, may include information identifying which untransformed primitives in the block, when transformed, at least partially fall within the bounds of the tile. The information identifying the untransformed primitive blocks may be the address of the untransformed primitive blocks in memory or any other suitable identifier that uniquely identifies the untransformed primitive blocks. The information identifying which untransformed primitives in the untransformed primitive blocks, when transformed, at least partially fall within the bounds of the tile 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, when transformed, is within the tile, and set to another value (e.g., "0") when the corresponding untransformed primitive, when transformed, is not within the tile. Once the untransformed display list has been generated, method 500 proceeds to block 512 where the rasterization phase begins.

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

[0078] At block 514, it is determined whether transformed geometry data for a selected untransformed primitive block exists in the cache. As will be described in more detail at 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 during 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 in the cache, then method 500 proceeds to block 516. However, if the cache includes the transformed geometry data for the selected untransformed primitive block, then method 500 proceeds to block 520.

[0079] At block 516, the untransformed geometry data for the selected untransformed primitive block is fetched (e.g., by fetch logic 312) from memory (such as memory 302 1 ). The untransformed geometry data for the untransformed primitive block can be fetched from memory based on the information in the untransformed primitive block. For example, as described above, each untransformed primitive block can include indices indicating the vertices that form each of the untransformed primitives in the block. The identified vertices can be used to obtain the 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 vertices can be an index in a vertex buffer, which can be used to obtain the untransformed geometry data associated with the vertices in the vertex buffer. Once the untransformed geometry data for the selected untransformed primitive block has been fetched, then method 500 proceeds to block 518.

[0080] At block 518, the untransformed geometric structure data extracted at block 516 is transformed to generate transformed geometric structure data, and the transformed geometric structure data is stored in the cache. The transformation for the untransformed geometric structure data of 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 to 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 geometry shading) and transforming the positions of those sub-primitives to 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) to a position in the rendering space may include transforming the coordinates of the vertices to rendering space (e.g., screen space) coordinates. Transforming the geometric structure data may also include performing one or more other operations on the untransformed geometric structure data, such as but not limited to clipping or culling irrelevant primitives, as described above with respect to block 506. Once the untransformed geometric structure data extracted at block 516 has been transformed and stored in the cache, method 500 proceeds to block 520.

[0081] At block 520, the transformed geometric structure data for the untransformed primitives identified in the untransformed display list (i.e., those untransformed primitives to be used for rendering the tile block) 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 primitives hidden in the scene, and / or performing texturing and / or shading on the fragments to determine the pixel values of the rendered image. Once the pixel values for the tile block have been determined, method 500 proceeds to block 522.

[0082] At block 522, the pixel values are passed to the memory 302 4 for storage in the frame buffer. Method 500 then proceeds to block 524, where it is determined whether the untransformed display list identifies another block of untransformed primitives. If the untransformed display list identifies another block of untransformed primitives, then method 500 proceeds to block 526, where the next block of untransformed primitives identified in the untransformed display list is selected and then blocks 514 through 522 are repeated for the block of untransformed primitives.

[0083] Boxes 512 to 522 (i.e., the rasterization stage) can be repeated for each untransformed display list (i.e., for each tile block), at which point the entire image has been rendered and stored in memory. At this point, the image can be output and displayed, for example, on a display.

[0084] Primitive block generator

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

[0086] The untransformed primitives (and the associated untransformed geometric structure data) can be provided to the geometric structure processing logic 304 in a particular order or sequence. In these situations, the transformation logic 308 can be configured to process the untransformed primitives in that order (i.e., transform the position data associated with the untransformed primitives) such 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 the scene is rendered. For example, if multiple overlapping primitives are translucent, then the order in which the multiple overlapping primitives are processed can affect the way the primitives are blended to form the rendered scene. Thus, to maintain the sequential order of the untransformed primitives, the primitive block generator 309 can be configured to group based on the order (“submit order”) in which the untransformed primitives (i.e., the transformed position data associated therewith) are received in order to preserve their order. For example, the primitive block generator 309 can be configured to continue placing the 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 received untransformed primitives are placed in the next group until that group is full, and so on. In this way, the order of the untransformed primitives is maintained in the untransformed primitive block. If the number of vertices in a group is greater than or equal to the maximum number of vertices (e.g., the maximum number of vertices in a primitive block can be 64 or 128 for two examples) and / or if the number of primitives in a group is greater than or equal to the maximum number of primitives (e.g., the maximum number of primitives in a primitive block can be 64 or 128, for two examples), then the group can be considered “full”. If there is a state change, then a new group can be started because, in the examples described herein, the primitives grouped together into an untransformed primitive block share the same state.

[0087] In the situation where untransformed primitives that are close in order are also close in space (i.e., in the rendering space (e.g., screen space)) when transformed, grouping the untransformed primitives based on the order in which the primitives (i.e., the transformed position data associated therewith) are received is Figure 3is implemented simply and works well in the graphics processing system 300. However, in situations where primitive elements that are close in order are likely to be spatially far apart in the rendering space (e.g., screen space), this method of grouping the primitive elements may not allow the rasterization logic 306 to operate efficiently. This is because in these situations this method is likely to produce a block of primitive elements containing untransformed primitive elements that are spatially far apart when transformed. If the block of untransformed primitive elements includes untransformed primitive elements 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 primitive elements in the block of untransformed primitive elements before retrieving the transformed geometry data from the cache.

[0088] For example, Figure 6 shows a simple example of a scene 600 to be rendered by Figure 3 the graphics processing system 300. The scene 600 includes two similar objects 602 1 and 602 2 , which are spatially separated from each other in the scene 600. As described above, in a TBR graphics processing system, the rendering space (e.g., screen space) is divided into a plurality of tile blocks. In the example shown in Figure 6 , the rendering space (e.g., screen space) is divided into a 4×6 array of rectangular tile blocks. In other examples, the rendering space (e.g., screen space) may be divided into different numbers and / or arrangements of tile blocks. In one example, each tile block includes 32×32 sample positions, and there may be many tile blocks (e.g., hundreds of tile blocks) in the rendering space (e.g., screen space), depending on the size and resolution of the image being rendered. In other examples, the tile blocks may be non-rectangular (e.g., triangular or hexagonal), or may vary in size according to their position.

[0089] Figure 6 shows two primitive elements 604 1 of the first object 602 1 , 604 2 , and two similar primitive elements 604 2 of the second object 602 3 , 604 4 . In Figure 6In the example, the primitive is a triangle that can be defined by vertex data at three vertices. However, in other examples, other types of primitives can be used, where the primitive can be other shapes such as a quadrilateral or a hexagon, or can be a line or a point. It can be considered an appropriate order to receive the primitive at the geometry processing logic 304, and the primitive can place similar primitives together in that order, for example, such that the primitive 604 is continuously received at the geometry processing logic 304 1 、604 2 。As an example, if the primitives have similar states, where the state is information describing the way the primitive will be rendered, then the primitives can be "similar" and thus placed together in that order.

[0090] If the untransformed primitives are placed in that order such that "similar" primitives are placed together in that order, then the primitive 604 1 、604 2 、604 3 、604 4 can be placed together in that order and other primitives of the first object can be placed farther 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 the primitive 604 1 、604 2 、604 3 、604 4 will likely be placed in the same untransformed primitive block, while other primitives of the first object 602 1 can be placed in one or more different untransformed primitive blocks. This means that when the rasterization logic 306 processes the tile block 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 the primitive 604 3 、604 4 (i.e., it will also extract and transform the untransformed geometry data for the primitive 604 1 、604 2 ). However, since the tile block in the third row of the second column is far from the tile block in the first row of the sixth column, when the tile block in the third row of the second column is processed by the rasterization logic 306, for the primitive 604 1 、604 2The transformed geometric structure data is unlikely to be in the cache again. This would mean that the untransformed geometric structure data for the untransformed primitive blocks would have to be fetched and transformed again. In cases where the process of transforming geometric structure data involves executing one or more shader programs, re-transforming the untransformed geometric structure data for the untransformed primitives can be time and processing resource intensive, such as but not limited to vertex shader programs; geometry shader programs; hull shader programs and domain shader programs. Additionally, when processing untransformed primitives by the Figure 3 graphics processing system 300, writing data to the memory 302 1 、302 2 、302 3 and reading data from it is a relatively slow process, especially when the memory is "off-chip", i.e., not on the same chip as the geometry processing logic 304 and / or the rasterization logic 306. If the untransformed primitives are grouped based on their spatial positions to increase the likelihood that the transformed geometric structure data associated with the "extra" untransformed primitives in the untransformed primitive block (i.e., those untransformed primitives in the untransformed primitive block that, when transformed, do not at least partially fall within the tile block being processed) will be in the cache when the tile block associated with the "extra" untransformed primitives is processed, the rasterization logic 306 may thus be able to process the primitives more efficiently.

[0091] Thus, in other situations, the primitive block generator 309 can be configured to group the untransformed primitives according to the transformed spatial positions of the untransformed primitives, as set forth in the transformed position data. Example methods for grouping primitives according to the spatial positions of the primitives are described in UK published patent application No. GB2526598 and incorporated herein by reference. Specifically, GB2526598 describes a method where, when receiving a primitive at the primitive block generator, the primitive block generator compares the spatial position of the received primitive with the spatial positions of one or more 'open' primitive blocks and assigns 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 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 positions of the primitives in the primitive block), then the primitive is assigned to the primitive block. GB2526598 describes several mechanisms for determining the spatial position of the primitive, the spatial position of the primitive block, and the distance between the spatial position of the primitive and the spatial position of the primitive block.

[0092] The present inventor has 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 compromise between having sufficient primitive blocks that will fill the SIMD lanes and having primitive blocks with primitives that are too far apart. Accordingly, 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 situations, if the distance between the spatial position of the primitive and the spatial position of the primitive block is less than a distance threshold, 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 situations, 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.

[0093] Now refer to Figure 7 , which illustrates an example method 700 for generating primitive blocks, the example method being implementable by a Figure 3 primitive block generator 309, where 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. Method 700 can be used, for example, in a UDL TBR graphics processing system 300 Figure 3 to generate untransformed primitive blocks (i.e., primitive blocks that refer to untransformed primitives), or method 700 can be used in a non-UDL TBR graphics processing system to generate transformed primitive blocks (i.e., primitive blocks that refer to transformed primitives). As described above, in some situations, an untransformed primitive can be transformed into multiple transformed primitives (i.e., multiple sub-primitives can be generated from it, and the sub-primitives can be transformed into transformed primitives). In these situations, the transformed primitives can be classified into untransformed primitive blocks based on the transformed primitives or based on the untransformed primitives.

[0094] In the case of classifying transformed primitives into primitive blocks based on untransformed primitives, for the purpose of making a decision on whether to add a primitive to a primitive block, all transformed primitives corresponding to a single untransformed primitive are considered as a single primitive. In these situations, the current primitive is a set of transformed primitives related to the untransformed primitive. In these situations, each untransformed primitive will be identified in only a single untransformed primitive block, which may mean that the untransformed primitive block only has to be re-transformed once. However, when transforming each untransformed primitive block, the transformed geometric structure data related to each untransformed primitive block may be stored in the transformed primitive block. If an untransformed primitive produces a large number of transformed primitives, then all of the transformed geometric structure data related to the untransformed primitive may not be able to 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 geometric structure data more complex.

[0095] In contrast, in the case of classifying transformed primitives into primitive blocks based on transformed primitives, the decision on whether to add a primitive to a primitive block is based only on the transformed position data for the transformed primitive. In these situations, 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 situations, additional information may be added to the untransformed primitive block to specify which of the transformed primitives related to the untransformed primitive identified in the untransformed primitive block are associated with the primitive block. Then, when transforming the untransformed primitive block, only the transformed geometric structure data related to 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, thus allowing one transformed primitive block per untransformed primitive block. However, this may cause the same untransformed primitive to be re-transformed multiple times during the rasterization phase - once for each untransformed primitive block to which the untransformed primitive belongs.

[0096] 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 can be a single transformed primitive (i.e., a primitive output by transformation logic) or a primitive formed from 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 the primitive is defined by one or more vertices, the transformed position data can include the position data (e.g., X, Y, Z coordinates) for the vertices that form the primitive. However, in the case where the current primitive is a primitive formed from a set of transformed primitives associated with the same untransformed primitive, the transformed position data can include information indicating the position of each of the one or more transformed primitives in the rendering space. However, it will be apparent to those skilled in the art that the position data can include other and / or different information. Once the transformed position data for the current primitive has been received, method 700 proceeds to block 704.

[0097] 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 method 700 proceeds to block 706. However, if the primitive block generator determines that there are no primitives in the current primitive block, then method 700 proceeds directly to block 712.

[0098] 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 can be determined in any suitable manner.

[0099] In some situations, 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 and the current primitive in the current primitive block). The "bounding box" for a set of one or more primitives is the smallest bounding box or enclosing box in which all the 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 primitive can be the maximum and minimum x and y coordinates of the vertices that form the primitive in the set. In some situations, the resolution of the bounding box can be per-sample resolution (i.e., the resolution of the sampling grid) or per-tile resolution. For example, Figure 8 An example rendering space 800 divided into tiles of a 4×5 matrix is shown. If the primitives in the set form an object 802, then the bounding box for the primitives can be shown at 804 if at per-sample resolution. In contrast, the bounding box for the primitives can be shown at 806 if at per-tile resolution.

[0100] In some situations, with respect to one or more dimensions, 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. For example, in some situations, with respect to one or more dimensions, the distance can be equal to the difference between the sizes of the bounding boxes for the primitive blocks with and without the current primitive. Specifically, the distance can be equal to: the difference in the x dimension of the bounding box; the difference in the y dimension of the bounding box; the difference in the area of the bounding box (e.g., x*y); or a combination of one or more of these differences. For example, the distance can be represented by any combination of the listed difference metrics. For example, the distance can be represented by a single difference metric or multiple difference metrics. For example, in some situations, the distance can be represented by a triple (a, b, c), where a is the difference in the x dimension of the bounding box, b is the difference in the y dimension of the bounding box, and c is the difference in the area of the bounding box.

[0101] In other examples, in terms of one or more dimensions, the distance may be equal to the ratio between the sizes of the bounding boxes of the current primitive block with and without the current primitive. For example, the distance may be equal to: the ratio of the x dimension of the bounding box; the ratio of the y dimension of the bounding box; the ratio of the area of the bounding box (e.g., x * y); or a combination of one or more of these ratios. For example, the distance may be represented by a single ratio measure or multiple ratio measures. For example, in some situations, the distance may be represented by a triple (a, b, c), where a is the ratio of the x dimension of the bounding box, b is the ratio of the y dimension of the bounding box, and c is the ratio of the area of the bounding box.

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

[0103] In other situations, instead of determining the distance based on the bounding boxes of the current primitive block with and without the current primitive, the distance may be determined based on the order in which the tile blocks are rendered. The tile block rendering order may not be fixed (e.g., it may be dynamically selected), but if it is fixed or at least estimable, then the tile block rendering order can be used to determine how 'close' the current primitive is to the current primitive block. Specifically, the tile block rendering order can be used to estimate how long it will take after processing the tile blocks related to the current primitive block and before processing the current primitive. Generally speaking, if the untransformed geometry data related to the current primitive and the untransformed geometry data for the current primitive block are transformed simultaneously, then based on the tile block rendering order, the more tile blocks the current primitive is from the tile blocks of the current primitive block, the lower the likelihood that the transformed geometry data related to the current primitive and the current primitive block will still be in the cache.

[0104] For example, Figure 9 An example rendering space 900 divided into a 4×5 matrix of tile blocks is shown, where the rendering order is shown by the arrow 902 (i.e., starting from the top row, rendering one row of tile blocks at a time and rendering each row from left to right). In this example, the primitives in the current primitive block form an object 904 that is located in the tile blocks in the first column and the first row, and the current primitive 906 is located in the tile block in the third row and the 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 tile blocks apart), but the distance based on the tile block rendering order between the current primitive 906 and the current primitive block 904 is much farther (e.g., 10 tile blocks apart).

[0105] Although this is a simple example where the primitive of the current primitive block falls within a single tile block and the current primitive also falls within a single tile block, the same principle can be applied in situations where the primitive of the current primitive block falls within multiple tile blocks and / or the current primitive falls within multiple tile blocks. For example, more generally, the bounding box of the current primitive and the bounding box for the current primitive block can be mapped to tile blocks in the rendering space. In some situations, the distance between the bounding boxes can be the distance (e.g., in terms of tile blocks) between the two closest tile blocks of the two bounding boxes (according to the tile block rendering order). For example, if the current primitive block is mapped to a 2×2 array of tile blocks at the upper left corner of the rendering space shown in Figure 9 and the current primitive is located in the tile block in the third column and the first row as shown in Figure 9 , then the distance will be 4 tile blocks. In other situations, the distance between the bounding box for the current primitive and the bounding box for the current primitive block can be determined as the distance between the centers of the two bounding boxes (e.g., in terms of tile blocks) according to the tile block rendering order.

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

[0107] 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, where 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 the maximum number (or near maximum number) of primitives or vertices) and includes primitives with spatially similar positions in the rendering space (e.g., they are close together). However, in many situations, fullness and spatial locality are competing criteria. Specifically, in many situations, in order for the primitive block to be full, the spatial distance between the primitives in the primitive block must increase such that the primitive block includes primitives that are far apart in the rendering space. Similarly, in many situations, in order to ensure that the spatial distance between the primitives is small, the primitive block becomes smaller. In addition to small primitive blocks (i.e., primitive blocks with a small number of primitives) not being able to fill SIMD channels, there are also additional items associated with each primitive block. Therefore, a balance needs to be found between the spatial distance between the primitives in the primitive block and the fullness of the primitive block.

[0108] The present inventor has recognized that a good balance can be achieved by adjusting the threshold based on the fullness of the current primitive block. Specifically, in some situations, if the fullness of the current primitive block is low, the distance threshold is high, and if the fullness of the current primitive block is high, the distance threshold is low. 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 to fill the primitive block, even when the current primitive is far from the primitives 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 the primitives already in the current primitive block. Thus, when the primitive block is fairly empty (e.g., includes 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 having the primitives be spatially close; and when the primitive block is fairly full (e.g., includes 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.

[0109] In some situations, one or more distance thresholds can be determined dynamically according to a formula based on the fullness of the current primitive block. For example, one or more distance thresholds can be inversely proportional to the fullness of the current primitive block. In other situations, there can be a predetermined set of one or more distance thresholds associated with certain ranges of fullness. For example, there can 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 can be a different number of sets of distance thresholds and / or the predetermined sets of distance thresholds can be matched with different ranges of fullness. In some situations, the predetermined sets of distance thresholds associated with different ranges can be stored in a lookup table.

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

[0111] The fullness of the current primitive block can be based on (i) the number of primitives in the current primitive block, and / or (ii) in the case where a primitive is formed by one or more vertices, the number of vertices in the current primitive block. For example, there can be a maximum number of primitives and / or a maximum number of vertices in the primitive block. The fullness of the primitive block can 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 the 'fullness' of the current primitive block can be determined in any suitable manner.

[0112] In the case where 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 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 method 700 is used to generate an untransformed primitive block, each untransformed primitive block can be associated with one or more transformed primitives and one or more transformed vertices. In the case of processing transformed primitives based on untransformed primitives, this is all the transformed primitives associated with the untransformed primitives in the untransformed primitive block. In the case of processing transformed primitives based on transformed primitives, this can be the transformed primitives associated with the untransformed primitives in the untransformed primitive block, where the untransformed primitives are explicitly associated with the untransformed primitive block. Similarly, the transformed primitive block can be associated with multiple transformed vertices. In these situations, the fullness can 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 can be restricted to limit its size when generating the corresponding transformed primitive block in the rasterization stage.

[0113] In cases where the distance comprises a single metric (e.g., a ratio of the area of a bounding box or a difference between the x - dimensions of a bounding box), there may be a single distance threshold. In these situations, 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, and otherwise not add it to the current primitive block. In cases where the distance comprises multiple metrics (e.g., a triple (a, b, c)), there may be a single distance threshold or multiple distance thresholds. For example, in some situations, multiple distance metrics may be combined in a certain way, and the combined metric may be compared to a single distance threshold. In other situations, there may be multiple distance thresholds for comparison with different distance metrics. For example, if the distance comprises a triple (a, b, c), where a is a ratio of the x - dimension of a bounding box, b is a ratio of the y - dimension of the bounding box, and c is a ratio of the area of the bounding box, then there may be three distance thresholds for comparison with one of the distance metrics. In these situations, the primitive block generator may be configured to determine not to add the current primitive to the current primitive block if more than a subset of the distance thresholds (e.g., only one distance threshold) is exceeded or only if all distance thresholds are exceeded.

[0114] If it is determined based on the comparison of the distance with one or more distance thresholds not to add the current primitive to the current primitive block, then method 700 proceeds to block 710. However, if it is determined based on the comparison of the distance with one or more distance thresholds to add the current primitive to the current primitive block, then method 700 proceeds directly to block 712.

[0115] 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 content 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 memory (e.g., memory 302 2 ). Thus, at the end of the clearing, the content of the current primitive block has been output (e.g., for the rasterization stage of the TBR) and the (new) current primitive block is empty. Once the current primitive block has been cleared, then method 700 proceeds to block 712.

[0116] At block 712, the primitive block generator adds the current primitive to the current primitive block. In the case where 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 that identifies the untransformed primitive associated with the current primitive. As described above, in the case where a primitive is defined by one or more vertices, the information identifying the primitive may include information identifying the vertices that form the primitive, which allows retrieval of the 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 that form the primitive. In some cases, the information identifying a particular vertex may be the index of the vertex sent from the application, which index points to the portion of the memory (e.g., vertex buffer) that stores the untransformed geometry data associated with the vertex. In the case where a transformed primitive is added to the primitive block based on the transformed primitive, in addition to adding the information identifying the untransformed primitive block associated with the current primitive, information identifying the particular transformed primitive may also be added. In the case where method 700 is used to generate a transformed primitive block, adding the current primitive to the current primitive block may include adding the transformed geometry data associated with the current primitive to the current primitive block.

[0117] In the case where block 712 is executed directly after block 710 or block 704, the current primitive block will be empty, such that the current primitive becomes the first primitive in the current primitive block. However, if block 712 is executed directly after block 708, then 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, method 700 proceeds to block 714.

[0118] 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 the primitive block. In these cases, the primitive block generator may determine that the current primitive block is full when 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 method 700 proceeds to block 716, where the primitive block is emptied (as described above with respect to block 710). However, if it is determined that the current primitive is not full, then method 700 proceeds to block 718.

[0119] At block 718, the primitive block generator determines whether there are any more primitives to process. If there is at least one additional primitive to process, then method 700 returns to block 702. However, if there are no more primitives to process (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 method 700 ends.

[0120] In other examples, in the case where a primitive is formed by one or more vertices, after determining at block 708 that the current primitive will not be added to the current primitive block based on a comparison between the distance between the current primitive and the current primitive block and one or more distance thresholds, the primitive block generator can 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 where the current primitive block is cleared. If the primitive block generator determines that the current primitive shares at least one vertex with a primitive in the current primitive block, then the primitive block generator can determine that the current primitive will be added to the current primitive block, despite not meeting the distance threshold, or can determine that the current primitive will be added to the current primitive block under certain conditions. For example, if the current primitive shares at least one vertex with a primitive in the current primitive block, then the distance can be compared to a different set of one or more distance thresholds or different criteria can 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, then the current primitive can 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 (e.g., less than a predetermined number of tiles).

[0121] In some situations, 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 situations, before executing block 704, the primitive block generator can determine whether the rendering state data for the current primitive is the same (or matches) as the rendering state data for the primitives in the current primitive block. 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, then the current primitive block can be cleared before 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 (or matches) as the rendering state data for the primitives in the current primitive block, then method 700 can proceed directly to block 704.

[0122] Although Figure 7Method 700 describes how to generate primitive blocks 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. However, 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, where 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 with the distance threshold indicates that the received primitive can 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.

[0123] Although in Figure 7 method 700, 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 emptied and then the primitive is added to the current primitive block), in other example methods, the current primitive may be added to multiple primitive blocks. For example, if the distance for the current primitive meets the distance threshold for being 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, and then the current primitive block may be emptied and the same primitive may be added to the (new) current primitive block after the emptying.

[0124] Now refer to Figure 10 , which illustrates an example implementation of primitive block generator 1000, which may be used to implement Figure 7 method 700. Figure 10 Primitive block generator 1000 of

[0125] 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 the 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 the rendering space (e.g., screen space). As described above, in the case 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 forming the primitive. The transformed position data for the primitive may have been generated by Figure 3 the transformation logic 308 of the system 300.

[0126] The distance is a measure or set of measures that describes how 'close' the current primitive (i.e., the primitive forming 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 determine the distance according to any one of the methods described in block 706 of method 700 referenced above Figure 7 . For example, the distance calculation logic 1008 may be configured to (i) determine the distance by comparing the bounding boxes of the current primitive block without the current primitive and the current primitive block with the current primitive; and / or (ii) determine the distance according to the tile block rendering order. For example, in some situations, 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 between the y dimensions of the bounding boxes; the difference or ratio between the areas of the bounding boxes; or any combination thereof. The distance may include a single measure (e.g., the ratio of the x dimension of the bounding box) or multiple measures (e.g., a triple (a, b, c), where a is the ratio of the x dimension of the bounding box; b is the ratio of the y dimension of the bounding box; and c is the ratio of the area of the bounding box).

[0127] 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 situations, a primitive block may have a maximum number of primitives and / or a maximum number of vertices. In these situations, the fullness determination logic 1010 can be configured to determine the fullness metric based on comparing, respectively, the number of primitives in the current primitive block and / or the number of vertices in the current primitive block with the maximum numbers of primitives and vertices. For example, the fullness metric can 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.

[0128] 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), which 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 sufficient primitive blocks and having primitive blocks that include closely spaced primitives can be achieved by adjusting the distance threshold used to determine whether a new primitive will be added to the current primitive block based on the fullness of the current primitive block. Specifically, the distance threshold is dynamically adjusted such that when the fullness of the current primitive block is low, primitives that are farther from the 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 the primitives in the current primitive block can be added to the current primitive block.

[0129] The set of distance thresholds for a particular fullness metric can be determined in any suitable manner. For example, the methods described above with respect to Figure 7Determine a set of distance thresholds for a particular fullness metric using any of the methods described in block 708 of method 700. As described above, in some situations, the set of distance thresholds for a particular fullness metric can be determined dynamically 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 situations, there can be a predetermined set of one or more distance thresholds associated with each of multiple ranges of the fullness metric. The distance threshold selection logic 1012 can then be configured to select a set of one or more distance thresholds from the predetermined set of one or more distance thresholds based on the fullness metric. For example, there can be a first set of one or more distance thresholds to use 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 to use 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 to use 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 to use when the fullness metric indicates that the current primitive block is at least three-quarters full. In cases where there is a predetermined set of one or more distance thresholds, the predetermined set of one or more distance thresholds can be stored in a lookup table 1016 or a similar structure.

[0130] The number of distance thresholds in the set can be based on the number of metrics used for distance and / or one or more other criteria. For example, in cases where the distance includes a single metric (e.g., the distance is equal to the ratio of the area of the bounding box), the set of distance thresholds can include a single distance threshold to compare with the single distance metric. In cases where the distance includes multiple metrics (e.g., the distance includes a triple (a, b, c), where a is the ratio of the x-dimension of the bounding box, b is the ratio of the y-dimension of the bounding box, and c is the ratio of the area of the bounding box), the set of distance thresholds can include one or more distance thresholds. For example, there can be a single distance threshold to compare with the combination of distance metrics, or there can be a distance threshold per distance metric to compare with the corresponding distance metric.

[0131] The comparison logic 1014 is configured to: determine whether a current primitive is to be added to a primitive block based on a comparison between a distance (calculated by the distance calculation logic 1008) and a distance threshold (generated by the distance threshold selection logic 1012); and output one or more control signals based on the determination to control the current primitive block. Specifically, if the comparison logic 1014 determines based on the comparison that the current primitive is to be added to the current primitive block, then the comparison logic 1014 can output one or more control signals that cause the current primitive to be added to the current primitive block. In some situations, causing the current primitive to be added to the primitive block can include causing information to identify the untransformed primitive that the current primitive is associated with the current primitive block. In other situations, causing the current primitive to be added to the primitive block can include causing the transformed geometric structure 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 can output one or more control signals that cause the current primitive block to be emptied (e.g., the content is output (e.g., written to memory) and then emptied) and then cause the current primitive to be added to the empty current primitive block.

[0132] Transformed Geometric Structure Data Cache

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

[0134] In, for example Figure 3In some graphics processing systems of the graphics processing system 300, the processing of the transformed geometric structure data for tiled blocks 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 situations, the hidden surface removal stage may be further divided into multiple sub-stages. The hidden surface removal stage and the texturing and shading stages typically both access the transformed geometric structure data associated with the tiled blocks being processed. Therefore, it may not be possible to safely remove the transformed primitive blocks associated with the tiled blocks until both stages have accessed the transformed primitive blocks. However, not all primitives associated with a particular tiled block may serve a purpose in all stages. For example, while hidden surface removal may be performed on all primitives associated with a tiled block, not all of those primitives may serve a purpose from the hidden surface removal stage to the texturing and shading stage (e.g., some primitives may be hidden). Therefore, there may be some transformed primitive blocks associated with the tiled blocks that can be reclaimed after the hidden surface removal stage (or a sub-stage of the hidden surface removal stage as described below) because all relevant primitives of the transformed primitive blocks are hidden, while other transformed primitive blocks associated with the tiled blocks cannot be reclaimed until the texturing and shading stage is complete.

[0135] In addition, in some graphics processing systems, it is possible to process the transformed geometric structure data for multiple tiled blocks simultaneously because multiple stages of the transformed geometric structure data processing may be pipelined (e.g., at any given time, the transformed geometric structure data associated with one tiled block may be processed at each of the stages) and / or there may be multiple parallel logics (e.g., pipelines) for processing the transformed geometric structure data.

[0136] Accordingly, the inventors have determined that an efficient mechanism for recording which transformed primitive blocks can be reclaimed is to record (by means of a counter) the number of tile blocks that require the transformed primitive blocks and are currently being processed in the rasterization stage, where a tile block can be considered to no longer require the transformed primitive blocks after any one of a plurality of stages of transformed geometry data processing. In other words, if the transformed primitive blocks are no longer required after, for example, the first stage of transformed geometry data processing, then the transformed primitive blocks can be considered available for reclamation even if the tile blocks associated with the transformed primitive blocks are still being processed. This mechanism ensures that the transformed primitive blocks will not be reclaimed when it is known that they will be used again, but once they are no longer required, they are made available for reclamation. Making the transformed primitive blocks available for reclamation does not mean that another tile block will not require the transformed primitive blocks later, but rather that none of the tile blocks currently being processed in the rasterization stage requires the transformed primitive blocks and they can therefore be safely reclaimed. If a subsequent tile block needs to access a reclaimed transformed primitive block, then the untransformed geometry data for the primitive block will have to be extracted and transformed again.

[0137] Now refer to Figure 11 , which illustrates an example transformed geometry data cache 1100 that can be used to implement the transformed geometry data cache 315 of the system 300 of Figure 3 . The transformed geometry cache 1100 includes: a memory 1102 (such as a buffer) for temporarily storing transformed geometry data (such as 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 reclaimed; and control logic 1106 for storing the transformed primitive blocks in the memory 1102 and maintaining the counter such that it reflects the number of tile blocks that require access to the transformed primitive blocks and are currently being processed by the rasterization logic.

[0138] The memory 1102 is configured to temporarily store transformed geometry data for processing in the rasterization stage. In a graphics processing system such as the graphics processing system of Figure 3 , the untransformed geometry data is extracted and transformed based on the primitive blocks, and thus the transformed geometry data associated with the primitive blocks can be stored together as transformed primitive blocks. Figure 12Shows an example format for a transformed primitive block 1200. In this example, the transformed primitive block 1200 includes a header 1204, status data 1206, transformed vertex data 1207, and primitive index data 1208. Similar to Figure 4 the untransformed primitive block 402 1 、402 2 the header 404, the header 1204 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. Similar to Figure 4 the untransformed primitive block 402 1 、402 2 the status data 406, the status data 1206 includes information describing how the primitives in the primitive block will be rendered. The status data can be described as identifying a recipe for rendering the primitives described in the primitive block. For example, the status data may contain, but is not limited to, information identifying a depth comparison mode, a blending state, a texture state, and / or a primitive type.

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

[0140] Similar to Figure 4 the untransformed primitive block 402 1 、402 2 the primitive index data 408, the primitive index data 1208 includes a set of indices identifying the vertices that form each primitive. For example, in the case where a primitive is a triangle formed by three vertices, the primitive index data 1208 may include information identifying the three vertices that form each primitive. However, while Figure 4 the indices in the primitive index data 408 are indices of vertices sent from the application, Figure 12 the indices in the primitive index data 1208 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.

[0141] As described above, each primitive block may be referred to (or associated with) by multiple tile blocks. In other words, the primitives of the primitive block may at least partially fall within multiple tile blocks. In some situations, the tiling engine 310 may be configured to record the number of tile blocks 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 302 2 For example, the number of tile blocks that refer to (or are associated with) a particular primitive block may be stored in, for example, the header portion of the primitive block, or the number of tile blocks that refer to (or are associated with) a particular primitive block may be provided to the extraction logic 312 as sideband data. In these situations, the memory 1102 (e.g., 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 tile blocks that refer to (or are associated with) the primitive block.

[0142] For example, Figure 13 An example illustrating the division of the memory 1102 into three sub-frames 1302, 1304, and 1306 of the memory is shown. In this example, the first sub-frame 1302 is used to store transformed primitive blocks that are associated with only 1 tile block; the second sub-frame 1304 is used to store transformed primitive blocks that are associated with 2 to 4 tile blocks; and the third sub-frame 1306 is used to store transformed primitive blocks that are associated with more than 4 tile blocks. It will be apparent to those skilled in the art that this is only an example and there may be a different number of sub-memory blocks and / or they may be associated with different ranges of tile blocks. Since the transformed primitive blocks associated with a smaller number of tile blocks are likely to be available for reclamation soon, a larger block of 'idle' memory can be obtained more quickly than if the transformed primitive blocks associated with a small number of tile blocks (e.g., 1 tile block) were not stored together. This may be advantageous in situations where the memory 1102 is divided into pages and only an entire page can be released 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.

[0143] 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., buffer) and a counter indicating whether the transformed primitive block can be reclaimed from the memory 1102 (e.g., buffer). As Figure 11As shown, in some situations, the information identifying the location of the transformed primitive block can be the address of the transformed primitive block in 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 memory. For example, in other situations, the information identifying the location of the transformed primitive block in memory can be an index, which can be used to generate the address of the transformed primitive block in memory. When the transformed primitive block is written to memory (e.g., by the transformation logic 313), an entry in the lookup table can be added to the lookup table.

[0144] In some situations, when the memory 1102 does not include the transformed primitive block, the lookup table may not have an entry for the transformed primitive block. For example, when the transformed primitive block is retrieved from the memory 1102 (e.g., a buffer), the corresponding entry in the lookup table 1104 can be removed. This allows determination of whether the cache 1100 includes a specific transformed primitive block based on the lookup table.

[0145] A counter for the untransformed primitive block is used to indicate whether the transformed primitive block can be retrieved from the cache (i.e., from the memory 1102). In some situations, 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 retrieved (i.e., when none of the tile blocks 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 retrieved (i.e., when at least one of the tile blocks currently being processed in the rasterization stage needs to access the transformed primitive block).

[0146] 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 retrieved from the memory 1102 and which cannot be retrieved therefrom. Specifically, the control logic 1106 is configured to maintain the counter in the lookup table 1104 (e.g., dynamically adjust the counter) such that it indicates how many tile blocks currently being processed by the rasterization logic 306 need to access the corresponding transformed primitive blocks. When the counter indicates that none of the tile blocks currently being processed by the rasterization logic 306 need to access a particular transformed primitive block, the transformed primitive block can be retrieved. In these examples, when any of the stages in the processing of the transformed geometry data (e.g., after the HSR stage or after the texturing / shading stage) indicates that the transformed geometry blocks are no longer needed, the tile blocks currently being processed by the rasterization logic can be considered to no longer need to access the primitives. 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 one of the transformed primitive blocks to retrieve based on the counter. The operation of the control logic 1106 will be described in more detail by way of Figure 14 method 1400.

[0147] Now refer to Figure 14 , which illustrates method 1400, which can be executed by the control logic 1106 to manage the cache 1100. Method 1400 begins at block 1402, where the control logic 1106 stores a plurality of transformed primitive blocks in the memory 1102 (e.g., buffer) of the cache 1100. When each of the transformed primitive blocks is stored in the memory, the lookup table 1104 may have been updated to include information (e.g., address) indicating the location of the transformed primitive blocks in the memory 1102 (e.g., buffer).

[0148] At block 1404, control logic 1106 maintains (e.g., dynamically updates) a counter (e.g., a counter in lookup table 1104) for each transformed primitive block stored in cache 1100 (e.g., memory 1102 (e.g., buffer)) to indicate the number of tile blocks of the transformed primitive block that are currently being processed by rasterization logic 306 and that require the transformed primitive block. Control logic 1106 may be configured to adjust (e.g., increment) the counter for the transformed primitive block when control logic 1106 detects that the rasterization logic has started processing a new tile block associated with the primitive block, to indicate that an additional tile block is being processed by the rasterization logic that requires access to the transformed primitive block. Control logic 1106 may also be configured to adjust (e.g., decrement) the counter for the transformed primitive block when control logic 1106 detects from any of the plurality of stages that a tile block associated with the transformed primitive block no longer requires the transformed primitive block, to indicate that one fewer tile block 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 can be marked for earlier reclamation. Specifically, for a transformed primitive block to be marked for reclamation, the processing of rasterization of the tile blocks associated with the transformed primitive block need not be complete. This allows for more efficient use of cache 1100 memory 1102.

[0149] A transformed primitive block is considered to be associated with a tile block if at least one primitive in the transformed primitive block at least partially falls within the bounds of the tile block. As described above with respect to Figure 3 the tile module determines which primitives (when transformed) at least partially fall within the bounds of the tile block and generates a display list for each tile block that identifies the primitives that at least partially fall within the bounds of the tile block and the primitive blocks in which the primitives are located. When the rasterization phase begins processing a tile block, the extraction module extracts the display list for the tile block. The extraction module then determines whether cache 1100 includes transformed geometry data (e.g., a transformed primitive block) for the untransformed primitive block identified in the untransformed display list (e.g., by sending a query to control logic 1106). Then, if 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 transformation logic 313 for transformation. The transformed geometry data for the untransformed primitive block is then stored in the cache.

[0150] Thus, in some situations, the control logic may be configured to (i) detect that the rasterization logic 306 has started processing a new tile block associated with a particular transformed primitive block 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 the control logic 1106 may detect that the rasterization logic 306 has started processing a new tile block associated with a particular transformed primitive block in another way.

[0151] As described above, the control logic 1106 may be configured to adjust a counter for a transformed primitive block (e.g., decrement it) to indicate that there is one less tile block being processed by the rasterization logic that needs to access the transformed primitive block when any of the multiple stages indicates that a tile block associated with the transformed primitive block no longer needs the transformed primitive block. For example, in a case 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 a counter for the transformed primitive block (e.g., decrement it) when either stage (e.g., the HSR stage or the texturing / shading stage) indicates that a tile block no longer needs the transformed primitive block to indicate that there is one less tile block being processed by the rasterization logic that needs to access the transformed primitive block.

[0152] 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 block no longer needs to access a transformed primitive block when the HSR stage does not output any fragments related to the primitives in the transformed primitive block. In some situations, 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 it has received primitive fragments from a transformed primitive block but outputs none, then the HSR stage may notify the control logic 1106. For example, the HSR stage may receive primitive fragments for processing as a data stream, and there may be markers inserted in the data stream to separate primitives and to 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 and no primitive fragments in between.

[0153] In some situations, the HSR phase may include two sub - phases - a first sub - phase that performs depth testing on primitive fragments in a tiled block and a second sub - phase in which the primitive fragments that pass the depth testing are stored in a tag buffer. For example, Figure 15 illustrates an example HSR logic 1502 (which can be used to implement Figure 3 the HSR logic 314), the example HSR logic includes depth - testing logic 1504 and a tag buffer 1506. The depth - testing logic 1504 receives primitive fragments and compares the depth value (e.g., Z - value or Z - coordinate) of the primitive fragment with the corresponding depth value in the depth buffer for the tiled block. Specifically, the depth buffer stores the 'best' depth value (e.g., the depth value closest to the screen) for each sample of the tiled block. If the received primitive fragment has a 'worse' depth value than the corresponding depth value in the depth buffer (e.g., a depth value indicating it is farther from the screen), then the primitive fragment will be hidden by another primitive and thus the primitive fragment 'fails' the depth test and is not output to the tag buffer. However, if the received primitive fragment has a 'better' depth value than the corresponding depth value in the depth buffer (i.e., a depth value indicating 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 the presence of the new 'best' depth value.

[0154] The tag buffer 1506 receives the primitive fragments that have passed the depth - testing phase, and for each received primitive fragment, the tag buffer 1506 is updated to identify the received primitive fragment as the primitive fragment that is visible at its sample location. For example, if the tag buffer 1506 receives primitive fragment x at sample location a, then the tag buffer 1506 stores information indicating that primitive fragment x is visible at sample location a. If the tag buffer 1506 subsequently receives primitive fragment y at sample location a, then the tag buffer updates the information for sample location a to indicate that it is actually the visible primitive fragment y. Thus, in a simple situation where all primitives are opaque, after the depth - testing logic 1504 has processed all primitives in the tiled block, the tag buffer 1506 includes the identification of the primitive fragments that are visible at each sample location. At this point, the tag buffer 1506 is emptied into 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.

[0155] Thus, it is possible for a primitive (primitive fragment) to fail in the depth test sub-stage or the stencil buffer sub-stage. Specifically, the primitive may fail the depth test and thus not be output by the depth test logic 1504, or it may pass the depth test because it has the 'best' depth when the depth test is performed, but a better depth may occur on the primitive fragment at the same sample location and thus the primitive is overwritten in the stencil buffer 1506 and thus never output from the stencil buffer 1506. In these situations, in addition to updating the counter for the transformed primitive block in the cache based on the output of the HSR stage, the efficiency of the transformed geometry cache 1100 can be further improved by updating the counter for the transformed primitive block based on the output of the stencil buffer stage. This will allow the transformed primitive block that fails in the depth test or stencil buffer stage and is thus not further needed by the HSR logic 1502 or the texturing / shading logic 1508 to meet the condition for earlier reclamation.

[0156] In these situations, the depth test logic 1504 can be configured to notify the control logic 1106 when it detects that a primitive block fails the depth test stage. If none of the primitives of the primitive block that fall within the processed tile block 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 fall within the processed tile block are visible, then the primitive block will fail 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 can update the counter associated with the primitive block (e.g., decrement it) to indicate that one less tile block is currently being processed by the rasterization logic, and that one less tile block needs to access the corresponding transformed primitive block.

[0157] Similarly, the tag buffer 1506 can be configured to notify the control logic 1106 when it detects that a primitive block fails at the tag buffer stage. A primitive block is considered to fail at 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., the texturing / shading logic 1508). To be able to determine when a primitive block fails at the tag buffer stage, the tag buffer 1506 needs to have a mechanism for tracking which primitive fragments have been received since an entry in the tag buffer itself can be overwritten. Thus, in some situations, the tag buffer 1506 can have a look-up table or similar structure that has an entry for each primitive block that indicates whether the primitive block has received primitive fragments for the 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., the texturing / shading logic 1508), the contents of the tag buffer 1506 are compared with the look-up table, and if there are any primitive blocks for which primitive fragments have been received but the primitive fragments associated with the primitive block are not output, then the tag buffer 1506 notifies the control logic 1106 that those primitive blocks have failed at the tag buffer stage and are thus no longer needed. The notification can take any suitable form. For example, the notification can take the form of a control signal.

[0158] 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 tiled blocks are then stored in a memory (e.g., a frame buffer). Thus, the control logic 1106 can be configured to determine that a tiled block associated with a 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 finished processing the primitives of the primitive block. For example, when the texturing / shading logic has finished processing the primitive fragments of a primitive block, the texturing / shading logic can notify the control logic 1106. In response to receiving this notification, the control logic 1106 can update a counter for the primitive block (e.g., decrement it) to indicate that there is one less tiled block currently being processed by the rasterization logic that needs to access the transformed primitive block. In other situations, the control logic 1106 can be configured to determine that a tiled block associated with a primitive block no longer needs to access the corresponding transformed primitive block once the texturing / shading stage has accessed the transformed primitive block (and extracted all relevant transformed geometry data). In this way, the transformed primitive block can become eligible for earlier reclamation from the cache 1100, thereby improving the efficiency of the cache 1100.

[0159] In a situation where there may be multiple 'running' (i.e., being processed by the rasterization logic) tile blocks in the rasterization logic 306 at any given point in time, it is possible for the counter for the primitive block to be updated multiple times (e.g., incremented) to indicate the existence of additional 'running' tile blocks 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 is one less 'running' tile block that needs to access the corresponding transformed primitive block. For example, the rasterization logic 306 may start processing the first tile block associated with a particular primitive block, causing the control logic to increment the counter to 1 for that primitive block, and before the control logic 1106 has determined that the first tile block no longer needs to access the transformed primitive block, the rasterization logic 306 may start processing the second tile block also associated with the particular primitive block, causing the control logic to increment the counter to 2 for that primitive block. Thus, when the control logic detects that the first tile block no longer needs to access the transformed primitive block (e.g., because it failed the depth test phase, it failed the stencil buffer phase, or its texturing / shading is complete), the transformed primitive block does not become eligible for reclamation because there is still one running tile block that needs to access the transformed primitive block. Therefore, updating the counter (e.g., decrementing) to indicate that there is one less tile block currently being processed by the rasterization logic 306 that needs to access the transformed primitive block may not automatically make the transformed primitive block eligible for reclamation.

[0160] Returning to Figure 14 Method 1400, 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. The cache may be determined to be full if there is enough free memory in the cache to store the new transformed primitive block. If it is determined that the cache is full, then method 1400 proceeds to block 1410. However, if it is determined that the cache is not full, then method 1400 proceeds directly to block 1414.

[0161] At block 1410, one of the transformed primitive blocks stored in 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 tile blocks that need to access the transformed primitive block and are currently being processed (e.g., 'in flight') by rasterization logic 306. Generally, it is not safe to evict a transformed primitive block from cache 1100 unless there are no tile blocks that need to access the transformed primitive block and are currently being processed by rasterization logic. Thus, in some situations, one of the transformed primitive blocks associated with a counter that indicates there are no tile blocks that need to access the transformed primitive block and are currently being processed by rasterization logic is selected for eviction. As described above, in some situations, the counter will have a zero value when there are no tile blocks that need to access the corresponding transformed primitive block and are currently being processed by rasterization logic. In these situations, one of the transformed primitive blocks in the cache with a counter can be selected for eviction, where the counter has a zero value.

[0162] When there are more than one transformed primitive blocks with counters (e.g., counters with zero values) that indicate there are no tile blocks that need to access the transformed primitive block and are currently being processed, one of those transformed primitive blocks can be selected for eviction in any suitable manner. For example, one of those transformed primitive blocks can be randomly selected for eviction.

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

[0164] If there is no associated counter for it indicating that there is no transformed primitive block of a tile block that is currently being processed by the rasterization logic and needs to access the transformed primitive block, then the control logic 1106 can wait until one of the adjustment counters is adjusted to indicate that there is no tile block of the corresponding transformed primitive block that is currently being processed by the rasterization logic and needs to access it (e.g., until the counter is set to zero). Alternatively, in a situation with a tag buffer, where emptying the tag buffer causes the tag buffer to notify the control logic 1106 that the primitive block is disqualified at the tag buffer stage, the control logic 1106 can be configured to cause the tag buffer to be emptied. In some situations, the control logic 1106 can initiate the emptying 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 the tag buffer to be refreshed. However, when the flag reaches the tag buffer, it may already have been emptied, so before performing the refresh, the tag buffer can first check whether the cache 1100 is still full. If the cache is still not full, then the tag buffer may not be emptied. However, if the cache is still full, then the tag buffer can be emptied. Although this may cause the tag buffer to be emptied before the HSR processing of the entire tile block is completed, this generally will not cause problems for downstream components because the downstream components (e.g., the texturing / shading logic) will be able to figure out which primitives are visible. This may only cause the downstream components to perform operations (e.g., texturing and shading) on primitives that are not visible and that would have been culled at the tag buffer stage if the tag buffer had not been emptied previously.

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

[0166] Figure 16 A computer system is shown where the graphics processing system, primitive block generator, and / or cache described herein can 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 can be implemented on the CPU 1602. The components of the computer system can communicate with each other via a communication bus 1622.

[0167] Figure 1 and 2 The graphics processing systems 100, 200, 300, primitive block generators 1000, and caches 1100 of 3, 10, and 11 are shown as including a plurality of functional blocks. This is merely illustrative and is not intended to define a strict partitioning between the different logic elements of such entities. Each functional block may be provided in any suitable manner. It should be understood that the 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 merely represent logical values that conveniently describe the processing performed by the graphics processing system, primitive block generator, or cache between its inputs and outputs.

[0168] The graphics processing systems, primitive block generators, and caches described herein may be embodied in hardware on an integrated circuit. The graphics processing systems described herein may be configured to perform any of the methods described herein. Generally, any of the functions, methods, techniques, or components described above may be implemented in software, firmware, hardware (e.g., fixed logic circuitry), or any combination thereof. The terms "module", "functionality", "component", "element", "unit", "block", and "logic" may be used herein to generically 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 program code that, when executed on a processor, performs a specified task. The algorithms and methods described herein may be executed by one or more processors executing code that causes the processors to perform the algorithm / method. Examples of computer-readable storage media include random access memory (RAM), read-only memory (ROM), optical discs, flash memory, hard disk storage, and other memory devices that may use magnetic, optical, and other technologies to store instructions or other data and that may be accessed by a machine.

[0169] 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, bytecode, code defining an integrated circuit (e.g., a hardware description language or netlist), and code expressed in a programming language such as C, Java, or OpenCL. Executable code may be, for example, any kind of software, firmware, script, module, or library that, when properly executed, processed, interpreted, or 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.

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

[0171] The present invention also aims to include software that defines the hardware configuration as described herein, such as hardware description language (HDL) software, for designing integrated circuits or for configuring programmable chips to perform the desired functions. That is, a computer-readable storage medium can be provided, encoded thereon with computer-readable program code in the form of an integrated circuit definition data set, which, 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 including any of the devices described herein. The integrated circuit definition data set can be, for example, an integrated circuit description.

[0172] Therefore, a method of manufacturing a graphics processing system, primitive block generator, or cache as described herein at an integrated circuit manufacturing system can be provided. Additionally, an integrated circuit definition data set can be provided that, when processed in an integrated circuit manufacturing system, enables the method of manufacturing a graphics processing system, primitive block generator, or cache as described herein to be executed.

[0173] The integrated circuit definition data set can be in the form of computer code, such as a netlist, code for configuring programmable chips, a hardware description language defining hardware suitable for manufacturing 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 (e.g., RTL) that logically defines hardware suitable for manufacturing in an integrated circuit can 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 the manufacturing definition of the integrated circuit defined by the representation. As is typically the case where software is executed at a computer system to define the state of a machine, one or more intermediate user steps (e.g., providing commands, variables, etc.) may be required to configure the computer system to generate a manufacturing definition of an integrated circuit to execute code that defines the integrated circuit to generate the manufacturing definition of the integrated circuit.

[0174] Now with regard toFigure 17 Describes an example of processing an integrated circuit definition dataset at an integrated circuit manufacturing system to configure the system to manufacture a graphics processing system, primitive block generator, or cache as described herein.

[0175] Figure 17 Shows an example of an integrated circuit (IC) manufacturing system 1702 that is configured to manufacture a graphics processing system, primitive block generator, or cache as described in any of the examples herein. 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 dataset (e.g., defining a graphics processing system, primitive block generator, or cache as described in any of the examples herein), process the IC definition dataset, and generate an IC according to the IC definition dataset (e.g., which embodies a graphics processing system, primitive block generator, or cache as described in any of the examples herein). The processing of the IC definition dataset configures the IC manufacturing system 1702 to manufacture an integrated circuit that embodies a graphics processing system, primitive block generator, or cache as described in any of the examples herein.

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

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

[0178] The different processes performed by the IC manufacturing system 1702 can all be implemented at one location, e.g., by one party. Alternatively, the IC manufacturing system 1702 can be a distributed system such that some processes can be performed at different locations and by different parties. For example, some of the following stages can 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 the circuit to be generated, (ii) generating a circuit layout based on the gate-level representation, (iii) forming a mask according to the circuit layout, and (iv) manufacturing an integrated circuit using the mask.

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

[0180] In some embodiments, when processed in an integrated circuit manufacturing system, the integrated circuit manufacturing definition data set can cause the integrated circuit manufacturing system to generate a device as described herein. For example, through the integrated circuit manufacturing definition data set, the configuration of the integrated circuit manufacturing system in the manner described above Figure 17 can manufacture a device as described herein.

[0181] In some examples, the integrated circuit definition data set can include software that runs on the hardware defined at the data set, or software that runs in combination with the hardware defined at the data set. In the Figure 17 example shown, the IC generation system can be further configured by the integrated circuit definition data set to load firmware onto the integrated circuit according to program code defined at the integrated circuit definition data set when manufacturing the integrated circuit, or otherwise provide program code for use with the integrated circuit.

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

[0183] The applicant hereby independently discloses each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the general knowledge of a person skilled in the art from the whole of this specification, regardless of whether such features or combinations of features solve any of the problems disclosed herein. Various modifications within the scope of the present invention will be apparent to those skilled in the art in light of the foregoing description.

Claims

1. A method for generating an untransformed primitive block at a primitive block generator in a graphics processing system, the primitive block generator including a data storage area for storing the current untransformed primitive block, wherein transformed primitives can be associated with the current untransformed primitive block, the method comprises: determining one or more distance metrics that indicate the distance between the spatial positions of a set of one or more transformed primitives in a rendering space and the spatial positions of the transformed primitives associated with the current untransformed primitive block in the rendering space; determining a fullness metric based on at least one of: (i) the number of transformed primitives associated with the current untransformed primitive block compared to a maximum primitive number; (ii) wherein each transformed primitive is defined by one or more transformed vertices, the number of transformed vertices associated with the current untransformed primitive block compared to a maximum vertex number; dynamically selecting a set of one or more distance thresholds based on the fullness metric, the set of one or more distance thresholds including a distance threshold for each of the one or more distance metrics; determining whether to associate the set of one or more transformed primitives with the current untransformed primitive block based on a comparison of each of the one or more distance metrics with the corresponding distance threshold in the set of one or more distance thresholds; and in response to determining that the set of one or more transformed primitives will be associated with the current untransformed primitive block, associating the set of one or more transformed primitives with the current untransformed primitive block by adding information identifying the untransformed geometric structure data from which the set of one or more transformed primitives is generated to the current untransformed primitive block.

2. The method according to claim 1, wherein, the set of one or more transformed primitives includes a plurality of transformed primitives generated from the same untransformed geometric structure data.

3. The method according to claim 1, wherein, the set of one or more transformed primitives includes a single transformed primitive among a plurality of transformed primitives generated from the same untransformed geometric structure data.

4. The method according to claim 3, wherein, associating the set of one or more transformed primitives with the untransformed primitive block further includes: adding information identifying the single transformed primitive among the plurality of transformed primitives to the untransformed primitive block.

5. The method according to any one of claims 1 to 3, wherein, selecting the set of one or more distance thresholds based on the fullness metric includes: selecting a first set of one or more distance thresholds when the fullness metric indicates a first fullness level, and selecting a second different set of one or more distance thresholds when the fullness metric indicates a second different fullness level.

6. The method according to any one of claims 1-3, wherein, There are multiple predetermined sets of one or more distance thresholds each associated with a different range of a full-scale level, and selecting a set of one or more distance thresholds based on the full-scale metric includes: selecting a predetermined set of one or more distance thresholds from the multiple predetermined sets of one or more distance thresholds that is associated with the full-scale level indicated by the full-scale metric.

7. The method according to claim 6, wherein, the multiple predetermined sets of one or more distance thresholds include a first predetermined set of one or more distance thresholds for when the full-scale metric indicates a full-scale level less than one-quarter full, a second predetermined set of one or more distance thresholds for when the full-scale metric indicates a full-scale level of at least one-quarter full and less than one-half full, a third predetermined set of one or more distance thresholds for when the full-scale metric indicates a full-scale level of 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 full-scale metric indicates a full-scale level of at least three-quarters full.

8. The method according to any one of claims 1-3, wherein, if at least one of the one or more distance metrics exceeds the corresponding distance threshold in the set of one or more distance thresholds, it is determined that the set of one or more transformed primitives is not associated with the current untransformed primitive block.

9. The method according to any one of claims 1-3, wherein, it is determined that the set of one or more transformed primitives is not associated with the current untransformed primitive block only if each of the one or more distance metrics exceeds the corresponding distance threshold of the set of one or more distance thresholds.

10. The method according to any one of claims 1-3, wherein, at least one of the one or more distance metrics is based on a first bounding box and a second bounding box, the first bounding box enclosing the transformed primitive associated with the current untransformed primitive block, and the second bounding box enclosing the transformed primitive associated with the current untransformed primitive block and the set of one or more transformed primitives.

11. The method according to claim 10, wherein, at least one of the one or more distance metrics is based on at least one of the following: (i) the ratio of a first dimension of the second bounding box to a first dimension of the first bounding box; (ii) the ratio of a second dimension of the second bounding box to a second dimension of the first bounding box; and (iii) the ratio of the area of the second bounding box to the area of the first bounding box.

12. The method according to claim 10, wherein, the rendering space is divided into a plurality of tile blocks, and each of the first bounding box and the second bounding box has a per-tile-block resolution.

13. The method according to any one of claims 1-3, wherein, the rendering space is divided into a plurality of tile blocks, and at least one of the one or more distance metrics is based on the rendering order of the plurality of tile blocks.

14. The method according to any one of claims 1 - 3, further comprises: after associating the current transformed primitive with the current untransformed primitive block, determining whether a fullness criterion is met; and in response to determining that the fullness criterion is met, outputting the current untransformed primitive block.

15. The method according to any one of claims 1 - 3, further comprises: if it is determined that the set of one or more transformed primitives is not associated with the current untransformed primitive block, outputting the current untransformed primitive block and associating the set of one or more transformed primitives with a new current untransformed primitive block.

16. A method for generating a rendering output in a graphics processing system, the method comprises: in a geometry processing stage: converting untransformed geometry data into a plurality of transformed primitives, the plurality of transformed primitives including a plurality of sets of transformed primitives, each set of transformed primitives being generated from the same portion of the untransformed geometry data; and generating untransformed primitive blocks based on the plurality of transformed primitives by performing the method according to claim 1 on each set of transformed primitives; and in a rasterization stage: generating transformed primitive blocks for one or more of the untransformed primitive blocks by transforming the untransformed geometry data identified in each of the one or more untransformed primitive blocks into transformed primitives and storing the transformed primitives in corresponding transformed primitive blocks, and generating a rendering output based on the transformed primitive blocks.

17. A primitive block generator for a graphics processing system, for generating untransformed primitive blocks, the primitive block generator comprises: a data storage area configured to store a current untransformed primitive block, wherein transformed primitives can be associated with the current untransformed primitive block; and block allocation logic, comprising: distance calculation logic configured to determine one or more distance metrics, the one or more distance metrics indicating the distance between the spatial position of a set of one or more transformed primitives in a rendering space and the spatial position of the transformed primitives associated with the current untransformed primitive block in the rendering space; fullness determination logic configured to determine a fullness metric based on at least one of the following: (i) the number of transformed primitives associated with the current untransformed primitive block compared to a maximum primitive number; (ii) wherein each transformed primitive is defined by one or more transformed vertices, the number of transformed vertices associated with the current untransformed primitive block compared to a maximum vertex number; distance threshold selection logic configured to dynamically select a set of one or more distance thresholds based on the fullness metric, the set of one or more distance thresholds including a distance threshold for each of the one or more distance metrics; comparison logic configured to: Determining whether to associate the set of one or more transformed primitives with the current untransformed primitive block based on a comparison of each of the one or more distance metrics with a corresponding distance threshold in the set of one or more distance thresholds; and In response to determining that the set of one or more transformed primitives is to be associated with the current untransformed primitive block, associating the set of one or more transformed primitives with the current untransformed primitive block by causing information identifying the untransformed geometric structure data from which the set of one or more transformed primitives is generated to be added to the current untransformed primitive block.

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

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

20. A computer-readable storage medium having stored thereon a computer-readable data set description of the primitive block generator according to claim 17, the computer-readable data set description, when processed in an integrated circuit manufacturing system, causing the integrated circuit manufacturing system to manufacture an integrated circuit embodying the primitive block generator.

Images