Graphical processing method, method of manufacturing a graphical processing system, and storage medium

Abstract

A graphics processing method, a method of manufacturing a graphics processing system, and a storage medium. A graphics processing system, the system comprising: a tiling unit configured to tile a first view of a scene into a plurality of tiles and to generate a list of primitives associated with each tile; a processing unit configured to identify, from the list, a first subset of the tiles that are respectively associated with at least a predetermined number of primitives; and a rendering unit configured to render each of the identified tiles into a render target.

Description

[0001] This application is a divisional application of the original patent application with application number 201710101958.3, application date of January 26, 2017, and invention title "Graphics Processing System and Graphics Processing Method". Technical Field

[0002] This invention relates to systems and methods for graphics processing. Background Technology

[0003] In 3D graphics processing systems, objects in a scene are represented by primitives, which are typically projected, scan-transformed, textured, and shaded during scene rendering. Primitives have simple geometry (usually a triangle) defined by the positions of one or more vertices (e.g., three vertices in the case of a triangle), and textures can be applied to this simple geometry. The rendering of a 3D scene processes primitives to form an image comprising an array of image pixels.

[0004] During scene rendering, the graphics processing unit (GPU) fetches texture data stored in memory to apply the textures to objects in the scene. This data transfer between the GPU and memory utilizes considerable memory bandwidth and consumes power. Furthermore, large textures require a significant amount of memory to be allocated to them, which can lead to memory shortages for other applications.

[0005] An example of a large texture is a shadow map, used to add shadows to a scene. The basic principle of a shadow map is to render the scene as seen from the viewpoint of a light source (such as the sun) and store the depth of each visible surface (i.e., each surface illuminated by the light source). Next, the regular scene (from the camera's viewpoint) is rendered, and the depth of each drawn point is compared to the stored depth to determine from the light source's viewpoint whether the drawn point is in front of or behind the stored depth. If the point's depth is behind an illuminated surface, then the point is in shadow. Otherwise, it is illuminated. Depth information is stored as a texture (i.e., as a shadow map), which requires a significant amount of memory, especially for high-resolution shadow maps. Generating and storing high-resolution shadow maps requires considerable processing power, a large amount of memory, and high memory bandwidth. Since data transfer between memory and the GPU is a significant cause of power consumption, reductions in this area will allow the GPU to operate at low power. Furthermore, any reduction in memory bandwidth usage and associated hardware optimizations can improve application performance.

[0006] Therefore, it is necessary to reduce memory and processing overhead in graphics processing systems. Summary of the Invention

[0007] According to a first aspect of the present invention, a graphics processing system is provided, the graphics processing system comprising: a tile-ization unit configured to tile a first view of a scene into a plurality of tiles and generate a list of primitives associated with each tile; a processing unit configured to identify, according to the list, a first subset of the tiles associated with at least a predetermined number of primitives; and a rendering unit configured to render each of the identified tiles as a rendering target.

[0008] The system may also include a memory and a memory management unit configured to allocate a portion of the memory to each identified tile.

[0009] The rendering unit can be configured to store the data obtained from the rendering of each identified tile in the portion of memory allocated for that tile.

[0010] The memory management unit can also be configured not to allocate a portion of memory for each tile that is not recognized by the processing unit among multiple tiles.

[0011] The rendering unit can also be configured to access memory locations associated with unrecognized tiles for subsequent rendering, and the memory management unit is further configured to return predefined values ​​in response to said access.

[0012] The rendering unit can also be configured not to render tiles that are not recognized by the processing unit.

[0013] The number of tiles identified in the first subset can be less than the number of tiles into which the scene is tiled.

[0014] The tiled unit can be configured to generate a list of elements associated with each tile by determining which elements are at least partially located within the tile.

[0015] The processing unit can be configured to identify a second subset of tiles associated with the portion of the scene visible in the second view. The rendering unit can be configured to render each tile identified in both the first and second subsets.

[0016] The processing unit can be configured to identify a second subset of tiles associated with portions of the scene visible in the second view. The memory management unit can be configured to allocate a portion of memory to each of the tiles identified in both the first and second subsets.

[0017] According to a second aspect of the present invention, a graphics processing system is provided, the graphics processing system comprising: a memory for storing data; a tileization unit configured to tile a first view of a scene into a plurality of tiles; a rendering unit configured to render each tile associated with at least a predetermined number of primitives and output rendering data obtained from the rendering of the tile; and a memory management unit configured to detect the rendering data output for each rendered tile and allocate a portion of memory for the rendered tile; and to store the rendering data for each rendered tile in the portion of memory allocated to the tile.

[0018] The memory management unit can also be configured not to allocate a portion of memory to each of the plurality of tiles that is not associated with at least a predetermined number of primitives.

[0019] The rendering unit can also be configured to access memory to read data associated with tiles that are not associated with at least a predetermined number of primitives for subsequent rendering, and the memory management unit is also configured to return a predefined value in response to the access.

[0020] The rendering unit can also be configured not to output data for tiles that are not associated with at least a predetermined number of primitives.

[0021] The system may also include a processing unit configured to identify a subset of tiles associated with portions of the scene visible in a second view, wherein a rendering unit may be configured to render each tile identified in the subset and associated with at least the predetermined number of primitives.

[0022] The rendering target can be a texture. The rendering data can be data used for the texture. A rendering unit can be configured to apply the texture to the scene in subsequent renderings of the scene. The texture can be applied to a second view of the scene, or a second view that differs from the first view. The texture can be a shadow map.

[0023] The predetermined quantity can be equal to or greater than 1.

[0024] According to a third aspect of the present invention, a graphics processing method is provided, the graphics processing method comprising: dividing a first view of a scene into a plurality of tiles; generating a list of primitives associated with each tile; identifying, according to the list, a first subset of the tiles that are associated with at least a predetermined number of primitives; and rendering each of the identified tiles as a rendering target.

[0025] The method may also include allocating a portion of the memory to each identified tile.

[0026] The method may further include storing the data obtained from rendering each identified tile in the portion of memory allocated for that tile.

[0027] The method may also include: not allocating a portion of memory for each unrecognized tile among multiple tiles.

[0028] The method may further include: accessing a memory location associated with an unrecognized tile for subsequent rendering, and returning a predefined value in response to the access.

[0029] The method may also include: not rendering unrecognized tiles.

[0030] The number of tiles identified in the first subset can be less than the number of tiles into which the scene is tiled.

[0031] Generating a list of elements associated with each tile may include determining which elements are at least partially located within the tile.

[0032] The method may further include: identifying a second subset of tiles associated with portions of the scene visible in a second view; and rendering each tile identified in both the first and second subsets.

[0033] The method may further include: identifying a second subset of tiles associated with portions of the scene visible in a second view; and allocating a portion of memory to each tile identified in both the first and second subsets.

[0034] According to a fourth aspect of the present invention, a graphics processing method is provided, the method comprising: dividing a first view tile of a scene into a plurality of tiles; rendering each tile associated with at least a predetermined number of primitives; and outputting rendering data obtained from the rendering of the tile; detecting the rendering data output for each rendered tile; allocating a portion of memory for the rendered tile; and storing the rendering data for each rendered tile in said portion of the memory allocated to the tile.

[0035] The method may further include: not allocating a portion of memory for each of the plurality of tiles that is not associated with at least a predetermined number of primitives.

[0036] The method may further include: for subsequent rendering, accessing memory to read data associated with tiles not associated with at least a predetermined number of primitives, and returning a predefined value in response to the access.

[0037] The method may also include: not outputting rendering data for tiles that are not associated with at least a predetermined number of primitives.

[0038] The method may further include: identifying a subset of tiles associated with portions of the scene visible in a second view, wherein the rendering step may include: rendering each tile identified in the subset and associated with at least the predetermined number of primitives.

[0039] The rendering target can be a texture. Rendering data can be data used for the texture. A rendering unit can be configured to apply the texture to the scene in subsequent renderings of the scene. The texture can be applied to a second view of the scene, different from the first view. The texture can be a shadow map.

[0040] The predetermined quantity can be equal to or greater than 1.

[0041] According to a fifth aspect of the present invention, a graphics processing system configured to perform the above-described method is provided.

[0042] The aforementioned graphics processing system can be implemented in hardware on an integrated circuit.

[0043] According to a sixth aspect of the present invention, a method for manufacturing the above-described graphics processing system in an integrated circuit manufacturing system is provided.

[0044] According to a seventh aspect of the present invention, an integrated circuit definition dataset is provided, which, when processed in an integrated circuit manufacturing system, configures the manufacturing system to manufacture the aforementioned graphics processing system.

[0045] According to an eighth aspect of the invention, a non-transitory computer-readable storage medium is provided, on which an integrated circuit definition dataset is stored, which, when processed in an integrated circuit manufacturing system, configures the manufacturing system to manufacture the aforementioned graphics processing system.

[0046] According to a ninth aspect of the present invention, an integrated circuit manufacturing system is provided, the system comprising: a non-transitory computer-readable storage medium storing thereon a computer-readable integrated circuit description describing a graphics processing system; a layout processing system configured to process the integrated circuit description to generate a circuit layout description of an integrated circuit specifically implementing the graphics processing system; and an integrated circuit generation system configured to manufacture the graphics processing system according to the circuit layout description, wherein the graphics processing system comprises: a tileization unit configured to tile a first view of a scene into a plurality of tiles and generate a list of primitives associated with each tile; a processing unit configured to identify, according to the list, a first subset of the tiles respectively associated with at least a predetermined number of primitives; and a rendering unit configured to render each of the identified tiles as a rendering target.

[0047] According to a tenth aspect of the invention, computer program code for performing any of the above methods is provided.

[0048] According to an eleventh aspect of the present invention, a non-transitory computer-readable storage medium is provided having computer-readable instructions stored thereon, which, when executed on a computer system, cause the computer system to perform any of the methods described above. Attached Figure Description

[0049] The invention will now be described by way of example with reference to the accompanying drawings. In the drawings:

[0050] Figure 1 A tile-based graphics system is shown;

[0051] Figure 2a Represents objects in a scene within a tile-based graphics system;

[0052] Figure 2b A top-down view of the scene is shown;

[0053] Figure 2c The scene is shown from the viewpoint of the light source;

[0054] Figure 2d A scene with shadows applied from the camera's viewpoint is shown;

[0055] Figure 3 This is a flowchart of the methods used to apply shadows to a scene;

[0056] Figure 4a This shows a top-down representation of another scenario;

[0057] Figure 4b The scene is shown from the viewpoint of the light source;

[0058] Figure 4c Showing the camera frustum as seen from the light source's viewpoint; and

[0059] Figure 5 This is a schematic diagram of an integrated circuit manufacturing system. Detailed Implementation

[0060] The following description is presented by way of example to enable those skilled in the art to implement and use the invention. The invention is not limited to the embodiments described herein, and various modifications to the disclosed embodiments will be readily apparent to those skilled in the art.

[0061] The following examples describe systems and methods for generating shadow maps and applying shadows to a scene using these maps. However, these systems and methods can be used in any situation where a scene is rendered as a texture.

[0062] As mentioned above, generating large textures such as shadow maps requires significant memory for storing the textures and high memory bandwidth for transferring the texture data to memory. High memory bandwidth is also required when the GPU retrieves the stored texture data to apply it to the scene. The following describes a tile-based graphics system capable of reducing these processing, memory, and memory bandwidth requirements. Broadly speaking, one way to achieve this is by subdividing the scene into multiple tiles and identifying specific subsets of tiles containing multiple primitives, and rendering only those tiles as textures. Unidentified tiles are ignored and not rendered. By rendering only specific subsets of tiles, memory and processing overhead can be reduced compared to rendering all tiles that constitute the entire scene. This is particularly effective for textures with large memory requirements but typically covering only a relatively small area of ​​the scene (e.g., shadow maps).

[0063] Figure 1 This is a schematic diagram illustrating a tile-based graphics system 100. The system 100 can be implemented on a device such as a smartphone, tablet, laptop, personal computer (PC), television, or any other suitable device for processing graphics data. The tile-based graphics system 100 is configured to, for example, receive data from an application, process the data, and provide output of the processed data. The system 100 includes a graphics processor 102 configured to process data. The graphics processor 102 can be implemented in hardware or software, or a combination thereof. For example, the graphics processor 102 can be implemented in fixed-function hardware, which includes circuitry configured to process data accordingly as described herein. For example, the processor 102 can be a graphics processing unit (GPU), or it can be implemented as a computer program running on a programmable device such as a GPU or a central processing unit (CPU).

[0064] The graphics processor 102 includes multiple functional blocks for processing data, wherein, Figure 1 The diagram shows some (but not all) functional blocks of the graphics processor 102. Specifically, the graphics processor 102 includes a tiled unit 106 and a rendering unit 108. The rendering unit 108 may include an image processor 114 and a texture processor 116.

[0065] The system 100 also includes a processing unit 104 configured to process data. The processing unit 104 may be implemented in hardware or software, or a combination thereof. For example, the processing unit 104 may be implemented in fixed-function hardware, which includes circuitry configured to process data accordingly as described herein. For example, the processor 104 may be a general-purpose central processing unit (CPU), or it may be implemented as a computer program running on a programmable device such as a GPU or a central processing unit (CPU).

[0066] The system 100 includes a memory 112 arranged to communicate with a graphics processor 102 and a processing unit 104. The memory 112 may include multiple memory blocks (not shown) for storing data. The system 100 may also include a memory management unit (MMU) 110 configured to manage the memory resources of the memory 112. The MMU 110 can perform virtual memory management and translate virtual memory addresses into physical addresses. The MMU 110 may be implemented as part of the processing unit 104 or as a separate hardware component or computer program. The graphics processor 102 may include a cache (not shown) that can be used to fetch and temporarily store data from the memory 112.

[0067] In operation, the graphics processor 102 is configured to receive graphics data, such as from an application currently running on the device implementing the system. The graphics data includes geometric data defining objects for display. The tileization unit 106 includes logic for implementing multiple functions within the graphics processor 102. For example, the tileization unit 106 receives geometric data and derives multiple primitives from the geometric data. The tileization unit 106 also tile-divides primitives into multiple tiles by classifying the primitives into a per-tile list. Some processing of the geometric data may or may not be performed by the graphics processor 102 before the tileization unit 106 receives the geometric data. Figure 1 (Executed in a function block not shown). Primitives represent geometric objects or other geometric shapes. Parameters describing the primitives are stored in memory 112. The stored parameters describe multiple primitives that may be located in multiple tiles. Primitives are typically polygons, such as triangles, but may have other forms, such as lines, points, or patches. The stored parameters indicate the position of the primitive (e.g., the position of the vertices forming the primitive in screen space coordinates). The parameter may also indicate other features of the object or geometry.

[0068] The tileization unit 106 tileizes the view of the scene into multiple screen-space tiles by classifying the primitives representing the scene into a list of tiles per tile. The tileization unit 106 determines which primitives exist within each screen-space tile and creates a list for each tile indicating which primitives exist within that tile. Primitives can exist in multiple tiles, and the primitives are indicated in the list of tiles used for those multiple tiles. Primitives existing in a single tile will only be listed in the list used for that tile.

[0069] The screen space is divided into multiple tiles. Tiles can be rectangular (including squares), but they can also be other shapes, such as triangles or hexagons. Tiles can be of various sizes; for example, a tile can be 32×32 pixels. In one example of an ultra-high resolution screen image, there are 3840×2160 pixels. Therefore, as an example, an ultra-high resolution image can be tiled into 8100 tiles (each consisting of 32×32 pixels). The screen space can correspond to the image or other rendering target used to display on the screen, such as texture data that will be stored in memory.

[0070] Figure 2a This is a simplified representation of screen space 202, comprising twenty-five tiles arranged in a 5x5 array, of a tile-based graphics system. Two objects exist within the shown screen space 202: a rectangular wall 204 and a sphere 206. Wall 204 and sphere 206 are composed of multiple primitives (not shown for clarity). It can be seen that wall 204 overlaps with six tiles of screen space 202: tiles with grid labels B3, B4, C3, C4, D3, and D4. Unless otherwise specified, the term "overlap" as used herein should be understood as meaning "at least partially overlapping." The primitives constituting wall 204 overlap with six tiles of screen space 202. It can be seen that sphere 206 overlaps with only one tile (grid label C2) of screen space 202. Therefore, the primitives constituting the sphere overlap with only one tile (C2) of screen space. Other objects will typically exist in the scene, but for clarity, these are not shown. Figures 2a to 2d Not shown in the image.

[0071] For each tile in screen space 202, the tileization unit 106 determines whether each primitive is at least partially located within the tile. That is, the tileization unit 106 determines whether at least a portion of the primitive is located within the viewable area of ​​the tile. This can be accomplished using various known techniques. In this way, the tileization unit 106 derives a display list for each tile (tiles A1 to E5), indicating primitives that are partially or completely located within the tile. The display list for a tile can be a list of reference markers for the memory locations of parameters for primitives that at least partially overlap with the tile. This saves duplication when primitives are in more than one tile. In the case of primitives in more than one tile, the display list for a tile can also copy primitive parameters, such that each tile list is a list of parameters, not a list of reference markers. These methods can also be combined, storing reference markers for some parameters and copying others. Figure 2aIn the example, it can be seen that the display list will indicate that for block C2, all the elements constituting sphere 206 will be located in that block. For each of blocks B3, B4, C3, C4, D3, and D4, the display list also indicates the elements constituting walls and at least partially located in each corresponding block. The remaining blocks (i.e., blocks A1 to A5, B1, B2, B5, C1, C2, C5, D1, D2, D5, and E1 to E5) will not have the elements listed for them.

[0072] The display list is provided from the tile rendering unit 106 to the memory 112 for storage. When the rendering unit 108 renders a tile, the rendering unit retrieves the display list for that tile from the memory 112 and uses the display list to determine which primitives at least partially overlap with the tile.

[0073] Rendering unit 108 may include image processor 114, which can process tiles to determine, for example, which primitives or portions of primitives require further processing by subsequent processing blocks (such as texture processor 116). For example, when rendering an image to be displayed, image processor 114 may determine which primitive portions are visible before texture processor 116 processes the tiles and remove primitive portions that do not affect the rendered image. To enable image processor 114 to process primitives within a tile, primitives (or parameters for those primitives) included in the tile's display list are read from memory 112 for processing the tile, such as determining whether primitives are visible.

[0074] Texture processor 116 processes tiles to apply texturing to objects visible within the tiles. Output from image processor 114 is provided to texture processor 116, indicating which primitives or portions of primitives will be needed to process the tiles. To enable texture processor 116 to process primitives within the tiles, parameters for the primitives indicated in the output from image processor 114 can be obtained directly from image processor 114 or from memory 112. Some or all of the parameters used by texture processor 116 to process the tiles may differ from those used by image processor 114 to process the same tiles. For example, parameters used by image processor 114 may relate to the location of primitives, while parameters used by texture processor 116 may additionally or alternatively relate to texture data to be applied to the primitives. Texture processor 116 reads parameters from memory 112 for use when processing the tiles, for example, to implement texturing. Parameters may include indications of the texture (or specific texture pixels from a texture) that texture processor 116 will apply to an object.

[0075] For example, before being output from graphics processor 102 to a display cache or another rendering target such as texture data in memory for display on the screen of a device implementing system 100, the output from texture processor 110 can be transferred to another processing block within graphics processor 102. Figure 1 (Not shown in the image).

[0076] Figure 1 The system can be used to direct information to scenarios (such as...) Figure 2a Adding effects, such as shadows and reflections, to a scene (e.g., a scene) can involve processing data within the scene in a certain way to generate those effects. One way to add shadows to a scene is, for example, by generating a shadow map and using that map to determine which areas of the scene should be in shadow. Steps 1 and 2 below generally describe how a shadow map is generated and used to apply shadows to a scene. Figure 2a A scene with a single light source is used as an example in the described steps.

[0077] Step 1 Renders the scene as seen from the light source's viewpoint to generate a shadow map.

[0078] Regular rendering of a render target such as a display cache outputs an image where pixel values ​​are colors. However, this render outputs an "image" where pixel values ​​are depth and are output to a texture. This render output is a shadow map. Regular rendering typically processes depth values ​​using a Z (or depth) cache before continuing to output color for each pixel in order to perform hidden surface removal. The processing of the shadow map can stop after the Z-cache is generated and output instead. At the end of the render, the Z-cache contains the depth (in this case, distance from the camera or light source) of the object found to be closest to the camera (or light source).

[0079] When primitives overlap (e.g., when sphere 206 overlaps with part of wall 204), a portion, not all, of the primitives is visible. This portion of a primitive is typically referred to as a "fragment." A fragment can be generated at each sample point (e.g., at each pixel) and therefore can have an (X, Y) position and depth. In the system for solving visibility in image processor 114, each fragment corresponds to a visible portion of an object. A shadow map can be written as a texture based on the position and depth of these visible fragments.

[0080] Figure 2b It shows Figure 2a This is a top-down view of the scene. As shown, the light source is located on a line 207 perpendicular to the plane of wall 204 and passing through the center of wall 204. The center of sphere 206 is located on line 207 and between the light source and wall 204. The light source can be a directional light source that projects parallel light rays onto the scene. Figure 2cThe scene is shown as viewed from a point of view of the light source. Visible segments in the scene indicate segments with incident light on them. Therefore, segments of the visible portion of the front of wall 204 (i.e., the portion of the wall not directly behind sphere 206) and the front half of sphere 206 have incident light on them. Depth values ​​for each location in screen space (e.g., for each pixel) are stored as a shadow map in memory 112. Depth values ​​for pixel locations that do not contain any objects can be stored with a background or default depth corresponding to "very far".

[0081] Step 2 Renders the scene as seen from the camera's viewpoint to produce the image to be displayed.

[0082] During the image rendering phase (e.g., during shading), the shadow map generated in step 1 is examined to determine whether a pixel is in shadow.

[0083] At some stage of rendering, a color can be assigned to each pixel. For example, a pixel can be identified as bright red (255,0,0) (according to the RGB color model) before considering whether it is in shadow. This can be the result of a regular texturing operation. The pixel's position on the screen is known because it is its depth in the scene from the Z-buffer: (x, y, d). The pixel position (x, y, d) is transformed from screen space to "light space" to find the position of the same point in the coordinate system used for rendering in step (1): (X, Y, D). The transformation can be a geometric calculation (matrix operation) based on the known relative position and orientation of the camera and the light. The light space coordinates (X, Y, D) indicate where the pixel is located and how far away it is from the light in the image rendered from the light's viewpoint. The shadow map at coordinates (X, Y) is read to retrieve the previously saved depth value (S). If the depth S is less than the depth D, this indicates the presence of something closer to the light that will cast a shadow on the pixel. Otherwise, the pixel is illuminated by the light. If a pixel is in shadow, the color assigned to that pixel can be modified accordingly. For example, the color (255,0,0) can become (25,0,0). Other modifications can be made to pixels in shadow; for example, a shadowed pixel can simply be assigned black (0,0,0).

[0084] In the example shown, Figure 2a The image shows the scene as seen from the camera's viewpoint. Figure 2b A view of the camera position is provided. Figure 2a In this scenario, pixels of the wall 204 that are directly behind the sphere 206 from the viewpoint of the light source will be in shadow. Furthermore, pixels that are visible in the scene from the viewpoint of the light source and that are behind the illuminated pixels of the sphere 206 will also be in shadow.

[0085] A scene can have multiple light sources, each casting different shadows. In this case, the scene is rendered from each light source (e.g., as described in step 1) to produce multiple shadow maps. When rendering the scene to be displayed, the shadows can be solved in a single step (step 2). Pixels are transformed to each light space (for each light source), and each shadow map is read to determine whether the pixel is illuminated by that particular light. The color of the pixel is then determined by appropriately mixing the object's color with the colors of the light from each source illuminating it.

[0086] Figure 3 The process for generating a shadow map (steps 300 to 308) and applying shadows to the scene at system 100 using the generated shadow map (step 310) is illustrated. The process described in steps 300 to 308 is not limited to rendering the scene as a texture for shadow mapping and can be used to render the scene as any suitable rendering target for other purposes.

[0087] In step 300, the scene viewed from the light source's viewpoint (as described in step 1 above) is tiled by the tiled unit 106 into multiple tiles. In the example shown, Figure 2c The scene, as seen from the light source's viewpoint, is tiled into twenty-five tiles.

[0088] In step 302, as described above, a display list is generated for each tile during tile generation and the display list is stored in memory 112. In the example shown, tiles W2 to W4, X2 to X4, and Y2 to Y4 will have the primitives listed for them, while tiles V1 to W1, W5, X1, X5, Y1, and Y5 to Z5 will not have the primitives listed for them.

[0089] Tile-based processing provides the opportunity to examine the contents of the display list before rendering each tile. The display list indicates which tiles do not have primitives, i.e., no shadow-casting objects. Therefore, it is possible to identify, without performing rendering, which tiles will have an empty shadow map (or contain values ​​indicating "very far").

[0090] In step 304, the list is analyzed to identify tiles with at least a predetermined number of primitives associated with them, such that only those tiles are rendered to generate the shadow map. In one example, the predetermined number could be 1. In this example, tiles that do not have any primitives associated with them (i.e., tiles for which there are no listed primitives) are identified so that these tiles are ignored in subsequent rendering for shadow map generation. This has several advantages, such as: i) reducing the amount of memory that needs to be allocated for the shadow map (as described further below); ii) reducing the number of tiles that need to be rendered, and thus increasing the speed of shadow map generation. In another example, the list of tiles can be analyzed to determine which tiles contain important shadow-cast primitives. Shadow-cast primitives can be determined to be unimportant if they only cover a single sample point in the tile, or if they only cover a small number of sample points in the tile, or if the aspect ratio of the area covered by the tile is higher than a threshold (e.g., such that very thin objects can be considered unimportant). Such primitives could, for example, represent very small objects, or at the edges of the tile, they could represent the edges of objects that are mainly present in other tiles. Tiles that do not contain any significant shadow-casting objects can be ignored. While ignoring potential shadow-casting objects can be seen as introducing errors into the shadow map, it must be remembered that shadow map resolution is typically limited, and objects that occupy only a small area of ​​the shadow map may cast poorly defined or visually inaccurate shadows into the rendered scene. Therefore, it is possible that omitting these objects from the shadow map rendering improves the visual quality of the rendered scene, and, with the aforementioned advantages, increases the efficiency of shadow map rendering. Similarly, omitting portions of primitives representing object edges removes shadow map data from areas already prone to inaccuracies and areas where measures to hide these inaccuracies may already be in place (i.e., at shadow edges). The number of sample points covered by primitives or groups of primitives can be calculated or estimated through geometric processing steps prior to the tileization unit 106, or may have already been performed as part of the tileization process in the tileization unit 106.

[0091] In another example, the predetermined number can be greater than 1 (e.g., 3). In this example, tiles containing relatively small and unimportant shadow-casting objects can be ignored in subsequent renderings used to generate the shadow map. This can further reduce the amount of memory that needs to be allocated and the number of tiles that need to be rendered to generate the shadow map.

[0092] In another example, a predetermined number of primitives greater than 1 can be combined with an analysis of the number of sample points covered by those primitives, allowing the importance of a shadow-projected object within a tile to be determined from both the number of primitives and the amount of tile each primitive covers. This can reduce the amount of memory that needs to be allocated and the number of tiles that need to be rendered to generate the shadow map, while maintaining shadow map accuracy in areas where a small number of primitives cover a significant proportion of the tiles.

[0093] The tile list can be analyzed by the graphics processor 102, the processing unit 104, or any other processor that can access the memory 112.

[0094] exist Figure 2c In the example shown, tiles W2 to W4, X2 to X4, and Y2 to Y4 will be identified as associated with at least one primitive according to the displayed list. The remaining tiles do not have primitives listed for them, so they will not be identified for further rendering and can therefore be ignored.

[0095] In step 306, the MMU 110 allocates memory for each identified tile. A portion or a block of memory can be allocated for each tile. For example, memory can be allocated within a page, where the MMU 110 controls the allocation and mapping of pages.

[0096] Conceptually, a shaded map can be thought of as solid blocks of memory, such as one page per tile or group of tiles. For example, a 4KB memory page could correspond to a 32×32 pixel tile with a 32-bit depth value for each pixel. If different tile sizes are used, such as 16×16 pixel tiles, the 4KB memory page could be allocated to four adjacent tiles in a 2×2 group.

[0097] Conventionally, rendering a shadow map allocates memory for the entire shadow map and then renders it as a single tile in a tile-based graphics system. Memory is typically allocated before the scene is tiled from the viewpoint of the light source. Allocating memory for the entire shadow map beforehand means allocating memory for all regions of the shadow map, even regions that do not contain any (or are unimportant) shadow-casting objects. In the currently disclosed processing and systems, the MMU 110 can be configured to allocate memory after the scene is tiled from the viewpoint of the light source. This allows the display list to be analyzed before allocating memory for the shadow map. The display list is analyzed to identify tiles that have at least one primitive associated with them. Only the identified tiles are allocated memory by the MMU 110; tiles that do not have any primitive associated with them (i.e., unidentified tiles) may not be allocated any memory. Therefore, the amount of memory allocated for the shadow map can be reduced.

[0098] For example, in Figure 2cThe scenario shown would typically allocate memory for all twenty-five tiles V1 through Z5. In this system, MMU 110 allocates memory only for the tiles identified in step 304. Therefore, memory will be allocated for only nine tiles (tiles W2 through W4, X2 through X4, and Y2 through Y4) instead of twenty-five. Unidentified tiles (tiles V1 through W1, W5, X1, X5, Y1, and Y5 through Z5) can be ignored and therefore no memory is allocated for them. Thus, memory is allocated only to a subset of the identified tiles, which reduces the amount of memory required for the shaded map.

[0099] The memory seen by the graphics processor 102 can be virtual memory, where the addresses where the graphics processor 102 operates are mapped by the MMU 110 to the actual physical addresses of the memory 112. The mapping can be page-by-page. Visibly contiguous blocks of virtual memory can be pieced together based on physical memory pages at different locations that do not necessarily have to be contiguous or in the same order. Physical memory allocation can occur at different stages. For example, blocks of virtual memory can be allocated to the entire shaded map, but physical memory backing is only provided by the MMU 110 to the identified tiles as needed or when required. In the example shown, the MMU 110 can generate a page table with virtual addresses for each of tiles V1 through Z5, but only the virtual addresses for tiles W2 through W4, X2 through X4, and Y2 through Y4 are mapped to physical addresses. The virtual addresses for tiles V1 through W1, W5, X1, X5, Y1, and Y5 through Z5 may not be mapped or may be mapped to a single physical address with a default value or a "background" value.

[0100] In step 308, the tiles identified in step 304 are rendered. Tiles can be rendered one at a time. Data obtained from the rendering of each tile (e.g., pixel depth values) is written to the memory address allocated to that tile. If the memory address is a virtual address, the MMU 110 translates that address into a physical address in memory 112.

[0101] In this example, only the tiles identified in step 304 are rendered. Therefore, unidentified tiles (tiles V1 to W1, W5, X1, X5, Y1, and Y5 to Z5) are not rendered, saving the processing overhead required to render those tiles. For empty tiles, some graphics processors can generate default or background values, which can still be written to memory. However, by not rendering those tiles, no data associated with those tiles is written to memory, thus saving memory for other uses.

[0102] For scenes with more than one light source, steps 300 to 308 can be repeated for each light source.

[0103] In step 310, the scene viewed from the camera's viewpoint is rendered (i.e., step 2 as described above). The scene viewed from the camera's viewpoint can be tiled by the tile-mapping unit 106 and rendered one tile at a time by the rendering unit 108. During this rendering, the rendering unit 108 queries the shadow map (or multiple texture maps) at coordinates (X, Y) to retrieve the depth value (S) for those coordinates in order to determine whether a pixel is in shadow, as described above. Pixels determined to be in shadow are modified accordingly. For example, the texture processor 116 can modify pixels based on other light sources, shadow colors, blur values, etc.

[0104] If a shadow map is queried at coordinates (X, Y) corresponding to an empty tile (i.e., an unrecognized and unassigned tile), the MMU 110 can be configured to return a default value or background depth value S corresponding to "very far" for any attempt to access those pages. Therefore, the pixel corresponding to that coordinate will be illuminated by the light source because it will have a depth value less than S. The default depth value can be stored in a single memory location, to which the MMU 110 maps all unrecognized tiles.

[0105] Then each rendered tile can be output to the display buffer (which can be accessed via...). Figure 1 (Another processing block not shown in the diagram). Figure 2d This shows the final scene to be displayed along with the shadows applied to the scene (in 208 and 210).

[0106] Figure 3The processing provides memory and memory bandwidth savings for the shadow map by allocating memory only to tiles containing shadow-casting objects. This is achieved by analyzing the display list generated by tileization to identify which tiles contain primitives and allocating memory only to those identified tiles. The tiles are then rendered to generate the shadow map. In an alternative embodiment, memory can be allocated for the shadow map after the tiles are rendered. In this embodiment, the tileization unit 106 tile-divides the scene from the viewpoint of the light source into multiple tiles, as described above. Each tile is then rendered sequentially by the rendering unit 108. When the rendering unit 108 renders a tile containing an object, the rendering unit determines the depth values ​​corresponding to the object and attempts to write those values ​​to memory. At this stage, memory has not yet been allocated for the tile. The MMU 110 can detect the attempted access to memory, capture the access, and allocate physical memory at that point. The MMU 110 can then release the access, allowing the rendering unit 108 to write the values ​​for the tile to the allocated memory. When rendering unit 108 renders tiles that do not contain any objects, it may not output any depth values ​​for those tiles. Therefore, for tiles that do not contain any objects, MMU 110 will not detect any attempts by rendering unit 108 to access memory 112. Consequently, no memory will be allocated to those tiles; only tiles containing objects will be allocated memory. Therefore, in this alternative embodiment, the amount of memory allocated to the shadow map is reduced, eliminating the need to analyze any display list.

[0107] Figures 4a to 4c Another technique for identifying tiles that can be omitted or ignored when generating a shaded map is shown. This technique can be applied in addition to or independently of the techniques described above.

[0108] A shadow map tile can contain primitives, i.e., objects that cast shadows. However, if no part of the frustum of the camera view rendered in step 2 (as described above) is visible in that tile, those objects will never cast their shadows onto anything the camera sees. Therefore, these tiles can be ignored when generating the shadow map, since any objects in those tiles will not affect the scene viewed by the camera.

[0109] Figure 4a A plan view of the scene is shown. The positions of the lights and the camera for the scene are indicated at 401 and 402, respectively. Objects such as the sphere 403, the pyramid 404, and the cube 405 are objects that may cast shadows. The camera's view frustum is shown at 406. The view frustum 406 can be considered as the spatial region in the 3D modeled world that may appear on the screen and is considered the camera's field of view.

[0110] The object between lamp 401 and camera frustum 406 may cast shadows onto other objects within camera frustum 406 (not shown for simplicity). Figure 4b A view of the scene as seen from the viewpoint of lamp 401 is shown. A portion of the camera frustum 406 is also visible from lamp 401. The observable extent of the camera frustum 406 is indicated by dashed lines. As shown, pyramid 404 and cube 405 are objects located within the area of ​​camera frustum 406 as seen from lamp 401. Therefore, from this viewpoint, pyramid 404 and cube 405 are objects that may cast shadows that could affect the scene seen by camera 402. Sphere 403 cannot cast shadows into the scene seen by camera 402 because light passing through the area of ​​this object will not interact with the camera's frustum 406. Therefore, the area in the lamp's view that could affect the scene seen by camera 402 can be identified.

[0111] Figure 4c The indicator specifies region 406 that can affect the scene as seen by camera 402. This region can be considered as the camera frustum 406 visible from the viewpoint of light 401. Any objects outside region 406 do not affect the scene as seen by camera 402. At 407, the indicator specifies the set of tiles that include this region. Therefore, when generating the shadow map, rendering of objects outside region 406 can be ignored because those objects do not affect the scene to be displayed. This provides processing and memory savings when generating and storing shadow maps in a manner similar to the savings described above.

[0112] In one exemplary embodiment, region 406 can be identified by determining the location of the extent of the camera frustum 406 and transforming those locations into "light space" to locate those same locations from the viewpoint of the light. Therefore, the location of the camera frustum 406 as seen from the point of the light 401 can be determined. The tile unit 106 can tile the scene as seen from the viewpoint of the light, as previously described. From the determined location of the frustum 406, the processing unit 104 (or graphics processor 102) can determine which tiles contain the frustum 406. These tiles are formed by… Figure 4c The block indicator for tile 407 in the diagram. Only those specific tiles 407 can be selected for rendering by the rendering unit 108. Similar to the above, the MMU 110 can allocate memory only for those tiles 407.

[0113] In another exemplary embodiment, a model of the camera frustum 406 (such as one that will be positioned in the 3D world of the scene) can be generated and used to determine which parts of the scene, viewed from the light source's viewpoint, might affect the camera scene. The camera frustum 406 can be modeled to form a frustum model object (composed of primitives) having the same geometry and positioning as the camera frustum 406. Thus, this object represents the camera frustum 406. The processing unit 104 can generate graphical data for the object provided to the graphics processor 102. The tileization unit 106 can receive the graphical data for the frustum model object and tile the scene viewed from the light 401's viewpoint. This will result in a scene that looks like... Figure 4c A tiled scene. A model of the camera frustum as seen from the light's viewpoint is shown at position 406. (See image below.) Figure 4c As shown, some tiles are empty, while others contain frustum 406. Shadow-casting objects in empty tiles may not cast shadows onto the scene as seen by the camera because light passing through that tile does not interact with the camera's view frustum 406. Therefore, empty tiles cannot affect the scene regardless of whether they contain any shadow-casting objects. Tiles containing frustum 406 are identified. These tiles are generally indicated at 407 as the set of tiles that can affect the scene. The tileization unit 106 can generate a list of tiles that categorizes the primitives of the frustum model 406 into a per-tile list (e.g., as described above). The processing unit 104 can then analyze this list (e.g., as described above) to identify tiles 407 containing frustum 406. Next, the normal scene as seen from the light's viewpoint (containing sphere 403, pyramid 404, and cube 405) can be tiled for generating a shadow map. When generating the shadow map, only the tiles corresponding to the identified tile 407 containing the frustum 406 are rendered, because only those tiles contain the portion of the shadow map that may affect the final scene to be displayed. Other tiles can be ignored. Similar to the above, only memory needs to be allocated to the tiles that continue to be rendered; no memory needs to be allocated to tiles that are not rendered.

[0114] This technique can be performed in a single step, for example, by establishing a stencil cache (not shown) using a frustum model 406. The stencil cache can form part of the graphics processor pipeline. The stencil cache can reject any objects not within the stencil region, thus rendering and / or allocating memory only for tiles within the stencil region (i.e., tiles corresponding to frustum 406).

[0115] Alternatively, the graphics processor may provide means for specifying a shearing (also known as culling) plane. This technique can then be performed by setting a shearing plane corresponding to the geometry of the frustum model 406. Shearing typically operates at a point in the pipeline prior to the tileization unit 106, such that objects outside the frustum region are rejected and not added to the tile list. Therefore, only tiles within the frustum region 407 are rendered and / or memory is allocated.

[0116] The technique for determining which parts of the scene a shadow map will affect can be combined with the aforementioned technique of rendering (and / or allocating memory for) only tiles containing shadow-casting objects. Therefore, if the frustum 406 is visible in a tile and a shadow-casting object exists in the tile, only the tile can be rendered and / or memory allocated for that shadow map. For example, such tiles can be identified by comparing the list of tiles generated when the model of the frustum is tiled with the list of tiles generated when the scene is tiled. In this example, only tiles containing the pyramid 404 and the cube 405 are identified for rendering / memory allocation.

[0117] In further optimization processing, one or more planes 408, including the back face of the camera frustum 406, can be identified from the viewpoint of the light. Objects extending beyond these planes (such as cube 405) can be clipped early in the shadow map generation process because such objects do not affect the scene seen by camera 402. For example, processing unit 104 can determine the position of plane 408 of the camera frustum 406. Processing unit 104 or tileization unit 106 can then clip any objects located far from the position of plane 408 as seen from the light's viewpoint. Thus, through this optimization processing, as shown, cube 405 extending beyond the frustum 406 will be clipped. Therefore, when the scene seen from the light 401's viewpoint is tiled, cube 405 will not exist, and only the tile containing pyramid 404 will be rendered and / or memory allocated. Such clipping can be performed in an early stage of any of the shadow mapping processes described above.

[0118] Identifying an empty tile list allows for avoiding all rendering of tiles outside the camera frustum region 406 (where there may be a large number of potential shadow-projecting geometries). The tileization unit 106 can be configured to discard objects early and / or avoid building a tile list for tiles outside the camera frustum region 406 to provide further graphics processing savings.

[0119] The graphics processor 102 can be implemented in hardware. When implemented in this way, it is inexpensive to compile and execute the display list by the tileization unit 106. The display list indicates which tiles in the scene, viewed from the light source's viewpoint, contain shadow-casting objects, thus providing an inexpensive and efficient way to determine which areas of the scene will be rendered and allocated memory for the shadow map.

[0120] Figure 1 The system is shown as comprising multiple functional blocks. This is merely illustrative and not intended to limit the strict division between different logical elements of such an entity. Each functional block can be provided in any suitable manner.

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

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

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

[0124] This also aims to cover software that defines the configuration of hardware as described herein, such as HDL (Hardware Description Language) software for designing integrated circuits or configuring programmable chips to perform desired functions. That is, a computer-readable storage medium may be provided on which computer-readable program code in the form of an integrated circuit definition dataset is encoded, which, when processed in an integrated circuit manufacturing system, configures the system to manufacture a graphics processing system for performing any of the methods described herein, or to manufacture a graphics processing system including any of the devices described herein. The integrated circuit definition dataset may, for example, be an integrated circuit description.

[0125] Integrated circuit definition datasets can be in the form of computer code, such as netlists, code for configuring programmable chips, hardware description languages ​​for defining integrated circuits at any level, including register-transfer level (RTL) code, high-level circuit representations such as Verilog or VHDL, and low-level circuit representations such as OASIS and GDSII. Higher-level representations that logically define integrated circuits (e.g., RTL) can be processed by a computer system configured to generate manufacturing definitions of integrated circuits within a software environment that includes definitions of circuit elements and rules for combining those elements, in order to generate manufacturing definitions of integrated circuits thus defined by such representations. Where software typically executed at a computer system to define the machine may require one or more intermediate user steps (e.g., providing commands, variables, etc.) to execute the code defining the integrated circuit for the computer system configured to generate manufacturing definitions of integrated circuits to generate those manufacturing definitions.

[0126] Now related to Figure 5 This describes an example of processing integrated circuit definition datasets at an integrated circuit manufacturing system in order to configure the system to manufacture a graphics processing system.

[0127] Figure 5An example of an integrated circuit (IC) manufacturing system 1002, including a layout processing system 1004 and an integrated circuit generation system 1006, is shown. The IC manufacturing system 1002 is configured to receive an IC definition dataset (e.g., a graphics processing system as described in any example herein), process the IC definition dataset, and generate an IC (e.g., a concrete implementation of a graphics processing system as described in any example herein) based on the IC definition dataset. The processing of the IC definition dataset configures the IC manufacturing system 1002 to manufacture integrated circuits that concretely implement the graphics processing system as described in any example herein.

[0128] The layout processing system 1004 is configured to receive and process an IC definition dataset to determine a circuit layout. Methods for determining the circuit layout from the 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, such as in terms of logic components (e.g., NAND, NOR, AND, OR, MUX, and FLIP-FLOP components). The circuit layout can be determined from the gate-level representation of the circuit by determining the location information for the logic components. This can be done automatically or with user intervention to optimize the circuit layout. Once the layout processing system 1004 has determined the circuit layout, it can output a circuit layout definition to the IC generation system 1006. The circuit layout definition may be, for example, a circuit layout description.

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

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

[0131] In other examples, processing of an integrated circuit definition dataset at an integrated circuit manufacturing system can configure the system to manufacture a graphics processing system without having to process the IC definition dataset to determine the circuit layout. For example, an IC definition dataset can define the configuration of a reconfigurable processor (such as an FPGA), and processing of that dataset can configure the IC manufacturing system to generate a reconfigurable processor with the defined configuration (e.g., by loading the configuration data into the FPGA).

[0132] In some implementations, when an integrated circuit manufacturing definition dataset is processed in an integrated circuit manufacturing system, the integrated circuit manufacturing system can generate the device described herein. For example, the integrated circuit manufacturing definition dataset, as described above, can be used to generate the device. Figure 5 The configuration of the integrated circuit manufacturing system described herein can result in the manufacture of equipment as described herein.

[0133] In some examples, an integrated circuit definition dataset may include software running on hardware defined at the dataset or software combined with hardware defined at the dataset. Figure 5 In the example shown, the IC generation system can also be configured by the integrated circuit definition dataset to load firmware onto the integrated circuit according to the program code defined at the integrated circuit definition dataset during the manufacturing of the integrated circuit, or to additionally provide program code to the integrated circuit for use with the integrated circuit.

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

Claims

1. A graphics processing method, the graphics processing method comprising: Divide the first view of the scene into multiple blocks; Render each tile associated with at least a predetermined number of primitives, and output the rendering data obtained from the rendering of that tile; Detect the rendering data output for each rendered tile and allocate a portion of memory for that rendered tile; as well as The rendered data for each rendered tile is stored in the portion of memory allocated for that tile, and no portion of memory is allocated for each of the plurality of tiles that is not associated with at least the predetermined number of primitives.

2. The graphics processing method according to claim 1, further comprising: For subsequent rendering, the memory is accessed to read data associated with tiles not associated with at least the predetermined number of primitives, and a predefined value is returned in response to the access.

3. The graphics processing method according to claim 1, further comprising: Rendering data is not output for tiles that are not associated with at least a predetermined number of primitives.

4. The graphics processing method according to claim 1, further comprising: Identify a subset of the tiles associated with a portion of the scene visible in a second view, wherein the rendering step includes rendering each tile in the subset that is identified and associated with at least the predetermined number of primitives.

5. The graphic processing method according to any one of claims 1 to 4, wherein, The rendering data is the data used for textures.

6. The graphics processing method according to claim 5, wherein, The texture is applied to the scene in subsequent rendering of the scene.

7. The graphics processing method according to claim 6, wherein, The texture is applied to a second view of the scene, which is different from the first view of the scene.

8. The graphics processing method according to claim 5, wherein, The texture is a shadow map.

9. The graphics processing method according to any one of claims 1 to 4, wherein, The predetermined quantity is equal to or greater than 1.

10. A non-transitory computer-readable storage medium storing computer-readable instructions that, when executed on a computer system, cause the computer system to perform the method according to any one of claims 1 to 9.

11. A non-transitory computer-readable storage medium storing an integrated circuit definition dataset, wherein when the integrated circuit definition dataset is processed in an integrated circuit manufacturing system, the integrated circuit manufacturing system is configured to manufacture a graphics processing system, the graphics processing system comprising: Memory used for storing data; A tile-based unit is configured to tile a first view of the scene into multiple tiles; A rendering unit configured to render each tile associated with at least a predetermined number of primitives and output rendering data obtained from the rendering of the tile; as well as Memory management unit, the memory management unit being configured to: Detect the rendering data output for each rendered tile and allocate a portion of memory for that rendered tile; as well as The rendered data for each rendered tile is stored in the portion of memory allocated for that tile, and no portion of memory is allocated for each of the plurality of tiles that is not associated with at least the predetermined number of primitives.

12. A method for manufacturing a graphics processing system in an integrated circuit manufacturing system, the graphics processing system comprising: Memory used for storing data; A tile-based unit is configured to tile a first view of the scene into multiple tiles; A rendering unit configured to render each tile associated with at least a predetermined number of primitives and output rendering data obtained from the rendering of the tile; as well as Memory management unit, the memory management unit being configured to: Detect the rendering data output for each rendered tile and allocate a portion of memory for that rendered tile; as well as The rendered data for each rendered tile is stored in the portion of memory allocated for that tile, and no portion of memory is allocated for each of the plurality of tiles that is not associated with at least the predetermined number of primitives.

Images