Graphics processing unit and method using rendering progress check

Abstract

The present disclosure relates to graphics processing units and methods using render progress checking. A graphics processing unit configured to process graphics data, the graphics processing unit comprising: a plurality of processor groups, each processor group formed of one or more processor cores, each processor group configured to render graphics data by processing an assigned rendering task; scheduling logic configured to: assign rendering tasks to the plurality of processor groups; and assign at least one rendering task to at least one other processor group for processing when at least one processor group has not completed processing of an assigned one or more tasks; progress indication logic configured to maintain a progress indication, the progress indication indicating areas for which processing of a first rendering has been completed; and progress checking logic configured to check the progress indication in response to a processor core requesting access to an area, and in response to the progress indication indicating that processing of the first rendering has been completed for the area, to cause the processor core to access the area.

Description

[0001] This application is a divisional application of Chinese Invention Patent Application No. 202010460318.3, filed on May 27, 2020, entitled “Graphics Processing Unit and Method Using Render Progress Check”. TECHNICAL FIELD

[0002] The present invention relates to graphics processing systems and methods for performing multiple renders. BACKGROUND

[0003] Graphics processing systems are typically configured to receive graphics data, for example from an application program running on a computer system, and to render the graphics data to provide a rendered output. For example, the graphics data provided to the graphics processing system can describe geometry within a three-dimensional (3D) scene to be rendered, and the rendered output can be a rendered image of the scene. Some graphics processing systems, which can be referred to as “tile-based” graphics processing systems, use a render space that is subdivided into a plurality of tiles. A “tile” is a region of the render space, and can have any suitable shape, but is typically rectangular (where the term “rectangular” includes square). For example, a tile can occupy a 16x16 pixel block or a 32x32 pixel block in the image to be rendered. As is known in the art, subdividing the render space into tiles has a number of benefits. For example, subdividing the render space into tiles enables the image to be rendered in a tile-by-tile manner, in which the graphics data for a tile can be stored “on-chip” temporarily during rendering of the tile.

[0004] Tile-based graphics processing systems typically have two stages of operation: a geometry processing stage and a rendering stage. In the geometry processing stage, the graphics data for rendering is analysed to determine, for each tile, which graphics data items are present within that tile. Then, in the rendering stage, the tile can be rendered by processing the graphics data items determined to be present within the tile (there is no need to process graphics data items determined in the geometry processing stage to be not present within the particular tile). The graphics data items can represent geometry, which describes surfaces of structures in the scene and are referred to as “primitives”. A common primitive shape is a triangle, but primitives can be other 2D shapes, or can also be lines or points. An object can be composed of one or more (e.g. hundreds, thousands or millions) such primitives.

[0005] Figure 1 Some elements of a graphics processing system 100 are shown, which can be used to render an image of a 3D scene. The graphics processing system 100 comprises a graphics processing unit (GPU) 102 and two memory portions 1041 and 1042. The two memory portions 1041 and 1042 can or can not be portions of the same physical memory.

[0006] GPU 102 includes a pre-processing module 106, a binning unit 108, and a rendering logic 110, which includes an acquisition unit 112 and a processing logic 113 containing one or more processor cores 114. Rendering logic 110 is configured to use processor cores 114 to implement hidden surface removal (HSR) and texturing and / or shading on graphics data (e.g., primitive fragments) for tiles of a rendering space.

[0007] Graphics processing system 100 is arranged such that a sequence of primitives provided by an application program is received at pre-processing module 106. In a geometry processing stage, pre-processing module 106 performs functions such as geometry processing including clipping and culling to remove primitives that do not fall within a visible view. Pre-processing module 106 can also project the primitives into screen space. The primitives output from pre-processing module 106 are passed to binning unit 108, which determines which primitives exist within each tile of a rendering space of graphics processing system 100. Binning unit 108 assigns the primitives to tiles of the rendering space by creating a control flow (or "display list") for the tiles of the rendering space, where the control flow for a tile contains an indication of the primitives that exist within the tile. The control flow and primitives are output from binning unit 108 and stored in memory 1041.

[0008] In the rendering stage, the rendering logic 110 renders the graphics data for a tile of the render space to generate rendered values, e.g., rendered image values. The rendering logic 110 can be configured to implement any suitable rendering technique, such as rasterization or ray tracing, to perform the rendering. To render a tile, the fetch unit 112 fetches the control flow for the tile and the primitives associated with the tile from the memory 1041. For example, the rendering unit can implement rasterization according to a deferred rendering technique such that one or more processor cores 114 are used to perform hidden surface removal to remove fragments of primitives that are hidden in the scene, and then one or more processor cores 114 are used to apply texturing and / or shading to the remaining primitive fragments to form the rendered image values. Methods of performing hidden surface removal and texturing / shading are known in the art. The term "fragment" refers to a sample of a primitive at a sample point that will be processed to render one or more pixels of the image. In some instances, there can be a one-to-one mapping of sample locations to pixels. In other instances, there can be more sample locations than pixels, and this oversampling can be used to render pixel values with higher quality, e.g., by facilitating anti-aliasing and other filtering that can be applied to multiple fragments to render each pixel value. The texturing and / or shading performed on the fragments that pass the HSR stage determine the pixel color values of the rendered image, which can be passed to the memory 1042 for storage in a frame buffer. Texture data can be received at the rendering logic 110 from the memory 1041 in order to apply texturing to the primitive fragments, as is known in the art. A shader program can be executed to apply shading to the primitive fragments. The texturing / shading process can include applying further processing to the primitive fragments (e.g., alpha blending and other processes), as is known in the art, in order to determine the rendered pixel values of the image. The rendering logic 110 processes the primitives in each tile, and when the entire image has been rendered and stored in the memory 1042, the rendered image can be output from the graphics processing system 100 and used in any suitable manner, e.g., displayed on a display or stored in memory or transmitted to another device, etc.

[0009] In some systems, a particular processor core can be used to perform hidden surface removal at one point in time and to perform texturing / shading at another point in time. In some other systems, some of the processor cores are dedicated to performing hidden surface removal, while other ones of the processor cores are dedicated to performing texturing and / or shading on the primitive fragments.

[0010] The graphics processing system 100 described above is a deferred rendering system because the rendering logic 110 is configured to perform HSR processing on a primitive fragment before texturing / shading is applied to the primitive fragment. Other graphics processing systems are not deferred rendering systems because they are configured to perform texturing and / or shading of a primitive fragment before performing HSR on those primitive fragments. Deferred rendering systems save the processing involved in applying texturing and / or shading to at least some of the primitive fragments that are removed by the hidden surface removal process.

[0011] If the rendering logic 110 includes more than one processor core 114, the processor cores can process different data in parallel, thereby improving the efficiency of the rendering logic 110. In some systems that include more than one processor core 114, the processor cores can be arranged into groups (referred to herein as processor groups). Each processor core within a group can share resources of the graphics processing system. The resources can be memory and / or processing resources of the graphics processing system. Each processor group can have its own allocated resources that are shared among the processor cores in that group. A processor group can contain one or more processor cores, and tiles can be assigned to processor groups of the rendering logic 110 such that graphics data for rendering a particular tile is processed in a single processor group. Graphics data for rendering different tiles can be processed by different single processor groups. Processing a particular tile in a single processor group, rather than spreading the processing of a particular tile across multiple processor groups, can have various benefits, such as improved cache hit rates. Multiple tiles can be assigned to the same processor group, which can be referred to as having “multiple tiles in flight.” If multiple tiles are assigned to the same processor group, the processor group can process those tiles by distributing the tiles across one or more processor cores in the group, and rendering is complete when all of the tiles for rendering have been processed by the rendering logic 110. The results of the rendering (e.g., the rendered frames) can then be used as appropriate (e.g., displayed on a display or stored in memory or transmitted to another device, etc.), and the rendering logic 110 can process tiles for subsequent renderings.

[0012] The above describes a series of example processing steps performed during a single render. In practice, a graphics processing system can perform multiple renders. Multiple renders can be performed to produce a single output frame or final render. For example, multiple renders can be performed that each output values to separate render targets. A render target can refer to a buffer that contains rendered image values generated by a render. A final output frame can be formed from one or more of these render targets in order to produce a final shading value for each pixel of the output frame. Each render target can contain render values that represent different information of a scene to be rendered. Example render targets include a buffer storing diffuse color information, a buffer storing specular color information, a depth buffer, and a stencil buffer. Some of the renders used to generate a final render can depend on a previous render, for example by referencing results of the previous render. Other renders can be independent of one another; that is, a render can not depend on results of another render. SUMMARY

[0013] A graphics processing unit configured to process graphics data using a render space subdivided into a plurality of tiles is provided, the graphics processing unit comprising:

[0014] a plurality of sets of one or more processor cores configured to render graphics data by processing assigned tiles, wherein data of processed tiles is output to a region of a memory resource;

[0015] scheduling logic configured to:

[0016] assign a set of one or more tiles to the plurality of sets of processor cores for rendering to perform a first render; and

[0017] when at least one of the plurality of sets of one or more processor cores has not completed processing of the assigned set of one or more tiles as part of the first render, assign at least one set of one or more tiles for a second render to at least one of the other sets of one or more processor cores for processing;

[0018] progress indication logic configured to maintain a progress indication indicating progress of the first render, the progress indication indicating a region of the memory resource for which processing of the first render has completed; and

[0019] progress check logic configured to check the progress indication in response to a processor core requesting access to a region of the memory resource as part of the second render, and cause the processor core to access the region in response to the progress indication indicating that processing of the first render has completed for the region of the resource.

[0020] In examples described herein, the other set of one or more processor cores is a set of one or more processor cores that have completed processing of at least one set of one or more tiles allocated as part of the first rendering.

[0021] The progress indication logic can be configured to update the progress indication according to an update scheme as the first rendering progresses.

[0022] Progress check logic can be configured to recheck the progress indication each time the progress indication is updated.

[0023] The memory resource can be arranged as a two-dimensional array of tiles corresponding to the rendering space, such that when the one or more tiles corresponding to a region of the memory resource have been rendered for the first rendering, the memory region has completed the processing of the first rendering.

[0024] The progress check logic can be configured to check the progress indication by mapping a spatial location of the access request in the memory resource to a region of the rendering space and using the progress indication to determine whether all of the tiles within the region have been processed according to the first rendering.

[0025] The progress indication can identify at least a subset of rendering regions in the rendering space that have completed processing of the first rendering, each rendering region comprising at least one tile.

[0026] Each of the rendering regions can have a size at least equal to each set of one or more tiles assigned to a processor core.

[0027] The progress indication can identify each of the rendering regions in the rendering space that have completed processing of the first rendering.

[0028] The progress indication can comprise a set of flags corresponding to each of the rendering regions, and the progress indication logic is configured to set the flag corresponding to a rendering region when the processing of the first rendering for each tile within the region is completed.

[0029] The progress indication can identify a sequence of consecutive rendering regions in which processing of the first rendering has been completed, following a predetermined order.

[0030] The progress indication logic can be configured to update the progress indication after completion of processing of a rendering region, the completion extending the sequence of consecutive rendering regions following the predetermined order.

[0031] The progress indication can comprise a counter indicating a number of rendering regions in the consecutive sequence in which processing of the first rendering has been completed.

[0032] The progress indication logic can comprise a first-in-first-out (FIFO) buffer for controlling the incrementing of the counter, the buffer being configured to receive a series of values corresponding to respective rendering regions, each value indicating whether the processing of the first rendering of its corresponding rendering region has been completed.

[0033] The FIFO buffer can be configured to output a value when its predecessor value indicates that the processing of the first rendering of its corresponding rendering region has been completed, and not to output a value when its predecessor value indicates that the processing of the first rendering of its corresponding rendering region has not been completed; and wherein the counter is configured to increment in response to the buffer outputting its predecessor value.

[0034] Each group of one or more processor cores can contain only a single processor core.

[0035] Each group of one or more processor cores can contain a plurality of processor cores.

[0036] Each of the plurality of processor cores within a group can share common processing resources of a graphics processing unit.

[0037] The graphics unit can further comprise a buffer configured to buffer access requests to regions of a memory resource, the progress check logic being configured to buffer an access request when the progress indication indicates that the processing of the first rendering has not been completed for the region of the memory resource specified by the access request.

[0038] The buffer can be arranged such that a request for processing resources required to complete the processing of the first rendering of a region of the memory resource specified by an access request located in the buffer is not obstructed by the access request located in the buffer.

[0039] There is provided a method of processing graphics data in a graphics processing unit comprising a plurality of groups of one or more processor cores, the graphics processing unit being configured to use a rendering space subdivided into a plurality of tiles; the method comprising:

[0040] performing a first rendering by allocating a set of one or more tiles to the plurality of groups of processor cores for rendering and outputting data of processed tiles to a region of a memory resource;

[0041] allocating at least one set of one or more tiles for a second rendering to at least one of the other groups of one or more processor cores for processing when at least one of the plurality of groups of one or more processor cores has not completed processing of the allocated set of one or more tiles as part of the first rendering;

[0042] maintaining a progress indication indicative of progress of the first rendering, the progress indication indicating regions of the memory resource for which processing of the first rendering has been completed;

[0043] checking the progress indication in response to a processor core requesting access to a region of the memory resource as part of the second rendering; and

[0044] in response to the progress indication indicating that processing of the first rendering has been completed for the region of the memory resource, accessing the region of the resource.

[0045] The method can further include updating the progress indication according to an update scheme as the first rendering progresses.

[0046] The method can include re-checking the progress indication each time the progress indication is updated.

[0047] The memory resource can be arranged as a two-dimensional array corresponding to the tiles of the rendering space, such that when the first rendering has rendered the one or more tiles corresponding to a region of the memory resource, the memory region has completed the processing of the first rendering.

[0048] The progress indication can be checked by mapping a spatial location of the access request in the memory resource to a region of the rendering space and using the progress indication to determine whether all tiles within the region have been processed according to the first rendering.

[0049] The progress indication can identify at least a subset of rendering regions in the rendering space for which processing of the first rendering has been completed, each rendering region comprising at least one tile.

[0050] Each of the rendering regions can have a size at least equal to each set of one or more tiles assigned to a processor core.

[0051] The progress indication can identify each rendering region in the rendering space for which processing of the first rendering has been completed.

[0052] The progress indication can include a set of flags corresponding to each of the rendering regions, and the progress indication logic is configured to set the flag corresponding to a rendering region when the processing of the first rendering for each tile within the region has been completed.

[0053] The progress indication can identify a sequence of consecutive rendering regions in which processing of the first rendering has been completed, following a predetermined order.

[0054] The method can comprise updating the progress indication upon completion of processing of a rendering region, the completion extending the predetermined order of the contiguous sequence of rendering regions.

[0055] The progress indication can comprise a counter indicating a number of rendering regions of the first rendering whose processing has been completed in the contiguous sequence.

[0056] The method can comprise receiving at a buffer a series of values corresponding to respective rendering regions, each value indicating whether the processing of the first rendering of its corresponding rendering region has been completed, and using the series of values in the buffer to control an increase of the counter.

[0057] The method can comprise outputting from the buffer a value when its leading value indicates that the processing of the first rendering of its corresponding rendering region has been completed, and causing the counter to increase in response to the buffer outputting its leading value.

[0058] Each group of one or more processor cores can contain only a single processor core.

[0059] Each group of one or more processor cores can contain a plurality of processor cores.

[0060] Each of the plurality of processor cores within a group can share common processing resources of a graphics processing unit.

[0061] The method can further comprise buffering in a buffer those access requests when a progress indication indicates that the processing of the first rendering has not yet been completed for a region of memory resource specified by an access request to a region of memory resource.

[0062] The buffer can be arranged such that a request for processing resources required to complete the processing of the first rendering of the region of memory resource specified by an access request located in the buffer is not obstructed by the access request located in the buffer.

[0063] The graphics processing unit can be embodied as hardware on an integrated circuit. There is provided a method of manufacturing a graphics processing unit as described herein using an integrated circuit manufacturing system. There is provided an integrated circuit definition data set which, when processed in an integrated circuit manufacturing system, configures the system to manufacture a graphics processing unit as described herein.

[0064] There is provided a non-transitory computer readable storage medium having stored thereon a computer readable description of an integrated circuit, which, when processed in an integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture a graphics processing unit as described herein. There is provided an integrated circuit manufacturing system configured to manufacture a graphics processing unit as described herein.

[0065] An integrated circuit manufacturing system is provided, comprising:

[0066] A non-transitory computer readable storage medium having stored thereon a computer readable integrated circuit description describing a graphics processing unit as described herein;

[0067] A layout processing system configured to process the integrated circuit description so as to generate a circuit layout description of an integrated circuit embodying the graphics processing unit; and

[0068] An integrated circuit generation system configured to manufacture the graphics processing unit according to the circuit layout description.

[0069] A graphics processing unit configured to perform a method as described herein is provided. Computer program code for performing a method as described herein is provided. A non-transitory computer readable storage medium having stored thereon computer readable instructions, which, when executed at a computer system, cause the computer system to perform a method as described herein. BRIEF DESCRIPTION OF DRAWINGS

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

[0071] Figure 1 A graphics processing system is shown;

[0072] Figure 2 A rendering space divided into a plurality of tile sets is shown, each tile set containing one tile block;

[0073] Figure 3A An instance of tile work load distribution across multiple groups of processor cores of a GPU when rendering tiles of a rendering space in a rendering Figure 2 is shown;

[0074] Figure 3B An instance of tile work load distribution across multiple groups of processor cores of a GPU when performing a first rendering of tiles of a rendering space in a rendering Figure 2 is shown.

[0075] Figure 4 An instance of a graphics processing system according to the present disclosure is shown;

[0076] Figure 5 An example architecture of processing logic forming part of a graphics processing system of Figure 4 is shown;

[0077] Figure 6 A flow diagram of a method of processing graphics data using a graphics processing system is shown;

[0078] Figure 7 An example of workload distribution across three groups of processor cores, each group containing three processor cores, is shown.

[0079] Figure 8 An example of a rendering space divided into a plurality of rendering regions, each containing a tile set, is shown.

[0080] Figure 9 is a schematic illustration of how a processing resource deadlock can arise.

[0081] Figure 10 An example of workload distribution across nine groups of processor cores, each group containing a single processor core, is shown.

[0082] Figure 11 is a schematic diagram of an integrated circuit manufacturing system. DETAILED DESCRIPTION

[0083] The present disclosure relates to processing graphics data in a graphics processing system comprising a plurality of groups of one or more processor cores. The graphics processing system performs a first rendering by assigning a set of one or more tiles to the groups of processor cores for rendering. Contrary to standard rendering techniques, the graphics processing system then initiates a second rendering while the first rendering is not yet complete. To this end, a set of one or more tiles for the second rendering is assigned to at least one of the groups of processor cores while at least one of the other groups of processor cores has not yet completed processing of the assigned tiles as part of the first rendering. Thus, processing of the second rendering can be interleaved to some extent with processing of the first rendering, in that one or more groups of processor cores process a set of tiles as part of the first rendering, while one or more other groups of processor cores process a set of tiles as part of the second rendering. The second rendering can or can not depend on the first rendering (that is, the second rendering can or can not reference results of the first rendering). In response to a processor core acting on the second rendering requesting data from a region of memory that can be modified by the first rendering still in progress, a progress indication is checked. If the progress indication identifies that all required work associated with the requested region of memory has been completed, then the processor core requesting access as part of the second rendering is granted access to the region of memory resources. Requests made by the second rendering for memory regions being processed in the first rendering can be made without having to wait for all processing associated with the first rendering to complete. The progress indicator can be used to avoid a situation in which a processor core performing processing as part of the second rendering requests access to a memory region before the data from the first rendering ends modifying the memory region.

[0084] As used herein, a processor group refers to a group of one or more processor cores. Each processor core within a group can share common processing resources. The processing resources can be hardware resources, such as texture units. However, in other examples, a processor group does not correspond to any particular hardware arrangement within a graphics processing unit. A processor group can refer to the granularity at which tiles or sets of tiles are assigned to processor cores for processing as part of rendering.

[0085] Figure 2 An example of a render space 200 is shown. The render space is divided into a plurality of tiles 202. In this example, the render space is divided into an 8x6 tile block for purposes of illustration. The tiles can be grouped into one or more sets of tiles, which can be assigned to processor cores 114 of a graphics processing system 100 to perform rendering N. As described above, the processor cores 114 can be arranged into one or more processor groups, with each processor group containing one or more processor cores. In this case, sets of tiles are allocated to processor groups. Each processor group then processes the allocated set of tiles by distributing the tiles in the set across the one or more processor cores in the group.

[0086] In Figure 2 The tiles that can be grouped into sets are illustrated by the bold boundary lines in the middle, which can be referenced by their spatial location within the render space: (0,0); (0,1); (0,2); (0,3); (1,0); (1,1); (1,2); and (1,3). That is, in this example, the tiles of the render space are grouped into eight sets of tiles, with each set of tiles formed by a 2x3 tile sub-block. Thus, in this example, each set contains six tiles, but the sets can likewise be formed by fewer (e.g., one) or more tiles. Again, the set size here is selected for purposes of illustration. Each set can have the same size (as shown here) or different sizes. Although the tiles of each set are shown here as a contiguous tile block, each set of tiles need not be formed by a contiguous tile block, they can also be formed by tiles that are separated within the render space. In some examples, the size of the sets of tiles can vary depending on the type of rendering. That is, the size of the sets of tiles can vary for different renderings. In other examples, the size of the sets of tiles can be set based on workload estimates, knowledge of previously rendered frames, or other externally sourced information (e.g., information provided by a component external to the graphics processing unit).

[0087] To perform rendering N, the sets of tiles are assigned to processor cores 114 of a graphics processing system 100.

[0088] Figure 3AThe execution timing of tile sets on processor cores 114 is illustrated. In this illustration, graphics processing system 100 is considered to contain four processor groups. The vertical axis is time extending downward from a render start time 302. In this example, tile sets are assigned or allocated to processor groups in raster scan order, but in other examples, tile sets can be allocated to processor cores in any other suitable order. Once a processor group finishes processing a tile set assigned to it, the processor group is assigned a next tile set according to a specified ordering pattern. Tile sets can be assigned according to any suitable ordering pattern, such as raster scan order, N-order, Z-order, etc. In this example, tile sets are assigned to processor groups in raster scan order. Thus, initially, the first four tile sets (sets (0,0), (0,1), (0,2), and (0,3)) are allocated to respective ones of the processor groups starting from the top row of the render space. Processor group 1 is the first group to finish processing an allocated tile set, and thus, is subsequently allocated a next tile set (tile set (1,0)) according to raster scan order. Processor group 4 is the second group to finish processing an allocated tile set, and thus, is subsequently allocated a next tile set (tile set (1,1)) according to raster scan order. This scheduling continues until all tile sets of the render space have been allocated to the processor groups, as shown in Figure 3A Blocks 3041-3048 indicate the time taken by the processor groups to process the respective tile sets.

[0089] When processing of all tile sets has completed, render N is complete. 306 represents a render end time. Note that the tile set that finishes processing last is not necessarily the tile set that was allocated last to a processor group. This is because different tile sets can take different amounts of time to process, e.g., because they depict regions of different complexity. In this example, the tile set that finishes processing last is tile set (1,2), but the tile set that was allocated last to a processor group is tile set (1,3).

[0090] Graphics processing system 100 can perform a subsequent render N+1, e.g., as part of performing multiple renders to generate a final render for output. Typically, processing of render N+1 does not begin until processing of the previous render N is complete. That is, typically, the rendering pipeline implemented by processor cores 114 is drained before processing of the next render begins. Reference is made to Figure 3AThis would mean that processor core 114 would not start processing any tiles for rendering N+1 until the end time 306 of rendering N. This approach is typically taken to avoid situations where a processor core performing the processing of a tile set as part of rendering N+1 needs to reference data generated by rendering N, but that data has not yet been generated because the processing of rendering N has not progressed far enough.

[0091] However, a problem with this approach is that it can result in idle time within the processor cores. For example, waiting until the end time 306 before starting the processing of rendering N+1 introduces idle time Tl for processor group 1, T3 for group 3, and T4 for group 4. This problem can be particularly severe when the work required to perform the rendering is not evenly distributed across the tile sets, but is concentrated within particular tile sets. This can result in some processor groups taking significantly longer to complete the processing of the first rendering than other processor groups, leaving a large number of processor cores idle for a significant amount of time.

[0092] If renderings N and N+1 are independent of each other, that is, rendering N+1 does not reference any results generated by rendering N, one approach to solving the idle time problem is to initiate rendering N+1 before rendering N is complete. To do this, the tile set for the subsequent rendering N+1 is assigned to selected ones of the processor groups while other ones of the processor groups are still processing their assigned tile sets as part of rendering N.

[0093] Figure 3B An illustration of how tile sets for rendering N+1 can be assigned to the processor groups while other ones of the processor groups are still processing tiles as part of rendering N. Again, each processor group can contain one or more processor cores.

[0094] In Figure 3B In Figure 3B, the work completed in processing the tile sets as part of renderings N and N+1 is distinguished by different hatching. Blocks 3041-3048 indicate the time spent processing the respective tile sets as part of rendering N, as indicated by the hatching in blocks 3041-3048. Blocks 3051-3058 indicate the time spent processing the respective tile sets as part of rendering N+1, as indicated by the hatching in blocks 3051-3058. Figure 3AThe blocks 3081, 3082 indicate the time spent processing the respective tile sets (0,0) and (0,1) for rendering N+1. It can be seen that in this example, the tile set (0,0) for rendering N+1 is assigned to processor group 1 at a time 310 when the remaining processor groups 2-4 are still processing tile sets assigned as part of the previous rendering N. Thus, rendering N+1 is initiated while at least one of the processor groups is still processing tile sets for rendering N (i.e., rendering N+1 is initiated before the end time 306 of the rendering of N). It can be seen from this figure how this approach can reduce, or in some cases, possibly eliminate, idle time of processor cores.

[0095] Figure 3B This approach described in the can be effective when rendering N and N+1 are independent of each other. However, it is common for a subsequent rendering to depend at least in part on a previous rendering, such that to complete rendering N+1, data generated by rendering N needs to be referenced or accessed. Similarly, the dependency between renderings is often not known before starting the rendering, as the location of the region of memory to be read can be programmatically determined at runtime. If rendering N and N+1 are not independent of each other, then Figure 3B The approach described in the of simply assigning tile sets for the next rendering to available processor groups and then processing those tile sets without regard to the progress of the previous rendering can result in reading incorrect data during processing.

[0096] One problem that can arise is that as part of rendering N+1, one or more incorrect values can be read. For example, referring again to Figure 3B processing of tile set (0,1) for rendering N+1 can require referencing a data value generated by processing tile set (1,2) for rendering N, but that value has not yet been generated by processor group 2. In this case, when attempting to access the data value from the memory resource, some other value (e.g., generated by a rendering prior to N) can actually be accessed. Thus, initiating rendering N+1 before the processing of rendering N is complete can be extremely risky when the graphics processing system is unaware of the progress of rendering N.

[0097] In the examples described herein, when some of the processor cores of a multi-core GPU have not finished processing a set of tiles allocated as part of a first rendering, a second rendering is initiated by allocating a set of one or more tiles for the second rendering to other processor cores. The second rendering can or can not depend on the first rendering. While processing the set of tiles as part of the first rendering, a progress indication is maintained that indicates the progress of the first rendering. If, as part of processing the second rendering, a processor core requests access to a region of a memory resource that stores data from the first rendering, the progress indication is checked, and the processor core is enabled to access the region of the memory resource if the progress indication indicates that processing of the first rendering for the region of the memory resource has been completed. If the progress indication indicates that processing of the first rendering for the region of the memory resource has not been completed, access to the region of the resource can be prevented. In this way, a situation in which a region of a memory resource is accessed as part of processing a second rendering before data from a first rendering is written to the region can be avoided. The memory resource can comprise a plurality of regions that store data generated by the processor cores while performing the first rendering. The memory resource can be a resource of a graphics processing unit. For example, it can be a cache that is accessible by the processor cores (e.g., through a memory resource access unit) while performing the rendering. Alternatively, the memory resource can not be part of a graphics processing unit, but can be part of a computer system of which the graphics processing unit is a constituent part. For example, the memory resource can be, or can form part of, a system memory of the computer system.

[0098] Figure 4 An example of a graphics processing system 400 configured to process graphics data to render an image of a scene is shown.

[0099] The graphics processing system comprises a graphics processing unit (GPU) 402 and two memory portions 404 and 406. The two memory portions can or can not be part of the same physical memory. The GPU 402 comprises a pre-processing module 408, a tiling unit 410, rendering logic 412 and a memory resource 414. The memory resource can be a cache, a buffer or some other type of on-chip memory. The memory resource can be a set of one or more caches or buffers. The memory resource can store data generated during or from a first rendering. Each processor core can have a respective memory resource, or each of the array of processor cores can have a memory resource, e.g., each pair of processor cores can have a memory resource. The rendering logic 412 comprises scheduling logic 416, fetch unit 418, processing logic 420 (which itself comprises a plurality of processor cores 4221, 4222...422N), and a memory resource 424. The memory resource 424 can be a cache, a buffer or some other type of on-chip memory. The memory resource 424 can be a set of one or more caches or buffers. The memory resource 424 can store data generated during or from a first rendering. Each processor core can have a respective memory resource, or each of the array of processor cores can have a memory resource, e.g., each pair of processor cores can have a memory resource. n) ; memory resource access unit 424 and progress indication logic 426. Memory resource access unit 424 itself includes progress check logic 428 and set aside buffer 430.

[0100] In alternative examples, memory resource 414 can be external to GPU 402. For example, memory resource 414 can be a set of one or more logical partitions of system memory 406 or the like. In other examples, there can be multiple memory resources, some of which are local to GPU 402 and others of which are in system memory.

[0101] Rendering logic 412 is configured to implement hidden surface removal (HSR) and texturing and / or shading of graphics data (e.g., primitive fragments) for a tile of a render space using processor cores 422 of processing logic 420. Graphics processing system 400 also includes compiler 432 configured to compile programs (e.g., shader programs) to be executed on GPU 402. Compiler 432 can write compiled shader programs to intermediate memory, from which GPU 402 retrieves the compiled shader programs at run time, although intermediate memory is not shown in the Figure 4 Rendering logic 412 includes any suitable number of processor cores, e.g., 1 to 256, or more. The number of processor cores in rendering logic 412 can be adapted to suit the intended use of the graphics processing system (e.g., a graphics processing system for a small mobile device that has strict constraints on processing resources and silicon size can include a small number of processor cores (e.g., 6 processor cores), while a graphics processing system for a large device such as a PC or server that has less strict constraints on processing resources and silicon size can include a large number of processor cores (e.g., 128 processor cores)).

[0102] Processor cores 422 of processing logic 420 can be arranged in groups, referred to herein as processor groups. Each processor group contains one or more processor cores. Figure 5 How processor cores 422 of processing logic 420 can be grouped is shown.

[0103] In this example, processing logic 420 is considered to have nine processor cores arranged into three processor groups 5021, 5022, 5023. Each processor group includes three processor cores 422. The first processor group 5021 contains processor cores 4221, 4222, 4223, the second processor group 5022 contains processor cores 4224, 4225, 4226, and the third processor group 5023 contains processor cores 4227, 4228, 4229. Of course, in other examples, different numbers of processor cores can be grouped together, and the processing logic can include different numbers of processor groups depending on the number of processor cores included by the processing logic. In some examples, each processor group can contain a single processor core.

[0104] In this example, each processor group includes its own processing resource 5041, 5042, 5043. The processing resource can be a hardware resource shared by each processor core in the group. The processing resource can perform memory accesses on behalf of the processor cores in the group, such as accessing memory resources 414, or complete processing tasks requested by the processor cores in the group. For example, the processing resource can be a texture processing unit configured to process texture accesses. The texture processing unit can receive texel requests and convert those requests into memory addresses to access the texture in memory. The texture processing unit can be configured to perform texture sampling. That is, the texture processing unit can be configured to retrieve one or more texel values in memory based on a received request and filter those texel values to produce a single texture color for a texture mapped pixel. The shared processing resource 5041, 5042, 5043 need not be a texture processing unit, but can be some other form of shared hardware resource. For example, it can be a shared memory, such as a cache.

[0105] The operation of the graphics processing system 400 will now be described with reference to the flowchart in Figure 6

[0106] Graphics data for performing rendering is received at the graphics processing unit 402, for example, from a game application running on a CPU in the same computing system as the graphics processing unit. The graphics data can include primitive data describing primitives of objects in a scene to be rendered. The graphics data can also specify one or more shader programs to be executed on the primitive data for rendering the primitives. Note that position specified shaders (e.g., vertex and geometry shaders) are executed on primitives; while shaders that specify how an image is to be rendered (e.g., pixel shaders) are executed on fragments covered by the primitive position.

[0107] ​A sequence of primitives provided by an application can be received at a pre-processing module 408. In a geometry processing stage, the pre-processing module 408 performs functions such as geometry processing including clipping and culling to remove primitives that do not fall in a visible view. The pre-processing module 408 can also project the primitives into screen space. The primitives output from the pre-processing module 408 are passed to a binning unit 410 for binning, as described below.

[0108] The binning unit 410 determines which primitives are present within each bin of the rendering space of the graphics processing system 400. The binning unit 410 assigns primitives to bins by creating a control stream for the bins of the rendering space, where the control stream for a bin includes an indication of the primitives present within the bin. The control stream and the primitives are output from the binning unit 410 and stored in the memory 404. The geometry processing stage (performed by the pre-processing module 408 and the binning unit 410) considers the primitives over the entire image, i.e., for all bins in the image. Then, in a rendering stage, the rendering logic 412 renders the bins of the image and stores the output of the rendered bins in the appropriate portions of the frame buffer, such that when all of the bins of the image have been rendered, the frame buffer stores the rendered results of the entire complete image.

[0109] At step 602, a first rendering is performed by assigning a set of one or more bins to a processor group 502i, 5022, 5023for rendering and outputting data of the processed bins to a region of the memory resource 414.

[0110] The scheduling logic 416 assigns a set of one or more bins to a processor group based on a scheduling order. The scheduling order can be, for example, a raster scan order. Alternatively, the scheduling logic can implement some other scheduling order, such as a Z order. When a processor group finishes processing an assigned set of bins, the scheduling logic assigns a next set of bins to the available group according to the implemented scheduling order.

[0111] Each set of bins can include one or more bins. Similar to the examples described above with reference to Figure 2 Each set of bins can be arranged in contiguous bins within the rendering space (in the case that more than one bin is present in a set). That is, each set of bins can be arranged as a bin block within the rendering space. Also, each set of bins can be formed by bins that are spatially separated within the rendering space. Each set of bins can or can not contain the same number of bins.

[0112] In the examples described herein, the processing of each particular tile is performed by a single processor core 422 within a processor group; that is, the processing of a tile is not divided among multiple cores 422 of a processor group (in cases where a processor group contains multiple cores). However, it should be noted that in some other examples, the processing of a single tile can be divided among multiple processor cores within a particular processor group. Further, in the examples described herein, in cases where a set of tiles contains more than one tile, the tiles assigned to a particular set of processor groups can be processed by one or more processor cores within the group. However, the processing of the assigned set of tiles is not divided among multiple processor groups.

[0113] As part of performing the first rendering, the fetch unit 418 of the processing logic 412 fetches primitive data to render a tile and provides the data to a selected one of the processor groups based on the schedule determined by the scheduling logic 416.

[0114] The processing logic 420 performs operations on the primitive data of a tile using the processor cores 422 in order to render the tile. The processing logic can contain other processing and / or memory resources, such as registers, caches, control logic, etc., for performing the processing of the primitive data using the processor cores 422. The memory resources 414 can be used to store data used and / or generated by the processor cores 422. The processor cores can output data generated by the processing of the assigned tiles as part of the first rendering to an area of the memory resources. For example, the memory resources can be one or more caches, buffers, or memories. Each processor core 422 can have a dedicated memory resource, or each set of processor cores 422 can have a dedicated memory resource. The one or more memory resources can have any suitable structure, for example, a cache can be single-level or multi-level.

[0115] The memory resources 414 can be arranged such that an area of the memory resources is associated with a tile of the render space. That is, each area of the memory resources can store data generated by the processing of the one or more tiles associated with the area. For example, each tile of the render space can be associated with a respective area of the memory resources. More generally, each area of the memory resources 414 can be associated with a respective block of one or more tiles of the render space. These tile blocks can correspond to the same tile blocks that form the set of tiles assigned to a processor group. Alternatively, the tile blocks associated with each area of the memory can have a different size than the tile blocks that form the set of tiles assigned to a processor group. Thus, the memory resources 414 can be arranged as a two-dimensional array of areas corresponding to the tiles of the render space, where each area of the array corresponds to one or more tiles of the render space.

[0116] The processing logic 420 can perform deferred rendering such that hidden surface removal is performed on the primitives to remove primitive fragments that are hidden by other primitives in the scene, and then texturing and / or shading is applied to the primitive fragments after the hidden surface removal has been applied to the primitive fragments. Texturing generally involves reading texture data from memory and applying a texture to a primitive fragment in order to determine a color value for the rendered primitive fragment. Shading generally involves executing a shader program on a primitive fragment in order to add visual effects to the rendering of the primitive fragment. These shader programs are the shader programs mentioned above that are compiled by the compiler 432 and provided to the rendering logic 420.

[0117] In other examples, the processing logic 420 can perform non-deferred rendering such that texturing and / or shading is applied to the primitive fragments first, and then hidden surface removal is performed on the textured / shaded primitive fragments to remove primitive fragments that are hidden by other primitives in the scene. Non-deferred rendering methods can be less efficient than deferred rendering methods because they involve unnecessary shading and texturing of primitive fragments that are ultimately hidden in the scene.

[0118] Both the deferred rendering and non-deferred rendering systems described above implement rasterization techniques to render the primitive data. In other examples, other rendering techniques can be used in the rendering logic, for example, ray tracing techniques can be used to render the primitive data.

[0119] When the processor core 422 completes processing of a tile, it outputs the results of the processing for storage in an associated region of the memory resource 414 (i.e., the region of the memory resource associated with the tile).

[0120] At step 604, a set of one or more tiles for a second rendering is assigned to at least one group of processor cores for processing while at least one other group of processor cores has not completed processing of a set of tiles as part of the first rendering.

[0121] The second rendering can be initiated by the scheduling logic 416. The scheduling logic can assign a set of one or more tiles for the second rendering to a group of processor cores that has completed processing of a set of tiles for the first rendering. A group of processors can be considered to have completed processing of a set of tiles for the first rendering when each processor core within the group has finished processing of the assigned tiles.

[0122] Figure 7 Examples are illustrated of the time it takes for each processor core 422 to complete processing of the tiles it is assigned for the first rendering, and thus the time it takes for each group of processors 5021, 5022, 5023 to complete processing of the set of tiles it is assigned for the first rendering. The vertical axis is the time elapsed from the start of the first rendering, with time increasing in the downward direction.

[0123] Blocks 702i-7029represent the time spent by the respective processor core 422i-4229in processing its assigned tiles for the first rendering. For clarity, the division of the time among different tiles (and tile sets) is not shown here. Thus, a given time block (e.g., block 7027) can represent the time that processor core 422 processed multiple tiles and / or tile sets.

[0124] The rendering end time, i.e., the time taken to complete the first rendering, is shown at 704. The first rendering is completed when all tiles for the first rendering have been rendered by the processor cores. Thus, the rendering end time is generated when the processing of the final tile of the first rendering is completed. As described above, the tile whose processing is last completed can not necessarily be the tile that was last assigned to the processor core.

[0125] The first processor group completes processing of the assigned tile set at time 706; and the second processor group completes processing of the assigned tile set at time 708. Both times 706 and 708 are prior to the rendering end time 704. The third processor group completes processing of the assigned tile set at time 704.

[0126] The scheduling logic 416 can assign a tile set for the second rendering to the first processor group at any time after time 706 (and prior to the end time 704), and can assign a tile set for the second rendering to the second processor group at any time after time 708 (e.g., prior to the end time 704). Thus, the scheduling logic 416 initiates the second rendering prior to completion of the first rendering.

[0127] To minimize idle time, the scheduling logic 416 can initiate the second rendering by assigning a tile set for the second rendering to the first processor group at time 706. At this time, the other processor groups have all completed processing of the first rendering of the assigned tile set. The scheduling logic 416 can then also begin assigning tile sets to the second processor group at time 708. The scheduling logic 416 can additionally begin assigning tile sets for the second rendering to the third processor group after the rendering end time 704. Operating the scheduling logic in this manner can advantageously reduce idle time of the processor cores.

[0128] It should be noted that idle time can still exist in the system (e.g., in the third processor group) even if a tile set for the second rendering is assigned to each processor group within the group only when the processing of the first rendering by each processor core in the group has been completed. Figure 7The intervals ΔΤ1, ΔΤ3, ΔΤ4, ΔΤ5, ΔΤ8, and ΔΤ9 are illustrated as time intervals. However, waiting for each processor core within a group to complete processing of a first render before assigning processor cores in the group to a set of tiles for a second render can provide other advantages, particularly when processor cores of a given group share resources of a graphics system. This scenario is explained in greater detail below.

[0129] In summary, the scheduling logic 416 is configured to assign a set of one or more tiles to processor cores to perform a first render, and to initiate a second render by assigning a set of tiles for the second render to at least one of the other groups of processor cores and using the processor group to process those assigned tiles for the second render when at least one group of processor cores has not completed processing of the assigned set of tiles as part of the first render. This can advantageously reduce idle time of the processor cores between renders.

[0130] At step 606, in response to a processor core requesting access to a region of the memory resource 414 as part of the second render, the progress indication is checked. The progress indication indicates progress of the first render.

[0131] At step 608, in response to the progress indication indicating that processing of the region of the resource indicated in the request has completed for the first render, the region of the resource is accessed.

[0132] The progress indication is checked each time a processor core requests access to a region of the memory resource 414 while the processor core is processing the tiles assigned to it as part of the second render. The region of the memory resource 414 is available for use by the processor core while processing the assigned set of tiles as part of the first render. The processor core can wish to access the region of the memory resource to access data generated by the first render. For example, if the first render generates a texture, and the second render is to generate a down-sampled version of the texture (e.g., for mip-mapping), the processor core processing the set of tiles as part of the second render can need to reference data from the first render. Or, the second render can apply a filter (e.g., blur) to the result of the first render. As another example, the first render can generate a shadow map, and as part of the second render, the shadow map is to be applied to an image. In general, a subsequent render can be said to depend on a first render if data from the first render needs to be accessed or referenced in the subsequent render in order to complete the subsequent render.

[0133] Step 606 is implemented by progress check logic 428, which in this example is part of memory resource access unit 424. As shown, memory resource access unit 424 can be a separate component from processing logic 420 (but connected with processing logic 420). In alternative configurations, memory resource access unit 424 can form part of processing logic 420.

[0134] When processor core 422 requests access to a region of memory resource 414 (e.g., in order to perform a processing task as part of a second rendering), the request can be received by memory resource access unit 424. Progress check logic 428 then checks the progress of the first rendering for this access request. If the progress indication indicates that processing of the first rendering has been completed for the region of memory resource 414, then memory resource access unit 424 grants the access request to the region of the memory resource. Memory resource access unit 424 can transmit an indication to the processor core that the access request has been granted. In response, the processor core can access the requested region of the memory resource to retrieve the appropriate data stored in the region. Alternatively, in response to granting the request, memory resource access unit 424 can forward the request to the memory resource. The memory resource can then return the appropriate data stored in the region of the memory resource. The data can be returned through the memory resource access unit or directly to the processor core that initiated the request. If the progress indication indicates that processing of the first rendering has not been completed for the region of the memory resource, then memory resource access unit 424 denies the processor core access to the data stored in the region. This prevents processor core 422 from accessing incorrect data in memory resource 414 in cases where data from the first rendering has not yet been written to the region of the memory resource, or in cases where the data stored in the region can still be modified by the remaining processing of the first rendering.

[0135] If the data stored in a region of the memory resource can no longer be modified by the first rendering (i.e., can no longer be modified because the set of tiles assigned to the processor group are still being processed as part of the first rendering), then it can be determined that processing of the first rendering for the region of the resource is complete. Such a region can be referred to as a set or complete region of the first rendering. If a region of the memory resource can still be modified by the first rendering, then the region can be referred to as a mutable region.

[0136] The progress indication can be maintained or generated by progress indication logic 426. Progress indication logic 426 is shown in this example as a separate component from check logic 428, but in another implementation, check logic 428 and progress indication logic 426 can both be implemented as a single piece of progress logic configured to perform the functions of both check logic 428 and progress indication logic 426.

[0137] The progress indication logic can be configured to update the progress indication for the region of the memory resource 414 according to the update scheme as the first rendering progresses. Examples of the form of the progress indication and the way in which it can be updated are described below.

[0138] The progress check logic 428 can be configured to recheck the progress indication each time the progress indication logic 426 updates the progress indication. That is, the progress check logic can recheck the progress of the first rendering for the region of the memory resource to which the access request relates. If, following the recheck, the progress indication indicates that the processing of the first rendering has been completed for the region of the memory resource, the memory resource access unit 424 grants the access request for the memory region and retrieves the data stored in the region or indicates to the processor core that it can now retrieve the data. By rechecking the progress indication for the access request each time the progress indication is updated, the access request latency can be reduced.

[0139] As described above, in this example, the memory resource 414 is arranged such that regions of the memory resource are associated with tiles of the rendering space. That is, the data for a tile is stored within a particular region of the memory resource. In this way, there can be a mapping between the regions of the memory resource and the spatial locations of the tiles within the rendering space. This is convenient because it enables the progress of the first rendering with respect to the tiles of the rendering space to be mapped to the regions of the memory resource. In other words, a request to access a region of the memory resource can be mapped to the rendering space, where a comparison with the progress indication can determine whether the region of the rendering space has completed processing of the first rendering.

[0140] The progress indication maintained by the progress indication logic 426 indicates the rendering regions in the rendering space for which the processing of the first rendering has been completed. The rendering regions can specify the finest granularity of the progress of the first rendering that can be known. That is, the rendering regions can be the smallest regions in the rendering space for which it can be known whether the processing of the first rendering has been completed. Each rendering region can comprise at least one tile. More specifically, each rendering region can have at least the same size as each set of one or more tiles allocated to the processor core 422 (i.e. have at least the same height and width as it). Thus, each rendering region can comprise at least one set of tiles. In other words, in the examples described herein, the granularity of the rendering regions can be equal to or coarser than the granularity of the sets of tiles in the rendering space. In some cases, each rendering region can be larger (in one or both dimensions) than the set of one or more tiles allocated to the processor core (i.e. each rendering region comprises multiple sets of tiles). As a simple illustration and returning to the example of Figure 2, the rendering space 202 can be divided into a grid of tiles 204. The grid of tiles 204 can be divided into sets of tiles 206. Each set of tiles 206 can be allocated to a processor core 208. In this example, the rendering space 202 can be divided into rendering regions 210. Each rendering region 210 can comprise at least one set of tiles 206. In this example, the rendering regions 210 can be equal in size to the sets of tiles 206. In other words, each rendering region 210 can comprise a single set of tiles 206. In other examples, the rendering regions 210 can be larger than the sets of tiles 206 (in one or both dimensions). In other words, each rendering region 210 can comprise multiple sets of tiles 206. Figure 2The rendering space can be divided into four rendering regions in a 2x2 arrangement, where each rendering region comprises a 2x1 arrangement of tile sets (each tile set comprising a 2x3 block of tiles). That is, a first rendering region comprises tile sets (0,0) and (0,1); a second rendering region comprises tile sets (0,2) and (0,3); a third rendering region comprises tile sets (1,0) and (1,1); and a fourth rendering region comprises tile sets (1,2) and (1,3).

[0141] In one example, the progress indication takes the form of a set of flags corresponding to each of the rendering regions. That is, each flag in the set corresponds to a respective rendering region. The value of a flag can indicate whether the first rendering of each tile located within the corresponding rendering region has been completed. For example, if the first rendering of each tile located within a given rendering region has been completed, then the flag for that rendering region can be set. If the first rendering of a given rendering region has not been completed (i.e. processing of one or more tiles within that rendering region has not been completed), then the flag associated with that rendering region can not be set. Thus, by reference to the set of flags, it is possible to know which rendering regions in the rendering space have completed processing of the first rendering.

[0142] Figure 8 An illustration of how the flags can be used to identify regions in the rendering space for which the first rendering has been completed.

[0143] Figure 8 A rendering space 200 is shown divided into a plurality of rendering regions 8021-8024. Each rendering region comprises two tile sets arranged in a 2x1 block. Each tile set itself comprises a block of 2x3 tiles, as shown in FIGS. 1-3 above and described in detail in the background section. Figure 2 The rendering regions are delineated by thick boundary lines, with the tile sets delineated by thin boundary lines. For clarity, individual tiles are not illustrated in Figure 8 The rendering regions are delineated by thick boundary lines, with the tile sets delineated by thin boundary lines. For clarity, individual tiles are not illustrated in

[0144] An example of how the memory resource access unit 424 can use the flags to grant or block requests for portions of the memory resource 414 will now be described.

[0145] The following example is contemplated: as part of the second rendering, processor core 422 is processing a tile and makes an access request to a region of memory resources 414 to access data from the first rendering. Note that the access request need not correspond to a region of memory resources 414 associated with a tile being processed at processor core 422 as part of the second rendering, and there need not be any correspondence between the rendering spaces, tile configurations, etc. of the two renderings. The requested memory address and / or screen space location can correspond to any location within the rendering space of the first rendering. Progress check logic 428 receives the access request and determines from the requested memory address that the request is for data of a tile within tile set 804 that is located within rendering region 8021. Checking the set of flags maintained by progress indication logic 426 confirms that the flag for the rendering region is set and thus processing of the first rendering for the region of memory resources has been completed (i.e., the first rendering for the tile corresponding to the region of memory resources has been completed). In response, memory resource access unit 424 can grant access to the requested region of memory resources. In another example, progress check logic 428 can receive an access request and determine from the requested memory address that the request is for data of a tile located within rendering region 8023. Then, progress check logic 428 checks the set of flags maintained by progress indication logic 426 and determines that the flag associated with rendering region 8023 is not set (i.e., processing of the first rendering for at least one tile within rendering region 8023 has not been completed). In response, memory resource access unit 424 can block access to the requested region of memory resources.

[0146] Note that because the rendering regions and tiles (or tile sets) can have different granularities, it is possible that an access request can be blocked when the required processing of the first rendering for the request has actually been completed. This is because the flags do not indicate the tiles (or tile sets) within a rendering region for which processing of the first rendering has been completed and not completed; if at least one tile within a rendering region has not been rendered for the first rendering, then the flag for the entire rendering region is not set. One solution to this problem is to increase the granularity of the rendering regions, e.g., by associating a flag with each individual tile. However, this approach has the disadvantage of increasing the data storage requirement for storing the progress indications by the number of flags. Thus, while having each rendering region cover multiple tiles can result in some access requests being unnecessarily blocked, it does provide the advantage of reducing the data storage requirement for the flags.

[0147] Progress indication logic 426 can update (i.e., change) the value of a flag when the first rendering for each tile located within the rendering region has been completed. If setting the flag indicates that the first rendering for the rendering region has been completed, then progress indication logic 426 can set the flag for the rendering region upon completion of the first rendering for each tile within the rendering region.

[0148] It is convenient to use a flag to indicate the progress of the first rendering because it enables the progress indication of each rendering region that has been rendered according to the first rendering to be identified regardless of the spatial location of the rendering region within the rendering space.

[0149] Alternatively, the progress indication maintained by the progress indication logic 426 can take the form of a count value. The progress indication logic 426 can implement a counter to maintain the count value. The counter can count the number of consecutive rendering regions that have been rendered according to the first rendering. The consecutive rendering regions can be rendering regions in a sequence in a predetermined order within the rendering space. For example, the predetermined order can be a raster scan, a boustrophedon order, a z-order, etc. The sequence can be counted from a predetermined location within the rendering space. For example, the sequence of rendering regions can start at the top left-most rendering region of the rendering space. The counter can stop when the first rendering region encountered in the ordered sequence has not completed its first rendering processing. The progress indication logic can be configured to increment the counter when the first rendering processing of a rendering region is completed, which extends the sequence of consecutive rendering regions that have completed the first rendering processing.

[0150] For example, with reference to Figure 8 , a counter configured to count the number of consecutive rendering regions that have completed the first rendering following a raster scan order would have a value of one (corresponding to rendering region 8021). If the rendering region 8022 of the first rendering is completed before the rendering region 8023, then the counter would be incremented to two because the completion of the rendering of the rendering region 8022 would extend the sequence of rendering regions that have completed the first rendering to two (corresponding to rendering regions 8021, 8022). However, if the rendering region 8023 of the first rendering is completed before the rendering region 8022, then the counter would not be incremented because the number of consecutive rendering regions that have completed has not increased. By using knowledge of the count value and the predetermined order of the rendering regions within the rendering space, the progress check logic 428 can determine which rendering regions have completed the first rendering processing.

[0151] The counter can be implemented in conjunction with a FIFO buffer. Both the counter and the buffer can form part of the progress indication logic 426. The FIFO buffer can be used to control the incrementing of the counter. Each rendering region can be associated with a respective value (e.g., '0' or '1'). The buffer is configured to generate a sequence of values corresponding to the rendering regions in a predetermined order (e.g., raster scan, herringbone, z-order, etc.) within the rendering space. If the leading value of the sequence indicates that the corresponding rendering region has completed processing of the first rendering (e.g., the value is '1'), then the value is output from the buffer and, in response, the counter is incremented. That is, the counter can be configured to increment each time a value is output from the buffer. When the leading value in the buffer indicates that the corresponding rendering region has not completed processing of the first rendering (e.g., the leading value is '0'), then the value is not output from the buffer and subsequent values received at the buffer are added to the trailing end of the buffer in sequence. When the rendering region corresponding to the leading value held in the buffer completes processing of the first rendering, the leading value is changed to reflect this and then output from the buffer so that the counter is incremented.

[0152] For example, the buffer can initially be empty. If rendering region 802i is the first rendering region to complete the first rendering, then a '1' is input into the buffer and then output, causing the counter to be incremented to '1'. If the next rendering region to complete the first rendering is 8024, then the string '001' is input into the buffer. This string indicates that the subsequent rendering regions 8022 and 8023 in the sequence have not completed the first rendering, but that rendering region 8024 has. The leading '0' value in the buffer prevents the value '1' from being output and causes the counter to be incremented. Thus, the bit for rendering region 8024 that has completed is effectively queued behind the placeholder '0' values representing rendering regions that have not yet completed. If a rendering region that has a '0' value stored in the buffer completes, then this value is modified and set to '1'. For example, if rendering region 8023 is the next completed rendering region, then the string stored in the buffer is modified to '011', with the '0' value indicating that rendering region 8022 has not completed. In contrast, if the next completed rendering region is 8022, then the string in the buffer is modified to '101'. Next, the leading '1' bit is output from the buffer, causing the counter to be incremented and leaving the string '01' in the buffer.

[0153] In some embodiments, it is possible for different processing cores (e.g., belonging to different processor groups) to share processing resources (e.g., texture processing units) of the graphics processing system. If two (or more) processor cores share a common resource but belong to different processor groups, then it is possible for one of the processor cores to begin processing a tile as part of a second rendering while another processor core (sharing the same processing resource) is still processing a tile as part of a first rendering.

[0154] Because the two processor cores share the same resources, scheduling the other processor core to start processing a tile for a second rendering while one of the processor cores is still processing a tile for a first rendering can cause a processing resource deadlock. For example, a deadlock can occur when a processor core needs to access a hardware resource to complete its processing of a first rendering but access to the hardware resource is prevented because the processor core is processing a tile as part of a second rendering.

[0155] An illustrative diagram showing how a deadlock can occur is shown in Figure 9

[0156] In Figure 9 In the diagram 900, processor core A is processing an assigned set of one or more tiles as part of a rendering N+1, and processor core B is processing an assigned set of one or more tiles as part of a rendering N (prior to rendering N+1). Rendering N can be referred to as a first rendering, and rendering N+1 can be referred to as a second rendering. Block 902 represents the time processor core A spends processing the assigned set of tiles, and block 904 represents the time processor core B spends processing the assigned set of tiles.

[0157] At time 906, processor core A accesses a hardware resource 908 to obtain data elements or values from a region of a memory resource 910. For example, the hardware resource 908 can be a texture processor unit that processes texels requests, and the data elements can be texel values stored in the memory resource 910. In other words, processor core A is requesting (through hardware resource 908) access to a region of memory resource 910. The hardware resource 908 is shared by processor cores A and B.

[0158] Upon checking the progress indication, the hardware resource 908 determines that the processing of the first rendering has not been completed for the memory region that processor core A is requesting access to (e.g., the flag for the region has not been set). Thus, the access request is blocked and remains pending within the hardware resource 908.

[0159] At time 912, processor core B requests access to the shared hardware resource 908 as part of its processing of the first rendering. However, the hardware resource is still blocked by the prior request of processor core A. Thus, the memory access request of core A cannot be granted, and access to the hardware resource by core B cannot be granted (as core A's request blocks the hardware resource), which means that core B cannot complete its processing of the first rendering. This scenario is an example of a deadlock.

[0160] The existence of a deadlock can cause a significant increase in latency, and in extreme cases, can prevent other processing within the processor cores and the rendering from ever completing. ​

[0161] To avoid creating a deadlock situation, the graphics processing system can include a buffer 914 that can buffer a particular request that can create a deadlock and release the shared hardware resource so that it can process a subsequent request. The buffer 914 can be referred to as a "reservation" buffer. It can form part of the memory access request unit, as shown in Figure 4 FIG. 4B (where the reservation buffer is denoted 430).

[0162] The reservation buffer 914 can be configured to buffer an access request to a region of a memory resource for which the progress indication indicates that processing of the first rendering has not been completed. The buffer can store the access request by storing data indicating the location of the region of the memory resource for which access has been requested. The buffer can also store an indication of the processor core that made the request. If the processing of the region of the memory resource in the access request has been completed for the first rendering, then the request will not block the shared hardware resource 908 and therefore does not need to be buffered.

[0163] The reservation buffer is arranged so that once it buffers an access request, the access request does not hinder or block a subsequent request for the shared processing resource 908. Thus, the reservation buffer is arranged so that a (temporally) subsequent request for the processing resource required to complete the processing of the region of the memory resource specified by a (temporally) previous access request located in the buffer is not hindered by the previous access request.

[0164] In other words, the reservation buffer 914 can buffer an access request made by core A at time 906, which means that this request does not hinder a hardware resource request made by core B at time 912, thereby avoiding a deadlock.

[0165] The reservation buffer can be controlled by the progress check logic 428. For example, the progress check logic can be configured to buffer an access request to a region of a memory resource in response to the progress indication indicating that processing of the first rendering has not been completed for the region of the memory resource. This arrangement is convenient because the progress check logic can easily check the value of the progress indication.

[0166] The progress check logic 428 can be configured to grant an access request to a region of a memory resource that is buffered within the reservation buffer in response to the progress indication being updated to indicate that processing of the first rendering has been completed for the region of the memory resource (e.g., in response to a flag associated with the region of the memory resource being set). At this point, the progress check logic can remove the access request from the reservation buffer.

[0167] The above examples describe how a graphics processing system can initiate a second rendering by processing a set of tiles at a group of one or more processor cores while at least one other group of processor cores is still processing assigned tiles as part of a first (prior) rendering. By checking the progress of the first rendering in response to a processor core processing a tile as part of the second rendering requesting access to data in a memory resource, the processor core processing the tile as part of the second rendering can be prevented from accessing memory regions that can still be modified by the first rendering. Thus, the second rendering can be initiated before the first rendering is completed (which has the potential to reduce processor core idle time) while reducing the likelihood that the second rendering adversely affects the first rendering.

[0168] Several changes and modifications can be made to the above-described examples.

[0169] For example, in the examples described thus far, the processing logic includes a number of processor cores arranged in groups of three. In other examples, each processor group can contain more or fewer processor cores. For example, each processor group can contain a single processor core. In Figure 10 An example of how a graphics processing unit initiates a second rendering as part of performing step 604 in the case where each processor group contains a single processor core is described in the following.

[0170] Figure 10 The workload distribution of the processor cores 4221-4229 is shown. Each processor core forms a respective processor group. Blocks 10021-10029 represent the time taken by the respective processor cores 4221-4229 to complete processing of the first rendering of the assigned set of one or more tiles. The end time of the first rendering is shown at 1004, and corresponds to the time taken by the processor core 4227 of the seventh processor group to complete its processing of the first rendering.

[0171] The processor core 4223 of the third group completes its processing of the first rendering at time 1006 (which occurs before the end time 1004).

[0172] The scheduling logic 416 can assign the set of one or more tiles for the second rendering to the processor core 4223 at any time after time 1006 (and before time 1004). The processor core 4223 can then initiate the second rendering by processing the assigned set of one or more tiles. To minimize idle time, the scheduling logic can assign the set of one or more tiles for the second rendering to the processor core 4223 at time 1006.

[0173] Similarly, processor core 4221 completes its processing of the first render at time 1008 (prior to the end of render time 1004). Thus, the scheduling logic can assign a set of one or more tiles to processor core 4221 for the second render at any time after time 1008 and prior to time 1004. Processor core 4221 can then process the assigned set of tiles for the second render. Again, to minimize idle time, the scheduling logic can assign a set of one or more tiles to processor core 4221 at time 1008.

[0174] The scheduling logic can assign a set of one or more tiles for the second render to each of processor cores 4222, 4224-4226, and 4228, 4229 in a similar manner, as each of these processor cores completes its processing of the first render prior to the end of render time 1004.

[0175] According to Figure 7 and 10 A comparison can be made that arranging each processor group to contain only a single processor core can further reduce idle time for the individual processor cores. This is because, in the case where a processor group contains multiple processor cores, a set of tiles for the second render can not be assigned to the group until each processor core within the processor group has completed its processing of the first render. However, a particular graphics processing system can contain processor groups formed of multiple processor cores because of hardware efficiencies that can be obtained with such an arrangement, such as each processor core in a group sharing physical resources (e.g., a texture unit).

[0176] The examples described herein have been referred to as a 'first' render and a'second' render. It should be understood that those terms are used for purposes of illustration to define the relative order of the renders; the labels 'first' and'second' are not intended to imply any absolute order of the renders performed by the graphics processing system, i.e., the 'first render' described herein can not necessarily be the first render performed by the graphics processing system. Furthermore, although the examples described herein refer to initiating the second render prior to completion of the first render, it should be appreciated that the techniques described herein are applicable to longer sequences of renders. For example, a graphics processing unit can be used to initiate a third render prior to completion of the second render, a fourth render prior to completion of the third render, and so on.

[0177] Thus far, examples have been described in the context of graphics processing systems that have been using a rendering space subdivided into a plurality of tiles to process graphics data. However, the techniques described herein are not limited to such applications, and can be applicable to rendering that does not utilize a tile-based graphics pipeline. Moreover, although the above examples have been described in the context of rendering of two-dimensional image / texture data, the techniques described herein are applicable to rendering of other types of graphics data, which can be one-dimensional (ID), two-dimensional (2D), or three-dimensional (3D) data.

[0178] Thus, more generally, the processor groups can be configured to render graphics data (e.g., ID, 2D, or 3D data) by processing assigned rendering tasks, respectively. Those rendering tasks can specify graphics data for a set of tiles of a rendering space (as in the above examples), but can also specify rendering of other types of graphics data. As the processor cores in the groups process the rendering tasks, data generated by processing those tasks is output to regions of a memory resource. Progress indication logic can then be configured to track progress of a first rendering by identifying which regions of the memory resource are associated with rendering tasks of the first rendering that have been completed. That is, the progress indication logic identifies regions of the memory resource for which processing of rendering tasks of the first rendering has been completed. The progress indication logic can maintain a progress indication that indicates progress of the first rendering. The progress indication can be in the form of flags, where a flag for each region of the memory resource is set when processing of the first rendering for that region is complete (i.e., when data in that region can no longer be modified as a result of the processor groups performing the first rendering). Regions of the memory resource that contain data that can still be modified by the first rendering (and thus can not have an associated set flag) can be referred to as mutable regions. Regions of the memory resource that contain data that can no longer be modified by the first rendering can be referred to as set or completed regions. When a processor core requests access to a region of the memory resource to process an assigned rendering task of a second rendering, the progress check logic first checks the progress indication maintained by the progress indication logic to determine progress of the first rendering. If the progress indication indicates that processing of the first rendering for that region has been completed (e.g., the region is a completed or set region), then the processor core is granted access to that region. If the progress indication indicates that processing of the first rendering for that region has not been completed (e.g., the region is a mutable region), then the processor core is denied access to that region. The progress indication can include a set of flags. Each flag can correspond to a region of the memory resource, and the progress indication logic can set a flag associated with a region of the resource when processing of the first rendering for that region has been completed (in the above example, the flags correspond to regions of the memory resource, and to tiles of the rendering space by way of a mapping between regions of the resource and tiles of the rendering space). This control of access to regions of the memory resource can also be controlled by the memory resource access unit, as in the above example.

[0179] Thus, in accordance with the techniques described herein, a graphics processing unit configured to process graphics data can be provided, the graphics processing unit comprising: a plurality of processor groups, each processor group formed of one or more processor cores and configured to render graphics data by processing assigned rendering tasks, wherein data of processed rendering tasks is output to a region of a memory resource; scheduling logic configured to: assign rendering tasks to the processor groups for processing to perform a first rendering; assign at least one rendering task of a second rendering to at least one of the other processor groups for processing while at least one of the processor groups has not completed processing of assigned rendering tasks as part of the first rendering; progress indication logic configured to maintain a progress indication indicating progress of the first rendering, the progress indication indicating a region of the memory resource for which processing of the first rendering has been completed; and progress checking logic configured to check the progress indication in response to a processor core requesting access to a region of the memory resource as part of the second rendering, and cause the processor core to access the region in response to the progress indication indicating that processing of the first rendering for the region of the resource has been completed.

[0180] A method of processing graphics data in a graphics processing unit comprising a plurality of groups of one or more processor cores can also be provided, the method comprising: performing a first rendering by assigning rendering tiles to the plurality of groups of processor cores for rendering and outputting data of processed rendering tasks to a region of a memory resource; assigning at least one rendering task for a second rendering to at least one of the other processor groups for processing while at least one of the plurality of groups of one or more processor cores has not completed processing of assigned rendering tasks as part of the first rendering; maintaining a progress indication indicating progress of the first rendering, the progress indication indicating a region of the memory resource for which processing of the first rendering has been completed; checking the progress indication in response to a processor core requesting access to a region of the memory resource as part of the second rendering; and accessing the region of the memory resource in response to the progress indication indicating that processing of the first rendering for the region of the memory resource has been completed.

[0181] For example, the processor complex can be configured to render 3D graphics data, e.g., as part of a fluid simulation. In this case, the processor core can be configured to process an assigned rendering task of a first rendering to generate simulation values for voxels, and then output those values to a region of a memory resource. Thus, each region of the memory resource can store data for a set of one or more voxels, and thus each region is associated with the set of one or more voxels. A second rendering can then be initiated prior to simulation values for all voxels being generated as part of the first rendering. As long as a voxel is associated with a set or completed region of the memory resource of the first rendering, the processor core can process an assigned rendering task to generate a simulation value for the voxel as part of the second rendering - without waiting for the computation of simulation values for all voxels as part of the first rendering.

[0182] Reference Figures 4 to 10 The described graphics processing system is shown as including a number of functional blocks. This is merely illustrative and is not intended to limit the strict partitioning between different logical elements of such entities. Each functional block can be provided in any suitable manner. It should be understood that the intermediate values described herein as being formed by the graphics processing system or graphics processing unit need not be physically generated by the graphics processing unit at any one time, and can simply represent logical values that facilitate describing the processing performed by the graphics processing unit / system between its inputs and outputs.

[0183] The graphics processing system / unit described herein can be embodied on an integrated circuit as hardware. The graphics processing system / unit described herein can be configured to perform any of the methods described herein. In general, any of the functions, methods, techniques, or means described above can 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" can be used generically herein to represent a software, firmware, hardware, or any combination thereof. In the case of a software implementation, the module, functionality, component, element, unit, block, or logic represents program code that performs specified tasks when executed on a processor. The algorithms and methods described herein can be performed by one or more processors executing code, the code causing the processor(s) to perform the algorithms / methods. Examples of computer-readable storage media include random access memory (RAM), read-only memory (ROM), optical disc drives, flash drives, hard drives, and solid-state drives, as well as any storage media that can be used to store or access instructions or other data that can be accessed by a machine.

[0184] The terms "computer program code" and "computer readable instructions" as used herein refer to any kind of executable code, including code expressed in machine language, interpreted language, or scripting language, for execution by a processor. Executable code includes binary code, machine code, byte code, code defining integrated circuits (e.g., a hardware description language or netlist), and code expressed in a programming language such as C, Java, or OpenCL. Executable code can be, for example, any kind of software, firmware, script, module, or library that, when executed, processed, interpreted, compiled in an appropriate software environment, or virtual machine, causes a processor of the computer system supporting the executable code to perform the tasks specified by the code.

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

[0186] The present application is also intended to include software that defines the configuration of the hardware described herein, such as HDL software, for use in the design and fabrication of an integrated circuit, or to configure a programmable chip to perform the desired function. That is, a computer readable storage medium can be provided having computer readable program code embodied therein that, when processed by a system configured to fabricate integrated circuits, configures the system to fabricate a graphics processing unit configured to perform any of the methods described herein, or to fabricate a graphics processing unit that includes any of the apparatus described herein. The integrated circuit definition data set can be, for example, an integrated circuit description.

[0187] A method of fabricating a graphics processing unit as described herein at an integrated circuit fabrication system can be provided. An integrated circuit definition data set can be provided that, when processed in an integrated circuit fabrication system, causes the method of fabricating a graphics processing unit to be performed.

[0188] The integrated circuit definition data set can be in the form of computer code, for example as a netlist, code for configuring programmable chips, as a hardware description language defining the integrated circuit at any level of abstraction, 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. Higher level representations of the integrated circuit defining the same, for example RTL, can be processed at a computer system configured to generate a manufacturing definition of the integrated circuit in the context of a software environment comprising definitions of circuit elements and rules for combining those elements to generate a manufacturing definition of the integrated circuit defined by the representation. As with software that is typically executed on a computer system to define a machine, one or more intermediate user steps (e.g., providing commands, variables, etc.) can be required to configure the computer system for generating a manufacturing definition of the integrated circuit, to execute the code defining the integrated circuit, to generate the manufacturing definition of the integrated circuit.

[0189] Reference will now be made to Figure 11 An example of processing an integrated circuit definition data set at an integrated circuit manufacturing system to configure the system to manufacture a graphics processing unit is described.

[0190] Figure 11 An example of an integrated circuit (IC) manufacturing system 1102 configured to manufacture a graphics processing unit as described in any of the examples herein is shown. In particular, the IC manufacturing system 1102 includes a layout processing system 1104 and an integrated circuit generation system 1106. The IC manufacturing system 1102 is configured to receive an IC definition data set (e.g., defining as described in any of the examples herein), process the IC definition data set, and generate an IC (e.g., embodying a graphics processing unit as described in any of the examples herein) from the IC definition data set. The processing of the IC definition data set configures the IC manufacturing system 1102 to manufacture an integrated circuit embodying a graphics processing unit as described in any of the examples herein.

[0191] The layout processing system 1104 is configured to receive and process the IC definition data set to determine a circuit layout. Methods of determining a circuit layout from an IC definition data set are known in the art and can involve, for example, 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, a circuit layout can be determined from the gate level representation of the circuit. This can be done automatically or with user involvement to optimize the circuit layout. When the layout processing system 1104 has determined a circuit layout, it can output a circuit layout definition to the IC generation system 1106. The circuit layout definition can be, for example, a circuit layout description.

[0192] As is known in the art, the IC production system 1106 produces an IC according to the circuit layout definition. For example, the IC production system 1106 can implement a semiconductor device manufacturing process that produces an IC, which can involve a multi-step sequence of photolithographic 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 that can be used in a photolithographic process to produce the IC according to the circuit definition. Alternatively, the circuit layout definition provided to the IC production system 1106 can be in the form of computer readable code that can be used by the IC production system 1106 to form a suitable mask for producing the IC.

[0193] The different processes performed by the IC manufacturing system 1102 can all be implemented at one location, e.g., by one party. Alternatively, the IC manufacturing system 1102 can be a distributed system such that some processes can be performed at different locations and can be performed by different parties. For example, some of the following stages can be performed at different locations and / or by different parties: (i) synthesis of RTL code representing the IC definition data set to form a gate level representation of the circuit to be produced, (ii) production of a circuit layout based on the gate level representation, (iii) formation of a mask according to the circuit layout, and (iv) use of the mask to manufacture an integrated circuit.

[0194] In other examples, processing of the integrated circuit definition data set at the integrated circuit manufacturing system can configure the system to manufacture a graphics processing unit in which the IC definition data set is not processed in order to determine a circuit layout. For example, the integrated circuit definition data set can define a configuration of a reconfigurable processor (e.g., an FPGA), and processing of the data set can configure the IC manufacturing system to produce a reconfigurable processor having the defined configuration (e.g., by loading configuration data to the FPGA).

[0195] In some embodiments, when processed in the integrated circuit manufacturing system, the integrated circuit manufacturing definition data set can cause the integrated circuit manufacturing system to produce a device as described herein. For example, by configuring the integrated circuit manufacturing system in the manner described above with reference to Figure 11 the integrated circuit manufacturing definition data set, a device as described herein can be manufactured.

[0196] In some examples, the integrated circuit definition data set can include or be run in combination with software that runs on hardware defined by the data set. For example, the integrated circuit definition data set can define a reconfigurable processor (e.g., an FPGA), and the software can be run on the reconfigurable processor. Figure 11In the illustrated example, the IC production system can also be configured by the integrated circuit definition data set to load firmware onto the integrated circuit according to program code defined in the integrated circuit definition data set when the integrated circuit is manufactured, or otherwise provide program code for use with the integrated circuit.

[0197] The graphics processing units described herein can be embodied on an integrated circuit as hardware. The graphics processing units described herein can be configured to perform any of the methods described herein.

[0198] Compared to known implementations, embodiments of the concepts set forth in this application in apparatuses, devices, modules, and / or systems (and in methods practiced herein) can improve performance. Performance improvements can include one or more of improved computational performance, reduced latency, increased throughput, and / or reduced power consumption. During fabrication of such apparatuses, devices, modules, and systems, for example, in integrated circuits, trade-offs can be made between performance improvements and physical implementations, improving fabrication methods. For example, trade-offs can be made between performance improvements and layout area, matching the performance of known implementations but using less silicon. For example, this can be done by reusing functional blocks in serial fashion or sharing functional blocks between elements of the apparatus, device, module, and / or system. Conversely, concepts set forth in this application that result in improvements in physical implementations of apparatuses, devices, modules, and systems, for example, reduced silicon area, can be traded off for performance improvements. For example, this can be done by fabricating multiple instances of a module within a pre-defined area budget.

[0199] Applicant hereby expressly disclaims any priority to any application that includes claims directed to combinations of features of the application other than those features set forth in the claims included herein. Applicant hereby incorporates by reference the entire disclosure of every prior application of which Applicant is an inventor or with which Applicant is associated, including any priority document. Applicant hereby rescinds any disclaimer of claim breadth in any prior application or patent filed by Applicant or any patent that issues thereon, unless the disclaimer is also contained in an information disclosure statement as defined in 37 C.F.R. § 1.97(c). Applicant hereby withdraws any disclaimer of claim breadth made in any prior application or patent filed by Applicant or any patent that issues thereon. Applicant hereby withdraws any disclaimer of claim breadth made in any priority document. Applicant hereby withdraws any disclaimer of claim breadth made in any information disclosure statement.

Claims

1. A graphics processing unit configured to process graphics data, the graphics processing unit comprising: a plurality of processor groups, each processor group formed of one or more processor cores and each processor group configured to render graphics data by processing assigned rendering tasks, wherein data of processed rendering tasks is output to a region of a memory resource; scheduling logic configured to: assign rendering tasks to the plurality of processor groups for processing to perform a first rendering; and when at least one of the plurality of processor groups has not completed processing of assigned one or more tasks as part of the first rendering, assign at least one rendering task for a second rendering to at least one of the other processor groups for processing; progress indication logic configured to maintain a progress indication indicating progress of the first rendering, the progress indication indicating a region of the memory resource for which processing of the first rendering has been completed; and progress check logic configured to check the progress indication in response to a processor core requesting access to a region of the memory resource as part of the second rendering, and in response to the progress indication indicating that processing of the first rendering has been completed for the region of the memory resource, cause the processor core to access the region of the processor resource.

2. The graphics processing unit of claim 1, wherein the progress indication logic is configured to update the progress indication according to an update scheme as the first rendering progresses.

3. The graphics processing unit of claim 2, wherein the progress check logic is configured to recheck the progress indication each time the progress indication is updated.

4. The graphics processing unit of claim 1, wherein the progress indication logic identifies a region of the memory resource for which processing of rendering tasks of the first rendering has been completed.

5. The graphics processing unit of claim 1, wherein processing of the first rendering has not been completed for a region of the memory resource when data stored in the region of the memory resource can be modified by an uncompleted portion of the first rendering.

6. The graphics processing unit of claim 1, wherein processing of the first rendering has been completed for a region of the memory resource when data stored in the region of the memory resource can no longer be modified by the first rendering.

7. The graphics processing unit of claim 1, wherein the progress indication comprises a set of flags corresponding to each region of the memory resource, and the progress indication logic is configured to set a flag associated with a region of the memory resource when processing of the first rendering has been completed for the region of the memory resource.

8. The graphics processing unit of claim 1, wherein the progress check logic is configured to deny the processor core access to the region of the memory resource in response to the progress indication indicating that processing of the first rendering has not been completed for the region of the memory resource. ​ 9. The graphics processing unit of claim 1, wherein each group of one or more processor cores contains only a single processor core.

10. The graphics processing unit of claim 1, wherein each group of one or more processor cores contains a plurality of processor cores.

11. The graphics processing unit of claim 10, wherein each of the plurality of processor cores within a group share common processing resources of the graphics processing unit.

12. The graphics processing unit of claim 1, wherein the graphics data is one-dimensional graphics data, two-dimensional graphics data, or three-dimensional graphics data.

13. The graphics processing unit of claim 1, wherein the graphics data is three-dimensional data and the processor cores are configured to process assigned rendering tasks as part of the first rendering to generate rendering values for voxels, and each region of the memory resource stores data for one or more voxels.

14. The graphics processing unit of claim 13, wherein the processor cores are configured to process rendering tasks assigned as part of the second rendering when not all voxels have a final rendering value generated for the first rendering.

15. The graphics processing unit of claim 1, wherein the graphics processing unit is embodied as hardware on an integrated circuit.

16. A method of processing graphics data in a graphics processing unit comprising a plurality of groups of one or more processor cores; the method comprising: performing a first rendering by assigning rendering tasks to the plurality of groups of one or more processor cores for rendering and outputting data of processed rendering tasks to regions of a memory resource; when at least one of the plurality of groups of one or more processor cores has not completed processing of assigned one or more processing tasks as part of the first rendering, assigning at least one rendering task for a second rendering to at least one of the other groups of processor cores for processing; maintaining a progress indication indicating progress of the first rendering, the progress indication indicating regions of the memory resource for which processing of the first rendering has been completed; as part of the second rendering, checking the progress indication in response to a processor core requesting access to a region of the memory resource; and in response to the progress indication indicating that processing of the first rendering has been completed for the region of the memory resource, accessing the region of the memory resource.

17. The method of claim 16, further comprising: updating the progress indication according to an update scheme as the first rendering progresses; and re-checking the progress indication each time the progress indication is updated.

18. A method of manufacturing a graphics processing unit as claimed in claim 1 using an integrated circuit manufacturing system.

19. A method of using an integrated circuit definition data set, the integrated circuit definition data set, when processed in an integrated circuit manufacturing system, configuring the system to manufacture a graphics processing unit as claimed in claim 1. ​ 20. A non-transitory computer readable storage medium having stored thereon a computer readable description of an integrated circuit, which when processed in an integrated circuit manufacturing system causes the integrated circuit manufacturing system to manufacture a graphics processing unit according to claim 1.

21. An integrated circuit manufacturing system comprising: a non-transitory computer readable storage medium having stored thereon a computer readable integrated circuit description describing a graphics processing unit according to claim 1; a layout processing system configured to process the integrated circuit description so as to generate a circuit layout description of an integrated circuit embodying the graphics processing unit; and an integrated circuit generation system configured to manufacture the graphics processing unit according to the circuit layout description.

22. A non-transitory computer readable storage medium having stored thereon computer readable instructions, which when executed at a computer system, cause the computer system to perform the method of claim 16.

Images