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 Objections
Claims 4, 19 and 27 are objected to because of the following informalities:
the term “hetergenous” should be changed to read “heterogeneous”.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-32 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Avkarogullari et al. (US 20150348224 A1).
Regarding claim 1, Avkarogullari et al. discloses a method, comprising:
at a device:
processing code defining a program to be executed using a pipeline having one or more stages (computer readable medium having instructions stored thereon to support immutable pipeline state objects containing code for a graphics processing unit (GPU). When executed, the instructions can cause one or more processors to create an immutable pipeline state object that contains compiled information about one or more graphics operations to display a graphical object, para. 0009), wherein the processing generates from the code metadata indicating: one or more processing contexts, an assignment of each processing context of the one or more processing contexts (one or more graphics operations can include one or more shaders of a type selected from the group consisting of a vertex shader, fragment shader, and a vertex fetch configuration. The one or more graphics operations can include at least one item selected from the group consisting of blend state, rasterization enablement, and multisample masking, para. 0009) to a corresponding stage of the one or more stages in the pipeline, and resources to be used for each stage of the one or more stages (in FIG. 5A. A pipeline state object can be associated, for example, with an object to be drawn. The illustrated pipeline state object 542 includes five components, a vertex fetch 501, a vertex shader 502, a rasterization 503, a fragment shader 504, and a frame buffer 506. Historically, each of these objects would have been controlled by a separate API. However, in any given instantiation associated with a real-world implementation, there is a predefined data flow among these objects.); and
outputting the metadata to hardware for use in executing the program using the pipeline in accordance with the metadata (the GPU 150, see figure 1, executes the native binary code, performing the graphics and compute kernels for data parallel operations, para. 0025).
Regarding claim 2, Avkarogullari et al. discloses the method of claim 1, wherein the code is an intermediate code generated by processing a source code for the program, wherein the intermediate code expresses the pipeline (submit source code in the unified programming interface 110, which can be a GPU-specific programming language. Once the code is written, it may be directed to a compiler 115, which parses the source code and generates a native binary code, paras. 0023, 0025).
Regarding claim 3, Avkarogullari et al. discloses the method of claim 2, wherein the intermediate code is generated by a compiler (compiler 115, para. 0023).
Regarding claim 4, Avkarogullari et al. discloses the method of claim 1, wherein the one or more stages of the pipeline are hetergenous (vertex fetch 501, a vertex shader 502, a rasterization 503, a fragment shader 504, and a frame buffer 506, para. 0052 and see figure 5A).
Regarding claim 5, Avkarogullari et al. discloses the method of claim 1, wherein each individual processing context of the one or more processing contexts includes a plurality of threads (fragment shaders 130, and vertex shaders 135, para. 0025).
Regarding claim 6, Avkarogullari et al. discloses the method of claim 1, wherein the resources for each stage of the one or more stages includes resources required by the corresponding processing context (pipeline state descriptor object 540 itself may be constructed using one or objects that include function object 524, blend state 526, and pixel format 528, para. 0047).
Regarding claim 7, Avkarogullari et al. discloses the method of claim 6, wherein the resources include static resources (vertex fetch 501, a vertex shader 502, a rasterization 503, a fragment shader 504, and a frame buffer 506, para. 0052 and see figure 5A are examples of static resources as they each execute a fixed function.).
Regarding claim 8, Avkarogullari et al. discloses the method of claim 7, wherein the static resources include at least one of storage or functional units (vertex fetch 501, a vertex shader 502, a rasterization 503, a fragment shader 504, and a frame buffer 506, para. 0052 and see figure 5A are examples of static resources and they are each a functional unit.).
Regarding claim 9, Avkarogullari et al. discloses the method of claim 8, wherein the resources include dynamic resources extrapolated from the static resources (the set of one or more associated state options for the immutable state object can include data attributes that can be changed without causing a corresponding change to the executable instructions for the GPU and the associated immutable state object, para. 0012. Examples of such attributes include input textures or input vertex data, viewport size, and/or occlusion query data, para. 0010.).
Regarding claim 10, Avkarogullari et al. discloses the method of claim 9, wherein the dynamic resources are determined based on all processing contexts corresponding to the stage (pipeline state descriptor object 540 itself may be constructed using one or objects that include function object 524, blend state 526, and pixel format 528, para. 0047).
Regarding claim 11, Avkarogullari et al. discloses the method of claim 1, wherein the processing is performed over a plurality of steps (parse the source code and generate a machine-independent programming language-independent representation. The result may then be distributed from the developer computer system 100 to application 120. Application 120 can contain the shader code in a device-independent form (in addition to everything else the application contains: CPU code, text, other resources, etc.), para. 0023).
Regarding claim 12, Avkarogullari et al. discloses the method of claim 11, wherein the plurality of steps include a first step in which the code is processed to generate a static program and the metadata with static resources allocated to each stage of the one or more stages of the pipeline (one or more graphics operations can include one or more shaders, such as a vertex shader, fragment shader, or a vertex fetch configuration. The one or more graphics operations can include at least one item such as blend state, rasterization enablement, and multisample masking, para. 0012).
Regarding claim 13, Avkarogullari et al. discloses the method of claim 12, wherein the first step is performed by a compiler (the immutable pipeline state object can contain compiled information about one or more graphics operations to display a graphical object and can be adapted to be compiled at a time other than the time at which the graphical object is rendered so as to encapsulate executable instructions for a GPU and externalize mutable attributes requiring re-compilation when changed, para. 0012. Executed by compiler 145, para. 0025).
Regarding claim 14, Avkarogullari et al. discloses the method of claim 12, wherein the plurality of steps further include a second step in which the static program is processed to generate a dynamic program and the metadata with dynamic resources determined based on all processing contexts (pipeline state descriptor object 540 itself may be constructed using one or objects that include function object 524, blend state 526, and pixel format 528, para. 0047. Possible values that may be set include vertex and fragment function properties that help specify the vertex and fragment shaders, and a value for the blend state that specifies the blend state of a specified frame buffer attachment, para. 0046.).
Regarding claim 15, Avkarogullari et al. discloses the method of claim 14, wherein the second step is performed by a hardware driver (pipeline objects can be created at any time, although it may be desirable to create them early during application launch. This allows selection of a pre-created pipeline during the second level of execution, para. 0048).
Regarding claim 16, Avkarogullari et al. discloses the method of claim 1, wherein outputting the metadata to hardware includes outputting the metadata to a scheduler configured in the hardware, wherein the scheduler is operable to select, based on the metadata, a processor core from a plurality of processor cores to use for execution of the one or more processing contexts (the GPU 150 may execute the native binary code, performing the graphics and compute kernels for data parallel operations, para. 0025; compiled executable instructions for the GPU 150 can be arranged so as to be compiled only one time at a time other than draw time of the graphical operation and cached for repeated use, para. 0011).
Regarding claim 17, Avkarogullari et al. discloses a system, comprising:
a non-transitory memory storage comprising instructions (para. 0009); and
one or more processors in communication with the memory, wherein the one or more processors execute the instructions (para. 0009) to:
process code defining a program to be executed using a pipeline having one or more stages (computer readable medium having instructions stored thereon to support immutable pipeline state objects containing code for a graphics processing unit (GPU). When executed, the instructions can cause one or more processors to create an immutable pipeline state object that contains compiled information about one or more graphics operations to display a graphical object, para. 0009), wherein the processing generates from the code metadata indicating: one or more processing contexts, an assignment of each processing context of the one or more processing contexts to a corresponding stage of the one or more stages in the pipeline, and resources to be used for each stage of the one or more stages (one or more graphics operations can include one or more shaders of a type selected from the group consisting of a vertex shader, fragment shader, and a vertex fetch configuration. The one or more graphics operations can include at least one item selected from the group consisting of blend state, rasterization enablement, and multisample masking, para. 0009); and
output the metadata to hardware for use in executing the program using the pipeline in accordance with the metadata (the GPU 150, see figure 1, executes the native binary code, performing the graphics and compute kernels for data parallel operations, para. 0025).
Regarding claim 18, Avkarogullari et al. discloses the system of claim 17, wherein the code is an intermediate code generated by processing a source code for the program, wherein the intermediate code expresses the pipeline (submit source code in the unified programming interface 110, which can be a GPU-specific programming language. Once the code is written, it may be directed to a compiler 115, which parses the source code and generates a native binary code, paras. 0023, 0025).
Regarding claim 19, Avkarogullari et al. discloses the system of claim 17, wherein the one or more stages of the pipeline are hetergenous (distinct stages offered are vertex fetch 501, a vertex shader 502, a rasterization 503, a fragment shader 504, and a frame buffer 506, para. 0052 and see figure 5A).
Regarding claim 20, Avkarogullari et al. discloses the system of claim 17, wherein each individual processing context of the one or more processing contexts includes a plurality of threads (fragment shaders 130, and vertex shaders 135, para. 0025).
Regarding claim 21, Avkarogullari et al. discloses the system of claim 17, wherein the resources for each stage of the one or more stages includes resources required by the corresponding processing context (pipeline state descriptor object 540 itself may be constructed using one or objects that include function object 524, blend state 526, and pixel format 528, para. 0047).
Regarding claim 22, Avkarogullari et al. discloses the system of claim 21, wherein the resources include static resources (vertex fetch 501, a vertex shader 502, a rasterization 503, a fragment shader 504, and a frame buffer 506, para. 0052 and see figure 5A are examples of static resources as they each execute a fixed function.).
Regarding claim 23, Avkarogullari et al. discloses the system of claim 22, wherein the resources include dynamic resources extrapolated from the static resources (the set of one or more associated state options for the immutable state object can include data attributes that can be changed without causing a corresponding change to the executable instructions for the GPU and the associated immutable state object, para. 0012. Examples of such attributes include input textures or input vertex data, viewport size, and/or occlusion query data, para. 0010.).
Regarding claim 24, Avkarogullari et al. discloses the system of claim 23, wherein the dynamic resources are determined based on all processing contexts corresponding to the stage (pipeline state descriptor object 540 itself may be constructed using one or objects that include function object 524, blend state 526, and pixel format 528, para. 0047).
Regarding claim 25, Avkarogullari et al. discloses a non-transitory computer-readable media storing computer instructions which when executed by one or more processors of a device cause the device to:
process code defining a program to be executed using a pipeline having one or more stages (computer readable medium having instructions stored thereon to support immutable pipeline state objects containing code for a graphics processing unit (GPU). When executed, the instructions can cause one or more processors to create an immutable pipeline state object that contains compiled information about one or more graphics operations to display a graphical object, para. 0009), wherein the processing generates from the code metadata indicating:
one or more processing contexts (one or more graphics operations can include one or more shaders of a type selected from the group consisting of a vertex shader, fragment shader, and a vertex fetch configuration. The one or more graphics operations can include at least one item selected from the group consisting of blend state, rasterization enablement, and multisample masking, para. 0009), an assignment of each processing context of the one or more processing contexts to a corresponding stage of the one or more stages in the pipeline, and resources to be used for each stage of the one or more stages (in FIG. 5A. A pipeline state object can be associated, for example, with an object to be drawn. The illustrated pipeline state object 542 includes five components, a vertex fetch 501, a vertex shader 502, a rasterization 503, a fragment shader 504, and a frame buffer 506. Historically, each of these objects would have been controlled by a separate API. However, in any given instantiation associated with a real-world implementation, there is a predefined data flow among these objects.);
and
output the metadata to hardware for use in executing the program using the pipeline in accordance with the metadata (the GPU 150, see figure 1, executes the native binary code, performing the graphics and compute kernels for data parallel operations, para. 0025).
Regarding claim 26, Avkarogullari et al. discloses the non-transitory computer-readable media of claim 25, wherein the code is an intermediate code generated by processing a source code for the program, wherein the intermediate code expresses the pipeline (submit source code in the unified programming interface 110, which can be a GPU-specific programming language. Once the code is written, it may be directed to a compiler 115, which parses the source code and generates a native binary code, paras. 0023, 0025).
Regarding claim 27, Avkarogullari et al. discloses the non-transitory computer-readable media of claim 25, wherein the one or more stages of the pipeline are hetergenous (distinct stages offered are vertex fetch 501, a vertex shader 502, a rasterization 503, a fragment shader 504, and a frame buffer 506, para. 0052 and see figure 5A).
Regarding claim 28, Avkarogullari et al. discloses the non-transitory computer-readable media of claim 25, wherein each individual processing context of the one or more processing contexts includes a plurality of threads (fragment shaders 130, and vertex shaders 135, para. 0025).
Regarding claim 29, Avkarogullari et al. discloses the non-transitory computer-readable media of claim 25, wherein the resources for each stage of the one or more stages includes resources required by the corresponding processing context (pipeline state descriptor object 540 itself may be constructed using one or objects that include function object 524, blend state 526, and pixel format 528, para. 0047).
Regarding claim 30, Avkarogullari et al. discloses the non-transitory computer-readable media of claim 29, wherein the resources include static resources (vertex fetch 501, a vertex shader 502, a rasterization 503, a fragment shader 504, and a frame buffer 506, para. 0052 and see figure 5A are examples of static resources as they each execute a fixed function.).
Regarding claim 31, Avkarogullari et al. discloses the non-transitory computer-readable media of claim 30, wherein the resources include dynamic resources extrapolated from the static resources (the set of one or more associated state options for the immutable state object can include data attributes that can be changed without causing a corresponding change to the executable instructions for the GPU and the associated immutable state object, para. 0012. Examples of such attributes include input textures or input vertex data, viewport size, and/or occlusion query data, para. 0010.).
Regarding claim 32, Avkarogullari et al. discloses the non-transitory computer-readable media of claim 31, wherein the dynamic resources are determined based on all processing contexts corresponding to the stage (pipeline state descriptor object 540 itself may be constructed using one or objects that include function object 524, blend state 526, and pixel format 528, para. 0047).
Claims 33-37, 40-56, and 59-70 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Prado et al. (US 20130339681 A1).
Claim 33, a method claim, is rejected for the same reason as claim 52.
Claim 34, a method claim, is rejected for the same reason as claim 53.
Claim 35, a method claim, is rejected for the same reason as claim 54.
Claim 36, a method claim, is rejected for the same reason as claim 55.
Claim 37, a method claim, is rejected for the same reason as claim 56.
Claim 40, a method claim, is rejected for the same reason as claim 59.
Claim 41, a method claim, is rejected for the same reason as claim 60.
Claim 42, a method claim, is rejected for the same reason as claim 61.
Claim 43, a method claim, is rejected for the same reason as claim 62.
Claim 44, a method claim, is rejected for the same reason as claim 63.
Claim 45 a method claim, is rejected for the same reason as claim 64.
Claim 46, a method claim, is rejected for the same reason as claim 65.
Claim 47, a method claim, is rejected for the same reason as claim 66.
Claim 48, a method claim, is rejected for the same reason as claim 67
Claim 49, a method claim, is rejected for the same reason as claim 68.
Claim 50, a method claim, is rejected for the same reason as claim 69.
Claim 51, a method claim, is rejected for the same reason as claim 70.
Regarding claim 52, Prado et al. discloses a system, comprising:
hardware configured to:
process metadata defined for a program to be executed using a pipeline having one or more stages (pipeline stages P1-P4 206-209 may be capable of executing a given thread based on that thread context. For instance, in some embodiments, first pipeline stage P1 206 may perform a "fetch" operation, second pipeline stage P2 207 may perform a "decode" operation, third pipeline stage P3 208 may perform an "execute" operation, and fourth pipeline stage P4 209 may perform a "write-back" operation, para. 0017), wherein the metadata indicates: one or more processing contexts ( retrieve a thread context from CTXMEM 203 and store it in one of register sets or banks CTX1 204 or CTX2 205, each of which including registers that define a processor's programming model (e.g., pc, sp, r0, . . . , rn, etc.), para. 0017), an assignment of each processing context of the one or more processing contexts to a corresponding stage of the one or more stages in the pipeline, and resources to be used for each stage of the one or more stages (concept of multithreading or multitasking was developed, in part, to improve the use of available computing resources), and
wherein the processing includes mapping the one or more processing contexts to one or more processing blocks of a processor core (direct each instruction to an appropriate one of register sets, para. 0019); and
the processor core configured to:
execute the one or more processing contexts based on the mapping (capable of executing a given thread based on that thread context, para. 0017.
Regarding claim 53, Prado et al. discloses the system of claim 52, wherein the processing further includes: selecting, based on the metadata, the processor core from among a plurality of processor cores to use for execution of the one or more processing contexts (processor cores may include a first and second context register sets, each of the context register sets adapted to store any given one of the plurality of thread contexts, as well as control circuitry operably coupled to the first and second context register sets, para. 0043).
Regarding claim 54, Prado et al. discloses the system of claim 53, wherein the processor core is selected based on total dynamic resources required for all processing contexts.
Regarding claim 55, Prado et al. discloses the system of claim 54, wherein the resources include at least one of registers (register sets, para. 0043) or scratchpad memory.
Regarding claim 56, Prado et al. discloses the system of claim 52, wherein mapping the one or more processing contexts to the one or more processing blocks of the processor core includes: sending each processing context of one or more processing contexts to a corresponding processing block of the one or more processing blocks (to direct each instruction to an appropriate one of register sets CTX1 204 or CTX2 205. Accordingly, pipeline stages P1-P4 206-209 may issue instructions that are context-agnostic--i.e., each pipeline stage may execute instructions without knowing which thread is being executed--because multithreading control engine 210 may be in charge of directing those instructions to an appropriate one between register sets CTX1 204/CTX2 205 at an appropriate time, para. 0019).
Regarding claim 59, Prado et al. discloses the system of claim 52, wherein the mapping maps all processing contexts belonging to a same pipeline slice together on a same processing block (pipeline stages P1-P4 206-209 may issue instructions that are context-agnostic--i.e., each pipeline stage may execute instructions without knowing which thread is being executed--because multithreading control engine 210 may be in charge of directing those instructions to an appropriate one between register sets CTX1 204/CTX2 205 at an appropriate time, para. 0019).
Regarding claim 60, Prado et al. discloses the system of claim 52, wherein the processing further includes: setting a program state for execution (thread context from CTXMEM 203 and store it in one of register sets or banks CTX1 204 or CTX2 205, each of which including registers that define a processor's programming model (e.g., pc, sp, r0, . . . , rn, etc.). After the thread context is retrieved and stored in one of register sets CTX1 204 or CTX2 205, para. 0017).
Regarding claim 61, Prado et al. discloses the system of claim 60, wherein the program state includes at least one of a memory buffer status, queue status, a pipeline stage identifier, or pipeline stage status (pipeline stages P1-P4 enumerated).
Regarding claim 62, Prado et al. discloses the system of claim 61, wherein the queue status is a register file queue status (order in which each operation of a given method is performed may be changed, and various elements of the systems illustrated herein may be added, reordered, para. 0033).
Regarding claim 63, Prado et al. discloses the system of claim 62, wherein the register file queue status includes one of more of empty (para. 0029), full, or current number of elements stored.
Regarding claim 64, Prado et al. discloses the system of claim 61, wherein the pipeline stage status is a number of instructions executed (paras. 0015, 0020).
Regarding claim 65, Prado et al. discloses the system of claim 52, wherein executing the one or more processing contexts on the processor core includes:
each processing block of the one or more processing blocks executing the processing context of the one or more processing contexts mapped thereto (capable of executing a given thread based on that thread context, para. 0017).
Regarding claim 66, Prado et al. discloses the system of claim 65, wherein executing the one or more processing contexts on the processor core is performed based on a prioritization policy (allows the thread to be interrupted--e.g., so that a different thread may be executed--and then continued at a later time (specific data or variables making up a thread context may depend upon the type of processor, application, thread, etc.), para. 0014).
Regarding claim 67, Prado et al. discloses the system of claim 66, wherein the prioritization policy uses a pipeline stage identifier included in a program state to determine a next processing context to execute based on a current stage of the pipeline (a particular sequence of operations or stages (e.g., fetch, decode, etc.), para. 0014).
Regarding claim 68, Prado et al. discloses the system of claim 66, wherein the prioritization policy uses a queue status included in a program state to determine a next processing context to execute (paras. 0015, 0020. See also, a particular sequence of operations or stages, para. 0014).
Regarding claim 69, Prado et al. discloses the system of claim 68, wherein the queue status is a register file queue status (paras. 0015, 0020. See also, a particular sequence of operations or stages, para. 0014).
Regarding claim 70, Prado et al. discloses the system of claim 52, wherein the hardware is a graphics processing unit (GPU), see para. 0009.
Allowable Subject Matter
Claims 38, 39, 57 and 58 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.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to THOMAS J LETT whose telephone number is (571)272-7464. The examiner can normally be reached Mon-Fri 9-6 ET.
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, Tammy Goddard can be reached at (571) 272-7773. 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.
/THOMAS J LETT/Primary Examiner, Art Unit 2611