Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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.
Claim(s) 1-4 and 14-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Paltashev et al. (U.S. PGPUB 20180114290) in view of Moreton et al. (U.S. Patent No. 6,900,810) and further in view of Cheng (U.S. PGPUB 20170178273).
With respect to claim 1, Paltashev et al. disclose a method, comprising:
placing, by a processing unit of a command processor of an accelerated processing device (APD), a plurality of graphics commands into a queue (paragraph 57, The CPU cores 401-404 provide the commands and data to queues 405, 406, 407, 408, 409, 410 (collectively referred to herein as “the queues 405-410”) that are part of a set 415);
monitoring, by a fixed-function hardware circuit, a graphics command stream output by the queue (paragraph 59, A command processor 440 fetches metacommands from the queues 405-410, paragraph 60, The command processor 500 is implemented using fixed function hardware blocks and RISC micro-engine cores). However, Paltashev et al. do not expressly disclose performing, by the fixed-function hardware circuit and responsive to the fixed-function hardware circuit detecting a specified graphics command in the monitored graphics command stream, at least one graphics command management operation including one or more of a graphics context management operation or a graphics persistent state management operation.
Moreton et al., who also deal with graphics processing, disclose a method for performing, by the fixed-function hardware circuit and responsive to the fixed-function hardware circuit detecting a specified graphics command in the monitored graphics command stream (column 14, lines 24-26, In step 508, the fixed function engine identifies the first primitive command in the set of related primitive commands to be processed), at least one graphics command management operation (column 14, lines 26-30, In step 510, the fixed function engine generates a program command corresponding to the first primitive command and transmits that program command to vertex engine 416 for processing).
Paltashev et al. and Moreton et al. are in the same field of endeavor, namely computer graphics.
Before the effective filing date of the claimed invention, it would have been obvious to apply the method of performing, by the fixed-function hardware circuit and responsive to the fixed-function hardware circuit detecting a specified graphics command in the monitored graphics command stream, at least one graphics command management operation, as taught by Moreton et al., to the Paltashev et al. system, because this enables programmable geometry engine 400 to be configured to implement specific user-programmed functions. This functionality provides users with the ability to influence a variety of computational parameters and metrics that determine how a graphics processor (e.g., graphics processor 302) actually generates primitives in the graphics pipeline (e.g. graphics pipeline 200) (column 18, lines 11-14 of Moreton et al.).
Cheng, who also deals with graphics processing, disclose a method wherein at least one graphics command management operation includes one or more of a graphics context management operation or a graphics persistent state management operation (paragraph 15, As used herein a graphics context refers to a set of instructions and associated state information corresponding to an object to be displayed, paragraph 26, In response to identifying that a command to request to modify data targets an unavailable frame buffer, and will therefore cause the corresponding graphics context to be stalled, the scheduler 105 selects a different graphics context for execution at the graphics pipeline 110).
Paltashev et al., Moreton et al., and Cheng are in the same field of endeavor, namely computer graphics.
Before the effective filing date of the claimed invention, it would have been obvious to apply the method wherein at least one graphics command management operation includes one or more of a graphics context management operation or a graphics persistent state management operation, as taught by Cheng, to the Paltashev et al. as modified by Moreton et al. system, because by scheduling execution of graphics contexts based on the availability of the frame buffers 119, the scheduler 105 enhances processor performance by ensuring that a stall for one graphics context does not cause a stall in all pending graphics contexts (paragraph 27 of Cheng).
With respect to claim 2, Paltashev et al. as modified by Moreton et al. and Cheng disclose the method of claim 1, wherein the plurality of graphics commands include one or more of a graphics context state update command, a graphics persistent state update command, or a draw command (Paltashev et al.: paragraph 36, The command buffers store rendering commands (e.g., Draw with geometry commands) or compute commands (e.g., shader code) that are targeted to one or more of the shader engines in the graphics pipeline 201), and wherein placing the plurality of graphics commands into the queue comprises placing the plurality of graphics commands into the queue independent of whether a graphics context is available for the plurality of graphics commands (Paltashev et al.: paragraph 36, Command buffers are generated by driver software and added to the queue 202. When the graphics pipeline 201 is ready to process another command, and input assembler (IA) 204 pulls command buffers from the queue 202, thus independent of context since command buffers are added to the queue).
With respect to claim 3, Paltashev et al. as modified by Moreton et al. and Cheng disclose the method of claim 1, wherein the fixed-function hardware circuit is disposed between the queue and a graphics pipeline of the APD (Paltashev et al.: paragraph 59, A command processor 440 fetches metacommands from the queues 405-410 and routes the metacommands to the appropriate shared hardware resources, paragraph 60, The command processor 500 is implemented using fixed function hardware blocks and RISC micro-engine cores, paragraph 64, The graphics processing system 600 includes a command processor 605 (such as the command processor 500 shown in FIG. 5) that is configured to route, queue, or map commands associated with different threads to corresponding asynchronous compute engines 610, 611, 612, paragraph 64, The graphics processing system 600 includes a first virtual graphics pipeline 615 that is supported by the asynchronous compute engine 610 and a second virtual graphics pipeline 630 that is supported by the asynchronous compute engine 612). The command processor (implemented using fixed function hardware) is disposed between the queue (Set 415 in Fig. 4) and graphics pipeline (first virtual graphics pipeline 615 in Fig. 6).
With respect to claim 4, Paltashev et al. as modified by Moreton et al. and Cheng disclose the method of claim 1, wherein detecting the specified graphics command in the monitored graphics command stream comprises: responsive to detecting a graphics command in the graphics command stream, comparing a register address included in the graphics command to a plurality of register apertures, wherein each register aperture of the plurality of register apertures is associated with a different graphics command type (Moreton et al.: column 5, lines 10-13, Primitive commands may include any information related to primitive processing such as pointers to user-developed primitive programs or subroutines stored in graphics memory 308, Moreton et al.: column 7, lines 41-45, the program command may include, without limitation, a pointer to the user-developed program or subroutine that vertex engine 416 is to execute (also referred to as a "program pointer")) and
responsive to the register address matching a register address in one register aperture of the plurality of register apertures, determining that the graphics command is a specified graphics command (Moreton et al.: column 15, lines 24-28, In step 602, floating point processor 420 retrieves the user-developed program or subroutine stored in graphics memory 308 at the memory location designated by the program pointer contained in the program command). It would have been obvious for applying the method wherein detecting the specified graphics command in the monitored graphics command stream comprises: responsive to detecting a graphics command in the graphics command stream, comparing a register address included in the graphics command to a plurality of register apertures, wherein each register aperture of the plurality of register apertures is associated with a different graphics command type; and responsive to the register address matching a register address in one register aperture of the plurality of register apertures, determining that the graphics command is a specified graphics command, because this would quickly retrieve instructions or data via pointers, or memory addresses, which is well-known in the art.
With respect to claim 14, Paltashev et al. as modified by Moreton et al. and Cheng disclose a processor (Paltashev et al.: paragraph 57, The graphics processing system 400 includes multiple CPU-type processor cores 401, 402, 403, 404) comprising: a plurality of state registers configured to maintain context states for a plurality of graphics contexts (Paltashev et al.: paragraph 52, the control element 340 can then allocate a set of registers to store a context queue status for each active application which can be monitored by dedicated hardware); and a command processor (Paltashev et al.: paragraph 59, A command processor 440 fetches metacommands from the queues 405-410 and routes the metacommands to the appropriate shared hardware resources), wherein the command processor comprises: a processing unit configured to execute the method of claim 1; see rationale for rejection of claim 1.
With respect to claim 15, Paltashev et al. as modified by Moreton et al. and Cheng disclose the processor of claim 14 for executing the method of claim 2; see rationale for rejection of claim 2.
With respect to claim 16, Paltashev et al. as modified by Moreton et al. and Cheng disclose the processor of claim 14 for executing the method of claim 4; see rationale for rejection of claim 4.
Claim(s) 5 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Paltashev et al. (U.S. PGPUB 20180114290) in view of Moreton et al. (U.S. Patent No. 6,900,810), Cheng (U.S. PGPUB 20170178273), and further in view of Jin et al. (U.S. PGPUB 20150294436).
With respect to claim 5, Paltashev et al. as modified by Moreton et al. and Cheng disclose the method of claim 1. However, Paltashev et al. as modified by Moreton et al. and Cheng do not expressly disclose wherein performing the at least one graphics command management operation comprises: responsive to determining that the specified graphics command is a graphics context state update command and a current graphics context is unallocated, performing a context allocation operation comprising: requesting a new graphics context from a context management circuit; updating the new graphics context based on the graphics context state update command; and setting the updated new graphics context as the current graphics context.
Jin et al., who also deal with graphics processing, disclose a method wherein performing the at least one graphics command management operation comprises: responsive to determining that the specified graphics command is a graphics context state update command and a current graphics context is unallocated, performing a context allocation operation comprising: requesting a new graphics context from a context management circuit (paragraph 78, In operation 501, the case where a graphics command received by a command processor is interpreted as a command to create a new state is one in which a graphics state change command is received for the first time after a system operation or after a draw call. In order to create a new graphics state according to this command, the state version manager allocates an entry for a new graphics state to be created in a state table in operation 503. Then, the state version manager requests the memory page manager to allocate pages for a graphics state to be created in a memory pool, and the memory page manager allocates requested pages in operation 505).
updating the new graphics context based on the graphics context state update command (paragraph 82, Referring to FIG. 6, changing a graphics state 600 starts with a graphics state change command transmitted to a command processor of a graphics processing apparatus from an application or a driver that is executed in a host. Changing of a graphics state is not related to creating a new graphics state, but to updating one or more items of the existing graphics states); and
setting the updated new graphics context as the current graphics context (paragraph 87, Subsequently in operation 609, values of the items are changed in pages created in operation 607, such that a state change command received in operation 601 may be performed).
Paltashev et al., Moreton et al., Cheng, and Jin et al. are in the same field of endeavor, namely computer graphics.
Before the effective filing date of the claimed invention, it would have been obvious to apply the method wherein performing the at least one graphics command management operation comprises: responsive to determining that the specified graphics command is a graphics context state update command and a current graphics context is unallocated, performing a context allocation operation comprising: requesting a new graphics context from a context management circuit; updating the new graphics context based on the graphics context state update command; and setting the updated new graphics context as the current graphics context, as taught by Jin et al., to the Paltashev et al. as modified by Moreton et al. and Cheng system, because initiate the memory with proper data values for tracking graphic states.
With respect to claim 17, Paltashev et al. as modified by Moreton et al., Cheng, and Jin et al. disclose the processor of claim 14, wherein the fixed-function hardware circuit is configured to execute the method of claim 5; see rationale for rejection of claim 5.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Paltashev et al. (U.S. PGPUB 20180114290) in view of Moreton et al. (U.S. Patent No. 6,900,810), Cheng (U.S. PGPUB 20170178273), and further in view of Sigatapu (U.S. PGPUB 20200211149).
With respect to claim 6, Paltashev et al. as modified by Moreton et al. and Cheng disclose the method of claim 5. However, Paltashev et al. as modified by Moreton et al. and Cheng do not expressly disclose performing the context allocation operation further comprises: obtaining a lock at the context management circuit prior to requesting the new graphics context; and releasing the lock after the updated new graphics context is set as the current graphics context.
Sigatapu, who also deals with graphics processing, discloses a method wherein performing the context allocation operation further comprises: obtaining a lock at the context management circuit prior to requesting the new graphics context; and releasing the lock after the updated new graphics context is set as the current graphics context (paragraph 44, If the backlog contains GL instructions, the method proceeds to 506 where the script interpreter allocates a new queue (or batch) called the copy queue, paragraph 45, The context backlog is locked at 508 and the copy queue is swapped with the backlog at 510. At 512, the main thread unlocks the context backlog and executes the GL commands in the copy queue at 514).
Paltashev et al., Moreton et al., Cheng, and Sigatapu are in the same field of endeavor, namely computer graphics.
Before the effective filing date of the claimed invention, it would have been obvious to apply the method wherein performing the context allocation operation further comprises: obtaining a lock at the context management circuit prior to requesting the new graphics context; and releasing the lock after the updated new graphics context is set as the current graphics context, as taught by Sigatapu, to the Paltashev et al. as modified by Moreton et al. and Cheng system, because this would allow software with hardware accelerated graphics to provide the responsiveness that a native library offers for its native interfaces, while allowing the Script application code to be written independently of such systems scheduling concerns (paragraph 47 of Sigatapu).
Claim(s) 7-8 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Paltashev et al. (U.S. PGPUB 20180114290) in view of Moreton et al. (U.S. Patent No. 6,900,810), Cheng (U.S. PGPUB 20170178273), McCrary et al. (U.S. PGPUB 20200379767), and further in view of Dunn et al. (U.S. PGPUB 20180089793).
With respect to claim 7, Paltashev et al. as modified by Moreton et al. and Cheng disclose the method of claim 1. However, Paltashev et al. as modified by Moreton et al. and Cheng do not expressly disclose performing the at least one graphics command management operation comprises: responsive to determining that the specified graphics command is a graphics context state update command and a current graphics context is allocated to a draw operation, performing a context roll operation comprising: inserting a marker into the graphics command stream indicating to components of a graphics pipeline of the APD that a state of the current graphics context is to be updated.
McCrary et al., who also deal with graphics processing, disclose a method wherein performing the at least one graphics command management operation comprises: responsive to determining that the specified graphics command is a graphics context state update command and a current graphics context is allocated to a draw operation, performing a context roll operation (paragraph 22, Accordingly, sequential processes may be run on one state set but if the driver changes context state after performing a draw operation, the CP must execute a sequence of register writes followed by a read to ensure completion once the GPU changes to a different state set. This context rolling process for a new context includes the command processor 122 sending an event down the graphics pipeline to release the current context).
Paltashev et al., Moreton et al., Cheng, and McCrary et al. are in the same field of endeavor, namely computer graphics.
Before the effective filing date of the claimed invention, it would have been obvious to apply the method wherein performing the at least one graphics command management operation comprises: responsive to determining that the specified graphics command is a graphics context state update command and a current graphics context is allocated to a draw operation, performing a context roll operation, as taught by McCrary et al., to the Paltashev et al. as modified by Moreton et al. and Cheng system, because by determining that a desired hash identifier is available for use, switching to the context for that hash identifier, and discarding any command packets that would have redefined that context, the GPU 104 improves operating efficiency by realizing that the requested hash identifier is currently available at GPU hardware and switching to it rather than forcing the processor to stall from lack of available contexts (paragraph 40 of McCrary et al.).
Dunn et al., who also deal with graphics processing, disclose a method comprising: inserting a marker into the graphics command stream indicating to components of a graphics pipeline of the APD that a state of the current graphics context is to be updated (paragraph 33, Embodiments according to the invention add marker commands (which may also be referred to herein as markers) to a stream of commands that are executed by the GPU 112, paragraph 34, the marker commands are implemented as “semaphores” that release a respective payload to a specified location in the memory 110. The payload is the information (“marker information”) that uniquely identifies the associated draw or compute command. In another embodiment, the marker commands set flags that are carried through the pipeline in the GPU 112 with their respective draw or compute command).
Paltashev et al., Moreton et al., Cheng, McCrary et al., and Dunn et al. are in the same field of endeavor, namely computer graphics.
Before the effective filing date of the claimed invention, it would have been obvious to apply the method comprising: inserting a marker into the graphics command stream indicating to components of a graphics pipeline of the APD that a state of the current graphics context is to be updated, as taught by Dunn et al., to the Paltashev et al. as modified by Moreton et al., Cheng, and McCrary et al. system, because The marker information can be used to narrow the search for the root cause of an invalid GPU state. The marker information can also be accumulated over time and across different GPUs to detect trends and classify the source(s) of invalid states, so that efforts can be prioritized to focus on the parts of applications that are causing the most occurrences of invalid states (paragraph 75 of Dunn et al.).
With respect to claim 8, Paltashev et al. as modified by Moreton et al., Cheng, McCrary et al., and Dunn et al. disclose the method of claim 7, wherein performing the context roll operation further comprises: requesting a new graphics context from a context management circuit; copying a state of the current graphics context to the new graphics context; and updating a state of the current graphics context based on the graphics context state update command (McCrary et al.: paragraph 10, the GPU will often change context state in order to start working on a new set of context registers because the graphics pipeline state needs to be changed to draw something else. The GPU performs a context roll to a newly supplied context to release the current context by copying the current registers into a newly allocated context before applying any new state updates by programming fresh register values); see rationale for rejection of claim 7 for applying McCrary et al.
With respect to claim 18, Paltashev et al. as modified by Moreton et al., Cheng, McCrary et al., and Dunn et al. disclose the processor of claim 14, wherein the fixed-function hardware circuit is configured to perform the method of claims 7-8; see rationale for rejection of claims 7-8.
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Paltashev et al. (U.S. PGPUB 20180114290) in view of Moreton et al. (U.S. Patent No. 6,900,810), Cheng (U.S. PGPUB 20170178273), and further in view of Dunn et al. (U.S. PGPUB 20180089793).
With respect to claim 10, Paltashev et al. as modified by Moreton et al., Cheng, and Dunn et al. disclose the method of claim 1, wherein performing the at least one graphics command management operation comprises: responsive to determining that the specified graphics command is a graphics persistent state update command and a current graphics context is allocated to a draw operation: inserting a marker into the graphics command stream indicating to components of a graphics pipeline of the APD that a graphics persistent state is to be updated (Dunn et al.: paragraph 33, Embodiments according to the invention add marker commands (which may also be referred to herein as markers) to a stream of commands that are executed by the GPU 112, paragraph 34, the marker commands are implemented as “semaphores” that release a respective payload to a specified location in the memory 110. The payload is the information (“marker information”) that uniquely identifies the associated draw or compute command. In another embodiment, the marker commands set flags that are carried through the pipeline in the GPU 112 with their respective draw or compute command); see rationale for rejection of claim 7 regarding inserting a marker.
Claim(s) 13 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Paltashev et al. (U.S. PGPUB 20180114290) in view of Moreton et al. (U.S. Patent No. 6,900,810), Cheng (U.S. PGPUB 20170178273), and further in view of Merry (U.S. PGPUB 20120299943).
With respect to claim 13, Paltashev et al. as modified by Moreton et al. and Cheng disclose the method of claim 1. However, Paltashev et al. as modified by Moreton et al. and Cheng do not expressly disclose: inserting, by the processing unit, an indicator into a field of at least one graphics command of the plurality of graphics commands, the indicator configured to force the fixed-function hardware circuit to perform one or more of a graphics context management operation or a graphics persistent state management operation.
Merry, who also deals with graphics processing, discloses a method for inserting, by the processing unit, an indicator into a field of at least one graphics command of the plurality of graphics commands, the indicator configured to force the fixed-function hardware circuit to perform one or more of a graphics context management operation or a graphics persistent state management operation (paragraph 51, responsive to that end instruction and to the software processing flag indicating that a blending software routine should be used, to trigger execution of the blending software routine). The software processing flag is an indicator that forces a graphics context management operation or a graphics persistent state management operation by running said software routine.
Paltashev et al., Moreton et al., Cheng, and Merry are in the same field of endeavor, namely computer graphics.
Before the effective filing date of the claimed invention, it would have been obvious to apply the method of inserting, by the processing unit, an indicator into a field of at least one graphics command of the plurality of graphics commands, the indicator configured to force the fixed-function hardware circuit to perform one or more of a graphics context management operation or a graphics persistent state management operation, as taught by Merry, to the Paltashev et al. as modified by Moreton et al. and Cheng system, because this will avoid the overhead and complication of having to switch processors as well as ensuring that data generated by the fragment shading software routine is available for use by the blending (blend shading) software routine (paragraph 35 of Merry).
With respect to claim 19, Paltashev et al. as modified by Moreton et al., Cheng, and Merry disclose the processor of claim 14, wherein the processing unit is further configured to execute the method of claim 13; see rationale for rejection of claim 13.
Allowable Subject Matter
Claims 9 and 11-12 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter: none of the cited art teaches or suggests a flag indicating the graphics context is not updatable, i.e., determining that the current graphics context is allocated to the draw operation is in response to determining that a flag is set to a first state indicating that the state of the current graphics context is not updatable, and wherein performing the context roll operation further comprises setting the flag to a second state in response to copying the state of the current graphics context to the new graphics context, wherein the second state indicates that the state of the current graphics context is updatable.
Claim 20 is allowed.
The following is a statement of reasons for the indication of allowable subject matter: none of the cited art teaches or suggests checking the state of a flag for performing context rolling, i.e.,
responsive to the detected context state update command, check a state of a flag associated with a graphics context state; and responsive to the state of the flag, selectively performing a context roll process to switch from a current graphics context to a new graphics context having a context state based on the context state update command.
Mantor et al., the closest art of record, disclose checking the state of a flag; however, this indicates context rolling has already been performed.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1 and 14 have been considered but are moot because the new ground(s) of rejection.
Applicant's arguments filed January 14, 2026 have been fully considered but they are not persuasive. Applicant argues that Paltashev does not disclose detecting a specified command in the monitored graphics command stream in that the cited paragraphs do not show hardware-based analysis of command type or semantics (bottom of page 9 of remarks). In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). In this case, the newly cited reference Moreton (U.S. Patent No. 6,900,810 teaches detecting a specified command in the monitored graphics command stream. It is the combination of Paltashev and Moreton that teaches this limitation as a whole.
Applicant argues that “monitoring” in Paltashev does not equate to hardware-based detecting (top of page 10). However, as explained above, Paltashev is cited to teach the “monitoring” step of claim 1, which does explicitly recite hardware-based detecting. Moreton is cited to teach the “detecting” of claim 1.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
U.S. PGPUB 20200234484 to Ellis for performing an operation with fixed-function hardware
U.S. PGPUB 20180181519 to Cheng for use of a register aperture.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDREW GUS YANG whose telephone number is (571)272-5514. The examiner can normally be reached M-F 9 AM - 5:30 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kent Chang can be reached at (571)272-7667. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ANDREW G YANG/Primary Examiner, Art Unit 2614
3/5/26