DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 8, 15; 3, 10, 19 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bolz et al. U.S. Pub. No. 2014/0267376 in view of Baral et al. U.S. Pub. No. 2017/0161863.
Re: claims 1 and 8 (claims 1 and 8 are rejected under the same rationale), Bolz teaches
1. (Original) An acceleration unit (AU), comprising: a plurality of per-tile queues each allocated to a tile of a plurality of tiles of a frame to be rendered; (“... the L2 cache 265 may be configured to transmit the multi-sample pixel data in tile-sized increments... to the Load/Store unit 290 via the crossbar 260. Accordingly the Load/Store unit 290 may be configured to store multi-sample pixel data in tile-sized increments ”; Bolz, [0031], Fig. 2B)
Fig. 2B illustrates the Load/Store unit that stores multi-sample pixel data in tile sized increments (a plurality of per-tile queues allocated to a tile of a plurality of tiles of a frame to be rendered).
(“The Load/Store unit 290 is configured to provide multi-sample pixel data to the processing unit 250 when a load request is received from the processing unit 250... The Load/Store unit 290 may include a buffer for storing the processed multi-sample data temporarily before outputting the processed multi-sample data to the frame buffer memory 270 via the crossbar 260 and L2 cache 265... the Load/Store unit 290 functions, at least in part, as a cache that is configured to buffer multi-sample pixel data received from the L2 cache 265 and processed multi-sample pixel data received from the processing unit 250 in a single buffer”; Bolz, [0032])
The Load/Store unit includes a buffer, that functions as a cache, for storing the multi-sample data (plurality or per-tile queues each allocated to a tile of a plurality of tiles) before outputting the processed multi-sample data to the frame buffer memory (of a frame to be rendered).
and a first instance of pixel circuitry configured to: based on an available tile mask indicating a first tile of the plurality of tiles is available, consume a first per-tile queue of the plurality of per-tile queues allocated to the first tile to attain geometry data associated with the first tile; (“The multi-sample data for each sample may include z (depth), color, texture coordinates, or other attributes associated with graphics primitives.”; Bolz, [0028])
The multi-sample data includes attributes associated with graphics primitives (geometry data associated with the first tile).
(“The cache 280 receives data for one or more multi-sample pixels and stores the data in cache entries. The data may correspond to a tile including two or more multi-sample pixels... The cache may also store the encoding state associated with the data (for each tile or each multi-sample pixel)... The load request unit 285 is configured to determine the encoding state for the data that is returned to the processing unit 250 in response to a load request.”; Bolz, [0039], Fig. 2C)
Fig. 2C illustrates a Load/Store unit that includes the cache 280 that stores tiles of multi-sample pixels. The Load/Store unit is considered to be a first instance of pixel circuitry.
(“... the coalesce unit 256 is configured to snoop the writes to the cache 281 that are received from the processing unit 250 and update the tile coverage mask maintained by the coverage tracking unit 276. When a tile is “full” the coalesce unit 256 reads the tile data from the cache 281. ”; Bolz, [0051], Fig. 2D)
Fig. 2D illustrates a coalesce unit that snoops the writes to the cache, received from the processing unit, and updates the tile coverage mask. When a tile is full (based on an available tile mask indicating a first tile of the plurality of tiles is available), the coalesce unit reads (consume a first per-tile queue of the plurality of per-tile queues allocated to the first tile to attain geometry data associated with the first tile) the tile data from the cache.
and render, to a buffer, pixel attribute data of one or more primitives at least partially visible in the first tile based on the geometry data associated with the first tile. (“The Load/Store unit 290 may include a buffer for storing the processed multi-sample data temporarily before outputting the processed multi-sample data to the frame buffer memory 270.”; Bolz, [0032], Fig. 2B)
Fig. 2B illustrates that a load/store unit that stores processed multi-sample data (tiles) before outputting the processed multi-sample data to the frame buffer (render, to a buffer, pixel attribute data of one or more primitives... in the first tile based on geometry data associated with the first tile).
(“The multi-sample data for each sample may include z (depth), color, texture coordinates, or other attributes associated with graphics primitives.”; Bolz, [0028])
The multi-sample data for the tiles includes attribute data for primitives included in a tile (based on geometry data associated with the first tile). Bolz is silent regarding one or more primitives at least partially visible in the first tile, however, Baral teaches this limitation.
(“CPU 6 and/or GPU 12 may store rendered image data in a frame buffer that is allocated within system memory 10.”; Baral, [0031], Fig. 1)
Fig. 1 illustrates the GPU that stores rendered image data to a frame buffer (render, to a buffer) in system memory.
(“In the second pass, GPU 12 uses the visibility information generated in the first pass while executing rendering commands for each bin (e.g., tile). For example, based on the visibility information the GPU 12 generates graphics data for pixels within the tile. The second pass includes three different sub-tasks.”; Baral, [0036])
In the second pass, the GPU uses the visibility information to generate pixel graphics data for pixels within the tile (pixel attribute data of one or more primitives at least partially visible in the first tile based on the geometry data associated with the first tile).
(“The second sub-task is the actual rendering pass. For instance, in the second sub-task, GPU 12 generates the graphics data for pixels in the tile and outputs the generated graphics data to the GPU cache 14. ”; Baral, [0038])
The second sub-task is the rendering pass, where the GPU generates the graphics data for pixels in the tile and outputs the generated graphics to the GPU cache.
(“In the third sub-task, GPU 12 writes the graphics data stored in GPU cache 14 to memory 10. For example, GPU 12 writes the result of the rendering pass of the second sub-task to memory 10.”; Baral, [0039])
In the third sub-task, the GPU writes the data stored in GPU cache to memory 10, which includes a frame buffer (render, to a buffer, pixel attribute data of one or more primitives at least partially visible in the first tile based on the geometry data associated with the first tile). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Bolz by adding the feature of one or more primitives at least partially visible in the first tile, in order to reduce the number of pixels that need to be rendered based on the visibility information, as taught by Baral ([0041]).
Re: claim 15, Bolz teaches
15. (Currently Amended) An acceleration unit (AU), comprising: one or more caches; and one or more processor cores coupled to the one or more caches... (“Fig. 7 illustrates a parallel processing unit (PPU)... the PPU 700 is configured to execute a plurality of threads concurrently in two or more streaming multi-processors (SMs) 750... the processing unit 250 and 550 are implemented as SMs 750... Each SM 750... may include... one or more processing cores, a level-one (L1) cache, shared memory, and the like.”; Bolz, [0107])
The parallel processing unit (AU) is implemented as two or more streaming multi-processors (SMs), which include one or more processing cores and a L1 cache (one or more caches and one or more processor cores coupled to the one or more caches).
based on an available tile mask indicating a first tile of the plurality of tiles is available for rendering, write pixel attribute data of primitives at least partially visible in the first tile to the one or more caches based on geometry data associated with the first tile; and based on the available tile mask indicating that a second tile of the plurality of tiles is available for rendering, write pixel attribute data of primitives at least partially visible in the second tile to the one or more caches based on geometry data associated with the second tile. (“When all of the bits for the multi-sample pixels of a tile are set, store requests have been received for all of the multi-sample pixels in the tile and the tile is “full”... When a tile is “full”, the data for the tile may be flushed from the coalesce buffer 258 or the cache 280 to the L2 cache 265.”; Bolz, [0044], Figs. 2B-2C)
When of the bits for the tile are set (available tile mask indicating a first tile of the plurality of tiles is available for rendering), store requests have been received and the tile is full. When a tile is full (based on an available tile mask), The data for the tile may be flushed from the coalesce buffer to the L2 cache (write pixel attribute data of primitives... in the first tile to one or more caches).
(“The coalesce unit 255 may flush the processed data that is already stored for the tile to begin coalescing the tile again with the new processed data.”; Bolz, [0047])
When the data for the tile is flushed, the coalesce unit begins coalescing the tile again with new processed data. Thus, the process repeats with a new tile (based on the available tile mask indicating that a second tile of the plurality of tiles is available for rendering, write pixel attribute data of primitives... in the second tile to the one or more caches).
(“The multi-sample data for each sample may include z (depth), color, texture coordinates, or other attributes associated with graphics primitives.”; Bolz, [0028])
The multi-sample data that is included in each tile include depth, color, texture coordinates or other attributes associated with graphics primitives. Thus, the writing of the tiles to the cache is based on the multi-sample pixels included in each tile and the attribute data associated with each primitive that covers the pixels in each tile (which includes the first and second tile).
Bolz is silent regarding primitives at least partially visible in the first tile and the second tile and partition a frame to be rendered into a plurality of tiles, however, Baral teaches this limitation.
(“For instance, GPU 12 generates graphics data for pixels in a tile and stores the graphics data for that tile in GPU cache 14.”; Baral, [0033])
The GPU generates pixel graphics data (write pixel attribute data of primitives... in the first tile) for a tile and stores it in the GPU cache (to the one or more caches).
(“In the first pass (also referred to VizBinning or visibility stream generation pass), GPU 12 generates per bin (per tile) visibility information of all primitives. For example, GPU 12 determines to which tile (e.g., bin) vertices of the primitives belong. If the vertex is within a tile, then that vertex is considered to belong to that tile. GPU 12 may also perform similar function for other pixels of the primitives as well to determine the per bin visibility information of all primitives.”; Baral, [0034])
In the first pass the GPU determines which primitives belong to each tile and then generates per tile visibility information for all primitives in each tile.
(“For example, assume that GPU 12 divided a frame into 10 tiles and there are a total of 100 primitives to render. In this example, GPU 12 may associated 100 bits to each of the tiles, where each bit is associated with a primitive, for a total of 1000 bits (100*10). If a primitive is visible in a particular tile, GPU 12 may set the bit associated with that primitive equal to 1 and if the primitive is not visible in a particular tile, GPU 12 may set the bit associated with that primitive equal to 0. The resulting 100 bits for each of the tiles is the visibility stream.”; Baral, [0035])
Based on the visibility information generated for the tile in the first pass, the second pass uses this visibility information and generates pixel graphics data for the tile (pixel attribute data of primitives at least partially visible in the first tile). The second pass includes three sub-tasks.
(“In the second pass, GPU 12 uses the visibility information generated in the first pass while executing rendering commands for each bin (e.g., tile). For example, based on the visibility information the GPU 12 generates graphics data for pixels within the tile. The second pass includes three different sub-tasks.”; Baral, [0036])
In the second pass, the GPU uses the visibility information to generate pixel graphics data for pixels within the tile (pixel attribute data of primitives at least partially visible in the first tile).
(“The second sub-task is the actual rendering pass. For instance, in the second sub-task, GPU 12 generates the graphics data for pixels in the tile and outputs the generated graphics data to the GPU cache 14.”; Baral, [0038])
The second sub-task is the rendering pass, where the GPU generates the graphics data for pixels in the tile and outputs the generated graphics to the GPU cache (write pixel attribute data of primitives at least partially visible in the first tile to the one or more caches).
... and configured to: partition a frame to be rendered into a plurality of tiles; (“... GPU 12 may be configured to implement tile-based rendering. In tile-based rendering, GPU 12 divides a frame to be rendered into a plurality of tiles, and renders the graphics data in each tile sequentially.”; Baral, [0033])
The GPU implements tile=based rendering, where the GPU divides a frame into a plurality of tiles (partition a frame to be rendered into a plurality of tiles). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Bolz by adding the feature of primitives at least partially visible in the first tile and the second tile and partition a frame to be rendered into a plurality of tiles, in order to reduce the number of pixels that need to be rendered based on the visibility information, as taught by Baral ([0041]).
Re: claims 3 and 10 (claims 3 and 10 are rejected under the same rationale), Bolz and Baral teach
3. (Original) The AU of claim 1, wherein the AU further comprises:... based on the available tile mask indicating a second tile of the plurality of tiles is available, consume a second per-tile queue of the plurality of per-tile queues allocated to the second tile to attain geometry data associated with the second tile; (“The multi-sample data for each sample may include z (depth), color, texture coordinates, or other attributes associated with graphics primitives.”; Bolz, [0028])
The multi-sample data includes attributes associated with graphics primitives (geometry data associated with the second tile).
(“The cache 280 receives data for one or more multi-sample pixels and stores the data in cache entries. The data may correspond to a tile including two or more multi-sample pixels... The cache may also store the encoding state associated with the data (for each tile or each multi-sample pixel)... The load request unit 285 is configured to determine the encoding state for the data that is returned to the processing unit 250 in response to a load request.”; Bolz, [0039], Fig. 2C)
Fig. 2C illustrates a Load/Store unit that includes the cache 280 that stores tiles of multi-sample pixels. The Load/Store unit is considered to be a second instance of pixel circuitry.
(“... the coalesce unit 256 is configured to snoop the writes to the cache 281 that are received from the processing unit 250 and update the tile coverage mask maintained by the coverage tracking unit 276. When a tile is “full” the coalesce unit 256 reads the tile data from the cache 281. ”; Bolz, [0051], Fig. 2D)
Fig. 2D illustrates a coalesce unit that snoops the writes to the cache, received from the processing unit, and updates the tile coverage mask. When a tile is full (based on an available tile mask indicating a second tile of the plurality of tiles is available), the coalesce unit reads (consume a second per-tile queue of the plurality of per-tile queues allocated to the second tile to attain geometry data associated with the second tile) the tile data from the cache. Bolz is silent regarding a second instance of pixel circuitry, however, Baral teaches this limitation.
a second instance of pixel circuitry configured to: (“GPU 12 includes one or more processing units ... such as shader core unit 43... In some examples, shader core unit 34 may include a plurality of processing units that are configured to operate in parallel... Examples of shader programs that execute on shader core unit 134 may include, for example, vertex shaders, pixel shaders (also called fragment shaders), geometry shaders, hull shaders, domain shaders, compute shaders, and/or unified shaders.”; Baral, [0056], Fig. 2)
The GPU (AU) includes a shader core unit which includes plural processing units that operate in parallel. For example pixel shaders are executed on the plural processors in parallel (this includes a second instance of pixel circuitry). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Bolz by adding the feature of a second instance of pixel circuitry, in order to operate on a plurality of vertices or pixels in a parallel manner such that GPU draws graphic images to the display more quickly, as taught by Baral ([0028]).
Bolz teaches and render, to a buffer, pixel attribute data of one or more primitives at least partially visible in the second tile based on the geometry data associated with the second tile. (“The Load/Store unit 290 may include a buffer for storing the processed multi-sample data temporarily before outputting the processed multi-sample data to the frame buffer memory 270.”; Bolz, [0032], Fig. 2B)
Fig. 2B illustrates that a load/store unit that stores processed multi-sample data (tiles) before outputting the processed multi-sample data to the frame buffer (render, to a buffer, pixel attribute data of one or more primitives... in the second tile based on geometry data associated with the second tile).
(“The multi-sample data for each sample may include z (depth), color, texture coordinates, or other attributes associated with graphics primitives.”; Bolz, [0028])
The multi-sample data for the tiles includes attribute data for primitives included in a tile (based on geometry data associated with the first tile). Bolz is silent regarding one or more primitives at least partially visible in the second tile, however, Baral teaches this limitation.
(“CPU 6 and/or GPU 12 may store rendered image data in a frame buffer that is allocated within system memory 10.”; Baral, [0031], Fig. 1)
Fig. 1 illustrates the GPU that stores rendered image data to a frame buffer (render, to a buffer) in system memory.
(“In the second pass, GPU 12 uses the visibility information generated in the first pass while executing rendering commands for each bin (e.g., tile). For example, based on the visibility information the GPU 12 generates graphics data for pixels within the tile. The second pass includes three different sub-tasks.”; Baral, [0036])
In the second pass, the GPU uses the visibility information to generate pixel graphics data for pixels within the tile (pixel attribute data of one or more primitives at least partially visible in the second tile based on the geometry data associated with the second tile).
(“The second sub-task is the actual rendering pass. For instance, in the second sub-task, GPU 12 generates the graphics data for pixels in the tile and outputs the generated graphics data to the GPU cache 14. ”; Baral, [0038])
The second sub-task is the rendering pass, where the GPU generates the graphics data for pixels in the tile and outputs the generated graphics to the GPU cache.
(“In the third sub-task, GPU 12 writes the graphics data stored in GPU cache 14 to memory 10. For example, GPU 12 writes the result of the rendering pass of the second sub-task to memory 10.”; Baral, [0039])
In the third sub-task, the GPU writes the data stored in GPU cache to memory 10, which includes a frame buffer (render, to a buffer, pixel attribute data of one or more primitives at least partially visible in the second tile based on the geometry data associated with the second tile). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Bolz by adding the feature of one or more primitives at least partially visible in the first tile, in order to reduce the number of pixels that need to be rendered based on the visibility information, as taught by Baral ([0041]).
Re: claim 19, Bolz and Baral teach
19. (Original) The AU of claim 15, wherein the one or more caches include a plurality of per-tile queues each allocated to a corresponding tile of the plurality of tiles.
(“... the L2 cache 265 may be configured to transmit the multi-sample pixel data in tile-sized increments... to the Load/Store unit 290 via the crossbar 260. Accordingly the Load/Store unit 290 may be configured to store multi-sample pixel data in tile-sized increments ”; Bolz, [0031], Fig. 2B)
Fig. 2B illustrates the Load/Store unit that stores multi-sample pixel data in tile sized increments (a plurality of per-tile queues allocated to a tile of a plurality of tiles of a frame to be rendered).
(“... the Load/Store unit 290 functions, at least in part, as a cache that is configured to buffer multi-sample pixel data received from the L2 cache 265 and processed multi-sample pixel data received from the processing unit 250 in a single buffer”; Bolz, [0032])
The Load/Store unit includes a buffer, that functions as a cache (one or more caches), for storing the multi-sample data (a plurality or per-tile queues each allocated to a corresponding tile of a plurality of tiles).
Re: claim 20, Bolz and Baral teach
20. (Currently Amended) The AU of claim 15, wherein the one or more processor cores are configured to consume a per-tile queue associated with the first tile to obtain the geometry data associated with the primitives at least partially visible in the first tile, the geometry data associated with the first tile indicating primitives at least partial visible in the first tile. (“Fig. 7 illustrates a parallel processing unit (PPU)... the PPU 700 is configured to execute a plurality of threads concurrently in two or more streaming multi-processors (SMs) 750... the processing unit 250 and 550 are implemented as SMs 750... Each SM 750... may include... one or more processing cores, a level-one (L1) cache, shared memory, and the like.”; Bolz, [0107])
The parallel processing unit (AU) is implemented as two or more streaming multi-processors (SMs), which include one or more processing cores and a L1 cache (one or more caches and one or more processor cores coupled to the one or more caches).
(“Fig. 8 illustrates the streaming multi-processor 750 of Fig. 5... The SM 750 is coupled to a Load/Store unit 290.”; Bolz, [0121], Fig. 8)
Fig. 8 illustrates that the streaming multi-processor is coupled to the Load/Store unit.
(“The Load/Store unit 290 is configured to provide multi-sample pixel data to the processing unit 250 when a load request is received from the processing unit 250.”; Bolz, [0032], Fig. 2B)
Fig. 2B illustrates a Load/Store unit that provides multi-sample pixel data (tiles) to the processing unit (one or more processing cores are configured to consume a per-tile queue associated with the first tile to obtain geometry data associated with the primitives... in the first tile) when a load request is received from the processing unit. Bolz is silent regarding primitives at least partially visible in the first tile, the geometry data associated with the first tile indicating primitives at least partial visible in the first tile, however, Baral teaches this limitation.
(“In the second pass, GPU 12 uses the visibility information generated in the first pass while executing rendering commands for each bin (e.g., tile). For example, based on the visibility information the GPU 12 generates graphics data for pixels within the tile. The second pass includes three different sub-tasks.”; Baral, [0036])
In the second pass, the GPU uses the visibility information to generate pixel graphics data for pixels within the tile (geometry data associated with the primitives at least partially visible in the first tile, the geometry data associated with the first tile indicating primitives at least partial visible in the first tile).
(“The second sub-task is the actual rendering pass. For instance, in the second sub-task, GPU 12 generates the graphics data for pixels in the tile and outputs the generated graphics data to the GPU cache 14. ”; Baral, [0038])
The second sub-task is the rendering pass, where the GPU generates the graphics data for pixels in the tile and outputs the generated graphics to the GPU cache.
(“In the third sub-task, GPU 12 writes the graphics data stored in GPU cache 14 to memory 10. For example, GPU 12 writes the result of the rendering pass of the second sub-task to memory 10.”; Baral, [0039])
In the third sub-task, the GPU writes the data stored in GPU cache to memory 10, which includes a frame buffer (render, to a buffer, geometry data associated with primitives at least partially visible in the first tile, the geometry data associated with the first tile indicating primitives at least partial visible in the first tile). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Bolz by adding the feature of one or more primitives at least partially visible in the first tile, in order to reduce the number of pixels that need to be rendered based on the visibility information, as taught by Baral ([0041]).
Claim(s) 2 and 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bolz and Baral as applied to claims 1 and 8 above, and further in view of Langtind et al. U.S. Pub. No. 2022/0245751 and Foo EP 3 316 143 A2.
Re: claims 2 and 9 (claims 2 and 9 are rejected under the same rationale), Bolz, Baral and Langtind teach
2. (Original) The AU of claim 1, wherein the AU further comprises: a geometry circuitry configured to: store the geometry data associated with the first tile to the per-tile queue of the allocated to the first tile; (“The tiler 34 performs the process of “tiling” to allocate the assembled primitives to primitive lists for respective render output regions (areas) which are then used to identify the primitives that should be rendered for each tile that is to be rendered to generate the output data (which may, e.g., be a frame to be rendered for display). For example, the tiler 34 may be implemented using a primitive list building unit which takes the assembled primitives as its input, builds primitive lists using that data, and stores the primitive lists in memory. The tiler may also cull certain primitives that are not visible.”; Langtind, [0194])
Fig. 2 illustrates that the graphics processor (AU) includes a tiler that allocates assembled primitives to primitive lists (geometry data associated with the first tile) for each render output region (tile), which are used to identify the primitives to be rendered for each tile. The primitive list for each tile is stored in memory store the geometry data associated with the first tile to the per-tile queue of the allocated to the first tile). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Bolz by adding the feature of a geometry circuitry configured to: store the geometry data associated with the first tile to the per-tile queue of the allocated to the first tile, in order to provide a more efficient graphics processing pipeline with respect to the primitive assembly process, as taught by Langtind ([0236]).
Langtind is silent regarding based on storing the geometry data associated with the first tile in the per-tile queue allocated to the first tile, updating the available tile mask to indicate the first tile is available, however, Bolz and Foo teach and based on storing the geometry data associated with the first tile in the per-tile queue allocated to the first tile, updating the available tile mask to indicate the first tile is available. (“... the coalesce unit 256 is configured to snoop the writes to the cache 281 that are received from the processing unit 250 and update the tile coverage mask maintained by the coverage tracking unit 276. When a tile is “full” the coalesce unit 256 reads the tile data from the cache 281. Entries in the cache 281 storing the data for the tile may be marked as empty and the bits in the coverage tracking unit 276 corresponding to the tile may be cleared with the tile is flushed.”; Bolz, [0051], Fig. 2D)
Fig. 2D illustrates a coalesce unit that snoops the writes to the cache, received from the processing unit, and updates the tile coverage mask. When a tile is full (updating the available tile mask to indicate a first tile is available), the coalesce unit reads the tile data from the cache. Bolz is silent regarding storing geometry data associated with the first tile in the per-tile queue allocated to the first tile, however, Foo teaches this limitation.
(“The TA 416 also performs tiling on the transformed primitives determined to be visible after the clipping, projection and culling. To perform the tiling, the TA updates a display list for each tile that the primitives of the transformed geometric data cover, where the display list for each tile contains a list of each primitive that at least partially overlaps that tile. The transformed data and updated display lists may be written to (and hence stored within) parameter buffer 122 in the system memory 106,”; Foo, [0095], Fig. 5)
Fig. 5 illustrates a TA that performs tiling and updates a display list for each tile (geometry data associated with the first tile) that the transformed primitives, at least partially, cover. This transformed primitive data and updated display list, for each tile, is written to the parameter buffer (per-tile queue allocated to the first tile), which indicates that the data is available for further processing (based on storing the geometry data associated with the first tile in the per-tile queue allocated to the first tile). Foo is combined with Bolz such that the updated display list of Foo includes the updated tile mask of Bolz. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Bolz by adding the feature of based on storing the geometry data associated with the first tile in the per-tile queue allocated to the first tile, updating the available tile mask to indicate the first tile is available, in order to tag work related to rendering tasks such that counters can be used to accurately measure the performance of the graphics system, as taught by Foo ([0045]).
Claim(s) 4 and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bolz and Baral as applied to claims 3 and 10 above, and further in view of Sansottera et al. U.S. Pub. No. 2025/0265673.
Re: claims 4 and 11 (claims 4 and 11 are rejected under the same rationale), Bolz and Baral are silent regarding the second instance of pixel circuitry is configured to access the available tile mask concurrently with the first instance of pixel circuitry rendering the pixel attribute data, however, Sansottera teaches
4. (Original) The AU of claim 3, wherein the second instance of pixel circuitry is configured to access the available tile mask concurrently with the first instance of pixel circuitry rendering the pixel attribute data of one or more primitives at least partially visible in the first tile. (“In some examples, multiple tiles may be processed in parallel by the rasterization logic 306, using respective tile processing pipelines (each of which may be identified by a unique tile pipeline ID), and in those examples, there may be a respective rendering queue for each tile currently being processed by the rasterization logic 306.”; Sansottera, [0064], Fig. 3)
Fig. 3 illustrates rasterization logic 306 that processes multiple tiles in parallel (concurrently) using respective pipelines, where each pipeline has a respective rendering queue for each tile concurrently being processed. There are multiple rendering pipelines operating in parallel (which includes a first and second instance of pixel circuitry).
(“In step S406, the tiling unit 314 generates control stream data for each of the tiles of the rendering space. The control stream data for a tile includes identifiers of input graphics data items which are to be used for rendering the tile... The identifiers in the control stream identify input graphics data items... The control stream data for a tile also includes primitive indications to indicate which of the primitives derived from the input graphics data items (i.e., which of the sub-primitives) are to be used for rendering the tile.”; Sansottera, [0060])
The tiling unit generates control stream data for each tile of the rendering space. The control stream data includes identifiers of graphics data items which are to be used for rendering the tile. The first and second pipelines (which includes a first and second instance of pixel circuitry) access their respective control stream for each tile for rendering. Sansottera is combined with Bolz such that the control stream data of Sansottera includes the tile mask of Bolz. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Bolz by adding the feature of the second instance of pixel circuitry is configured to access the available tile mask concurrently with the first instance of pixel circuitry rendering the pixel attribute data of one or more primitives at least partially visible in the first tile, in order to reduce the amount of processing which is performed to derive sub-primitives for a tile, as taught by Sansottera, ([0060]).
Claim(s) 5, 6, 12, 13, 17 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bolz in view of Baral as applied to claims 1 and 8 above, and further in view of Bolz U.S. Pub. No. 2017/0053375 (Bolz’3375).
Re: claims 5 and 12 (claims 5, 12 and 17 are rejected under the same rationale), Baral is silent regarding, however, Bolz and Bolz’3375 teach
5. (Original) The AU of claim 1, wherein the first instance of pixel circuitry is configured to: based on completing a tile lighting stage for the first tile, accessing the available tile mask. (“The cache 280 receives data for one or more multi-sample pixels and stores the data in cache entries. The data may correspond to a tile including two or more multi-sample pixels... The cache may also store the encoding state associated with the data (for each tile or each multi-sample pixel)... The load request unit 285 is configured to determine the encoding state for the data that is returned to the processing unit 250 in response to a load request.”; Bolz, [0039], Fig. 2C)
Fig. 2C illustrates a Load/Store unit that includes the cache 280 that stores tiles of multi-sample pixels. The Load/Store unit is considered to be a first instance of pixel circuitry.
(“... the coalesce unit 256 is configured to snoop the writes to the cache 281 that are received from the processing unit 250 and update the tile coverage mask maintained by the coverage tracking unit 276. When a tile is “full” the coalesce unit 256 reads the tile data from the cache 281.”; Bolz, [0051], Fig. 2D)
Fig. 2D illustrates a coalesce unit that snoops the writes to the cache, received from the processing unit, and updates the tile coverage mask. When a tile is full (based on an available tile mask indicating a first tile of the plurality of tiles is available), the coalesce unit reads (consume a first per-tile queue of the plurality of per-tile queues allocated to the first tile to attain geometry data associated with the first tile) the tile data from the cache. Bolz is silent regarding completing the lighting stage, however, Bolz’3375 teaches this limitation.
(“... the VTG 365 may include... one or more of a vertex processing unit...and a geometry processing unit... The vertex processing unit is a programmable execution unit that is configured to execute vertex shader programs, lighting and transforming vertex data as specified by the vertex shader programs... The vertex processing unit may read vertex data and vertex attributes that is stored in shared memory by the VAF and may process the vertex data and vertex attributes. The vertex processing unit 415 stores processed vertices in shared memory.”; Bolz’3375, [0057], [0058], Fig. 3B)
Fig. 3b illustrates that the geometry processing unit (VTG 365) includes a vertex processing unit that performs lighting and transforming (completing a lighting stage of the first tile) of vertex data, which is stored to shared memory.
(“... The pixel shading unit 390 may read data that is stored in shared memory.”; Bolz’3375, [0071])
When geometry processing is complete, the pixel shader reads the geometry data from shared memory for processing. Bolz’3375 is combined with Bolz and Baral such that the tile mask of Bolz is included in the geometry data of Bolz’3375. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Bolz by adding the feature of : based on completing a tile lighting stage for the first tile, accessing the available tile mask, in order to optimize data flow, thereby reducing memory bandwidth consumption, as taught by Bolz’3375 ([0013]).
Re: claims 6 and 13 (claims 6 and 13 are rejected under the same rationale), Bolz, Baral and Bolz’3375 teach
6. (Original) The AU of claim 5, wherein the first instance of pixel circuitry is configured to: based on the available tile mask indicating a third tile is available, consume a third per-tile queue of the plurality of per-tile queues allocated to the third tile to attain geometry data associated with the third tile. (“The multi-sample data for each sample may include z (depth), color, texture coordinates, or other attributes associated with graphics primitives.”; Bolz, [0028])
The multi-sample data includes attributes associated with graphics primitives (geometry data associated with the third tile).
(“The cache 280 receives data for one or more multi-sample pixels and stores the data in cache entries. The data may correspond to a tile including two or more multi-sample pixels... The cache may also store the encoding state associated with the data (for each tile or each multi-sample pixel)... The load request unit 285 is configured to determine the encoding state for the data that is returned to the processing unit 250 in response to a load request.”; Bolz, [0039], Fig. 2C)
Fig. 2C illustrates a Load/Store unit that includes the cache 280 that stores tiles of multi-sample pixels. The Load/Store unit is considered to be a third instance of pixel circuitry.
(“... the coalesce unit 256 is configured to snoop the writes to the cache 281 that are received from the processing unit 250 and update the tile coverage mask maintained by the coverage tracking unit 276. When a tile is “full” the coalesce unit 256 reads the tile data from the cache 281.”; Bolz, [0051], Fig. 2D)
Fig. 2D illustrates a coalesce unit that snoops the writes to the cache, receive from the processing unit, and updates the tile coverage mask. When a tile is full (based on an available tile mask indicating a third tile of the plurality of tiles is available), the coalesce unit reads (consume a third per-tile queue of the plurality of per-tile queues allocated to the third tile to attain geometry data associated with the third tile) the tile data from the cache.
Re: claim 18, Bolz, Baral and Bolz’3375 teach
18. (Currently Amended) The AU of claim 17, wherein the one or more processor cores are configured to: based on the available tile mask indicating a third tile is available for rendering, write pixel attribute data of primitives at least partially visible in the third tile to the one or more caches based on geometry data associated with the third tile. (“When all of the bits for the multi-sample pixels of a tile are set, store requests have been received for all of the multi-sample pixels in the tile and the tile is “full”... When a tile is “full”, the data for the tile may be flushed from the coalesce buffer 258 or the cache 280 to the L2 cache 265.”; Bolz, [0044], Figs. 2B-2C)
When of the bits for the tile are set (available tile mask indicating a third tile is available for rendering), store requests have been received and the tile is full. When a tile is full (based on an available tile mask), The data for the tile may be flushed from the coalesce buffer to the L2 cache (write pixel attribute data of primitives at least partially visible in the third tile to one or more caches).
(“The coalesce unit 255 may flush the processed data that is already stored for the tile to begin coalescing the tile again with the new processed data.”; Bolz, [0047])
When the data for the tile is flushed, the coalesce unit begins coalescing the tile again with new processed data. Thus, the process repeats with a new tile (based on the available tile mask indicating that a second tile of the plurality of tiles is available, write pixel attribute data of primitives... in the second tile to the one or more caches).
(“The multi-sample data for each sample may include z (depth), color, texture coordinates, or other attributes associated with graphics primitives.”; Bolz, [0028])
The multi-sample data that is included in each tile include depth, color, texture coordinates or other attributes associated with graphics primitives. Thus, the writing of the tiles to the cache is based on the multi-sample pixels included in each tile and the attribute data associated with each primitive (based on geometry data associated with the third tile) that covers the pixels in each tile (which includes the third tile).
Bolz is silent regarding primitives at least partially visible in the third tile, however, Baral teaches this limitation.
(“For instance, GPU 12 generates graphics data for pixels in a tile and stores the graphics data for that tile in GPU cache 14.”; Baral, [0033])
The GPU generates pixel graphics data (write pixel attribute data of primitives... in the first tile) for a tile and stores it in the GPU cache (to the one or more caches).
(“In the first pass (also referred to VizBinning or visibility stream generation pass), GPU 12 generates per bin (per tile) visibility information of all primitives. For example, GPU 12 determines to which tile (e.g., bin) vertices of the primitives belong. If the vertex is within a tile, then that vertex is considered to belong to that tile. GPU 12 may also perform similar function for other pixels of the primitives as well to determine the per bin visibility information of all primitives.”; Baral, [0034])
In the first pass the GPU determines which primitives belong to each tile and then generates per tile visibility information for all primitives in each tile.
(“For example, assume that GPU 12 divided a frame into 10 tiles and there are a total of 100 primitives to render. In this example, GPU 12 may associated 100 bits to each of the tiles, where each bit is associated with a primitive, for a total of 1000 bits (100*10). If a primitive is visible in a particular tile, GPU 12 may set the bit associated with that primitive equal to 1 and if the primitive is not visible in a particular tile, GPU 12 may set the bit associated with that primitive equal to 0. The resulting 100 bits for each of the tiles is the visibility stream.”; Baral, [0035])
Based on the visibility information generated for the tile in the first pass, the second pass uses this visibility information and generates pixel graphics data for the tile (pixel attribute data of primitives at least partially visible in the third tile). The second pass includes three sub-tasks.
(“In the second pass, GPU 12 uses the visibility information generated in the first pass while executing rendering commands for each bin (e.g., tile). For example, based on the visibility information the GPU 12 generates graphics data for pixels within the tile. The second pass includes three different sub-tasks.”; Baral, [0036])
In the second pass, the GPU uses the visibility information to generate pixel graphics data for pixels within the tile (pixel attribute data of primitives at least partially visible in the third tile).
(“The second sub-task is the actual rendering pass. For instance, in the second sub-task, GPU 12 generates the graphics data for pixels in the tile and outputs the generated graphics data to the GPU cache 14.”; Baral, [0038])
The second sub-task is the rendering pass, where the GPU generates the graphics data for pixels in the tile and outputs the generated graphics to the GPU cache (write pixel attribute data of primitives at least partially visible in the third tile to the one or more caches). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Bolz by adding the feature of primitives at least partially visible in the third tile, in order to reduce the number of pixels that need to be rendered based on the visibility information, as taught by Baral ([0041]).
Claim(s) 7, 14 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bolz in view of Baral as applied to claims 1, 8 and 15 above, and further in view of Brigg et al. GB 2580166 A.
Re: claims 7 and 14 (claims 7 and 14 are rejected under the same rationale), Bolz and Baral are silent regarding the first instance of pixel circuitry is configured to consume the first per-tile queue of the plurality of per-tile queues allocated to the first tile concurrently with a geometry circuitry performing a visibility pass that determines which primitives of the frame are at least partially visible in each tile of the plurality of tiles, however, Brigg teaches
7. (Original) The AU of claim 1, wherein the first instance of pixel circuitry is configured to consume the first per-tile queue of the plurality of per-tile queues allocated to the first tile concurrently with a geometry circuitry performing a visibility pass that determines which primitives of the frame are at least partially visible in each tile of the plurality of tiles. (“The tag buffer 1506 receives primitive fragments that have passed the depth test stage and for each received primitive fragment updates the tag buffer 1506 to identify that the received primitive fragment is the primitive fragment that is visible at its sample position... in a simple case where all of the primitives are opaque, after all the primitives in a tile have been processed by the depth testing logic 1504 the tag buffer 1506 comprises the identity of the primitive fragments that are visible at each sample location. At this point the tag buffer 1506 is flushed to the texturing/shading logic 1508 where texturing and shading are performed on the primitive fragments that are visible.”; Brigg, [0148], Fig. 15)
Fig. 15 illustrates that tag buffer receives primitive fragments that have passed the depth test stage, identifying these fragments as visible (geometry circuitry performing a visibility pass that determines which primitives of the frame are at least partially visible). When the primitives in a tile have been processed by the depth testing logic, the tag buffer includes the identity of the visible primitive fragments and the tag buffer is flushed to the texturing/shading logic (a first instance of pixel circuitry is configured to consume the first per-tile queue of the plurality of per-tile queues allocated to the first tile). The operations are considered to be concurrent because, as the depth testing for one tile finishes, and the tile is stored in the tag buffer and flushed to the texturing shading logic, the next tile starts depth testing. So, depth testing (geometry circuitry performing a visibility pass) is occurring for the next tile while the previous tile is flushed (consume the first per-tile queue) to the texturing/shading logic. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Bolz by adding the feature of the first instance of pixel circuitry is configured to consume the first per-tile queue of the plurality of per-tile queues allocated to the first tile concurrently with a geometry circuitry performing a visibility pass that determines which primitives of the frame are at least partially visible in each tile of the plurality of tiles, in order to avoid wasting resources texturing and shading primitives/primitive fragments which are not visible in the final image, as taught by Brigg ([0148]).
Re: claim 16, Bolz and Baral are silent regarding the one or more processor cores are configured to write the pixel attribute data of primitives at least partially visible in the second tile concurrently with releasing the pixel attribute data of the primitives at least partially visible in the second tile from the one or more caches, however Brigg teaches
16. (Original) The AU of claim 15, wherein the one or more processor cores are configured to write the pixel attribute data of primitives at least partially visible in the second tile concurrently with releasing the pixel attribute data of the primitives at least partially visible in the second tile from the one or more caches. (“The tag buffer 1506 receives primitive fragments that have passed the depth test stage and for each received primitive fragment updates the tag buffer 1506 to identify that the received primitive fragment is the primitive fragment that is visible at its sample position... in a simple case where all of the primitives are opaque, after all the primitives in a tile have been processed by the depth testing logic 1504 the tag buffer 1506 comprises the identity of the primitive fragments that are visible at each sample location. At this point the tag buffer 1506 is flushed to the texturing/shading logic 1508 where texturing and shading are performed on the primitive fragments that are visible.”; Brigg, [0148], Fig. 15)
Fig. 15 illustrates that tag buffer receives/saves primitive fragments that have passed the depth test stage, identifying these fragments as visible. When the primitives in a tile have been processed by the depth testing logic, the saved primitive fragments in the tag buffer include the identity of the visible primitive fragments and then the tag buffer is flushed to the texturing/shading logic (releasing the pixel attribute data of the primitives at least partially visible in the second tile from the one or more caches). The operations are considered to be concurrent because, as the visible primitive fragments are stored to the tag buffer and then flushed to the texturing shading logic, the next tile starts depth testing and storing to the tag buffer. So, storing to the tag buffer (write the pixel attribute data of primitive at least partially visible in the second tile) is occurring for the next tile while the previous tile is flushed (releasing the pixel attributes of the primitives at least partially visible in the second tile form the one or more caches) to the texturing/shading logic. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Bolz by adding the feature of the one or more processor cores are configured to write the pixel attribute data of primitives at least partially visible in the second tile concurrently with releasing the pixel attribute data of the primitives at least partially visible in the second tile from the one or more caches, in order to avoid wasting resources texturing and shading primitives/primitive fragments which are not visible in the final image, as taught by Brigg ([0148]).
Response to Arguments
Applicant's arguments filed 12/29/2025 have been fully considered but they are not persuasive. Applicant argues regarding claim 1:
“However, Boltz is silent as to per-tile queues containing geometry data, which pixel circuitry then consumes and uses to render pixel attribute data. Firstly, Boltz is generally silent as to geometry data that is stored in queues and then consumed to render pixel data. Instead, Boltz discloses that a single sample of already-rendered pixel may be used to represent a tile of pixels to reduce storage requirements... Secondly, Boltz contains no discussion as to multiple per-tile queues storing any data, let alone geometry data... However, while Bolz discloses that the L2 cache can transmit tile-sized increments of data, Bolz is silent as to the L2 Cache or load/store unit including multiple queues each associated with a corresponding tile and each storing data for that tile, let alone geometry data that is to be consumed to render pixel data. In light of this, Bolz does not disclose or suggest “a first instance of pixel circuitry configured to” based on an available tile mask indicating a first tile of the plurality of tiles is available, consume a first per-tile queue of the plurality of per-tile queues allocated to the first tile to attain geometry data associated with the first tile” as recited by claim 1.”
Examiner disagrees. Bolz teaches these limitations of claim 1. The data is not already rendered. Bolz teaches that the multi-sample data includes attributes associated with graphics primitives (geometry data associated with the first tile). (Bolz, [0028]). Fig. 2C illustrates a Load/Store unit that includes the cache 280 that stores tiles of multi-sample pixels. The Load/Store unit is considered to be a first instance of pixel circuitry. {Bolz, [0039], Fig. 2C). Fig. 2D illustrates a coalesce unit that snoops the writes to the cache, received from the processing unit, and updates the tile coverage mask. When a tile is full (based on an available tile mask indicating a first tile of the plurality of tiles is available), the coalesce unit reads (consume a first per-tile queue of the plurality of per-tile queues allocated to the first tile to attain geometry data associated with the first tile) the tile data from the cache. (Bolz, [0051], Fig. 2D). Also, Fig. 2B illustrates that the load/store unit receives and stores multi-sample pixel data from the processing unit. The load/store unit then outputs the processed multi-sample data to the frame buffer, via the L2 cache. (Bolz, [0032]). The multi-sample pixel data is not rendered until it is output to the frame buffer. Thus, the pixel data is not already rendered.
Applicant's arguments filed 12/29/2025 have been fully considered but they are not persuasive. Applicant argues regarding claims 1 and 8:
“But Baral is generally silent as to how to store geometry data which is consumed to render pixel data, let alone per-tile queues containing such geometry data. Because both Bolz and Baral disclose how to store already rendered-pixel data and are silent as to per-tile queue containing geometry data to be consumed to render pixel data, neither Bolz, Baral, nor a combination of the two discloses or suggests “a first instance of pixel circuitry configured to: based on an available tile mask indicating a first tile of the plurality of tiles is available, consume a first per-tile queue of the plurality of per-tile queues allocated to the first tile to attain geometry data associated with the first tile” as recited by claim 1. Claim 8 recites similar features as claim 1. As such, claim 8 overcomes these rejections for at least the same reasons discussed above with reference to claim 1.”
Examiner disagrees. As discussed above, Bolz teaches this limitation. The data is not already rendered, as discussed above. Bolz teaches that the multi-sample data includes attributes associated with graphics primitives (geometry data associated with the first tile). (Bolz, [0028]). Fig. 2C illustrates a Load/Store unit that includes the cache 280 that stores tiles of multi-sample pixels. The Load/Store unit is considered to be a first instance of pixel circuitry. {Bolz, [0039], Fig. 2C). Fig. 2D illustrates a coalesce unit that snoops the writes to the cache, received from the processing unit, and updates the tile coverage mask. When a tile is full (based on an available tile mask indicating a first tile of the plurality of tiles is available), the coalesce unit reads (consume a first per-tile queue of the plurality of per-tile queues allocated to the first tile to attain geometry data associated with the first tile) the tile data from the cache. (Bolz, [0051], Fig. 2D).
Applicant's arguments filed 12/29/2025 have been fully considered but they are not persuasive. Applicant argues regarding claim 15:
“... while Bolz does discloses transferring already-rendered pixel data at a tile level, Bolz is silent as to using geometry data to write pixel data based on any tile mask, let alone a tile mask indicating a first tile is available for rendering For example, though Bolz generally discusses how pixel data is written to a frame buffer using vertex data, Bolz contains no discussion as to the conditions or trigger for writing pixel data to this frame buffer... In other words, Bolz is silent as to using a mask when writing pixel data to a frame buffer... Bolz contains no discussion as to rendering the pixel data or writing pixel data based on geometry data for a tile based on data indicating that the tile is ready to be rendered and instead only discloses flushing the pixel data of a tile after its been rendered. In light of this, Bolz does not disclose or suggest “based on an available tile mask indicating a first tile of the plurality of tiles is available for rendering, write pixel attribute data of primitives at least partially visible in the first tile to the one or more caches based on geometry data associated with the first tile” as recited by claim 15.”
Examiner disagrees. Bolz teaches this limitation. The data is not already rendered, as discussed above. Bolz teaches that when the bits for the tile are set (available tile mask indicating a first tile of the plurality of tiles is available for rendering), store requests have been received and the tile is full. When a tile is full (based on an available tile mask), The data for the tile may be flushed from the coalesce buffer to the L2 cache (write pixel attribute data of primitives... in the first tile to one or more caches). (Bolz, [0044], Figs. 2B-2C). When the data for the tile is flushed, the coalesce unit begins coalescing the tile again with new processed data. Thus, the process repeats with a new tile (based on the available tile mask indicating that a second tile of the plurality of tiles is available for rendering, write pixel attribute data of primitives... in the second tile to the one or more caches). (Bolz, [0047]). The multi-sample data that is included in each tile include depth, color, texture coordinates or other attributes associated with graphics primitives. Thus, the writing of the tiles to the cache is based on the multi-sample pixels included in each tile and the attribute data associated with each primitive that covers the pixels in each tile (which includes the first and second tile). (Bolz, [0028]).
Applicant's arguments filed 12/29/2025 have been fully considered but they are not persuasive. Applicant argues regarding claim 15:
“Baral does not remedy these deficiencies of Bolz... However, Baral is generally silent as to writing pixel data using geometry data according to any type of mask, let alone a tile mask indicating a tile is available for rendering. Because both Bolz and Baral do not disclose writing pixel data to a cache using geometry data based on a mask indicating a tile is available for rendering, neither Bolz, Baral, nor a combination of the two discloses or suggests “based on an available tile mask indicating a first tile of a plurality of tiles is available for rendering, write pixel attribute data of primitives at least partially visible in the first tile to the one or more caches based on geometry data associated with the first tile” as recited in claim 15.”
Examiner disagrees. Bolz and Baral teach this limitation. Baral is used to teach the primitives at least partially visible in the first tile and the second tile and partition a frame to be rendered into a plurality of tiles. The GPU generates pixel graphics data (write pixel attribute data of primitives... in the first tile) for a tile and stores it in the GPU cache (to the one or more caches). (Baral, [0033]).
In the first pass the GPU determines which primitives belong to each tile and then generates per tile visibility information for all primitives in each tile. (Baral, [0034]). Based on the visibility information generated for the tile in the first pass, the second pass uses this visibility information and generates pixel graphics data for the tile (pixel attribute data of primitives at least partially visible in the first tile). The second pass includes three sub-tasks. (Baral, [0035]). In the second pass, the GPU uses the visibility information to generate pixel graphics data for pixels within the tile (pixel attribute data of primitives at least partially visible in the first tile). (Baral, [0036]). The second sub-task is the rendering pass, where the GPU generates the graphics data for pixels in the tile and outputs the generated graphics to the GPU cache (write pixel attribute data of primitives at least partially visible in the first tile to the one or more caches). (Baral, [0038]).
Applicant's arguments filed 12/29/2025 have been fully considered but they are not persuasive. Applicant argues regarding claims 3, 9, 10, 19, and 20, claims 2 and 9, claims 4 and 11, and claims 5, 6, 12, 13, 17 and 18:
“As explained above, Bolz fails to disclose or render obvious the features of claims 1, 8, and 15. Further, Baral does not remedy the deficiencies of Bolz. Accordingly, the cited references, individually and in combination, fail to disclose or render obvious the features of independent claims 1, 8, and 15. The cited references therefore fail to disclose the features of dependent claims 3, 9, 10, 19, and 20... the features of dependent claims 2 and 9... the features of dependent claims 4 and 11... the features of dependent claims 5, 6, 12, 13, 17, and 18, at least by virtue of their respective dependence from claims 1, 8, and 15. In addition, these dependent claims recite additional novel and non-obvious features, ”
Examiner disagrees. Claims 1, 8, 15 as well as claims 3, 9, 10, 19, and 20, claims 2 and 9 and claims 5, 6, 12, 13, 17, and 18 have been rejected. Please see the corresponding rejections.
Applicant's arguments filed 12/29/2025 have been fully considered but they are not persuasive. Applicant argues regarding claims 7, 14 and 16:
“... Briggs discloses generating pixel data based on visible primitive fragments. However, as discussed above, both Bolz and Baral are directed toward the storage of already-rendered pixel data, which would only occur after the texturing and shading disclosed by Briggs. In light of this, a person of ordinary skill in the art would not find it obvious to modify the storage of already-rendered pixel data based on Brigg’s disclosure of rendering pixel data for visible primitive fragments and would have no reasonable expectation of success in meeting the claimed features through such a combination.”
Examiner disagrees. As discussed above, the pixel data is not already rendered. Briggs illustrates in Fig. 15, that the tag buffer receives primitive fragments that have passed the depth test stage, identifying these fragments as visible (geometry circuitry performing a visibility pass that determines which primitives of the frame are at least partially visible). When the primitives in a tile have been processed by the depth testing logic, the tag buffer includes the identity of the visible primitive fragments and the tag buffer is flushed to the texturing/shading logic (a first instance of pixel circuitry is configured to consume the first per-tile queue of the plurality of per-tile queues allocated to the first tile). The operations are considered to be concurrent because, as the depth testing for one tile finishes, and the tile is stored in the tag buffer and flushed to the texturing shading logic, the next tile starts depth testing. So, depth testing (geometry circuitry performing a visibility pass) is occurring for the next tile while the previous tile is flushed (consume the first per-tile queue) to the texturing/shading logic. (Brigg, [0148], Fig. 15).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONNA J RICKS whose telephone number is (571)270-7532. The examiner can normally be reached on M-F 7:30am-5pm EST (alternate Fridays off).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Devona Faulk can be reached on 571-272-7776. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Donna J. Ricks/Examiner, Art Unit 2612
/DEVONA E FAULK/Supervisory Patent Examiner, Art Unit 2618
Prosecution Insights