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 .
Response to Amendment
This Office Action is in response to Applicant’s amendment/response filed on 08/10/2026, which has been entered and made of record. Applicant’s amendments to the Specification have overcome each and every objection previously set forth in the Non-Final Office Action mailed 05/11/2026.
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.
Claims 1-5, 9, 11-15, 19, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Kleen et al. (US 20170309027 A1, hereinafter “Kleen”).
Regarding claim 1, Kleen discloses A method of operating a tile-based graphics processor that is operable to generate a render output by performing first and second processing passes to generate plural rendering tiles that the render output is divided into, (page 1, para. [0001], “The technology described herein relates to a method of and apparatus for processing graphics, and in particular to such a method and apparatus for use in a tile-based graphics processing system … In tile-based rendering, the two-dimensional render output or target (i.e. the output of the rendering process, such as an output frame to be displayed) is rendered as a plurality of smaller area sub-regions, usually referred to as "tiles"). Note that: (1) tile-based rendering renders the tiles the render output is divided into; and (2) first and second passes are two passes for generating the tiles of a render output as follows. wherein the first processing pass generates data (Abstract, “A primitive list building unit divides a render target into various subregions, determines which sub-regions a primitive falls within and adds the primitive to the primitive lists corresponding to those sub-regions”). Note that: processing primitive and building the primitive related data (e.g., primitive lists) can be regarded as a first processing pass. that is used in the second processing pass to determine which primitives to process to generate a rendering tile of the plural rendering tiles; (Abstract, “The predictor processor then determines a set of sub-region sizes to be used when sorting primitives for the next render output to be generated into lists, based on the histograms”). Note that: using the data generated by the first processing pass and determining which primitives related data to process can be regarded as a second processing pass to generate each rendering tile.
wherein the tile-based graphics processor comprises:
a geometry processing control unit; and
a set of plural programmable processing units operable to execute programs; (FIG. 1: a “Geometry Processor 21”, a “Renderer 22”; page 13, para. [0185], “The geometry processor 21 comprises, inter alia, a programmable vertex shader 27 and a tiler 40. The tiler comprises a primitive list building unit 41 and a predictor processor 42.”; page 14, para. [0192], “The renderer 22 includes a primitive selection unit 29, a primitive list cache 30, a vertex selection unit 31, a vertex data cache 32, a rasterizing unit 33, a rendering unit 34, and tile buffers 35.”. para. [0169], “the various functional elements of the technology described herein may comprise a suitable processor or processors, controller or controllers, functional units, circuitry, processing logic, microprocessor arrangements, etc., that are operable to perform the various functions, etc., such as appropriately dedicated hardware elements or processing circuitry and/or programmable hardware elements”). Note that: (1) a “Geometry Processor 21” can be regarded as a geometry processing control unit; (2) the units in a “Geometry Processor 21” and a “Render 22” can be regarded as one or more programmable processing units; and (3) programmable hardware elements here can be regarded as a set of plural programmable processing units operable to execute programs to perform the various functions.
the method comprising generating a render output by performing first and second processing passes; (Abstract, “A primitive list building unit divides a render target into various subregions, determines which sub-regions a primitive fall within and adds the primitive to the primitive lists corresponding to those sub-regions … The predictor processor then determines a set of sub-region sizes to be used when sorting primitives for the next render output to be generated into lists, based on the histograms”). Note that: (1) processing primitive and building the primitive related data (e.g., primitive lists) can be regarded as a first processing pass; and (2) using the data generated by the first processing pass and determining which primitives related data to process can be regarded as a second processing pass to generate each rendering tile.
wherein performing the first processing pass comprises:
the geometry processing control unit assembling primitives to be processed to generate the render output; (page 1, para. [0006], “it is known to prepare for each rendering tile a list of the primitives to be rendered for that rendering tile (e.g. that will appear in the tile). Such a "primitive-list" (which can also be referred to as a "tile list") identifies (e.g. by reference to a primitive indicator) the primitives to be rendered for the tile in question.”; page 1, para. [0009], “It is also known to prepare primitive-lists with a lower precision than is achieved with exact binning. This can be useful to, e.g., simplify the preparation of the primitive-lists. One common "less precise" binning technique is "bounding box" binning. In this case, a so-called "bounding box" is drawn around a primitive or a set of primitives, and then the tiles covered by the bounding box are determined”; page 13, para. [0185], “The geometry processor 21 comprises, inter alia, a programmable vertex shader 27 and a tiler 40. The tiler comprises a primitive list building unit 41 and a predictor processor 42.”). Note that: (1) formulating primitive lists or related geometry data from the primitives to be rendered for the tile(s) can be regarded as assembling primitives to be processed to generate the render output; (2) a set of bounding boxes can be drawn around a primitive or a set of primitives; and (3) The geometry processor 21 including a primitive list building unit 41 can be regarded as the geometry processing control unit.
one or more programmable processing units of the set of plural programmable processing units transforming geometry data defining the primitives to generate transformed geometry data; and
one or more programmable processing units of the set of plural programmable processing units processing the transformed geometry data to generate data to be used in the second processing pass to determine which of the assembled primitives to process to generate rendering tiles that the render output is divided into; and (FIG. 1: “Geometry Processor 21” has a “Programable Vertex Shader 27”; page 13, paras. [0186]-[0188], “The programmable vertex shader 27 takes as it input the raw geometry data 24 stored in the memory 23, and processes that data to provide transformed geometry data 25 (which it then stores in the memory 23) comprising the geometry data in a form that is ready for 2D placement in the render output (e.g. frame to be displayed). The programmable vertex shader 27 and the processes it carries out can take any suitable form and be any suitable and desired such processes … the primitive list building unit 28 takes as its input the transformed and processed vertex (geometry) data 25 from the programmable vertex shader 27 (i.e. the positions of the primitives in the frame), builds primitive lists using that data, and stores those lists as the primitive lists 26 in the memory 23”; para. 13 page 14, para. [0201], “In step 303, the primitive list building unit 41 retrieves the transformed primitive position data from the programmable vertex shader 27 for a primitive to be processed. In step 304, the primitive list building unit 41 uses the transformed primitive position data to calculate a bounding box for the primitive.”). Note that: (1) “Programable Vertex Shader 27” as one or more programmable processing units of the set of plural programmable processing units transforms the raw geometry data 24 into transformed geometry data 25 (transformed vertex data), resulting in the generated transformed geometry data; (2) the transformed and processed vertex (geometry) data 25 are processed by one or more programmable processing units of the set of plural programmable processing units to build primitive lists, calculated for drawing bounding boxes or related geometry data to be used in the second processing; and (3) the above processing can be regarded as a first processing pass.
wherein performing the second processing pass comprises, for one or more of the rendering tiles:
using the data generated in the first processing pass to determine which of the assembled primitives to process to generate the respective rendering tile; and (FIG. 2: “Generate bounding box for primitive 304”, “Determine which sub-region the bounding box falls within 305”. And “Add primitive to primitive lists corresponding to those sub-regions 306”; page 7, para. [0094], “Essentially the process will involve identifying, for each primitive to be processed for the render output, which sub-regions of the render output the primitive (potentially) falls in. Various techniques for sorting and binning primitives into tile-lists and render output regions or areas, such as exact binning, or bounding box binning, or anything in between, can be used for this process. In an embodiment bounding box binning is used”). Note that: bounding box binning with the information representative of the set of bounding boxes is used to determine primitives of the set of primitives to process to generate the respective rendering tile.
processing the determined primitives to generate the respective rendering tile. (page 17, para. [0245], “The primitive selection unit 29 then chooses a next primitive to be rendered for the primitive list or lists that have been read for the rendering tile in question. Once a primitive has been selected, the primitive selection unit 29 passes that primitive to the vertex selection unit 31. The vertex selection unit 31 then retrieves the appropriate transformed geometry data for the vertices of the primitive in question from the transformed geometry data 25 stored in the memory 23, and provides that data to the rasterising unit 33. The primitive is then rasterised and rendered, and the resulting rendered primitive data stored appropriately in the tile buffers 35. This process is repeated for all the primitives that need to be rendered for a given rendering tile (i.e. that are included in primitive lists 26 appropriate to the tile) until all the primitives for the tile have been rendered (and so the tile buffers contain all the rendered data for the tile in question). The rendered tile data can then be written out (exported) to external memory, such as a frame buffer in main memory (not shown)”). Note that: for each given rendering tile each primitive of the determined primitives is processed by repeating the way of selecting the primitive, retrieving the appropriate transformed geometry data, rasterizing, and rendering the primitive above.
Before the effective filing date of the claimed invention, it would have been obvious to learn and use the teachings on drawing and calculating bounding boxes around primitive, determining primitives for generate rendering tiles, and processing the determined primitive, as taught by Kleen. Although the information of the bounding boxes’ positions and included primitives’ positions and vertexes are not explicitly described by Kleen using the application’s terms regarding information representative of the set of bounding boxes, it is obvious for one having ordinary skills in the art to understand the perform the corresponding operations, calculations, and determinations. The motivation would have been “This allows the overall number of graphics processing necessary for a given render output to be reduced.” (Kleen, page 1, para. [0005]). The suggestion for doing so would allow to determine the primitives of the set of primitives using the information representative of the set of bounding boxes. Therefore, it would have been obvious to use the teachings by Kleen.
Regarding claim 2, Kleen discloses The method of claim 1, comprising:
one or more programmable processing units of the set of plural programmable processing units executing one or more programs to transform the geometry data and to process the transformed geometry data;
one or more programmable processing units of the set of plural programmable processing units executing one or more programs to generate the data to be used in the second processing pass; and (FIG. 1: “Geometry Processor 21” has a “Programable Vertex Shader 27”; page 13, paras. [0186]-[0188], “The programmable vertex shader 27 takes as it input the raw geometry data 24 stored in the memory 23, and processes that data to provide transformed geometry data 25 (which it then stores in the memory 23) comprising the geometry data in a form that is ready for 2D placement in the render output (e.g. frame to be displayed). The programmable vertex shader 27 and the processes it carries out can take any suitable form and be any suitable and desired such processes … the primitive list building unit 28 takes as its input the transformed and processed vertex (geometry) data 25 from the programmable vertex shader 27 (i.e. the positions of the primitives in the frame), builds primitive lists using that data, and stores those lists as the primitive lists 26 in the memory 23”; page 14, para. [0201], “In step 303, the primitive list building unit 41 retrieves the transformed primitive position data from the programmable vertex shader 27 for a primitive to be processed. In step 304, the primitive list building unit 41 uses the transformed primitive position data to calculate a bounding box for the primitive.”). Note that: (1) “Programable Vertex Shader 27” as one or more programmable processing units of the set of plural programmable processing units transforms the raw geometry data 24 into transformed geometry data 25 (transformed vertex data); and (2) the transformed and processed vertex (geometry) data 25 are processed by one or more programmable processing units of the set of plural programmable processing units to build primitive lists, and calculated for drawing bounding boxes or related geometry data to be used in the second processing.
one or more programmable processing units of the set of plural programmable processing units executing one or more programs to process the determined primitives to generate the respective rendering tile. (paras. [0185]-[0187], “The geometry processor 21 comprises, inter alia, a programmable vertex shader 27 and a tiler 40. The tiler comprises a primitive list building unit 41 and a predictor processor 42 … The primitive list building unit 41 of the tiler 40 carries out the process of the technology described herein of dividing the render target into a plurality of sub-regions for which primitive lists are to be prepared. The sizes of the sub-regions that the render target is divided into are determined according to sub-region size configuration information for the target render output being generated that is provided to the primitive list building unit 41 by the predictor processor 42”). Note that: (1) primitive lists are of the determined primitives to process; and (2) the respective rendering tile is generated by tiler 40.
Regarding claim 3, Kleen discloses The method of claim 1, wherein each programmable processing unit of the set of plural programmable processing units comprises:
one or more programmable execution units configured to execute program instructions and
one or more processing circuits configured to process transformed geometry data to generate data to be used in the second processing pass; and
wherein the method comprises:
one or more programmable execution units of the set of plural programmable processing units executing one or more programs to transform the geometry data; and
one or more processing circuits of the set of plural programmable processing units processing the transformed geometry data to generate the data to be used in the second processing pass. (FIG. 1: “Geometry Processor 21” has a “Programable Vertex Shader 27”; page 13, paras. [0186]-[0188], “The programmable vertex shader 27 takes as it input the raw geometry data 24 stored in the memory 23, and processes that data to provide transformed geometry data 25 (which it then stores in the memory 23) comprising the geometry data in a form that is ready for 2D placement in the render output (e.g. frame to be displayed). The programmable vertex shader 27 and the processes it carries out can take any suitable form and be any suitable and desired such processes … the primitive list building unit 28 takes as its input the transformed and processed vertex (geometry) data 25 from the programmable vertex shader 27 (i.e. the positions of the primitives in the frame), builds primitive lists using that data, and stores those lists as the primitive lists 26 in the memory 23”; page 14, para. [0201], “In step 303, the primitive list building unit 41 retrieves the transformed primitive position data from the programmable vertex shader 27 for a primitive to be processed. In step 304, the primitive list building unit 41 uses the transformed primitive position data to calculate a bounding box for the primitive.”). Note that: (1) “Programable Vertex Shader 27” as one or more programmable processing units of the set of plural programmable processing units transforms the raw geometry data 24 into transformed geometry data 25 (transformed vertex data); and (2) the transformed and processed vertex (geometry) data 25 are processed by one or more programmable processing units of the set of plural programmable processing units to build primitive lists, and calculated for drawing bounding boxes or related geometry data to be used in the second processing.
Regarding claim 4, Kleen discloses The method of claim 1, comprising plural programmable processing units of the set of plural programmable processing units processing transformed geometry data to generate the data to be used in the second processing pass at the same time. (page 11, para. [0150], “This rendering can be carried out in any desired manner, for example, by rendering the individual tiles in succession or in a parallel fashion”; page 11, paras. [0155]-[1056], “When there is more than a single primitive list to checked for a single rendering tile, in an embodiment all of those primitive lists are provided to the primitive selection unit in parallel (i.e. simultaneously), with the primitive selection unit then selecting the next primitive to process from one of the lists. The set of primitive lists that primitives are to be selected from for a given rendering tile (i.e. the set of primitive lists that the primitive selection unit should read to identify primitives for rendering for a given tile) can be indicated (e.g. to the primitive selection unit) in any desired fashion, for example by sending this data as appropriate to the graphics processor (e.g. primitive selection unit)”; page 13, para. [0188], “the primitive list building unit 28 takes as its input the transformed and processed vertex (geometry) data 25 from the programmable vertex shader 27 (i.e. the positions of the primitive in the frame), builds primitive lists using that data, and stores those lists as the primitive lists 26 in the memory 23”; page 7, para. [0094], “Essentially the process will involve identifying, for each primitive to be processed for the render output, which sub-regions of the render output the primitive (potentially) falls in. Various techniques for sorting and binning primitives into tile-lists and render output regions or areas, such as exact binning, or bounding box binning, or anything in between, can be used for this process. In an embodiment bounding box binning is used”). Note that: (1) bounding box binning with the information representative of the set of bounding boxes is used to determine primitives of the set of primitives to process to generate the respective rendering tile to be used in the second processing pass; and (2) since all the primitive lists are provided to the primitive selection unit in parallel (i.e. simultaneously) for selecting the set of primitive lists, it is obvious to one having ordinary skill in the art that the transformed and processed vertex (geometry) data 25 are processed in parallel (i.e. simultaneously) to build primitive lists for the processing pipeline to render the individual tiles in a parallel fashion.
Regarding claim 5, Kleen discloses The method of claim 1, wherein performing the first processing pass comprises one or more programmable processing units of the set of plural programmable processing units transforming the geometry data and processing the transformed geometry data without the transformed geometry data being provided to the geometry processing control unit. (FIG. 1: “Raw Geometry 24” from “Memory 23” is transformed by “Programable Vertex Shader 27” into “Transformed Geometry 25” which stored at a different location in “Memory 23”, and “Transformed Geometry 25” as input can be processed directly by “Primitive List Building Unit 41” (receiving the output directly from “Programable Vertex Shader 27”) to generate primitive trees without “Transformed Geometry 25” being written out to memory again, and “
PNG
media_image1.png
402
872
media_image1.png
Greyscale
”). Note that: between “Programable Vertex Shader 27” and “Primitive List Building Unit 41”, there are not the transformed geometry data being provided to the geometry processing control unit (“Geometry Processor 21”).
Regarding claim 9, Kleen discloses The method of claim 1, wherein the data to be used in the second processing pass comprises data representing a set of bounding boxes representative of positions of assembled primitives. (page 1, para. [0009], “It is also known to prepare primitive-lists with a lower precision than is achieved with exact binning. This can be useful to, e.g., simplify the preparation of the primitive-lists. One common "less precise" binning technique is "bounding box" binning. In this case, a so-called "bounding box" is drawn around a primitive or a set of primitives, and then the tiles covered by the bounding box are determined”; page 14, para. [0201], “In step 303, the primitive list building unit 41 retrieves the transformed primitive position data from the programmable vertex shader 27 for a primitive to be processed. In step 304, the primitive list building unit 41 uses the transformed primitive position data to calculate a bounding box for the primitive.”). Note that: (1) a set of bounding boxes can be drawn around a primitive or a set of primitives; and (2) this process for generating a set of bounding boxes can be regarded as a first processing pass.
Claim 11 reciting “A tile-based graphics processor” is corresponding to the method of claim 1. Therefore, claim 11 is rejected for the same rationale for claim 1.
In addition, Kleen discloses A tile-based graphics processor (page 12, para. [0162], “As will be appreciated from the above, the graphics processor and system is in an embodiment a tile-based graphics processor and system”).
Claims 12-15 are corresponding to the method of claims 2-5, respectively. Therefore, claims 12-15 are rejected for the same rationale for claims 2-5, respectively.
Claim 19 is corresponding to the method of claim 9. Therefore, claim 19 is rejected for the same rationale for claim 9.
Claim 21 reciting “A non-transitory computer readable storage medium storing software code which when executing on a processor performs” is corresponding to the method of claim 1. Therefore, claim 21 is rejected for the same rationale for claim 1.
In addition, Kleen discloses A non-transitory computer readable storage medium storing software code which when executing on a processor performs (Kleen, page 13, para. [0179], “The technology described herein may accordingly suitably be embodied as a computer program product for use with a computer system. Such an implementation may comprise a series of computer readable instructions either fixed on a tangible medium, such as a non-transitory computer readable medium, for example, diskette, CD ROM, ROM, RAM, flash memory, or hard disk.”; page 19, claim 20, “A computer readable storage medium storing computer software code which when executing on a processor performs a method”). Note that: the computer readable storage medium storing computer software code can be as a non-transitory computer readable medium while executing the instructions on a processor.
Claims 6-8, 10, 16-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kleen et al. (US 20170309027 A1, hereinafter “Kleen”) in view of Hakura (US 20140118365, hereinafter “Hakura”).
Regarding claim 6, Kleen discloses The method of claim 1, wherein performing the first processing pass comprises: the geometry processing control unit
… to transform the geometry data and to generate the data to be used in the second processing pass. FIG. 1: “Geometry Processor 21” has a “Programable Vertex Shader 27”; page 13, paras. [0186]-[0188], “The programmable vertex shader 27 takes as it input the raw geometry data 24 stored in the memory 23, and processes that data to provide transformed geometry data 25 (which it then stores in the memory 23) comprising the geometry data in a form that is ready for 2D placement in the render output (e.g. frame to be displayed). The programmable vertex shader 27 and the processes it carries out can take any suitable form and be any suitable and desired such processes … the primitive list building unit 28 takes as its input the transformed and processed vertex (geometry) data 25 from the programmable vertex shader 27 (i.e. the positions of the primitives in the frame), builds primitive lists using that data, and stores those lists as the primitive lists 26 in the memory 23”; para. 13 page 14, para. [0201], “In step 303, the primitive list building unit 41 retrieves the transformed primitive position data from the programmable vertex shader 27 for a primitive to be processed. In step 304, the primitive list building unit 41 uses the transformed primitive position data to calculate a bounding box for the primitive.”). Note that: (1) “Programable Vertex Shader 27” as a programmable processing unit transforms the raw geometry data 24 into transformed geometry data 25 (transformed vertex data); and (2) the transformed and processed vertex (geometry) data 25 are processed to build primitive lists, calculated for drawing bounding boxes or related geometry data to be used in the second processing.
However, Kleen fails to disclose, but in the same art of computer graphics, Hakura discloses
assigning assembled primitives to one or more packets of one or more primitives; (Hakura, ABSTRACT, “each bounding box is associated with one or more graphics primitives being rendered to a render surface, and wherein the render surface is divided into the plurality of cache tiles”; page 11, para. [0114], “any number of accumulated bounding boxes may be combined to generate each coarse bounding box. In one implementation, each coarse bounding box may include approximately 128 graphics primitives. Thus, if it is assumed that each accumulated bounding box includes approximately eight graphics primitives, then approximately 16 accumulated bounding boxes would be combined to generate each coarse bounding box. One example of this type of bounding box hierarchy is shown in FIG. 11, which is a conceptual illustration showing the relationship between a coarse bounding box 1110-2 and multiple accumulated bounding boxes 620, according to one embodiment of the present invention”; page 10, para. [0107]), “FIG. 9B is a conceptual illustration showing how a global bounding box 910 is generated from the accumulated bounding boxes of FIG. 9A, according to one embodiment of the present invention. During tiled rendering, if the array indicates that one or more accumulated bounding boxes stored in the buffer memory intersect a particular cache tile 410, the tiling unit 375 then further determines whether the global bounding box 910 intersects the cache tile 410. As shown in FIG. 9B, if the global bounding box 910 does not intersect the cache tile 410, then the cache tile 410 is empty.”; FIG. 9B: iteratively accumulating bounding boxes with the corresponding primitives’ positions, “910” as a packet bounding box bounding primitive bounding boxes “620-7”, “620-8”, and “620-9”). Note that: (1) a bounding box hierarchy is built as a representation of the set of bounding boxes while each bounding box is associated with one or more graphics primitives being rendered to the rendering tile; (2) the tiling unit 375 can traverse the bounding box hierarchy to determine whether the global bounding box 910 and lower one or more accumulated bounding boxes stored in the buffer memory intersect a particular cache tile 410; (3) a primitive bounding box can be drawn around each primitive of all primitives; (4) lower level bounding boxes including primitive bounding boxes can be accumulated or assigned as one or more packets or pocket bounding boxes at higher levels; and (5) one or more pocket bounding boxes at higher levels can be accumulated or assigned as a root bounding box.
and one or more programmable processing units of the set of plural programmable processing units processing the one or more packets to transform the geometry data and to generate the data to be used in the second processing pass. (Hakura, ABSTRACT, “each bounding box is associated with one or more graphics primitives being rendered to a render surface, and wherein the render surface is divided into the plurality of cache tiles”; page 11, para. [0114], “any number of accumulated bounding boxes may be combined to generate each coarse bounding box. In one implementation, each coarse bounding box may include approximately 128 graphics primitives. Thus, if it is assumed that each accumulated bounding box includes approximately eight graphics primitives, then approximately 16 accumulated bounding boxes would be combined to generate each coarse bounding box. One example of this type of bounding box hierarchy is shown in FIG. 11, which is a conceptual illustration showing the relationship between a coarse bounding box 1110-2 and multiple accumulated bounding boxes 620, according to one embodiment of the present invention”; page 10, para. [0107]), “FIG. 9B is a conceptual illustration showing how a global bounding box 910 is generated from the accumulated bounding boxes of FIG. 9A, according to one embodiment of the present invention. During tiled rendering, if the array indicates that one or more accumulated bounding boxes stored in the buffer memory intersect a particular cache tile 410, the tiling unit 375 then further determines whether the global bounding box 910 intersects the cache tile 410. As shown in FIG. 9B, if the global bounding box 910 does not intersect the cache tile 410, then the cache tile 410 is empty.”; FIG. 9B: iteratively accumulating bounding boxes with the corresponding primitives’ positions, “910” as a packet bounding box bounding primitive bounding boxes “620-7”, “620-8”, and “620-9”). Note that: (1) since the pocket(s)’s primitives have been transformed by Kleen above, the pocket(s) can be regarded being transformed accordingly; and (2) the root, packet, and primitive bounding boxes at different levels are processed to form or generate the set of bounding boxes.
Kleen and Hakura are in the same field of endeavor, namely computer graphics. Before the effective filing date of the claimed invention, it would have been obvious to apply building and using a bounding box hierarchy including packets for one of more rending tiles, as taught by Hakura into Kleen. The motivation would have been “reduce the amount of data transmitted over a crossbar and increase the efficiency of tiling operations in a parallel tile-based architecture” (Hakura, page 1, para. [0008]). The suggestion for doing so would allow to reduce the amount of data transmutation and improve the efficiency of tiling operations. Therefore, it would have been obvious to combine Kleen and Hakura.
Regarding claim 7, Kleen in view of Hakura discloses The method of claim 6, wherein performing the first processing pass comprises: the geometry processing control unit allocating memory space for storing one or more packets, and storing the one or more packets in the allocated memory space; and the one or more programmable processing units fetching the packet from the allocated memory space, and processing the one or more packets. (Hakura, page 1, para. [0010], “One advantage of the disclosed technique is that intersections between cache tiles and bounding boxes stored in the buffer memory are tracked, enabling the tiling unit to skip empty cache tiles during tiled rendering”). Note that: since the bounding boxes including primitive bounding boxes, packet bounding boxes, and root bounding box, are stored in the buffer memory, it is obvious to one having ordinary skill in the art that: (a) the buffer memory has been allocated before it is used; and (b) when the packets are processed, they are accessed or fetched and processed by the corresponding programmable processing units.
The motivation to combine Kleen and Hakura given in claim 6 is incorporated here.
Regarding claim 8, Kleen in view of Hakura discloses The method of claim 1, wherein performing the first processing pass comprises:
one or more programmable processing units of the set of plural programmable processing units culling one or more of the assembled primitives from further processing. (Hakura, page 5, para. [0065], “The VPC 370 performs clipping, culling, and viewport transform to determine which graphics primitives are potentially viewable in the final rendered image and which graphics primitives are not potentially viewable”). Note that: VPC 370 as one or more programmable processing units of the set of plural programmable processing units performs culling.
The motivation to combine Kleen and Hakura given in claim 6 is incorporated here.
Claims 16-18 are corresponding to the method of claims 6-8, respectively. Therefore, claims 16-18 are rejected for the same rationale for claims 6-8, respectively.
Regarding claim 10, Kleen in view of Hakura discloses The method of claim 9, wherein
the set of bounding boxes is a hierarchy of bounding boxes, and wherein performing the second processing pass comprises traversing the hierarchy of bounding boxes to determine which of the assembled primitives to process to generate the rendering tile. (Hakura, ABSTRACT, “each bounding box is associated with one or more graphics primitives being rendered to a render surface, and wherein the render surface is divided into the plurality of cache tiles”; page 11, para. [0114], “any number of accumulated bounding boxes may be combined to generate each coarse bounding box. In one implementation, each coarse bounding box may include approximately 128 graphics primitives. Thus, if it is assumed that each accumulated bounding box includes approximately eight graphics primitives, then approximately 16 accumulated bounding boxes would be combined to generate each coarse bounding box. One example of this type of bounding box hierarchy is shown in FIG. 11, which is a conceptual illustration showing the relationship between a coarse bounding box 1110-2 and multiple accumulated bounding boxes 620, according to one embodiment of the present invention”; page 10, para. [0107]), “FIG. 9B is a conceptual illustration showing how a global bounding box 910 is generated from the accumulated bounding boxes of FIG. 9A, according to one embodiment of the present invention. During tiled rendering, if the array indicates that one or more accumulated bounding boxes stored in the buffer memory intersect a particular cache tile 410, the tiling unit 375 then further determines whether the global bounding box 910 intersects the cache tile 410. As shown in FIG. 9B, if the global bounding box 910 does not intersect the cache tile 410, then the cache tile 410 is empty.”; FIG. 9B: iteratively accumulating bounding boxes with the corresponding primitives’ positions, “910” as a packet bounding box bounding primitive bounding boxes “620-7”, “620-8”, and “620-9”). Note that: (1) a bounding box hierarchy is built as a representation of the set of bounding boxes while each bounding box is associated with one or more graphics primitives being rendered to the rendering tile; and (2) the tiling unit 375 can traverse the bounding box hierarchy to determine whether the global bounding box 910 and lower one or more accumulated bounding boxes stored in the buffer memory intersect a particular cache tile 410.
The motivation to combine Kleen and Hakura given in claim 6 is incorporated here.
Claim 20 is corresponding to the method of claim 10. Therefore, claim 19 is rejected for the same rationale for claim 10.
Response to Arguments
Applicant's arguments filed have been fully considered but they are not persuasive.
Applicant alleges, “Kleen therefore does not disclose, in particular, one or more programmable processing units of a set of plural programmable processing units operable to execute programs processing the transformed geometry data to generate data to be used in the second processing pass to determine which of the assembled primitives to process to generate rendering tiles that the render output is divided into, as now claimed in claim 1.” (page 11, lines 24-28). However, Examiner respectfully disagrees about the respective allegations as whole because: Kleen does disclose one or more programmable processing units of a set of plural programmable processing units operable to execute programs to perform various functions. Please see the corresponding citations and explanations for rejection of all limitations of claim 1 above. The arguments are not persuasive.
Applicant alleges, “Amended independent claims 11 and 21 recite the same distinguishing limitations discussed above, and the§ 103 rejections of those claims relied Kleen (and, as understood though not listed in the rejection, Hakura (para. no.5, last paragraph). As such, claims 11 and 21, and dependent 2-5, 9, 12-15, and 19 which depend from and add additional features to independent claims 1 and 11, are patentable over the applied references” (page 12, lines 1-5). However, Examiner respectfully disagrees about the respective allegations as whole because: (1) claims 11 and 21 correspond to claim 1. Therefore, claims 11 and 21 are rejected for the same rationale for claim 1; and (2) dependent claims 2-5, 9, 12-15, and 19 are rejected for the respective rationale above. The arguments are not persuasive.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 BIAO CHEN whose telephone number is (703)756-1199. The examiner can normally be reached M-F 8am-5pm ET.
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, Kee M Tung can be reached at (571)272-7794. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Biao Chen/
Patent Examiner, Art Unit 2611
/KEE M TUNG/ Supervisory Patent Examiner, Art Unit 2611
Prosecution Insights