DETAILED ACTION
Claims 1-3, 6-13, 16-23, 26-28, and 31-33 are amended. Claim 34 is cancelled Claims 1-33 are pending in the application.
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 .
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.
Examiner’s Notes
The Examiner cites particular sections in the references as applied to the claims below for the convenience of the applicant(s). Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant(s) fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 07/29/2026 has been entered.
Response to Amendment
Amendments to claims 13 and 27 are fully considered and are satisfactory to overcome the objections directed to claims 13 and 27-33 in the previous Office Action.
Amendments to claim 1 are fully considered and are satisfactory to overcome the rejections under 35 U.S.C. §112(b) directed to claims 1-10 in the previous Office Action.
Amendments to claim 27 are fully considered and are satisfactory to overcome the rejections under 35 U.S.C. §101 directed to claims 27-33 in the previous Office Action.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 6-8, 10-12, 16, 18, 20-23, 26, 27, 31, and 33 are rejected under 35 U.S.C. 103 as being unpatentable over Tian et al. (WO 2016/145632 A1; from IDS filed on 10/07/2022; hereinafter “Tian”) in view of Asthana (US 11,055,812 B1) and Kini et al. (US 2014/0344821 A1; hereinafter “Kini”).
With respect to claim 1, Tian teaches: One or more processors (see e.g. Tian, Fig. 2: “Processor 200”), comprising circuitry (see e.g. Tian, paragraph 39: “processor 200 can be implemented on one or more chips or as an SoC integrated circuit”; and Fig. 6, 12), wherein the circuitry:
causes, based on whether the one or more operations to launch the one or more first software modules and the one or more operations to launch the second software modules can be concurrently performed (see e.g. Tian, paragraph 60: “executing multiple simultaneous threads”; paragraph 65: “thread dispatcher 604 that arbitrates thread initiation requests from the graphics and media pipelines and instantiates the requested threads on one or more execution units 608A-608N”; and paragraph 70: “in response to an add instruction the execution unit performs a simultaneous add operation across each color channel representing a texture element or picture element”), the one or more operations to launch the one or more first software modules and the one or more operations to launch the one or more second software modules to be concurrently performed (see e.g. Tian, paragraph 60: “each execution unit (e.g. 608A) is an individual vector processor capable of executing multiple simultaneous threads and processing multiple data elements in parallel for each thread”; paragraph 65: “instantiates the requested threads on one or more execution units 608A-608N”; and paragraph 70: “in response to an add instruction the execution unit performs a simultaneous add operation across each color channel representing a texture element or picture element”) by the one or more processors (see e.g. Tian, paragraph 60: “each execution unit (e.g. 608A) is an individual vector processor capable of executing multiple simultaneous threads and processing multiple data elements in parallel for each thread”; paragraphs 36, 43, 59; and Fig. 2, 3, 6) or another processor (see e.g. Tian, Fig. 2: “Graphics Processor 208”; paragraph 59: “thread execution logic 600 including an array of processing elements employed in some embodiments of a GPE”; and Fig. 3: “Graphics Processor 300”, “GPE 310”).
Tian does not but Asthana teaches:
Identifies… whether one or more operations to launch one or more first software modules and one or more operations to launch the one or more second software modules can be concurrently performed (see e.g. Asthana, column 16, lines 27-31: “firmware 520 may attempt to opportunistically launch the work in geometry stage 2 (6042). In such embodiments, the geometry stage 2 (6042) may be launched at the same time (or even prior to) geometry stage 0 (6040)”) based on whether the one or more operations to launch the one or more first software modules are independent of the one or more operations to launch the one or more second software modules (see e.g. Asthana, column 6, lines 19-26: “the geometry stage operations of the given command are waiting on no such true dependency, then the system may simply attempt to opportunistically launch one or more of the geometry stage operations at a determined time, e.g., at the earliest time that it has been determined that no “true” barriers remain for that portion of the command (i.e., the geometry stage operations, in this example)”; and column 16, lines 28-31: “opportunistically launch the work in geometry stage 2 (6042). In such embodiments, the geometry stage 2 (6042) may be launched at the same time (or even prior to) geometry stage 0 (6040)””); and
Tian and Asthana are analogous art because they are in the same field of endeavor: managing parallel execution of software modules. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Tian with the teachings of Asthana. The motivation/suggestion would be to improve the parallel processing efficiency (see e.g. Asthana, column 16, lines 22-49).
Furthermore, even though Tian discloses driver software (see e.g. Tian, paragraph 88), Tian does not explicitly disclose using the driver software for identifying concurrent performance of launching operations.
However, Kini teaches:
using one or more software drivers (see e.g. Kini, Fig.2: “CUDA Driver 220”; paragraph 43: “by allocating the valid device priorities 222 based on an application-specific max nesting depth 224, the CUDA driver 220 provides a flexible framework for supporting both prioritization and dynamic parallelism”; paragraph 35: “dynamic parallelism enables a "parent" work component executing on the parallel processing subsystem 112 to launch a "child" work component on the parallel processing subsystem 112”;and paragraphs 39, 45-46),
Tian and Kini are analogous art because they are in the same field of endeavor: managing parallel execution of software modules. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Tian with the teachings of Kini. The motivation/suggestion would be to improve workload management associated with the parallel processing mechanism.
With respect to claim 2, Tian as modified teaches: The one or more processors of claim 1, wherein the circuitry is to perform the one or more software drivers (see e.g. Tian, paragraph 88: “driver software for the graphics processor translates API calls that are specific to a particular graphics or media library into commands that can be processed by the graphics processor”), wherein the one or more software drivers are to cause the one or more operations to launch the one or more first software modules and the one or more operations to launch the one or more second software modules to be concurrently performed by the one or more processors or one or more other processors (see e.g. Tian, paragraph 88: “driver software for the graphics processor translates API calls that are specific to a particular graphics or media library into commands that can be processed by the graphics processor”; paragraph 108: “graphics driver 1029 communicates with graphics processor 1032 to dispatch commands and instructions”; and paragraph 60: “each execution unit (e.g. 608A) is an individual vector processor capable of executing multiple simultaneous threads and processing multiple data elements in parallel for each thread”).
With respect to claim 3, Tian as modified teaches: The one or more processors of claim 1, wherein the circuitry is to cause the one or more operations to launch (see e.g. Tian, paragraph 27: “process instructions which, when executed, perform operations for system and user software”) the one or more first software modules to be performed concurrently with the one or more operations to launch the one or more second software modules (see e.g. Tian, paragraph 27: “one or more processors 102 each include one or more processor cores 107 to process instructions which, when executed, perform operations for system and user software. In some embodiments, each of the one or more processor cores 107 is configured to process a specific instruction set 109”; and paragraph 60: “each execution unit (e.g. 608A) is an individual vector processor capable of executing multiple simultaneous threads and processing multiple data elements in parallel for each thread”).
With respect to claim 6, Tian as modified teaches: The one or more processors of claim 1, wherein an application programming interface (API) (see e.g. Tian, paragraph 88: “API calls”; and paragraph 115: “3D APIs like OpenGL/DirectX”) is to cause the one or more software drivers (see e.g. Tian, paragraph 88: “driver software for the graphics processor translates API calls”) to concurrently perform operations to prepare the one or more first software modules and the one or more second software modules to be launched concurrently (see e.g. Tian, paragraph 61: “execution units in array 608A-608N execute an instruction set that includes native support for many standard 3D graphics shader instructions, such that shader programs from graphics libraries (e.g., Direct 3D and OpenGL) are executed”; paragraph 60: “each execution unit (e.g. 608A) is an individual vector processor capable of executing multiple simultaneous threads and processing multiple data elements in parallel for each thread”; and paragraph 88: “driver software for the graphics processor translates API calls that are specific to a particular graphics or media library into commands that can be processed by the graphics processor”).
With respect to claim 7, Tian as modified teaches: The one or more processors of claim 1, wherein to cause the one or more operations to launch the one or more first software modules and the one or more operations to launch the one or more second software modules to be concurrently performed by one or more processors includes performing operations concurrently to prepare the one or more first software modules and the one or more second software modules to be performed by one or more graphics processing cores (see e.g. Tian, paragraph 58: “graphics processor 500 includes scalable thread execution resources featuring modular cores 580A-580N (sometimes referred to as core slices) , each having multiple sub-cores 550A-550N, 560A-560N (sometimes referred to as core sub-slices) (e.g., 550A)… Each sub-core in the set of first sub-cores 550A-550N includes at least a first set of execution units 552A-552N… Each sub-core in the set of second sub-cores 560A-560N includes at least a second set of execution units 562A-562N”; paragraph 60: “each execution unit (e.g. 608A) is an individual vector processor capable of executing multiple simultaneous threads and processing multiple data elements in parallel for each thread”; and Fig. 5).
With respect to claim 8, Tian as modified teaches: The one or more processors of claim 1, wherein to cause the one or more operations to launch the one or more first software modules and the one or more operation to launch the one or more second software modules to be concurrently performed includes performing operations concurrently to verify the one or more first software modules and the one or more second software modules are set up to be performed by one or more graphics processing units (see e.g. Tian, paragraph 111: “generate a software simulation 1110 of an IP core design in a high level programming language (e.g., C/C++) . The software simulation 1110 can be used to design, test, and verify the behavior of the IP core”; paragraph 112: “The HDL may be further simulated or tested to verify the IP core design”; paragraph 110: ““IP cores, ” are reusable units of logic for an integrated circuit”; and paragraph 60).
With respect to claim 10, Tian as modified teaches: The one or more processors of claim 1, wherein the circuitry is to perform the one or more software drivers (see e.g. Tian, paragraph 88: “driver software for the graphics processor translates API calls that are specific to a particular graphics or media library into commands that can be processed by the graphics processor”), wherein the one or more software drivers are to perform operations to encode work submissions from one or more central processing cores to be performed by one or more graphics processing cores (see e.g. Tian, paragraph 88: “driver software for the graphics processor translates API calls that are specific to a particular graphics or media library into commands that can be processed by the graphics processor”; paragraph 108: “user mode graphics driver 1026 uses operating system kernel mode functions 1028 to communicate with a kernel mode graphics driver 1029. In some embodiments, kernel mode graphics driver 1029 communicates with graphics processor 1032 to dispatch commands and instructions”; and Fig. 10).
With respect to claims 11-12, 16, and 18: Claims 11-12, 16, and 18 are directed to a system implementing active functions corresponding to the active functions implemented by the one or more processors recited in claims 1-2, 8, and 10, respectively; please see the rejections directed to claims 1-2, 8, and 10 above which also cover the limitations recited in claims 11-12, 16, and 18. Note that, Tian also discloses a system 100 with processor(s) 102 and memory 120 storing instructions 121 and data 122 to implement functions (see e.g. Tian, Fig. 1) corresponding to the functions implemented by the one or more processors disclosed in claims 1-2, 8, and 10.
With respect to claim 20, Tian as modified teaches: The system of claim 11, wherein to cause the one or more operations to launch the one or more first software modules and the one or more operations to launch the one or more second software modules to be concurrently performed includes performing operations to encode work submissions from different central processing cores to be performed by one or more graphics processing cores (see e.g. Tian, paragraph 88: “driver software for the graphics processor translates API calls that are specific to a particular graphics or media library into commands that can be processed by the graphics processor”; paragraph 105: “processor 1030 includes a graphics processor 1032 and one or more general-purpose processor core (s) 1034. The graphics application 1010 and operating system 1020 each execute in the system memory 1050 of the data processing system”; paragraph 108: “user mode graphics driver 1026 uses operating system kernel mode functions 1028 to communicate with a kernel mode graphics driver 1029. In some embodiments, kernel mode graphics driver 1029 communicates with graphics processor 1032 to dispatch commands and instructions”; and Fig. 10).
With respect to claims 21-23 and 26: Claims 21-23 and 26 are directed to a non-transitory machine-readable medium having stored thereon one or more instructions, which if performed by one or more processors, cause one or more processors to perform operations corresponding to the operations performed by the one or more processors recited in claims 1-3 and 6, respectively; please see the rejections directed to claims 1-3 and 6 above which also cover the limitations recited in claims 21-23 and 26. Note that, Tian also discloses a machine-readable medium including instructions to be executed by a processor in order to perform operations (see e.g. Tian, paragraph 110) corresponding to the operations performed by the one or more processors recited in claims 1-3 and 6.
With respect to claims 27: Claim 27 is directed to a method corresponding to the operations performed by the one or more processors recited in claim 1; please see the rejection directed to claim 1 above which also covers the limitations recited in claim 27.
With respect to claim 31, Tian as modified teaches: The method of claim 27, the method further comprising:
receiving, at the one or more software drivers (see e.g. Tian, paragraph 88: “driver software for the graphics processor translates API calls”), instructions from an application programming interface (API) (see e.g. Tian, paragraph 88: “API calls”; and paragraph 115: “3D APIs like OpenGL/DirectX”) to prepare one or more first graphics kernels and one or more second graphics kernels to be performed concurrently (see e.g. Tian, paragraph 61: “execution units in array 608A-608N execute an instruction set that includes native support for many standard 3D graphics shader instructions, such that shader programs from graphics libraries (e.g., Direct 3D and OpenGL) are executed”; paragraph 60: “each execution unit (e.g. 608A) is an individual vector processor capable of executing multiple simultaneous threads and processing multiple data elements in parallel for each thread”; and paragraph 88: “driver software for the graphics processor translates API calls that are specific to a particular graphics or media library into commands that can be processed by the graphics processor”).
With respect to claim 33, Tian as modified teaches: The method of claim 27, the method further comprising:
performing, with the one or more software drivers (see e.g. Tian, paragraph 88: “driver software for the graphics processor translates API calls that are specific to a particular graphics or media library into commands that can be processed by the graphics processor”), one or more operations to encode work submissions from one or more central processing cores to be performed by one or more graphics processing cores (see e.g. Tian, paragraph 88: “driver software for the graphics processor translates API calls that are specific to a particular graphics or media library into commands that can be processed by the graphics processor”; paragraph 108: “user mode graphics driver 1026 uses operating system kernel mode functions 1028 to communicate with a kernel mode graphics driver 1029. In some embodiments, kernel mode graphics driver 1029 communicates with graphics processor 1032 to dispatch commands and instructions”; and Fig. 10).
Claims 4, 5, 9, 13-15, 17, 19, 24, 25, 28-30, and 32 are rejected under 35 U.S.C. 103 as being unpatentable over Tian in view of Asthana and Kini as applied to claims 1, 11, 21, and 27 above, and further in view of Gummaraju et al. (US 2013/0160016 A1; from IDS filed on 10/07/2022; hereinafter Gummaraju).
With respect to claim 4, Tian as modified teaches: The one or more processors of claim 1, wherein the one or more first software modules and the one or more second software modules… that are to be performed by a single graphics processing unit (see e.g. Tian, paragraph 42: “graphics processor 300 includes… graphics processing engine (GPE) 310”; paragraph 59: “thread execution logic 600 including an array of processing elements employed in some embodiments of a GPE”; and Fig. 3, 6).
Tian does not but Gummaraju teaches:
include one or more first graphics kernels and one or more second graphics kernels respectively (see e.g. Gummaraju, paragraph 20: “allocating compute kernels to different types of processors”; and paragraph 22: “Kernels are sometimes also referred to by other terms such as shaders, shader programs, or programs. According to an embodiment, a compute kernel may have the same code base to be executed on different processor types, such as GPUs”)
Tian and Gummaraju are analogous art because they are in the same field of endeavor: managing software module executions within graphics processing units. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Tian with the teachings of Gummaraju. The motivation/suggestion would be to improve software module execution by refining resource allocations (see e.g. Gummaraju, paragraph 23).
With respect to claim 5, Tian as modified teaches: The one or more processors of claim 1, wherein the one or more first software modules and the one or more second software modules… that are to be performed by a plurality of graphics processing units (see e.g. Tian, paragraph 42: “graphics processor 300 includes… graphics processing engine (GPE) 310”; paragraph 59: “thread execution logic 600 including an array of processing elements employed in some embodiments of a GPE”; paragraph 121: “executed by multiple GPUs simultaneously”; and Fig. 3, 6).
Tian does not but Gummaraju teaches:
include one or more first graphics kernels and one or more second graphics kernels respectively (see e.g. Gummaraju, paragraph 20: “allocating compute kernels to different types of processors”; and paragraph 22: “Kernels are sometimes also referred to by other terms such as shaders, shader programs, or programs. According to an embodiment, a compute kernel may have the same code base to be executed on different processor types, such as GPUs”)
Tian and Gummaraju are analogous art because they are in the same field of endeavor: managing software module executions within graphics processing units. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Tian with the teachings of Gummaraju. The motivation/suggestion would be to improve software module execution by refining resource allocations (see e.g. Gummaraju, paragraph 23).
With respect to claim 9, Tian as modified teaches: The one or more processors of claim 1, wherein the circuitry is to perform the one or more software drivers (see e.g. Tian, paragraph 88: “driver software for the graphics processor translates API calls that are specific to a particular graphics or media library into commands that can be processed by the graphics processor”), wherein the one or more software drivers are to include a data tracking structure (see e.g. Tian, paragraph 117: “I/O registers, GPU page tables, etc.”) to synchronize one or more operations to launch the one or more first software modules and the one or more operations to launch the one or more second software modules that are to be performed in parallel and performed in sequence (see e.g. Tian, paragraph 65: “thread dispatcher 604 that arbitrates thread initiation requests from the graphics and media pipelines and instantiates the requested threads on one or more execution units 608A-608N”; paragraph 70: “in response to an add instruction the execution unit performs a simultaneous add operation across each color channel representing a texture element or picture element”; paragraph 93: “graphics processor command sequence 910 may begin with a pipeline flush command 912 to cause any active graphics pipeline to complete the currently pending commands for the pipeline… In response to a pipeline flush, the command parser for the graphics processor will pause command processing until the active drawing engines complete pending operations and the relevant read caches are invalidated. pipeline flush command 912 can be used for pipeline synchronization”; paragraph 117: “graphics commands are forwarded down to a hypervisor layer 1410 which includes a mediator 1412 that traps all privileged accesses from the driver 1403 (e.g., to I/O registers, GPU page tables, etc) , emulates the vGPU 1416, and replays the configuration”; and paragraph 118: “all the pGPUs1420-1421 have the same configuration (e.g., registers, GPU page table entries, etc) , so each of them is in a state expected by the graphics driver 1403 and thus any one of them can execute the GPU commands submitted from the graphics driver 1403”)
Tian does not but Gummaraju teaches:
to prepare one or more first graphics kernels and one or more second graphics kernels to be launched (see e.g. Gummaraju, paragraph 20: “allocating compute kernels to different types of processors”; and paragraph 22: “Kernels are sometimes also referred to by other terms such as shaders, shader programs, or programs. According to an embodiment, a compute kernel may have the same code base to be executed on different processor types, such as GPUs”).
Tian and Gummaraju are analogous art because they are in the same field of endeavor: managing software module executions within graphics processing units. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Tian with the teachings of Gummaraju. The motivation/suggestion would be to improve software module execution by refining resource allocations (see e.g. Gummaraju, paragraph 23).
With respect to claim 13, Tian as modified teaches: The system of claim 11, wherein the instructions, if performed by the one or more processors, further cause the system to perform the one or more software drivers (see e.g. Tian, paragraph 88: “driver software for the graphics processor translates API calls that are specific to a particular graphics or media library into commands that can be processed by the graphics processor”), wherein the one or more software drivers are to cause… to be performed concurrently (see e.g. Tian, paragraph 88: “driver software for the graphics processor translates API calls that are specific to a particular graphics or media library into commands that can be processed by the graphics processor”; paragraph 108: “graphics driver 1029 communicates with graphics processor 1032 to dispatch commands and instructions”; and paragraph 60: “each execution unit (e.g. 608A) is an individual vector processor capable of executing multiple simultaneous threads and processing multiple data elements in parallel for each thread”)
Tian does not but Gummaraju teaches:
one or more first graphics kernels and one or more second graphics kernels… by causing at least a first graphics kernel and a second graphics kernel to be performed (see e.g. Gummaraju, paragraph 20: “allocating compute kernels to different types of processors”; paragraph 22: “Kernels are sometimes also referred to by other terms such as shaders, shader programs, or programs. According to an embodiment, a compute kernel may have the same code base to be executed on different processor types, such as GPUs”; and paragraph 36: “execute multiple instances of a compute kernel in parallel. Each instance of an executing compute kernel may be referred to as a "workitem." In GPU 102, for example, workitems may simultaneously execute on each processing element 121, 122, 123, and 124”).
Tian and Gummaraju are analogous art because they are in the same field of endeavor: managing software module executions within graphics processing units. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Tian with the teachings of Gummaraju. The motivation/suggestion would be to improve software module execution by refining resource allocations (see e.g. Gummaraju, paragraph 23).
With respect to claims 14-15 and 17: Claims 14-15 and 17 are directed to a system implementing active functions corresponding to the active functions implemented by the processor recited in claims 4-5 and 9, respectively; please see the rejections directed to claims 4-5 and 9 above which also cover the limitations recited in claims 14-15 and 17.
With respect to claim 19, Tian as modified teaches: The system of claim 11, wherein the memory storing instructions, if performed by the one or more processors, further cause the system to perform the one or more software drivers (see e.g. Tian, paragraph 88: “driver software for the graphics processor translates API calls that are specific to a particular graphics or media library into commands that can be processed by the graphics processor”), wherein the one or more software drivers include a data tracking structure (see e.g. Tian, paragraph 117: “I/O registers, GPU page tables, etc.”) to track progress of the one or more operations to launch the one or more first software modules and the one or more operations to launch the one or more second software modules that are to be performed in parallel and to be performed in sequence (see e.g. Tian, paragraph 65: “thread dispatcher 604 that arbitrates thread initiation requests from the graphics and media pipelines and instantiates the requested threads on one or more execution units 608A-608N”; paragraph 93: “graphics processor command sequence 910 may begin with a pipeline flush command 912 to cause any active graphics pipeline to complete the currently pending commands for the pipeline… In response to a pipeline flush, the command parser for the graphics processor will pause command processing until the active drawing engines complete pending operations and the relevant read caches are invalidated... pipeline flush command 912 can be used for pipeline synchronization”; paragraph 117: “graphics commands are forwarded down to a hypervisor layer 1410 which includes a mediator 1412 that traps all privileged accesses from the driver 1403 (e.g., to I/O registers, GPU page tables, etc) , emulates the vGPU 1416, and replays the configuration”; and paragraph 118: “all the pGPUs1420-1421 have the same configuration (e.g., registers, GPU page table entries, etc) , so each of them is in a state expected by the graphics driver 1403 and thus any one of them can execute the GPU commands submitted from the graphics driver 1403”)
Tian does not but Gummaraju teaches:
to prepare one or more graphics kernels to launch (see e.g. Gummaraju, paragraph 20: “allocating compute kernels to different types of processors”; and paragraph 22: “Kernels are sometimes also referred to by other terms such as shaders, shader programs, or programs. According to an embodiment, a compute kernel may have the same code base to be executed on different processor types, such as GPUs”).
Tian and Gummaraju are analogous art because they are in the same field of endeavor: managing software module executions within graphics processing units. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Tian with the teachings of Gummaraju. The motivation/suggestion would be to improve software module execution by refining resource allocations (see e.g. Gummaraju, paragraph 23).
With respect to claims 24 and 25: Claims 24 and 25 are directed to a non-transitory machine-readable medium having stored thereon one or more instructions, which if performed by one or more processors, cause one or more processors to perform operations corresponding to the operations performed by the processor recited in claims 4 and 5, respectively; please see the rejections directed to claims 4 and 5 above which also cover the limitations recited in claims 24 and 25.
With respect to claim 28, Tian as modified teaches: The method of claim 27, wherein causing the one or more operations to launch the one or more first software modules and the one or more operations to launch the one or more second software modules to be concurrently performed further includes:
performing operations concurrently… on one or more graphics processing cores (see e.g. Tian, paragraph 58: “graphics processor 500 includes scalable thread execution resources featuring modular cores 580A-580N (sometimes referred to as core slices) , each having multiple sub-cores 550A-550N, 560A-560N (sometimes referred to as core sub-slices) (e.g., 550A)… Each sub-core in the set of first sub-cores 550A-550N includes at least a first set of execution units 552A-552N… Each sub-core in the set of second sub-cores 560A-560N includes at least a second set of execution units 562A-562N”; paragraph 60: “each execution unit (e.g. 608A) is an individual vector processor capable of executing multiple simultaneous threads and processing multiple data elements in parallel for each thread”; and Fig. 5).
Tian does not but Gummaraju teaches:
to prepare one or more first graphics kernels and one or more second graphics kernels to be launched (see e.g. Gummaraju, paragraph 20: “allocating compute kernels to different types of processors”; and paragraph 22: “Kernels are sometimes also referred to by other terms such as shaders, shader programs, or programs. According to an embodiment, a compute kernel may have the same code base to be executed on different processor types, such as GPUs”).
Tian and Gummaraju are analogous art because they are in the same field of endeavor: managing software module executions within graphics processing units. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Tian with the teachings of Gummaraju. The motivation/suggestion would be to improve software module execution by refining resource allocations (see e.g. Gummaraju, paragraph 23).
With respect to claim 29, Tian as modified teaches: The method of claim 27, the method further comprises:
obtaining one or more operations to run in parallel and one or more operations to run in sequence… on one or more graphics processing cores (see e.g. Tian, paragraph 93: “graphics processor command sequence 910 may begin with a pipeline flush command 912 to cause any active graphics pipeline to complete the currently pending commands for the pipeline… In response to a pipeline flush, the command parser for the graphics processor will pause command processing until the active drawing engines complete pending operations and the relevant read caches are invalidated... pipeline flush command 912 can be used for pipeline synchronization”; paragraph 117: “graphics commands are forwarded down to a hypervisor layer 1410 which includes a mediator 1412 that traps all privileged accesses from the driver 1403 (e.g., to I/O registers, GPU page tables, etc) , emulates the vGPU 1416, and replays the configuration”; and paragraph 118: “all the pGPUs1420-1421 have the same configuration (e.g., registers, GPU page table entries, etc) , so each of them is in a state expected by the graphics driver 1403 and thus any one of them can execute the GPU commands submitted from the graphics driver 1403”).
Tian does not but Gummaraju teaches:
to launch one or more first graphics kernels and one or more second graphics kernels (see e.g. Gummaraju, paragraph 20: “allocating compute kernels to different types of processors”; and paragraph 22: “Kernels are sometimes also referred to by other terms such as shaders, shader programs, or programs. According to an embodiment, a compute kernel may have the same code base to be executed on different processor types, such as GPUs”).
Tian and Gummaraju are analogous art because they are in the same field of endeavor: managing software module executions within graphics processing units. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Tian with the teachings of Gummaraju. The motivation/suggestion would be to improve software module execution by refining resource allocations (see e.g. Gummaraju, paragraph 23).
With respect to claim 30, Tian as modified teaches: The method of claim 27, the method further comprises:
receiving from one or more central processing cores requests… on one or more graphics processing cores (see e.g. Tian, paragraph 88: “driver software for the graphics processor translates API calls that are specific to a particular graphics or media library into commands that can be processed by the graphics processor”; paragraph 105: “processor 1030 includes a graphics processor 1032 and one or more general-purpose processor core (s) 1034. The graphics application 1010 and operating system 1020 each execute in the system memory 1050 of the data processing system”; paragraph 108: “user mode graphics driver 1026 uses operating system kernel mode functions 1028 to communicate with a kernel mode graphics driver 1029. In some embodiments, kernel mode graphics driver 1029 communicates with graphics processor 1032 to dispatch commands and instructions”; and Fig. 10).
Tian does not but Gummaraju teaches:
to prepare one or more first graphics kernels and one or more second graphics kernels to be launched (see e.g. Gummaraju, paragraph 20: “allocating compute kernels to different types of processors”; and paragraph 22: “Kernels are sometimes also referred to by other terms such as shaders, shader programs, or programs. According to an embodiment, a compute kernel may have the same code base to be executed on different processor types, such as GPUs”)
Tian and Gummaraju are analogous art because they are in the same field of endeavor: managing software module executions within graphics processing units. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Tian with the teachings of Gummaraju. The motivation/suggestion would be to improve software module execution by refining resource allocations (see e.g. Gummaraju, paragraph 23).
With respect to claim 32, Tian as modified teaches: The method of claim 27, the method further comprising:
obtaining a status… based, at least in part, on a data tracking structure (see e.g. Tian, paragraph 117: “I/O registers, GPU page tables, etc.”) of the one or more software drivers that track progress of operations that run in parallel and operations that run in sequence (see e.g. Tian, paragraph 93: “graphics processor command sequence 910 may begin with a pipeline flush command 912 to cause any active graphics pipeline to complete the currently pending commands for the pipeline… In response to a pipeline flush, the command parser for the graphics processor will pause command processing until the active drawing engines complete pending operations and the relevant read caches are invalidated... pipeline flush command 912 can be used for pipeline synchronization”; paragraph 117: “graphics commands are forwarded down to a hypervisor layer 1410 which includes a mediator 1412 that traps all privileged accesses from the driver 1403 (e.g., to I/O registers, GPU page tables, etc) , emulates the vGPU 1416, and replays the configuration”; and paragraph 118: “all the pGPUs1420-1421 have the same configuration (e.g., registers, GPU page table entries, etc) , so each of them is in a state expected by the graphics driver 1403 and thus any one of them can execute the GPU commands submitted from the graphics driver 1403”)
Tian does not but Gummaraju teaches:
of preparing one or more graphics kernels to be launched (see e.g. Gummaraju, paragraph 20: “allocating compute kernels to different types of processors”; and paragraph 22: “Kernels are sometimes also referred to by other terms such as shaders, shader programs, or programs. According to an embodiment, a compute kernel may have the same code base to be executed on different processor types, such as GPUs”)… to prepare the one or more graphics kernels (see e.g. Gummaraju, paragraph 20: “allocating compute kernels to different types of processors”; and paragraph 22: “Kernels are sometimes also referred to by other terms such as shaders, shader programs, or programs. According to an embodiment, a compute kernel may have the same code base to be executed on different processor types, such as GPUs”).
Tian and Gummaraju are analogous art because they are in the same field of endeavor: managing software module executions within graphics processing units. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Tian with the teachings of Gummaraju. The motivation/suggestion would be to improve software module execution by refining resource allocations (see e.g. Gummaraju, paragraph 23).
Response to Arguments
Applicant's arguments filed 07/29/2026 have been fully considered but they are not persuasive. In detail:
(i) Regarding Applicant’s arguments with respect to the limitation “identifies… whether one or more operations to launch one or more first software modules and one or more operations to launch the one or more second software modules can be concurrently performed based on whether the one or more operations to launch the one or more first software modules are independent of the one or more operations to launch the one or more second software modules” recited in claims 1 (Remarks, pages 14-15), note that Asthana discloses an opportunistic launch mechanism to launch work items (e.g. geometry stage work items) at the same time (i.e. concurrently).
More specifically, Asthana discloses opportunistically launching a geometry stage 2 (6042) (i.e. executing an operation to launch the geometry stage 2 (6042)) at the same time with launching a geometry stage 0 (6040) (i.e. executing an operation to launch the geometry stage 0 (6040)) ((see e.g. Asthana, column 16, lines 27-31: “firmware 520 may attempt to opportunistically launch the work in geometry stage 2 (6042). In such embodiments, the geometry stage 2 (6042) may be launched at the same time (or even prior to) geometry stage 0 (6040)”).
Note that, the opportunistic launch mechanism is based on identifying no true dependencies between geometry stage operations exist (see e.g. Asthana, column 6, lines 19-26: “the geometry stage operations of the given command are waiting on no such true dependency, then the system may simply attempt to opportunistically launch one or more of the geometry stage operations at a determined time, e.g., at the earliest time that it has been determined that no “true” barriers remain for that portion of the command (i.e., the geometry stage operations, in this example)”). That is, launching and executing such geometry stage operations are independent of each other.
Therefore, Asthana teaches the limitations “identifies… whether one or more operations to launch one or more first software modules and one or more operations to launch the one or more second software modules can be concurrently performed based on whether the one or more operations to launch the one or more first software modules are independent of the one or more operations to launch the one or more second software modules” as recited in claim 1. For more details, please see the corresponding rejection above.
(ii) Applicant’s arguments with respect to claims 2-33 are fully considered; however, in view of the above discussion (i), they are not found to be persuasive. Consequently, the Examiner maintains the rejections directed to claims 2-33. For details, please see the corresponding rejections above.
Applicant’s arguments with respect to the limitation “using one or more software drivers” recited in claims 1, 11, 21, and 27 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
CONCLUSION
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Jia et al. (US 2018/0075605 A1) discloses concurrent execution of independent kernels, regardless of the launch order (see paragraph 90).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Umut Onat whose telephone number is (571)270-1735. The examiner can normally be reached M-Th 9:00-7:30.
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, Kevin L Young can be reached on (571) 270-3180. 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.
/UMUT ONAT/Primary Examiner, Art Unit 2194
Prosecution Insights