DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 8, 14; 4, 6, 7, 12, 18 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Patel et al. U.S. Patent No. 7,671,862 in view of Livesley et al. U.S. Pub. No. 2025/0182235. .
Re: claims 1 and 14 (which are rejected under the same rationale), Patel teaches
1. A method of operating a graphics processor, the graphics processor comprising: one or more processing circuits that can be used to implement a set of generic pipeline stages, wherein respective ones of the generic pipeline stages of the set of generic pipeline stages can be configured as respective, different shader stages to be executed as part of a processing pipeline, (“... the present invention provides systems and methods for optimizing the use of hardware in the graphics pipeline by having a common core which may function as either a pixel shader, a vertex shader or a geometry shader... the common core is programmable or dynamically configurable as a pixel shader, a vertex shader, or a geometry shader, so a graphics pipeline can employ all pixel shaders, all vertex shaders, or all geometry shaders, or a combination of shaders based upon optimization of the computational needs for a specific application. The common cores can be dynamically configured (and reconfigured) depending upon demands on the graphics pipeline made by the host.”; Patel, col. 7, lines 13-22, lines 31-36)
The common cores (one or more processing circuits that can be used to implement a set of generic pipeline stages) are dynamically configured and reconfigured as a pixel shader, a vertex shader or a geometry shader (respective ones of the generic pipeline stages of the set of generic pipeline stages can be configured as respective, different shader stages to be executed as part of a processing pipeline).
(“The exemplary non limiting embodiment of the graphics pipeline 184’-1, as illustrated, includes a plurality of instances of a common core element 184’-1a, such as vertex shaders 184’-1a1 and 184’-1a2, a geometry shader 184’-1a3 having an associated stream output 184’-2 and a pixel shader 184’-1a4... As shown, the first common core of the embodiment is configured as a vertex shader... Following the tessellator 184’-1b, there is another common core in the pipeline, which can be used to perform post tessellation vertex shading on the data... The second common core is followed by a third common core that is configured as a geometry shader, 184’-1a3... The next component of the pipeline is a rasterizer 184’-1c... Following the rasterizer is a fourth common core, 184’-1a4, and it functions as a pixel shader...”; Patel, col. 15, line 60-col. 16, line 21, Fig. 3A)
Fig. 3A illustrates a graphics pipeline, where plural common core elements (respective ones of the generic pipeline stages of the set of generic pipeline stages) that have been programmed as different shaders. For example, first and second common cores are programmed as vertex shaders, the third common core is programmed as a geometry shader and the fourth common core is programmed as a pixel shader (can be configured as respective, different shader stages to be executed as part of a processing pipeline).
the method comprising: obtaining, for one or more instances of processing pipeline execution, a set of pipeline configuration information including an indication of a respective set of one or more shader stages to be executed for the processing pipeline; (“At 560, programs for execution by the GPU can be downloaded to the GPU to define the algorithmic elements for operation by the GPU. At 570, the input assembler... automatically takes the graphics data specified at 550 and the programs specified at 560 and optimizes the arrangement of common cores in accordance with the invention. Thus, where vertex or pixel computation is intensive as part of the specification of programmatic elements delivered to the GPU at 560 and the graphics data specified at 550, the invention may configure the pipeline cores to include a lot of vertex shaders or pixel shaders, respectively.”; Patel, col. 21, line 62-col. 22, line 6, Fig. 5)
Programs for execution by the GPU are downloaded to the GPU to define algorithmic elements for operation by the GPU (obtaining, for one or more instances of processing pipeline execution, a set of pipeline configuration information). The input assembler takes, for example, programs specified at 560 and optimizes the arrangement of common cores so that where vertex or pixel computation is intensive, the common cores may be configured to include plural vertex shaders or plural pixel shaders, respectively (including an indication of a respective set of one or more shader stages to be executed for the processing pipeline).
transferring the obtained set of pipeline configuration information into storage associated with the processing pipeline; (“... a “shader” can refer to the set of instructions or tokens downloaded to the GPU that are subsequently loaded into memory, e.g., register storage, used by the shader (hardware) to perform the shading.”; Patel, col. 2, lines 50-56)
A shader includes instructions that are loaded into memory or register storage used by the shader (transferring the obtained set of pipeline configuration information into storage associated with the processing pipeline).
and using the stored set of pipeline configuration information to control operation of the one or more processing circuits to execute the processing pipeline for the one or more instances of processing pipeline execution. (“At 580, the input assembler reviews the work items specified for processing by the graphics pipeline, and assigns the work to the cores.”; Patel, col. 22, lines 11-13)
The input assembler reviews the work items for processing by the graphics pipeline (using the set of pipeline configuration information) and assigns the work to the cores (to control the operation of the one or more processing circuits to execute the processing pipeline for the one or more instances of processing pipeline execution).
Patel is silent regarding the set of pipeline configuration information also includes an indication of which of the shader stages to be executed for the graphics processing pipeline are permitted to allocate portions of memory for packets of work items being processed by that shader stage, and which shader stages are permitted to access portions of memory allocated by other shader stages, however, Livesley teaches
wherein the set of pipeline configuration information also includes an indication of which of the shader stages to be executed for the graphics processing pipeline are permitted to allocate portions of memory for packets of work items being processed by that shader stage, and which shader stages are permitted to access portions of memory allocated by other shader stages. (“A GPU typically consumes dynamically allocated memory which is virtualised within the GPU when performing the first phase of a tile-based deferred rendering process, also known as the geometry phase or tile acceleration (TA) phase. This memory is used to write a data structure which is later consumed (read) in the second phase, known as the rendering phase or fragment processing phase. After the memory has been read for the last time in a given kick it can be recycled.... A memory management circuit, sometimes known as the parameter management (PM) module, performs both allocation of memory resources in the geometry phase... and recycling the memory resource... in the fragment phase in parallel.”; Livesley, [0151])
A memory management circuit performs allocation of memory in the geometry phase (indication of which shader stages to be executed for the graphics processing pipeline are permitted to allocate portions of memory for packets of work items being processed by that shader stage) and recycling the memory resource in the fragment phase (and which shader stages are permitted to access portions of memory allocated by other shader stages). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Patel by adding the feature of the set of pipeline configuration information also includes an indication of which of the shader stages to be executed for the graphics processing pipeline are permitted to allocate portions of memory for packets of work items being processed by that shader stage, and which shader stages are permitted to access portions of memory allocated by other shader stages, in order to enable the overlapping of the processing of the next fragment kick with the recycling of memory used by the preceding kick, as taught by Livesley ([0153]).
Claim 8 is a method analogous to the method of claim 1, is similar in scope and is rejected under the same rationale. Claim 8 has additional limitations. Re: claim 8, Patel teaches
8. (Currently Amended) A method of operating a data processing system that comprises: a host processor; (CPU or host processing unit 120; col. 14, lines 18-20, Fig. 2B)
and a graphics processor, (GPU 184; Patel, col. 14 lines 20-22, Fig. 2B)
wherein the graphics processor comprises a set of one or more processing circuits that can be used to implement a set of generic pipeline stages, (“Fig. 3A shows an exemplary graphics subunit, such as a video card, that includes a graphics processing unit (GPU) 184’ and an exemplary hardware configuration for the associated graphics pipeline 184’-1... the graphics pipeline 184’-1, as illustrated includes a plurality of instances of a common core element 184’-1a, such as vertex shaders 184’-1a1 and 184’-1a2, a geometry shader 184’-1a3 having an associated stream output 184’-2 and a pixel shader 184’-1a4.”; Patel, col. 15, lines 57-65, Fig. 3A)
Fig. 3A illustrates a GPU (graphics processor) that includes plural common core elements, where each common core element represents a shader, such as a vertex shader, a geometry shader and a pixel shader (a set of one or more processing circuits that can be used to implement a set of generic pipeline stages).
wherein respective ones of the generic pipeline stages of the set of generic pipeline stages can be configured as respective, different shader stages to be executed as part of a processing pipeline, (“... the present invention provides systems and methods for optimizing the use of hardware in the graphics pipeline by having a common core which may function as either a pixel shader, a vertex shader or a geometry shader... the common core is programmable or dynamically configurable as a pixel shader, a vertex shader, or a geometry shader, so a graphics pipeline can employ all pixel shaders, all vertex shaders, or all geometry shaders, or a combination of shaders based upon optimization of the computational needs for a specific application. The common cores can be dynamically configured (and reconfigured) depending upon demands on the graphics pipeline made by the host.”; Patel, col. 7, lines 13-22, lines 31-36)
The common cores (one or more processing circuits that can be used to implement a set of generic pipeline stages) are dynamically configured and reconfigured as a pixel shader, a vertex shader or a geometry shader (respective ones of the generic pipeline stages of the set of generic pipeline stages can be configured as respective, different shader stages to be executed as part of a processing pipeline).
(“The exemplary non limiting embodiment of the graphics pipeline 184’-1, as illustrated, includes a plurality of instances of a common core element 184’-1a, such as vertex shaders 184’-1a1 and 184’-1a2, a geometry shader 184’-1a3 having an associated stream output 184’-2 and a pixel shader 184’-1a4... As shown, the first common core of the embodiment is configured as a vertex shader... Following the tessellator 184’-1b, there is another common core in the pipeline, which can be used to perform post tessellation vertex shading on the data... The second common core is followed by a third common core that is configured as a geometry shader, 184’-1a3... The next component of the pipeline is a rasterizer 184’-1c... Following the rasterizer is a fourth common core, 184’-1a4, and it functions as a pixel shader...”; Patel, col. 15, line 60-col. 16, line 21, Fig. 3A)
Fig. 3A illustrates a graphics pipeline, where plural common core elements (respective ones of the generic pipeline stages of the set of generic pipeline stages) that have been programmed as different shaders. For example, first and second common cores are programmed as vertex shaders, the third common core is programmed as a geometry shader and the fourth common core is programmed as a pixel shader (can be configured as respective, different shader stages to be executed as part of a processing pipeline).
the method comprising: preparing on the host processor, in response to a request from an application executing on the host processor for processing to be performed by the graphics processor, a set of commands including a command to trigger one or more instances of processing pipeline execution,, (“RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120... Fig. 2B illustrates operating system 134, application programs 135...”; Patel, col. 13, lines 35-40, Fig. 2B)
The host processor operates on the application programs.
(“Fig. 5 illustrates... flow diagram to show how an application would make graphics calls... At 550, the graphics data to be operated upon is specified... At 560, programs for execution by the GPU can be downloaded to the GPU to define the algorithmic elements for operation by the GPU. At 570, the input assembler (See, e.g., Fig. 3A) automatically takes the graphics data specified at 550 and the programs specified at 560 and optimizes the arrangement of common cores in accordance with the invention”; Patel, col. 21, line 55-col. 22, line 1, Figs. 3A and 5)
Fig. 5 illustrates how an application makes graphics calls (preparing on the host processor, in response to a request from an application execution on the host processor for processing to be performed by the graphics processor). In response to the graphics calls, programs are downloaded to the GPU to define the algorithmic elements for operation by the GPU. The input assembler takes the graphics data and programs and optimizes the arrangement of common cores for pipeline execution (a set of commands including a command to trigger one or more instances of processing pipeline execution).
Re: claim 6, Patel teaches
6. (Original) The method of claim 1, wherein the transferring the obtained set of pipeline configuration information into the storage associated with the processing pipeline is triggered by execution from within a command buffer for the processing pipeline of a respective command to perform processing using the processing pipeline, the command to perform processing using the processing pipeline also indicating the set of pipeline configuration information to be transferred to the storage associated with the processing pipeline. (“The enhanced graphics pipeline of the invention thus includes a common core that is dynamically configurable to allocate pixel shaders, geometry shaders and vertex shaders in a manner that is best suited for the tasks being requested of the pipeline.”; Patel, col. 22, lines 31-35)
The enhanced graphics pipeline includes a common core that is dynamically configurable to allocate shaders (indicating the set of pipeline configuration information to be transferred to the storage associated with the processing pipeline), such as pixel shaders, geometry shaders and vertex shaders for tasks requested (triggered by execution from within a command buffer for the processing pipeline of a respective command to perform processing using the processing pipeline) of the pipeline.
Re: claim 7, Patel teaches
7. (Original) The method of claim 1, comprising obtaining a new set of pipeline configuration information including an indication of a respective set of one or more shader stages to be executed for another one or more instances of graphics processing pipeline execution, (“... the common core is programmable or dynamically configurable as a pixel shader, a vertex shader, or a geometry shader, so a graphics pipeline can employ all pixel shaders, all vertex shaders, or all geometry shaders, or a combination of shaders based upon optimization of the computational needs for a specific application. The common cores can be dynamically configured (and reconfigured) depending upon the demands on the graphics pipeline made by the host.”; Patel, col. 7, lines 31-38)
The common core is programmable as a pixel shader, a vertex shader or a geometry shader or a combination of shaders. The common cores can be dynamically configured and reconfigured (obtaining a new set of pipeline configuration information including indication of a respective set of one or more shader stages to be executed for another one or more instances of graphics pipeline execution) depending upon the demands of the graphics pipeline.
(“... since shaders are able to function as one another, where a pixel shader can be reconfigured to function as a vertex shader, the underlying resources of the graphics chip can be optimized for the tasks being aske of the graphics chip.”; Patel, col. 16, lines 48-53)
For example, when a pixel shader is reconfigured as a vertex shader (obtaining a new set of pipeline configuration information including an indication of a respective set of one or more shader stages to be executed), the resources of the graphics chip are optimized for the tasks being asked of the graphics chip (to be executed for another one or more instances of the graphics processing pipeline execution).
and subsequently storing the new set of pipeline configuration information in the storage associated with the processing pipeline (“The enhanced graphics pipeline of the invention thus includes a common core that is dynamically configurable to allocate pixel shaders, geometry shaders and vertex shaders in a manner that is best suited for the tasks being requested of the pipeline.”; Patel, col. 22, lines 31-35)
When the common core is reconfigured, requires shaders are allocated for the tasks requested of the pipeline (subsequently storing the new set of pipeline configuration information in the storage associated with the processing pipeline).
and using the new set of pipeline configuration information to control operation of the one or more processing circuits to execute the processing pipeline for the another one or more instances of processing pipeline execution. (“... since shaders are able to function as one another, where a pixel shader can be reconfigured to function as a vertex shader, the underlying resources of the graphics chip can be optimized for the tasks being aske of the graphics chip.”; Patel, col. 16, lines 48-53)
Dynamically configuring or reconfiguring the common cores (using the new set of pipeline configuration information to control operation of the one or more processing circuits) of the processing pipeline is considered to be another instance of the processing pipeline. When the common cores are reconfigured, the new programs are used control execution of the pipeline (to control operation of the one or more processing circuits to execute the processing pipeline for another one or more instances of the processing pipeline execution)
(“At 560, programs for execution by the GPU can be downloaded to the GPU to define the algorithmic elements for operation by the GPU. At 570, the input assembler... automatically takes the graphics data specified at 550 and the programs specified at 560 and optimizes the arrangement of common cores in accordance with the invention. Thus, where vertex or pixel computation is intensive as part of the specification of programmatic elements delivered to the GPU at 560 and the graphics data specified at 550, the invention may configure the pipeline cores to include a lot of vertex shaders or pixel shaders, respectively.”; Patel, col. 21, line 62-col. 22, line 6, Fig. 5)
Programs for execution by the GPU are downloaded to the GPU to define algorithmic elements for operation by the GPU. The input assembler takes, for example, programs specified at 560 and optimizes the arrangement of common cores so that where vertex or pixel computation is intensive, the common cores may be configured to include plural vertex shaders or plural pixel shaders, respectively (using the new set of pipeline configuration information to control operation of the one or more processing circuits to execute the processing pipeline for another one or more instances of the processing pipeline)
Re: claim 20, Patel teaches
20. (Original) A non-transitory computer readable storage medium storing computer software code which when executing on one or more processor will cause the one or more processor to perform a method as claimed in claim 1. (“The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132... RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120.”; Patel, col. 13, lines 29-38, Fig. 2B)
Fig. 2B illustrates system memory 130 that includes RAM 132 (computer readable storage medium), which stores program modules (storing computer software code) that are executed by processing unit 120 (which when execution on one or more processor will cause the one or more processor to perform a method).
Re: claim 4, Patel and Livesley teach
4. (Currently Amended) The method of claim 1, wherein the set of pipeline configuration information further includes an indication of which shader stages are able to deallocate portions of memory allocated by other shader stages. (“A memory management circuit, sometimes known as the parameter management (PM) module, performs both allocation of memory resources in the geometry phase... and recycling the memory resource... in the fragment phase in parallel.”; Livesley, [0151])
A memory management circuit performs recycling (deallocation) of memory in the fragment phase (an indication of which shader stages are able to deallocate portions of memory allocated by the other stages). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Patel by adding the feature of the set of pipeline configuration information further includes an indication of which shader stages are able to deallocate portions of memory allocated by other shader stages, in order to enable the overlapping of the processing of the next fragment kick with the recycling of memory used by the preceding kick, as taught by Livesley ([0153]).
Re: claims 12 and 18 (which are rejected under the same rationale), Patel is silent regarding the set of pipeline configuration information also includes an indication of which of the shader stages to be executed for the graphics processing pipeline are permitted to allocate portions of memory for packets of work items being processed by that shader stage, which shader stages are permitted to access portions of memory allocated by other shader stages, and optionally which shader stages are able to deallocate portions of memory allocated by other shader stages, however Livesley teaches
12. (Currently Amended) The method of claim 8, wherein the set of pipeline configuration information also includes an indication of which shader stages are able to deallocate portions of memory allocated by other shader stages. (“A GPU typically consumes dynamically allocated memory which is virtualised within the GPU when performing the first phase of a tile-based deferred rendering process, also known as the geometry phase or tile acceleration (TA) phase. This memory is used to write a data structure which is later consumed (read) in the second phase, known as the rendering phase or fragment processing phase. After the memory has been read for the last time in a given kick it can be recycled.... A memory management circuit, sometimes known as the parameter management (PM) module, performs both allocation of memory resources in the geometry phase... and recycling the memory resource... in the fragment phase in parallel.”; Livesley, [0151])
A memory management circuit performs allocation of memory in the geometry phase and recycling the memory resource in the fragment phase. A memory management circuit also performs recycling (deallocation) of memory in the fragment phase (and optionally which shader stages are able to deallocate portions of memory allocated by the other stages). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Patel by adding the feature of the set of pipeline configuration information also includes an indication of which shader stages are able to deallocate portions of memory allocated by other shader stages, in order to enable the overlapping of the processing of the next fragment kick with the recycling of memory used by the preceding kick, as taught by Livesley ([0153]).
Claim(s) 2, 5, 9, 10, 11, 13, 15, 16, 17 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Patel in view of Livesley as applied to claims 1, 8 and 14 above, and further in view of Lindholm et al. U.S. Patent No. 8,223,158.
Re: claims 2, 11 and 17 (which are rejected under the same rationale), Patel is silent regarding the set of pipeline configuration information also includes an indication of which shader program or programs should be executed by which of the shader stages to be executed for the graphics processing pipeline, however, Lindholm teaches
2. (Original) The method of claim 1, wherein the set of pipeline configuration information also includes an indication of which shader program or programs should be executed by which of the shader stages to be executed for the graphics processing pipeline. (“Fig. 3B is a simplified diagram of MPipe table 350... MPipe table 350 includes a number of m slots, each containing a pointer pointing to a block of memory locations in video memory 122 that store the programming instructions of a shader generic MPipe 300. In particular, slot 0 of MPipe table 350 contains a pointer 352, which points to shader A 304 in video memory 122. Similarly, slot/and slot m contain pointers 354 and 356, which point to shader B 306 and shader C 308, respectively... In one implementation , each slot of MPipe table 350 is associated with an enable bit. If the enable bit for a slot, such as slot 0 is set to 1, then the content of slot 0 is retrieved, meaning the configuration for slot 0 and the program for slot 0 are read from memory and the MPipe stage is put into a state where work packets can be received and processed.”; Lindholm, col. 4, lines 53-61, col. 4, line 65-col. 5, line 3, Fig. 3B)
Fig. 3B illustrates a MPipe table that includes plural slots where each slot includes a pointer pointing to a block of memory locations in video memory that store programming instructions for shaders. Each slot of the MPipe table has an enable bit. For example, if the enable bit for a slot 0 is set to 1, then the configuration and program (set of pipeline configuration information) for slot 0 are read and the MPipe stage (such as for example, the vertex shader stage) is put into a state where work packets are received and processed (includes an indication of which shader program or programs should be executed by which of the shader stages to be executed for the graphics processing pipeline). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Patel by adding the feature of the set of pipeline configuration information also includes an indication of which shader program or programs should be executed by which of the shader stages to be executed for the graphics processing pipeline, in order to have the flexibility and programmability of configuring a set of shaders in any user-defined sequence, as taught by Lindholm (col. 2, line 27-30).
Re: claims 5, 13 and 19 (which are rejected under the same rationale), Patel is silent regarding a shader stage to be executed for the processing pipeline is operable to generate, from an incoming packet of work items, a corresponding plurality of child packets to be further processed within that shader stage and wherein the set of pipeline configuration information also includes a set of one or more parameters for controlling the generation of child packets from incoming packets of work items for one or more of the shader stages to be executed for the processing pipeline, however, Lindholm teaches
5. (Original) The method of claim 1, wherein a shader stage to be executed for the processing pipeline is operable to generate, from an incoming packet of work items, a corresponding plurality of child packets to be further processed within that shader stage, (“The application program also invoked the shader programs with programming instructions that are designed to be executed by one or more streaming multiprocessors (SM) within GPU 116”; Lindholm, col. 3, lines 32-35, Fig. 1)
The shader programs (shader stages) are invoked and executed by the streaming multiprocessors within the GPU (executed for the processing pipeline).
(“SM0 is further couped to a modular pipe (MPipe) controller 202, which includes a resource manager 204... a software graphics pipe, instead of SM0 executes one or more instances of an MPipe and allows distribution of packets among these MPipes... ”; Lindholm, col. 3, lines 57-67, Fig. 2)
Fig. 2 illustrates a software graphics pipe, MPipe, that executes plural instances of MPipe and allows distribution of packets (incoming packet of work items) among MPipes for execution.
(“Generic MPipe 300 includes a set of shaders, such as shader A 304, shader B 306, and shader C 308... The shaders can form a linear processing list, where shader A 304 may receive input in the form of vertices, the output from shader A forms the input to shader B 306, and the output from shader B 306 forms the input to shader C 308... Also, generic MPipe 300 also supports replicating any shader within the MPipe... For instance... instead of performing vertex processing once in a single pass through the traditional graphics pipeline, generic MPipe 300 may be configured to have multiple vertex shaders successively. In addition each of the shaders can be of a different type. For example, in one implementation, shader A 304 is a vertex shader, shader B 306 is a tessellation shader, and shader C 308 is a geometry shader. Such an MPipe is referred to as a geometry MPipe. In another implementation, however, all the shaders in generic MPipe 300 are of the same type, such as vertex shaders.”; Lindholm, col. 4, lines 8-10, lines 22-45, Fig. 3A)
Fig. 3A illustrates a generic MPipe that includes a set of shaders. The MPipe 300 is considered to be a shader stage. Incoming packets are processed by the shaders. For example, the output from shader A (a shader stage to be executed for the processing pipeline is operable to generate, from an incoming packet of work items, a corresponding plurality of child packets) is the input to shader B, and the output of shader B is the input to shader C (child packets to be further processed within the shader stage).
and wherein the set of pipeline configuration information also includes a set of one or more parameters for controlling the generation of child packets from incoming packets of work items for one or more of the shader stages to be executed for the processing pipeline. (“An overlap between the output map of the first shader and the input map of the second shader is referred to as a “buffer map.” Fig. 5 is a conceptual diagram of a buffer map 500 in between shader A 304 and shader B 306... SM0 uses buffer map 500 to determine the appropriate resources to allocate at the output of shader A 304 and at the input of shader B 306.”; Lindholm, col. 6, lines 30-38, Fig. 5)
Fig. 5 illustrates a buffer map, between shaders A and B, that is used to determine resources needed at the output of shader A and the input of shader B.
(“To illustrate, suppose in the first scenario, the output map of shader A 304 contains attributes of a, b, and c, and the input map of shader B 306 contains attributes of b and c., where a, b, and c can be scalars, vectors, or some other resource. Whenever shader A 304 generates an output including the attribute of a SM0 recognizes that a is not in buffer map 500 and thus removes a before it reaches shader B 306. In other words, instead of allocating resources for a, b, and c, only the resources for b and c are allocated.”; Lindholm, col. 6, lines 38-46)
For example, the output map of shader A has attributes of a, b and c and the input map of shader B has attributes b and c, where a, b and c are scalars, vectors or some other resource (parameters for controlling the generation of child packets from incoming packets or work items for one or more shader stages to be executed for the processing pipeline. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Patel by adding the feature of a shader stage to be executed for the processing pipeline is operable to generate, from an incoming packet of work items, a corresponding plurality of child packets to be further processed within that shader stage and wherein the set of pipeline configuration information also includes a set of one or more parameters for controlling the generation of child packets from incoming packets of work items for one or more of the shader stages to be executed for the processing pipeline, in order to have the flexibility and programmability of configuring a set of shaders in any user-defined sequence, as taught by Lindholm (col. 2, line 27-30).
Re: claims 9 and 15 (which are rejected under the same rationale), Patel is silent regarding the set of pipeline configuration information is initially transferred into the graphics processor via a command processing circuit of the graphics processor, the command processing circuit providing commands to a command buffer for the processing pipeline, and wherein when the command to trigger one or more instances of processing pipeline execution is executed from the command buffer, the command causes pipeline configuration information to be transferred from storage associated with the command processing circuit to the storage associated with the processing pipeline, however, Lindholm teaches
9. (Original) The method of claim 8, wherein the set of pipeline configuration information is initially transferred into the graphics processor via a command processing circuit of the graphics processor, the command processing circuit providing commands to a command buffer for the processing pipeline, (“The application program also invokes the shader programs with programming instructions that are designed to be executed by one or more streaming multiprocessors (SM) within GPU 116. Graphics driver 104 transmits the programming instructions of the shader programs to the GPU 116.”; Lindholm, col. 3, lines 32-37, Fig. 1)
The graphics driver transmits the programming instructions (the set of pipeline configuration information) of the shader programs to the GPU (transferred into the graphics processor). Figs. 1-2 illustrate that that the graphics driver transmits the programming instructions via the work distribution unit, which is considered to include a buffer (via command processing circuit of the graphics processor, the command processing circuit providing commands to a command buffer for the processing pipeline).
(“... SM0 receive processing tasks for execution via a work distribution unit 200, which receives commands defining these processing tasks from graphics driver 104 shown in Fig. 1.”; Lindholm, col. 3, lines 45-49, Fig. 2)
Fig. 2 illustrates the SM0 receiving processing tasks via the work distribution unit (via command processing circuit of the graphics processor, the command processing circuit providing commands to a command buffer for the processing pipeline), which receives these commands from the graphics driver.
and wherein when the command to trigger one or more instances of processing pipeline execution is executed from the command buffer, the command causes pipeline configuration information to be transferred from storage associated with the command processing circuit to the storage associated with the processing pipeline. (“SM0 is further coupled to a modular pipe (MPipe) controller 202, which includes a resource manager 204... MPipe controller 202 is responsible for setting up and triggering one or more instances of an MPipe to be executed on SM0... ”; Lindholm, col. 3, lines 57-61, Fig. 2)
Fig. 2 illustrates a MPipe controller that triggers one or more instances of an MPipe to be executed on SM0 (the command to trigger one or more instances of processing pipeline execution is executed from the command buffer).
(“To identify the various shaders that are loaded in a memory system, one embodiment of generic MPipe 300 utilizes an MPipe table... for illustration purposes, the following discussions assume the shaders are loaded in video memory 122.”; Lindholm, col. 4, lines 46-52)
The shaders are loaded into video memory 122 (the command causes pipeline configuration information to be transferred from storage associated with the command processing circuit to the storage associated with the processing pipeline)
(“MPipe table 350 includes a number m of slots, each containing a pointer pointing to a block of memory locations in video memory 122 that store the programming instructions of a shader in generic MPipe 300. In particular, slot 0 of MPipe table 350 contains a pointer 352, which points to a shader A 304 in video memory 122. Similarly, slot/and slot m contain pointers 354 and 356, which point to shader B 306 and shader C 308, respectively.”; Lindholm, col. 4, lines 53-61, Fig. 3B)
Fig. 3B illustrates an MPipe table that includes slots, each containing a pointer to a block of memory locations in video memory that store the programming instructions of a shader in the generic MPipe. For example, slot 0 of the table points to a shader A in the video memory.
(“System memory 102 further includes an application program, one or more shader programs, an API, and graphics driver 104... The application program also invokes the shader programs with programming instructions that are designed to be executed by one or more streaming multiprocessors (SM) within the GPU 116. Graphics driver 104 transmits the programming instructions of the shader programs to the GPU 116.”; Lindholm, )
Figs. 1-2 illustrate system memory, which includes for example, shader programs. The graphics driver transmits the programming instructions of the shader programs to the GPU via the work distribution unit of Fig. 2, stores the shader program in the video memory (the command causes pipeline configuration information to be transferred from storage associated with the command processing circuit to the storage associated with the processing pipeline). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the method of Patel by adding the feature of the set of pipeline configuration information is initially transferred into the graphics processor via a command processing circuit of the graphics processor, the command processing circuit providing commands to a command buffer for the processing pipeline, and wherein when the command to trigger one or more instances of processing pipeline execution is executed from the command buffer, the command causes pipeline configuration information to be transferred from storage associated with the command processing circuit to the storage associated with the processing pipeline, in order to have the flexibility and programmability of configuring a set of shaders in any user-defined sequence, as taught by Lindholm (col. 2, line 27-30).
Re: claims 10 and 16 (which are rejected under the same rationale), Patel and Lindholm teach
10. (Original) The method of claim 9, wherein the set of pipeline configuration information is initially transferred into a set of registers associated with the command processing circuit of the graphics processor, (“... a “shader” can refer to the set of instructions or tokens downloaded to the GPU that are subsequently loaded into memory, e.g., register storage, used by the shader (hardware) to perform the shading.”; Patel, )
Shader instructions are downloaded to the GPU and loaded into register storage (the set of pipeline configuration information is initially transferred into as set of registers) used by the shader hardware (associated with the command processing circuit of the graphics processor) to perform shading
and wherein the command to trigger one or more instances of processing pipeline execution indicates which register values are to be transferred to the storage associated with the processing pipeline. (“... a developer is able to download instructions, or small programs, to a vertex shader unit that effectively program the vertex shader to perform specialized behavior. For instance, APIs expose functionality associated with increased number of registers in vertex shaders, e.g., specialized vertex shading functionality with respect to floating point numbers at a register level. In addition, it is possible to implement an instruction set that causes the extremely fast vertex shader to return only the fractional portion of floating point numbers.”; Patel, col. 4, 10-19)
Instructions are downloaded to program, for example, vertex shaders (command to trigger one or more instances of the processing pipeline execution). APIs expose functionality associated with an increased number of registers in vertex shaders, which indicates floating point numbers at a register level (indicates which register values are to be transferred to the storage associated with the processing pipeline).
Response to Arguments
Applicant’s arguments, see Amendment/Request for Reconsideration-After Non-Final Rejection, filed 1/22/2026, with respect to the Objection to the Specification have been fully considered and are persuasive. The Objection to the Specification of the previous Office Action has been withdrawn.
Applicant's arguments filed 1/22/2026 have been fully considered but they are not persuasive. Applicant argues:
“It is respectfully submitted that the independent claims, as amended, are not rendered obvious by the combined teaching of Patel and Livesey. The subject matter of claims 1, 12 and 18 now specifies: wherein the set of pipeline configuration information also includes an indication of which of the shader stages to be executed for the graphics processing pipeline are permitted to allocate portions of memory for packets of work items being processed by that shader stage, and which shader stages are permitted to access portions of memory allocated by other shader stages... Respectfully, there is no disclosure in Livesey however of a configurable pipeline, where different shader stages can be configured, or therefore of different shader stages being (selectively) permitted to allocate different portions of memory for packets of work items being processed by that shader stage, or of different shader stages being (selectively) permitted to access portions of memory allocated by other shader stages, let alone that these permissions may be changed over time, and be defined as part of the set of pipeline configuration information that indicates which shader stages are to be executed. Livesey does not therefore disclose a set of pipeline configuration information as claimed that indicates all of this. Further, applying Livesey to Patel does not obviously result in this, since the operation in Livesey is based on the geometry and fragment phases using the same pool of memory space. In this respect, the memory access/allocation control for the shader stages will thus control the flow of data along the processing pipeline, and so, if/when the processing pipeline is re-configured, the memory access/allocation permissions may also be changed to reflect the new pipeline configuration... Thus Livesey in combination with Patel fails to disclose or suggest the subject matter previously defined in claims 3, 12 and 18 (now incorporated in the independent claims). Livesey in combination with Patel therefore cannot render obvious to one of average skill in the art the subject matter of claims 1, 8 and 14. It is therefore respectfully requested that the rejection of claims 1, 6-8, 14 and 20 under 35 U.S.C. §102 and claims 4, 12 and 18 under 35 U.S.C. §103 be withdrawn. Reconsideration of the aforementioned rejections is respectfully requested.“
Examiner disagrees. It is the combination of references that teach the amended limitation of claim 1. Patel teaches the configuration/reconfiguration. Patel teaches that the common cores (one or more processing circuits that can be used to implement a set of generic pipeline stages) are dynamically configured and reconfigured as a pixel shader, a vertex shader or a geometry shader. (Patel, col. 7, lines 13-22, lines 31-36). Fig. 3A illustrates a graphics pipeline, where plural common core elements that have been programmed as different shaders. For example, first and second common cores are programmed as vertex shaders, the third common core is programmed as a geometry shader and the fourth common core is programmed as a pixel shader. (Patel, col. 15, line 60-col. 16, line 21, Fig. 3A). Thus, the common core elements can be configured as respective, different shader stages to be executed as part of a processing pipeline. Livesley teaches that a memory management circuit performs allocation of memory in the geometry phase (indication of which shader stages to be executed for the graphics processing pipeline are permitted to allocate portions of memory for packets of work items being processed by that shader stage) and recycling the memory resource in the fragment phase (and which shader stages are permitted to access portions of memory allocated by other shader stages). (Livesley, [0151]). Livesley is combined with Patel such that the operations of the memory management circuit of Livesley is included in the dynamically configured common cores of Patel. Claims 1, 8, 14 and claims 4, 6, 7, 12, 18 and 20 have been rejected. Please see the corresponding rejections.
Applicant's arguments filed 1/22/2026 have been fully considered but they are not persuasive. Applicant argues:
“Lindholm is added to the asserted teachings of Patel as teaching the features of 2, 5, 9-11, 13, 15-17 and 19 admitted in the Action to be missing from Patel. It is respectfully submitted that Lindholm alone, nor in combination with Patel, does not teach one of average skill the missing features of claims 1, 12 and 18 from which claims of 2, 5, 9-11, 13, 15-17 and 19 depend. Accordingly, one of average skill in the art could not be led by the combined teachings of Patel and Lindholm to find the claimed subject matter, as defined in claim of 2, 5, 9-11, 13, 15-17 and 19, obvious. It is therefore respectfully requested that the rejection of 2, 5, 9-11, 13, 15-17 under 35 35 U.S.C. §103 be withdrawn. Reconsideration is respectfully requested.”
Examiner disagrees. Claims 1, 8, 14 and claims 2, 5, 9-11, 13, 15-17 and 19 have been rejected. Please see the corresponding rejections.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONNA J RICKS whose telephone number is (571)270-7532. The examiner can normally be reached on M-F 7:30am-5pm EST (alternate Fridays off).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Devona Faulk can be reached on 571-272-7776. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Donna J. Ricks/Examiner, Art Unit 2618
/DEVONA E FAULK/Supervisory Patent Examiner, Art Unit 2618
Prosecution Insights