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 action is in response to the amendment filed on 22nd December, 2025. Claims 1-2, 7, 10-11, and 19 have been amended. Claims 3-6 and 12-15 have been cancelled. Claim 20 has been added. Claims 1-2, 7-11, and 16-20 remain rejected in the application.
Response to Arguments
Applicant's arguments with respect to Claims 1, 10, and 19, filed on 22nd December, 2025, with respect to the rejection under 35 U.S.C. § 103 regarding that the prior art does not teach "an assigning circuit configured to, for each of a plurality of draw calls and/or draw call parts to be processed in a particular processing order to generate the render output: assign a respective identifier indicative of the particular processing order to the respective draw call or draw call part" and " the primitive list reader is configured to cause the rendering circuit to process primitives in accordance with the particular processing order to generate a rendering tile of the render output by using identifiers indicative of the particular processing order output by the plurality of tiling units to provide primitives to the rendering circuit in accordance with the particular processing order by: selecting primitives from a respective set of primitive lists prepared by one tiling unit of the plurality of tiling units at a time". The proposed amended claim limitations have been fully considered, but are not persuasive.
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, it would have been obvious to a person of ordinary skill in the art to implement an identical tile detector that compares identification codes of primitive lists of one tile to another tile as taught by Cho as the suggestion for doing so would allow the system to avoid extra repeated render calls, thereby resulting in improved rendering performance. Therefore, applicant’s remark cannot be considered persuasive.
In response to applicant's argument that the prior art does not teach "an assigning circuit configured to, for each of a plurality of draw calls and/or draw call parts to be processed in a particular processing order to generate the render output: assign a respective identifier indicative of the particular processing order to the respective draw call or draw call part" as recited in Claim 1, these limitations are taught by the combination of Dimitrov and Heggelund. In particular, Dimitrov teaches the following:
Paragraph [0086]: discloses tiling units 375 receiving primitives from crossbar unit 530 <read on assigning circuit>, where "each tiling unit 375 accepts and stores these primitives until the tiling unit 375 decides to perform a flush operation"; XBAR 530, which sends primitives from world-space pipelines to screen-space pipelines through assigned tiling units, is being interpreted as an assigning circuit; and
Paragraph [0101]: discloses the graphics subsystem 500 receiving commands to draw objects 602, where the crossbar unit 530 transmits primitives to tiling units 375 for tiling operations <read on processing draw calls/draw call parts>, which include commands to draw the objects to driver 103 <read on generate render output>.
In addition, Heggelund teaches the following:
Paragraph [0170]: discloses "repeated instances of a 'full-frame' command are identified by comparing configuration data (state data) <read on identifier> indicating data (e.g. indexes or pointers, such as, and in an embodiment, an index for a draw call descriptor <read on assigned draw calls/draw call parts>) included in the commands," where "if the configuration data (state data) indicating data, e.g. (e.g. draw call descriptor) indexes, for the commands are the same, then the commands can be, and are in an embodiment, taken to be the same (and vice-versa)";
Paragraph [0171]: discloses a primitive list reading circuit determining "whether the next command to be processed for the rendering tile is a second (repeated) instance of the “full-frame” command by comparing the configuration data (state data) indicating data (e.g. indexes <read on respective identifier> or pointers) included in the commands," where "in this case, it is determined that the next command to be processed for the rendering tile is a second (repeated) instance of the “full-frame” <read on particular processing order> command when the configuration data (state data) indicating data (e.g. index or pointer) for the next command is the same as the configuration data (state data) indicating data (e.g. index or pointer) for the (first) “full-frame” command".
Therefore, applicant’s remark cannot be considered persuasive.
In response to applicant's argument that the prior art does not teach "the primitive list reader is configured to cause the rendering circuit to process primitives in accordance with the particular processing order to generate a rendering tile of the render output by using identifiers indicative of the particular processing order output by the plurality of tiling units to provide primitives to the rendering circuit in accordance with the particular processing order by: selecting primitives from a respective set of primitive lists prepared by one tiling unit of the plurality of tiling units at a time" as recited in Claim 1, these limitations are taught by the combination of Dimitrov and Heggelund. In particular, Dimitrov teaches the following:
Paragraph [0086]: discloses "the tiling units 375 receive primitives from the crossbar unit 530," where "each tiling unit 375 accepts and stores these primitives until the tiling unit 375 decides to perform a flush operation"; and
Paragraph [0095]: discloses cache tile batches being transmitted to and processed by screen-space pipelines 345 sequentially, where the screen-space pipelines 345 are after tiling units 375; the process of storing primitives before a flush operation is performed is being interpreted as a form of preparation.
In addition, Heggelund teaches the following:
Paragraph [0129]: discloses generating a render output on a tile-by-tile basis <read on generate rendering tile>;
Paragraph [0171]: discloses a primitive list reading circuit determining "whether the next command to be processed for the rendering tile is a second (repeated) instance of the “full-frame” command by comparing the configuration data (state data) <read on identifier> indicating data (e.g. indexes or pointers) included in the commands," where "in this case, it is determined that the next command to be processed <read on process primitives> for the rendering tile is a second (repeated) instance of the “full-frame” <read on particular processing order> command when the configuration data (state data) indicating data (e.g. index or pointer) for the next command is the same as the configuration data (state data) indicating data (e.g. index or pointer) for the (first) “full-frame” command";
Paragraph [0127]: discloses "each rendering tile is processed and rendered separately, i.e. the separate, individual tiles are rendered one-by-one (i.e. on at tile-by-tile basis)"; and
Paragraph [0262]: discloses "the primitive list reader 31 of the GPU 3 determines which command (primitive) is to be processed next for a tile currently being rendered" by "considering the primitive lists 8B, stored in the memory 5, and selecting from one of those lists <read on respective set of primitive lists> the next command (primitive) <read on selecting primitives> to be processed," where "the primitive list reader 31 reads the stored primitive lists 8B <read on prepared primitive lists>, that have been determined as applying to the tile that is currently being rendered".
Therefore, applicant’s remark cannot be considered persuasive.
Regarding arguments to Claims 2, 7-9, 11, 16-18, and 20, they directly/indirectly depend on independent Claims 1, 10, and 20 respectively. Applicant does not argue anything other than independent Claims 1, 10, and 20. The limitations in those claims, in conjunction with combination, was previously established as explained.
Claim Rejections - 35 USC § 103
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-2, 8-11, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Dimitrov et al. (US 20150213638 A1, previously cited), hereinafter referenced as Dimitrov, in view of Heggelund et al. (US 20200111247 A1, previously cited), hereinafter referenced as Heggelund.
Regarding Claim 1, Dimitrov discloses a tiled-based graphics processor (Dimitrov, [0068]: teaches ROP 395, which "is a processing unit <read on tiled-based graphics processor> that performs raster operations, such as stencil, z test, blending, and the like, and transmits pixel data as processed graphics data for storage in graphics memory via the memory interface 214, where graphics memory is typically structured as one or more render targets") comprising:
a rendering circuit configured to process primitives to generate rendering tiles of a render output (Dimitrov, [0085]: teaches "a primitive may be transmitted to multiple screen-space pipelines 354 if the primitive overlaps raster tiles 420 <read on rendering tiles of render output> associated with more than one screen-space pipeline 354," where "after the world-space pipelines 352 generate the primitives, the world-space pipelines 352 transmit the primitives to the crossbar unit 530, which transmits the primitives to the corresponding tiling units 375 <read on rendering circuit> as specified by the bounding box generator unit"; [0086]: teaches tiling units 375 receiving primitives <read on process primitives> from crossbar unit 530, where "each tiling unit 375 accepts and stores these primitives until the tiling unit 375 decides to perform a flush operation");
a plurality of tiling units configured to process primitives to prepare primitive lists (Dimitrov, FIG. 5 teaches tiling units 375(0) and 375(1) <read on plurality of tiling units>); and
PNG
media_image1.png
364
578
media_image1.png
Greyscale
[[a primitive list reader configured to select, from primitive lists prepared by the plurality of tiling units, primitives to be processed by the rendering circuit to generate a rendering tile of the render output, and]]
[[to provide the selected primitives to the rendering circuit for processing; wherein]]
the tile-based graphics processor further comprises:an assigning circuit configured to, for each of a plurality of draw calls and/or draw call parts to be processed [[in a particular processing order]] to generate the render output (Dimitrov, [0086]: teaches tiling units 375 receiving primitives from crossbar unit 530 <read on assigning circuit>, where "each tiling unit 375 accepts and stores these primitives until the tiling unit 375 decides to perform a flush operation"; XBAR 530, which sends primitives from world-space pipelines to screen-space pipelines through assigned tiling units, is being interpreted as an assigning circuit; [0101]: teaches the graphics subsystem 500 receiving commands to draw objects 602, where the crossbar unit 530 transmits primitives to tiling units 375 for tiling operations <read on processing draw calls/draw call parts>, which include commands to draw the objects to driver 103 <read on generate render output>):
[[assign a respective identifier indicative of the particular processing order to the respective draw call or draw call part;]]
assign a tiling unit of the plurality of tiling units to process primitives of the respective draw call or draw call part (Dimitrov, [0086]: teaches "the tiling units 375 receive primitives from the crossbar unit 530," where "each tiling unit 375 accepts and stores these primitives <read on assigned tiling units> until the tiling unit 375 decides to perform a flush operation"; [0087]: teaches "upon receiving primitives, a tiling unit 375 updates several resource counters associated with the primitives"; [0108]: teaches the tiling units 375 processing multiple draw-calls, where "screen tiles 704 represent a portion of render target 601 that primitives associated with sub-draw-calls <read on process primitives of respective draw call/draw call part> may overlap"; Note: it should be noted that the plurality of GPCs are a part of a processing cluster array 230, which are being interpreted as hardware units that process assigned draw calls; in addition, the tiling units in the graphics processing pipeline are implemented with PPU 202, which includes the processing cluster array 230); and
cause the assigned tiling unit to process primitives of the respective draw call or draw call part [[to prepare a respective set of primitive lists]] (Dimitrov, [0086]: teaches "the tiling units 375 receive primitives from the crossbar unit 530," where "each tiling unit 375 accepts and stores these primitives <read on assigned tiling units> until the tiling unit 375 decides to perform a flush operation"; [0101]: teaches a set of draw-call commands to draw objects 602 being sent to crossbar unit 530, which then transmits the selected primitives to tiling units 375; [0108]: teaches the tiling units 375 processing multiple draw-calls, where "screen tiles 704 represent a portion of render target 601 that primitives associated with sub-draw-calls <read on process primitives of respective draw call/draw call part> may overlap"), and
[[to output the respective set of primitive lists together with the respective assigned identifier indicative of the particular processing order; wherein]]
[[the primitive list reader is configured to cause the rendering circuit to process primitives in accordance with the particular processing order to generate a rendering tile of the render output by using identifiers indicative of the particular processing order output by the plurality of tiling units to provide primitives to the rendering circuit in accordance with the particular processing order by:]]
[[selecting primitives from a respective set of primitive lists]] prepared by one tiling unit of the plurality of tiling units at a time (Dimitrov, [0086]: teaches "the tiling units 375 receive primitives from the crossbar unit 530," where "each tiling unit 375 accepts and stores these primitives until the tiling unit 375 decides to perform a flush operation"; [0095]: teaches cache tile batches being transmitted to and processed by screen-space pipelines 345 sequentially, where the screen-space pipelines 345 are after tiling units 375; Note: it should be noted that the process of storing primitives before a flush operation is performed is being interpreted as a form of preparation); and
[[in response to an indication of the end of a current draw call or draw call part or the start of a new draw call or draw call part, comparing the identifiers indicative of the particular processing order, and]]
[[selecting primitives from a respective set of primitive lists based on the comparison.]]
However, Dimitrov does not expressly disclose
a primitive list reader configured to select, from primitive lists prepared by the plurality of tiling units, primitives to be processed by the rendering circuit to generate a rendering tile of the render output, and
to provide the selected primitives to the rendering circuit for processing; wherein
the tile-based graphics processor further comprises:an assigning circuit configured to, for each of a plurality of draw calls and/or draw call parts to be processed in a particular processing order to generate the render output:
assign a respective identifier indicative of the particular processing order to the respective draw call or draw call part;
cause the assigned tiling unit to process primitives of the respective draw call or draw call part to prepare a respective set of primitive lists, and
to output the respective set of primitive lists together with the respective assigned identifier indicative of the particular processing order; wherein
the primitive list reader is configured to cause the rendering circuit to process primitives in accordance with the particular processing order to generate a rendering tile of the render output by using identifiers indicative of the particular processing order output by the plurality of tiling units to provide primitives to the rendering circuit in accordance with the particular processing order by:
selecting primitives from a respective set of primitive lists prepared by one tiling unit of the plurality of tiling units at a time; and
in response to an indication of the end of a current draw call or draw call part or the start of a new draw call or draw call part, comparing the identifiers indicative of the particular processing order, and
selecting primitives from a respective set of primitive lists based on the comparison.
Heggelund discloses
a primitive list reader configured to select, from primitive lists prepared by the plurality of tiling units, primitives to be processed by the rendering circuit to generate a rendering tile of the render output (Heggelund, [0177]: teaches a primitive list reader being able to identify repeated instances of a "full-frame" command before the processor <read on rendering circuit> reads (loads) configuration data (state data) for the repeated instances of the "full-frame" command; [0181]: teaches a "full-frame" command is a command to draw a "full-frame" primitive and to perform a "full-frame" graphics processing operation for the "full-frame" primitive that sets each data element corresponding to the entire area of the render output to a respective selected, where the system determines whether each data element for the rendering tile is (already) set to the respective selected value; [0184]: teaches the rasterizer testing a "full-frame" primitive against a patch covering the entire area of the render output being generated), and
to provide the selected primitives to the rendering circuit for processing (Heggelund, [0126]: teaches "the graphics processor <read on rendering circuit> comprises a primitive list reading unit (circuit) configured to read the primitive lists <read on provided selected primitives> and determine which commands to process for a rendering tile"); wherein
the tile-based graphics processor further comprises:an assigning circuit configured to, for each of a plurality of draw calls and/or draw call parts to be processed in a particular processing order to generate the render output (Heggelund, [0171]: teaches a primitive list reading circuit determining "that the next command to be processed for the rendering tile is a second (repeated) instance of the “full-frame” <read on particular processing order> command when the configuration data (state data) indicating data (e.g. index or pointer) for the next command is the same as the configuration data (state data) indicating data (e.g. index or pointer) for the (first) “full-frame” command"):
assign a respective identifier indicative of the particular processing order to the respective draw call or draw call part (Heggelund, [0170]: teaches "repeated instances of a 'full-frame' command are identified by comparing configuration data (state data) <read on identifier> indicating data (e.g. indexes or pointers, such as, and in an embodiment, an index for a draw call descriptor <read on assigned draw calls/draw call parts>) included in the commands," where "if the configuration data (state data) indicating data, e.g. (e.g. draw call descriptor) indexes, for the commands are the same, then the commands can be, and are in an embodiment, taken to be the same (and vice-versa)"; [0171]: teaches a primitive list reading circuit determining "whether the next command to be processed for the rendering tile is a second (repeated) instance of the “full-frame” command by comparing the configuration data (state data) indicating data (e.g. indexes <read on respective identifier> or pointers) included in the commands," where "in this case, it is determined that the next command to be processed for the rendering tile is a second (repeated) instance of the “full-frame” <read on particular processing order> command when the configuration data (state data) indicating data (e.g. index or pointer) for the next command is the same as the configuration data (state data) indicating data (e.g. index or pointer) for the (first) “full-frame” command"; Note: it should be noted that each draw call descriptor being included in each index is being interpreted as assigning an identifier, where the indexes include a respective descriptor);
cause the assigned tiling unit to process primitives of the respective draw call or draw call part to prepare a respective set of primitive lists (Heggelund, [0222]: teaches GPU 3 preparing "for each rendering tile a list of the commands (primitives) <read on respective set of primitive lists> to be processed for that rendering tile (e.g. that will apply to the tile)"), and
to output the respective set of primitive lists together with the respective assigned identifier indicative of the particular processing order (Heggelund, [0072]: teaches "a sequence of plural graphics processing commands <read on particular processing order> that includes one or more instances of a “full-frame” command to draw (one or more instances of) a “full-frame” primitive occupying the entire area of the render output is issued to the graphics processor to generate (render) the render output, together with one or more other commands to draw one or more other primitives," where "the one or more other primitives <read on primitive list> will typically not occupy the entire area of the render output, but may each occupy some but not all of the area of the render output"); wherein
the primitive list reader is configured to cause the rendering circuit to process primitives in accordance with the particular processing order to generate a rendering tile of the render output by using identifiers indicative of the particular processing order output by the plurality of tiling units to provide primitives to the rendering circuit in accordance with the particular processing order by (Heggelund, [0129]: teaches generating a render output on a tile-by-tile basis <read on generate rendering tile>; [0171]: teaches a primitive list reading circuit determining "whether the next command to be processed for the rendering tile is a second (repeated) instance of the “full-frame” command by comparing the configuration data (state data) <read on identifier> indicating data (e.g. indexes or pointers) included in the commands," where "in this case, it is determined that the next command to be processed <read on process primitives> for the rendering tile is a second (repeated) instance of the “full-frame” <read on particular processing order> command when the configuration data (state data) indicating data (e.g. index or pointer) for the next command is the same as the configuration data (state data) indicating data (e.g. index or pointer) for the (first) “full-frame” command"):
selecting primitives from a respective set of primitive lists prepared by one tiling unit of the plurality of tiling units at a time (Heggelund, [0127]: teaches "each rendering tile is processed and rendered separately, i.e. the separate, individual tiles are rendered one-by-one (i.e. on at tile-by-tile basis)"; [0262]: teaches "the primitive list reader 31 of the GPU 3 determines which command (primitive) is to be processed next for a tile currently being rendered" by "considering the primitive lists 8B, stored in the memory 5, and selecting from one of those lists <read on respective set of primitive lists> the next command (primitive) <read on selecting primitives> to be processed"; [0262]: further teaches "the primitive list reader 31 reads the stored primitive lists 8B <read on prepared primitive lists>, that have been determined as applying to the tile that is currently being rendered"); and
in response to an indication of the end of a current draw call or draw call part or the start of a new draw call or draw call part, comparing the identifiers indicative of the particular processing order (Heggelund, [0170]: teaches "repeated instances of a 'full-frame' command are identified by comparing configuration data (state data) <read on identifier> indicating data (e.g. indexes or pointers, such as, and in an embodiment, an index for a draw call descriptor <read on draw call parts>) included in the commands," where "if the configuration data (state data) indicating data, e.g. (e.g. draw call descriptor) indexes, for the commands are the same, then the commands can be, and are in an embodiment, taken to be the same (and vice-versa)"), and
selecting primitives from a respective set of primitive lists based on the comparison (Heggelund, [0263]: teaches a primitive list reader 31 reading primitive lists <read on set of primitive lists>; [0264]: teaches "if the primitive list reader 31 selects a “full-frame” command (e.g. a “full-frame” clear command, such as command C1), the “full-frame” command is “held back”, and before the “full-frame” command is passed to the resource allocation/state loading unit 32, the primitive list reader 31 selects the next command (primitive) <read on selecting primitives> to be processed for the tile"; [0265]: teaches "the primitive list reader 31 may then compare the “held-back” “full-frame” command <read on respective set of primitive lists based on comparison> with the next command").
Heggelund is analogous art with respect to Dimitrov because they are from the same field of endeavor, namely tile-based graphics processing. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to implement a primitive list reader that performs hierarchical rasterization by comparing configuration data as taught by Heggelund into the teaching of Dimitrov. The suggestion for doing so would allow the system to determine duplicate information and avoid repeated rendering steps, thereby improving overall rendering performance. Therefore, it would have been obvious to combine Heggelund with Dimitrov.
Regarding Claim 10, it recites the limitations that are similar in scope to Claim 1, but in a method. As shown in the rejection, the combination of Dimitrov and Heggelund discloses the limitations of Claim 1. Additionally, Dimitrov discloses a method of operating a tiled-based graphics processor that comprises (Dimitrov, [0068]: teaches ROP 395, which "is a processing unit <read on tiled-based graphics processor> that performs raster operations, such as stencil, z test, blending, and the like, and transmits pixel data as processed graphics data for storage in graphics memory via the memory interface 214, where graphics memory is typically structured as one or more render targets"; [0127]: teaches a method for rendering graphics objects):…
Thus, Claim 10 is met by Dimitrov according to the mapping presented in the rejection of Claim 1, given the tile-based graphics processor corresponds to a method.
Regarding Claim 19, it recites the limitations that are similar in scope to Claim 1, but in a non-transitory computer readable storage medium. As shown in the rejection, the combination of Dimitrov and Heggelund discloses the limitations of Claim 1. Additionally, Dimitrov discloses a non-transitory computer readable storage medium storing software code which when executing on a processor performs a method of operating a tiled-based graphics processor that (Dimitrov, [0068]: teaches ROP 395, which "is a processing unit <read on tiled-based graphics processor> that performs raster operations, such as stencil, z test, blending, and the like, and transmits pixel data as processed graphics data for storage in graphics memory via the memory interface 214, where graphics memory is typically structured as one or more render targets"; [0127]: teaches a method for rendering graphics objects; [0133]: teaches a computer-readable media being a solid-state non-volatile semiconductor memory <read on non-transitory computer readable storage medium> that stores a program product <read on software code> for use with a computer system) comprises…
Thus, Claim 19 is met by Dimitrov according to the mapping presented in the rejection of Claim 1, given the tile-based graphics processor corresponds to a non-transitory computer readable storage medium.
Regarding Claims 2 and 11, the combination of Dimitrov and Heggelund discloses the tile-based graphics processor and the method of Claims 1 and 10 respectively. Additionally, Dimitrov further discloses wherein the assigning circuit is configured to:
assign a first tiling unit of the plurality of tiling units to process primitives of a first draw call or draw call part to be processed to generate the render output (Dimitrov, [0079]: teaches a first tiling unit 375(0); [0101]: teaches the graphics subsystem 500 receiving commands to draw objects 602, where the crossbar unit 530 transmits primitives to tiling units 375 for tiling operations <read on processing first draw call/draw call part>, which include commands to draw the objects to driver 103; [0105]: teaches a sequence of render states being drawn by tiling units <read on generate render output>), and
cause the first tiling unit to process primitives of the first draw call or draw call part (Dimitrov, [0078]: teaches a plurality of GPCs 208, where each one are assigned <read on first tiling unit> to process respective raster tiles <read on process first draw call/draw call part> for tiling units; [0101]: teaches a set of draw-call commands to draw objects 602 being sent to crossbar unit 530, which then transmits the selected primitives to tiling units 375); and
assign a second, different tiling unit of the plurality of tiling units to process primitives of a second, different draw call or draw call part to be processed to generate the same render output (Dimitrov, [0079]: teaches a second tiling unit 375(1); [0101]: teaches the graphics subsystem 500 receiving commands to draw objects 602 <read on primitives>, where the crossbar unit 530 transmits primitives to tiling units 375 for tiling operations <read on processing second draw call/draw call part>, which include commands to draw the objects to driver 103 using screen tile batches; [0109]: teaches each screen tile batch being associated with a different screen tile <read on different draw call/draw call part>; [0105]: teaches a sequence of render states being drawn by tiling units <read on generate render output>), and
cause the second tiling unit to process primitives of the second draw call or draw call part (Dimitrov, [0078]: teaches a plurality of GPCs 208, where each one are assigned <read on second tiling unit> to process respective raster tiles <read on process second draw call/draw call part> for tiling units; [0101]: teaches a set of draw-call commands to draw objects 602 being sent to crossbar unit 530, which then transmits the selected primitives to tiling units 375).
Regarding Claims 8 and 17, the combination of Dimitrov and Heggelund discloses the tile-based graphics processor and the method of Claims 1 and 10 respectively. Additionally, Dimitrov further discloses
a draw call splitting circuit configured to split draw calls into draw call parts (Dimitrov, [0111]: teaches driver 103 dividing <read on splitting> "each draw-call into sub-draw-calls <read on draw call parts> and groups together sub-draw-calls into screen tile batches 702"), and
provide the draw call parts to the assigning circuit (Dimitrov, [0115]: teaches driver 103 transmitting sub-draw-calls in screen tile 704 order to the graphics subsystem 500 for rendering, which contains crossbar unit 530 <read on provide draw call parts to assigning circuit>).
Regarding Claims 9 and 18, the combination of Dimitrov and Heggelund discloses the tile-based graphics processor and the method of Claims 8 and 17 respectively. Additionally, Dimitrov further discloses wherein the draw call splitting circuit is configured to:
determine whether a draw call can be split into parts that can be processed independently of each other (Dimitrov, [0106]: teaches a situation where "application programs transmit multiple draw-calls that include a large number of primitives for single geometric objects," resulting in the operations of tiling units 375 not providing substantial advantages for cache memory traffic, which results in received draw-called being reorganized and divided into sub-draw-calls <read on determine if draw call can be split into parts>; [0128]: teaches driver 103 dividing "the draw-calls into sub-draw-calls," where "each sub-draw-call specifies a subset of the geometry specified by the received draw-calls <read on draw call parts being processed independently of each other>"); and
when it is determined that a draw call can be split into parts that can be processed independently of each other, split the draw call into parts (Dimitrov, [0111]: teaches driver 103 dividing <read on splitting> "each draw-call into sub-draw-calls <read on parts> and groups together sub-draw-calls into screen tile batches 702").
Regarding Claim 20, the combination of Dimitrov and Heggelund discloses the tile-based graphics processor of Claim 1. Additionally, Dimitrov further discloses wherein the primitive list reader comprises:
a plurality of primitive list fetchers (Dimitrov, [0050]: teaches a setup unit 380 being included in a screen-space pipeline, which receives primitives from tiling units through XBAR <read on primitive list fetcher>; [0079]: teaches a plurality of screen-space pipelines, which includes a plurality of setup units 380 as shown in FIG. 5), wherein
PNG
media_image1.png
364
578
media_image1.png
Greyscale
different primitive list fetchers of the plurality of primitive list fetchers are configured to fetch primitives from primitive lists prepared by different tiling units of the plurality of tiling units (Dimitrov, [0062]: teaches "the tiling unit 375 transmits graphics primitives <read on fetched primitives> to the setup unit 380 one cache tile at a time"; [0079]: teaches a plurality of screen-space pipelines, which includes a plurality of setup units 380 <read on different primitive list fetchers> as shown in FIG. 5; FIG. 5 teaches separate setup units 380 receiving primitives from separate tiling units <read on different tiling units> 375(0) and 375(1)).
Claims 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Dimitrov et al. (US 20150213638 A1, previously cited), hereinafter referenced as Dimitrov, in view of Heggelund et al. (US 20200111247 A1, previously cited), hereinafter referenced as Heggelund as applied to Claims 1 and 10 above respectively, and further in view of Cho et al. (US 20160163087 A1, previously cited), hereinafter referenced as Cho.
Regarding Claims 7 and 16, the combination of Dimitrov and Heggelund discloses the tile-based graphics processor and the method of Claims 1 and 10 respectively. The combination of Dimitrov and Heggelund does not expressly disclose the limitations of Claims 7 and 16; however, Cho discloses wherein the identifier comprises
a number that starts at an initial value for a first draw call or draw call part for a render output (Cho, [0063]: teaches a frame number <read on initial number value> being assigned to the draw call <read on first draw call/draw call part for render output> and a number being assigned to the G-State, where both number values are independent of each other), and
is incremented for each subsequent draw call or draw call part for the same render output (Cho, [0064]: teaches an example of the rendering device 300 receiving three draw calls for an Nth frame, where "the rendering device 300 performs a clear operation when a 0th draw call is received, draws a triangle when a 1st draw call is received, and draws a circle when a 2nd draw call is received" and goes to the N+1th frame to repeat the process <read on increment number for each subsequent draw call/draw call part for same render output>).
Cho is analogous art with respect to Dimitrov, in view of Heggelund because they are from the same field of endeavor, namely tile-based graphics processing techniques. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to implement an identical tile detector that compares identification codes of primitive lists of one tile to another tile as taught by Cho into the teaching of Dimitrov, in view of Heggelund. The suggestion for doing so would allow the system to avoid extra repeated render calls, thereby resulting in improved rendering performance. Therefore, it would have been obvious to combine Cho with Dimitrov, in view of Heggelund.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Howson (US 20130002663 A1) discloses a graphics processing system that includes tiling units with primitive and command fetch units;
Yang (US 20200065935 A1) discloses performing tiling tests for a subset of tiles, which are used to determine whether primitives are in other tiles, which are located within a region bounded by two or more of the tiles of the subset; and
Yang et al. (US 20180276876 A1) discloses a graphics processing system that includes fetch units, including a geometry fetch unit for tile-based rasterization.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KARL TRUONG whose telephone number is (703)756-5915. The examiner can normally be reached 10:30 AM - 7:30 PM.
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, Kent Chang can be reached at (571) 272-7667. 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.
/K.D.T./Examiner, Art Unit 2614
/KENT W CHANG/Supervisory Patent Examiner, Art Unit 2614