.
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
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 of this title, 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-20 are rejected under 35 U.S.C. 103 as being unpatentable by Crago et al. (U.S. 2025/0036418 A1) in view of Brennan et al. (U.S. 2022/0414950 A1).
Regarding Claim 1, Crago discloses a method of rendering in a graphics processing system (Cargo, [0008] “a method”and [0093] “a graphics processing unit (GPU) configured to implement a graphics rendering pipeline for processing three-dimensional (3D) graphics data” the method comprising:
compiling a program for a dual phase fragment task by a compiler, the first phase of the program being executed at a fragment rate and the second phase or the program being executed at a sample rate, the compiler being configured to determine data comprising the number of registers required per fragment in the first phase, the number of registers common between the first and second phase per fragment and the number of registers required per sample for the second phase to a processor (Cargo, [0064] “the programs for the pipeline stage are combined to create a complete program, the compiler performs a simple reallocation by compacting the registers into contiguous space. The program specification is updated to assign register allocation sizes per stage” and Fig. 13A, [0106] “the pipeline manager 1310 may configure at least one of the one or more DPCs 1320 to implement at least a portion of a graphics rendering pipeline” and [0108] “the fine raster engine to generate attributes for the pixel fragments based on the plane equations generated by the setup engine. The output of the raster engine 1325 comprises fragments to be processed, for example, by a fragment shader implemented within a DPC 1320” and [0160] The fragment shading stage 1570 processes fragment data by performing a set of operations (e.g., a fragment shader or a program) on each of the fragments and [0118] “The ROP unit 1350 also implements depth testing in conjunction with the raster engine 1325, receiving a depth for a sample location associated with a pixel fragment from the culling engine of the raster engine 1325. The depth is tested against a corresponding depth in a depth buffer for a sample location associated with the fragment” and Fig. 13A, [01288] “the SFUs 1452 may include texture unit configured to perform texture map filtering operations, the texture units are configured to load texture maps (e.g., a 2D array of texels) from the memory 1204 and sample the texture maps to produce sampled texture values for use in shader programs executed by the SM 1340” Crago teaches a program for the pipeline stages wherein a dual phase fragment task by a compiler, a first phase of the program being executed at a fragment (the fragment shading stage is implemented by a fragment shader within a DPC 1320, Fig. 13A), a second phase of the program being executed at a sample (sample the texture maps to produce sampled texture values for use in shader programs executed by the SM 1340, Fig. 13A, wherein a sample location associated with a pixel fragment) and the compiler determines data is allocated in the number of registers for the first phase and second phase the compiler performs a simple reallocation by compacting the registers into contiguous space. The program specification is updated to assign register allocation sizes per stage);
providing, by the compiler to a processor, the compiled program and data comprising the number of registers required per fragment in the first phase, the number of registers common between the first and second phase per fragment and the number of registers required per sample for the second phase (Cargo, [0064] “the compiler performs a simple reallocation by compacting the registers into contiguous space. The program specification is updated to assign register allocation sizes per stage” and Fig. 13A, [0108] “the fine raster engine to generate attributes for the pixel fragments based on the plane equations generated by the setup engine. The output of the raster engine 1325 comprises fragments to be processed” and [0128] “the texture units are configured to load texture maps (e.g., a 2D array of texels) from the memory 1204 and sample the texture maps to produce sampled texture values for use in shader programs executed by the SM 1340” and Fig. 13A, [0120] “The tasks are allocated to a particular DPC 1320 within a GPC 1250 and, if the task is associated with a shader program, the task may be allocated to an SM 1340” and Fig. 14A, [0124] Each SM 1340 includes a register file 1420 that provides a set of registers for the functional units of the SM 1340” Cargo teaches providing, by the compiler to a processor includes the number register (the register files 1420) per fragment in the 1st phase by the SM 1340, per sample in the 2nd phase (Fig. 13A, 14A).
computing, by the processor, the number of registers needed per fragment based on at least the number of registers required per fragment in the first phase, the number of registers per fragment common between the first and second phase and the number of registers required per sample for the second phase in the compiled program (Cargo, [0083] “FIG. 10 depicts how register file queues (RFQs) integrate into the processor core processing block” and [0064] “The program specification is updated to assign register allocation sizes per stage” and Fig. 13A, [0108] “the fine raster engine to generate attributes for the pixel fragments based on the plane equations generated by the setup engine. The output of the raster engine 1325 comprises fragments to be processed” and [0128] “the texture units are configured to load texture maps (e.g., a 2D array of texels) from the memory 1204 and sample the texture maps to produce sampled texture values for use in shader programs executed by the SM 1340” and Fig. 13A, [0120] “The tasks are allocated to a particular DPC 1320 within a GPC 1250 and, if the task is associated with a shader program, the task may be allocated to an SM 1340” and Fig. 14A, [0124] Each SM 1340 includes a register file 1420 that provides a set of registers for the functional units of the SM 1340” Cargo teaches computing (integrating, the program specification is updated to assign register allocation sizes per stage), by a core processor includes the number register (the register files 1420) per fragment in the 1st phase by the SM 1340, per sample in the 2nd phase (Fig. 13A, 14A).
However, Cargo does not explicitly teach the program being executed at a fragment rate;
the program being executed at a sample rate
obtaining, by the processor, a fragment shading rate value; and
computing, by the processor, the number of registers needed per fragment, the number of registers required per sample in the compiled program and the fragment shading rate value.
Brennan teaches the program being executed at a fragment rate (Brennan, [0017] “FIG. 2. The APD driver 122 also includes a just-in-time compiler that compiles programs for execution by processing components” and [0032] The graphics processing pipeline 134 is capable of performing rendering operations in a mode referred to as variable rate shading” and [0033] “FIG. 4A, The rasterizer stage 314 determines which of these pixels 402 is covered by the triangle 406 (shown as covered pixels 404) and generates fragments for each such pixel for fragment shading by the pixel shader stage 316” and Fig. 6, [0047] “The comparison operation 601 involves receiving a fragment for a particular pixel position in the render target. The comparison operation 601 includes performing a comparison function on the source data value 608 and the comparison value 604 to generate a shading rate for the fragment at the pixel position 608” Brennan a compiler compiles program for execution by processing components of the graphics processing pipeline, performing rendering operations e.g., the rasterizer stage (referred to as a first stage) generates a shading rate for the fragment at the pixel position (referred to as a fragment rate).
the program being executed at a sample rate (Brennan, [0037] “variable rate shading (“VRS”) is how to determine VRS rates for different portions of the render target. The VRS rate determines how many samples or pixels each work-item executing on the pixel shader stage 316” and Fig. 6, [0039] “the comparison operation is performed for each sample for which a source value is received by the VRS rate determiner 502, but comparing the source data 504 and comparison data 506 for each sample and generating a VRS rate for the sample” Brennan a compiler compiles program for execution by processing components of the graphics processing pipeline, performing rendering operations e.g., the pixel shader stage 316 (referred to as a second phase) generates a shading rate for the sample (referred to as a fragment rate);
obtaining, by the processor, a fragment shading rate value (Brennan, [0048] “Fig. 7, the VRS rate determiner 502 examines the per-pixel data 702 for multiple fragments within coarse VRS areas 704 and determines a VRS rate value 706 for the coarse VRS area 704” and [0050] “A coarse fragment is a fragment that corresponds to the pixel size of the determined VRS rate. For a 2×2 VRS rate, a single coarse fragment is generated for four original fragments (e.g., for four render target pixels). For a 2×1 VRS rate or a 1×2 VRS rate, a single coarse fragment is generated for two original fragments” Brennan teaches obtaining a fragment shading rate value, e.g., for a 2×2 VRS rate, a single coarse fragment is generated for four original fragments (e.g., for four render target pixels). For a 2×1 VRS rate or a 1×2 VRS rate, a single coarse fragment is generated for two original fragments (Fig. 7).
computing, by the processor, the number of registers needed per fragment, the number of registers required per sample in the compiled program and the fragment shading rate value (Brennan, [0061] “a non-transitory computer-readable storage medium for execution by a processor, non-transitory computer-readable storage mediums include registers” and [0032] The graphics processing pipeline 134 is capable of performing rendering operations in a mode referred to as variable rate shading”) and [0050] “A coarse fragment is a fragment that corresponds to the pixel size of the determined VRS rate. For a 2×2 VRS rate, a single coarse fragment is generated for four original fragments (e.g., for four render target pixels). For a 2×1 VRS rate or a 1×2 VRS rate, a single coarse fragment is generated for two original fragments” Brennan teaches computing, by the processor, the number of storage registers per fragment, per sample based on the fragment rate value (Fig. 7).
Crago and Brennan are combinable because they are from the same field of endeavor, system and method for image processing and try to solve similar problems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention was made for modifying the method of Crago to combine with executing the fragment rate (as taught by Brennan) in order to apply the program being executed at a fragment rate because Brennan can provide a compiler compiles program for execution by processing components of the graphics processing pipeline, performing rendering operations e.g., the rasterizer stage (referred to as a first stage) generates a shading rate for the fragment at the pixel position (referred to as a fragment rate) (Brennan, [0017], [0033], [0047]). Doing so, it may provide the source value for the fragment comes from a tile-based VRS rate map. The tile-based VRS rate map stores VRS rates on a screen tile basis (Brennan, [0053]).
Regarding Claim 2, a combination of Crago and Brennan discloses the method according to claim 1, further comprising allocating the computed number of registers to the dual phase fragment task for each fragment (Cargo, [0064] Finally, the programs for the pipeline stages are combined to create a complete program. First register re-allocation is performed; the compiler performs a simple reallocation by compacting the registers into contiguous space. The program specification is updated to assign register allocation sizes per stage" and Fig. 13A, [0108] “The output of the raster engine 1325 comprises fragments to be processed, for example, by a fragment shader implemented within a DPC 1320” and Fig. 14A [0124] “Each SM 1340 includes a register file 1420 that provides a set of registers for the functional units of the SM 1340” Cargo teaches allocating the computed number of register (the register file 1420) to the dual phase fragment task for each fragment via the SM 1340 (Figs 13A, 14A).
Regarding Claim 3, Cragodiscloses the method according to claim 1, wherein the number of registers required per fragment is the maximum of (Cargo, [0082] In parallel processing pipelines, different pipeline stages run different programs and therefore use a different number of registers. However, in current processing units, parallel processing pipelines are allocated a uniform value for processing context register allocation which is the maximum usage among all pipeline stages” Cargo teaches the number of registers required per fragment is the maximum usage:
the registers required per fragment in the first phase (Cargo, Fig. 13A, [0108] “The output of the raster engine 1325 comprises fragments to be processed, for example, by a fragment shader implemented within a DPC 1320” and [0120] “if the task is associated with a shader program, the task may be allocated to an SM 1340” and Fig. 14A [0124] “Each SM 1340 includes a register file 1420 that provides a set of registers for the functional units of the SM 1340” Cargo teaches allocating the register (the register file 1420) per fragment by the SM 1340 (Figs 13A, 14A) ; and
the number of registers required per fragment for the second phase wherein the number of registers required for the second phase comprises registers per fragment common between the first and second phase plus the number of registers required per sample for the second phase in the compiled program multiplied by the samples per fragment (Cargo, Fig. 13A, [0118] “The ROP unit 1350 receiving a depth for a sample location associated with a pixel fragment from the culling engine of the raster engine 1325”and [0128] “the texture units are configured to load texture maps (e.g., a 2D array of texels) from the memory 1204 and sample the texture maps to produce sampled texture values for use in shader programs executed by the SM 1340” and Fig. 14A [0124] “Each SM 1340 includes a register file 1420 that provides a set of registers for the functional units of the SM 1340” Cargo teaches allocating the register (the register file 1420) per sample associated with a pixel fragment from the raster engine 1325 by the SM 1340 (Figs 13A, 14A)
However, Cargo does not explicitly teach wherein the samples per fragment are based on the fragment shading rate value.
Brennan teaches wherein the samples per fragment is based on the fragment shading rate value (Brennan, [0057] “In the situation that a per-pixel VRS rate indicates a multi-sample VRS rate, the VRS rate determiner 502 indicates to the pixel shader stage 316 that at least one of the fragments” and [0050] “A coarse fragment is a fragment that corresponds to the pixel size of the determined VRS rate. For a 2×2 VRS rate, a single coarse fragment is generated for four original fragments (e.g., for four render target pixels). For a 2×1 VRS rate or a 1×2 VRS rate, a single coarse fragment is generated for two original fragments” Brennan teaches the multi-sample VRS rate indicates at least one of the fragment corresponding to fragment shading rate value, e.g., for a 2×2 VRS rate, a single coarse fragment is generated for four original fragments (e.g., for four render target pixels). For a 2×1 VRS rate or a 1×2 VRS rate, a single coarse fragment is generated for two original fragments (Fig. 7).
Crago and Brennan are combinable see rationale in claim 1.
Regarding Claim 4, the method according to claim 3, Cargo does not explicitly teach each fragment has a multisampling level per pixel, the method further comprising:
providing a multisampling level per pixel to the processor, and wherein the samples per fragment comprises the multisampling level per pixel multiplied by the fragment size.
However, Brennan teaches providing a multisampling level per pixel to the processor, and wherein the samples per fragment comprises the multisampling level per pixel multiplied by the fragment size (Brennan, [0057] “In the situation that a per-pixel VRS rate indicates a multi-sample VRS rate, the VRS rate determiner 502 indicates to the pixel shader stage 316 that at least one of the fragments” and [0058] “the pixels shader stage 316 shades fragments in the coarse VRS area at the rate determined for the coarse VRS area. The coarse fragments are sized according to the VRS rate. For example, in the situation that the rate is determined to be 2×2, and the buffer in which the fine fragments are stored is 2×2 in size, the rasterizer stage 314 generates one fragment for these four fine fragments” Brennan providing a multi-sample VRS rate level per-pixel, the multi-sampling level per pixel multiplied by the fragment size, e.g. 2x2 size.
Crago and Brennan are combinable see rationale in claim 1.
Regarding Claim 5, a combination of Cargo and Brennan discloses the method according to claim 1, wherein computing the number of registers further comprises setting a maximum number of registers required per fragment in the second phase (Cargo, [0082] In parallel processing pipelines, different pipeline stages run different programs and therefore use a different number of registers. However, in current processing units, parallel processing pipelines are allocated a uniform value for processing context register allocation which is the maximum usage among all pipeline stages” and Fig. 13A, [0108] “The output of the raster engine 1325 comprises fragments to be processed, for example, by a fragment shader implemented within a DPC 1320” and [0120] “if the task is associated with a shader program, the task may be allocated to an SM 1340” and Fig. 14A [0124] “Each SM 1340 includes a register file 1420 that provides a set of registers for the functional units of the SM 1340” Cargo teaches computing (allocating) a maximum computed number of register (the register file 1420) to the dual phase fragment task for each fragment by the SM 1340 (Figs 13A, 14A).
Regarding Claim 6, the method according to claim 1, Cargo does not explicitly teach wherein obtaining the fragment shading rate comprises computing the fragment shading rate value.
However, Brennan teaches obtaining the fragment shading rate comprises computing the fragment shading rate value (Brennan, [0048] “Fig. 7, the VRS rate determiner 502 examines the per-pixel data 702 for multiple fragments within coarse VRS areas 704 and determines a VRS rate value 706 for the coarse VRS area 704” and [0050] “A coarse fragment is a fragment that corresponds to the pixel size of the determined VRS rate. For a 2×2 VRS rate, a single coarse fragment is generated for four original fragments (e.g., for four render target pixels). For a 2×1 VRS rate or a 1×2 VRS rate, a single coarse fragment is generated for two original fragments” Brennan teaches obtaining a fragment shading rate value, e.g., for a 2×2 VRS rate, a single coarse fragment is generated for four original fragments (e.g., for four render target pixels). For a 2×1 VRS rate or a 1×2 VRS rate, a single coarse fragment is generated for two original fragments (Fig. 7).
Cargo and Brennan are combinable see rationale in claim 1.
Regarding Claim 7, a combination of Crago and Brennan discloses the method according to claim 1, further comprising:
computing, by the processor, the number of registers needed per fragment for a second execution of the program based on the number of registers required per fragment in the first phase, the number of registers per fragment common between the first and second phase and the number of registers required per sample for the second phase in the compiled program and the second fragment shading rate value (Cargo, [0083] “FIG. 10 depicts how register file queues (RFQs) integrate into the processor core processing block” and Fig. 13A, [0108] “the fine raster engine to generate attributes for the pixel fragments based on the plane equations generated by the setup engine. The output of the raster engine 1325 comprises fragments to be processed” and [0128] “the texture units are configured to load texture maps (e.g., a 2D array of texels) from the memory 1204 and sample the texture maps to produce sampled texture values for use in shader programs executed by the SM 1340” and Fig. 13A, [0120] “The tasks are allocated to a particular DPC 1320 within a GPC 1250 and, if the task is associated with a shader program, the task may be allocated to an SM 1340” and Fig. 14A, [0124] Each SM 1340 includes a register file 1420 that provides a set of registers for the functional units of the SM 1340” Cargo teaches computing (the program specification is updated to assign register allocation sizes per stage), by a core processor includes the number register (the register files 1420) per fragment in the 1st phase by the SM 1340, per sample in the 2nd phase (Fig. 13A, 14A).
However, Cargo does not explicitly teach obtaining, by the processor, a second fragment shading rate value to the processor;
Brennan teaches obtaining, by the processor, a second fragment shading rate value to the processor (Brennan, [0048] “Fig. 7, the VRS rate determiner 502 examines the per-pixel data 702 for multiple fragments within coarse VRS areas 704 and determines a VRS rate value 706 for the coarse VRS area 704” and [0050] “A coarse fragment is a fragment that corresponds to the pixel size of the determined VRS rate. For a 2×2 VRS rate, a single coarse fragment is generated for four original fragments (e.g., for four render target pixels). For a 2×1 VRS rate or a 1×2 VRS rate, a single coarse fragment is generated for two original fragments” Brennan teaches obtaining a second fragment shading rate value, e.g., for a 2×1 VRS rate or a 1×2 VRS rate, a single coarse fragment is generated for two original fragments (Fig. 7).
Cargo and Brennan are combinable see rationale in claim 1.
Regarding Claim 8, a combination of Crago and Brennan discloses the method according to claim 1, wherein the compiler provides a plurality of data fields, distinct from the compiled program to the processor, the data fields comprising:
the number of registers required per fragment in the first phase (Cargo, Fig. 13A, [0108] “the fine raster engine to generate attributes for the pixel fragments based on the plane equations generated by the setup engine. The output of the raster engine 1325 comprises fragments to be processed” and [0120] “The tasks are allocated to a particular DPC 1320 within a GPC 1250 and, if the task is associated with a shader program, the task may be allocated to an SM 1340” and Fig. 14A [0124] “Each SM 1340 includes a register file 1420 that provides a set of registers for the functional units of the SM 1340” Cargo teaches number of registers (a set of register file 1420) for the pixel fragments may be allocated via the SM 1340 (Fig. 14A);
the number of registers common between the first and second phase per fragment (Cargo, Fig. 13A, [0108] “The output of the raster engine 1325 comprises fragments to be processed, for example, by a fragment shader implemented within a DPC 1320” and [0120] “The tasks are allocated to a particular DPC 1320 within a GPC 1250 and, if the task is associated with a shader program, the task may be allocated to an SM 1340” and Fig. 14A [0124] “Each SM 1340 includes a register file 1420 that provides a set of registers for the functional units of the SM 1340” Cargo teaches the number of register common (register files 1420) for the task associated with a shader program (referred to as between the first and second phase fragment) are allocated via the SM 1340; and
the number of registers required per sample for the second phase (Cargo, Fig. 13A, [0128] “the texture units are configured to load texture maps (e.g., a 2D array of texels) from the memory 1204 and sample the texture maps to produce sampled texture values for use in shader programs executed by the SM 1340” and Fig. 14A [0124] “Each SM 1340 includes a register file 1420 that provides a set of registers for the functional units of the SM 1340” Cargo teaches number of registers (a set of register file 1420) for the sampled texture values may be allocated via the SM 1340 (Fig. 14A) for the second phase;
Regarding Claim 9, a combination of Crago and Brennan discloses a graphics processing system configured to render a scene formed of primitives (Cargo, [0024] “FIG. 14B, a processing system implemented using the PPU” and [0149] the PPU 1200 comprises a graphics processing unit (GPU). The PPU 1200 is configured to receive commands that specify shader programs for processing graphics data. Graphics data may be defined as a set of primitives such as points, lines, triangles, quads, triangle strips”, wherein the graphics processing system comprises logic configured to:
compile for a dual phase fragment task by a compiler, the first phase of the program being executed at a fragment rate and the second phase or the program being executed at a sample rate, the compiler being configured to provide the number of registers required per fragment in the first phase, the number of registers common between the first and second phase per fragment and the number of registers required per sample for the second phase;
provide the compiled program to a processor, the compiled program and data comprising the number of registers required per fragment in the first phase, the number of registers common between the first and second phase per fragment and the number of registers required per sample for the second phase;
provide fragment shading rate value to the processor; and
compute, by the processor, the number of registers needed per fragment based on the number of registers required per fragment in the first phase, the number of registers per fragment common between the first and second phase and the number of registers required per sample for the second phase in the compiled program and the fragment shading rate value.
Claim 9 is substantially similar to claim 1 is rejected based on similar analyses.
Regarding Claim 10, a combination of Crago and Brennan discloses the graphics processing system according to claim 9, wherein the logic is further configured to allocate the computed number of registers to the dual phase fragment task for each fragment.
Claim 10 is substantially similar to claim 2 is rejected based on similar analyses.
Regarding Claim 11, Cragodiscloses a combination of Crago and Brennan discloses the graphics processing system according to claim 9, wherein the number of registers required per fragment is the maximum of:
the registers required per fragment in the first phase; and
the number of registers required per fragment for the second phase wherein the number of registers required for the second phase comprises registers per fragment common between the first and second phase plus the number of registers required per sample for the second phase in the compiled program multiplied by the samples per fragment, wherein the samples per fragment is based on the fragment shading rate value.
Claim 11 is substantially similar to claim 3 is rejected based on similar analyses.
Regarding Claim 12, a combination of Crago and Brennan discloses the graphics processing system according to claim 11, wherein each fragment has a multisampling level per pixel wherein the logic is further configured to provide a multisampling level per pixel to a processor, and wherein the samples per fragment comprises the samples per fragment comprises the multisampling level per pixel multiplied by the fragment size.
Claim 12 is substantially similar to claim 4 is rejected based on similar analyses.
Regarding Claim 13 a combination of Crago and Brennan discloses the graphics processing system according to claim 9, wherein the logic is further configured to set a maximum number of registers required per fragment in the second phase.
Claim 13 is substantially similar to claim 5 is rejected based on similar analyses.
Regarding Claim 14, a combination of Crago and Brennan discloses the graphics processing system according to claim 9, wherein the logic is further configured to:
provide a second fragment shading rate value to the processor;
compute, by the processor, the number of registers needed per fragment for a second execution of the program based on the number of registers required per fragment in the first phase, the number of registers per fragment common between the first and second phase and the number of registers required per sample for the second phase in the compiled program and the second fragment shading rate value.
Claim 14 is substantially similar to claim 7 is rejected based on similar analyses.
Regarding Claim 15, a combination of Crago and Brennan discloses the graphics processing system according to claim 9, wherein the compiler provides a plurality of data fields, distinct from the compiled program to the processor, the data fields comprising:
the number of registers required per fragment in the first phase.
the number of registers common between the first and second phase per fragment; and
the number of registers required per sample for the second phase.
Claim 15 is substantially similar to claim 8 and is rejected based on similar analyses.
Regarding Claim 16, a combination of Crago and Brennan discloses the graphics processing system according to claim 9, further comprising:
a CPU (Cargo, [0031] “the pipeline is defined for a processing unit. The processing unit may be a central processing unit (CPU) configured to compile the dual phase fragment task (Cargo, [0163] “[0163] The graphics processing pipeline 1500 may be implemented via an application executed by a host processor, such as a CPU” and [0159] “The rasterization stage 1560 generates fragment data” Cargo teaches a CPU implements (compile) the graphics processing pipe line stages e.g., the rasterization stage 1560 generates fragment data; and
a GPU (Cargo, [0031] The processing unit may be a graphics processing unit (GPU)”, configured to compute the number of registers needed (Cargo, [0083] “FIG. 10 depicts how register file queues (RFQs) integrate into the processor core processing block” Cargo teaches the processor core (the GPU) computes (integrates) the number of registers needed.
Regarding Claim 17, a combination of Crago and Brennan discloses a graphics processing system configured to perform the method as set forth in claim 1 (Cargo, [0027] “FIG. 1, a system comprised of a non-transitory memory storage comprising instructions, may execute the instructions to perform the method 100” Cargo teaches a graphics processing system perform the method.
Regarding Claim 18, a combination of Crago and Brennan discloses the graphics processing system of claim 9, wherein the graphics processing system is embodied in hardware on an integrated circuit (Cargo, [0024] “FIG. 14B, a processing system implemented using the PPU” and [0093] “FIG. 12, the PPU 1200 is a multi-threaded processor that is implemented on one or more integrated circuit devices” Cargo teaches the graphics processing system is implement on an integrated circuit.
Regarding Claim 19, a combination of Crago and Brennan discloses a non-transitory computer readable storage medium having stored thereon computer executable code configured to cause the method as set forth in claim 1 to be performed when the code is run (Cargo, [0007] “a method, non-transitory computer readable medium are disclosed to provide software support for a parallel processing pipeline. Code defining a program to be executed using a pipeline having one or more stages is processed” Cargo teaches a non-transitory computer readable storage medium stored the coding defining a program to be executed using a pipeline.
Regarding Claim 20, a combination of Crago and Brennan discloses a non-transitory computer readable storage medium having stored thereon an integrated circuit definition dataset that (Cargo, [0007] “a non-transitory computer readable are disclosed to provide software support for a parallel processing pipeline” and [0093] “FIG. 12, the PPU 1200 is a multi-threaded processor that is implemented on one or more integrated circuit devices”
However, Cargo does not explicitly teach inputted to an integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture a graphics processing system as set forth in claim 9.
Brennan teaches inputted to an integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture a graphics processing system as set forth in claim 9 (Brennan, [0032] “The graphics processing pipeline 134 is capable of performing rendering operations” and [0060] “The methods provided can be implemented in any other type of integrated circuit (IC), such processors can be manufactured by configuring a manufacturing process using the results of processed hardware description language (HDL) instructions” Brennan teaches a method can be implemented in an input device as an integrated circuit such processors can be manufactured by configuring a manufacturing process using the results of processed hardware description language (HDL) instructions on the graphics processing pipeline.
Cargo and Brennan are combinable see rationale in claim 1.
Conclusion
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure Berson et al. (U.S. 2024/0378089 A1) and Saleh et al. (U.S. 2020/020594 A1).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KHOA VU whose telephone number is (571)272-5994. The examiner can normally be reached 8:00- 4:00.
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 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.
/KHOA VU/Examiner, Art Unit 2611
/KEE M TUNG/Supervisory Patent Examiner, Art Unit 2611
Prosecution Insights