DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1 - 10 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Though claims 1 - 10 recite a “compiler” comprising configuration (methods) for the compiler to perform procedural steps. The original specification discloses the compiler 110 to be part of the graphics processing system 100 (page 18, lines 12 – 33), however does not disclose the compiler to be specifically and exclusively hardware. It is noted that compilers are purely software in the known technology. Therefore, the “compiler” being structured as an “apparatus” in the claims is merely just software and/or improperly claiming two statutory categories of an “apparatus” claim with method limitations.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1 – 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1 and 11 recite “the fragments” in the end of the preamble. It is unclear if “the fragments” is referencing the first instance of “fragments” in (i) of the preamble or the second instance of “fragments” in (ii) of the preamble.
Claims 2 and 12 recite the limitation “the final instruction”. There is insufficient antecedent basis for this limitation in the claim.
Claims 3 and 13 recite the limitation “a point”. It is unclear if the mentioned “a point” is referencing “the point” (claims 3 and 13) or “a point” (claims 1 and 11) or is different from these two.
Claims 5 and 15 recite the limitation “the instruction”. Claim 1 recites “identify an instruction” following “the identified instruction”. Though it appears these instructions are the same instructions, it is unclear claims 5 and 15 reciting “the instruction” is the identified instruction or different from the identified instruction since two different references, “the identified instruction” (claims 1 and 11) and “the instruction” (claims 5 and 15) are used.
Claims 6 and 16 recite the limitation “the instruction”. Claim 1 recites “identify an instruction” following “the identified instruction”. Though it appears these instructions are the same instructions, it is unclear claims 6 and 16 reciting “the instruction” is the identified instruction or different from the identified instruction since two different references, “the identified instruction” (claims 1 and 11) and “the instruction” (claims 6 and 16) are used.
Claims 6 and 16 recite the limitation “an instruction”. It is unclear if the mentioned “an instruction” is referencing the instruction or the identified instruction or its own instruction that is neither the instruction or the identified instruction.
Claims 2, 6, 12, and 16 recite the limitation “the final instruction”. There is insufficient antecedent basis for this limitation in the claim.
Claims 2, 6, 12, and 16 recite the limitation “a fragment”. Claims 1 and 11 recite “a fragment” in the first limitation. It is unclear if “a fragment” mentioned in claims 2, 6, 12, and 16 is the same fragment or a different fragment from “a fragment” mentioned in claims 1 and 11.
A broad range or limitation together with a narrow range or limitation that falls within the broad range or limitation (in the same claim) may be considered indefinite if the resulting claim does not clearly set forth the metes and bounds of the patent protection desired. See MPEP § 2173.05(c). Claims 2 and 12 recite, “wherein the shader program is split into two stages, and wherein the identified instruction is the final instruction in the shader program which can affect the shader-dependent property of a fragment” with claims 1 and 11 recite “splitting the shader program into stages by splitting the shader program at a point after the identified instruction in the shader program”. If the shader program is split after the identified instruction and the identified instruction is the final instruction, one of ordinary skill would not know how the shader program code could be split after the final instruction since there would not be any more instructions of the shader program after the final instruction to be able to split or it is not known that there are more instructions after the final instruction in the shader program. Therefor claims 2 and 12 are rejected under 35 U.S.C. 112(b) for being indefinite.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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.
Claim(s) 1 – 3, 5, 7, 8, 11 – 13, 15, 17, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Nystad (US 2018/0108167) in view of Okubo (US 2019/0362459).
Regarding independent claim 1, Nystad teaches a compiler configured to analyse a shader program (paragraph 184: The shader compiler will receive a shader program in a high level programming language to be compiled, and first parse the shader program source code and then optimise the shader program (e.g. in accordance with its normal compiler operation) (steps 60 and 61)) for execution in a graphics processing system (intended use; paragraph 194: Once all the shader program instructions have been analysed, the compilation of the shader program can be finalised (step 69) and the compiled shader program output to the graphics processing pipeline for execution (step 70)) which comprises:
(i) hidden surface removal logic configured to perform hidden surface removal on fragments (intended use; paragraph 180: If the fragment passes the depth and stencil tests, the shader execution then proceeds to the next instruction in the shader program (step 58). Otherwise, the fragment is discarded (the shader execution for the fragment is stopped) (i.e. if the coverage for the fragment ends up as zero following the depth/stencil test, then the execution of the fragment shader for the fragment in question is stopped (killed) at that point); paragraph 175: The alpha-to-coverage operation will proportionally remove coverage for the fragment based on the alpha value for the fragment (and so will, e.g., remove sample positions from the fragment if the alpha value indicates that the fragment is at least partially transparent)), and
(ii) processing logic configured to execute shader programs for fragments (intended use; paragraph 194: Once all the shader program instructions have been analysed, the compilation of the shader program can be finalised (step 69) and the compiled shader program output to the graphics processing pipeline for execution (step 70)), wherein one or more of the fragments has a shader-dependent property (paragraph 191: The test instruction is also included in the shader program before any instructions that will output depth or stencil values (i.e. if the shader outputs depth or stencil values, that happens after the test instruction), and before any instructions that generate blend outputs (i.e. any blend outputs of the shader program happen after the test instruction is (potentially) executed)),
the compiler being configured to:
identify an instruction in the shader program (paragraph 187: Thus, starting at the beginning of the shader program (step 63), {1}the compiler will analyse the first shader operation (step 64) and determine if that shader operation affects the test instruction (step 65){2} (e.g. will have an effect on a value that the test instruction will use or not); paragraphs 197 – 200 and Figure 7: alpha value decision portion having at least a SKIP (to jump/keep fragment) and DISCARD fragment) which can affect the shader-dependent property of a fragment (paragraph 191: The test instruction is also included in the shader program before any instructions that will output depth or stencil values (i.e. if the shader outputs depth or stencil values, that happens after the test instruction), and before any instructions that generate blend outputs (i.e. any blend outputs of the shader program happen after the test instruction is (potentially) executed); paragraph 204: The test instruction could also or instead operate to determine if the alpha value for the fragment being processed has a particular value or values, and trigger and/or perform a particular operation in the event that the alpha value has a particular value or values);
split the shader program into stages by splitting the shader program at a point after the identified instruction in the shader program (paragraph 188: If it is determined that the shader operation will affect the test instruction, then that operation is moved to be executed before the test instruction if possible (step 66). Conversely, if it is determined that the shader operation in question will not affect the test instruction, then that operation is moved to be executed after the test instruction if possible (step 67). paragraphs 197 – 200 and Figure 7: Examiner notes that the inserted test instructions split the shader program into two parts, being the shader program before the inserted test instructions (alpha value decision) --> inserted test instructions --> the shader program after the inserted test instruction (blending operation)); and
store the stages of the shader program <in a memory>, wherein the graphics processing system can read the stages of the shader program <from the memory> (paragraph 194: Once all the shader program instructions have been analysed, the compilation of the shader program can be finalised (step 69) and the compiled shader program output to the graphics processing pipeline for execution (step 70); paragraph 135: the graphics processing pipeline comprises, and/or is in communication with, one or more memories and/or memory devices that store the data described herein, and/or store software for performing the processes described herein). Though it is highly well known in the art that compiled shader program that generates machine assembly code are stored in memory (i.e. RAM), Nystad does not expressly disclose the stages of the shader program are stored in memory and read from the memory. Okubo discloses the shader code cache processing unit 204 makes a retrieval request to the GPU driver 205 to retrieve a compiled shader code, as well the shader code cache processing unit 204 stores the retrieved shader code in the nonvolatile memory (the ROM 104 or the storage unit 110) in order to skip the compiling process in the subsequent stages, and reads the stored shader code when using it (paragraph 42). Both Nystad and Okubo relate to the same field of invention of compiling shader program for a graphics processing pipeline/system. It would have been obvious for one of ordinary skill in the art at the time of the invention (pre-AIA ) or at the time of the effective filing date of the application (AIA ) to modify Nystad's system to store in memory shader program code and compiled shader codes for retrieving the necessary compiled shader code for execution by the GPU. One would be motivated to do so because the processing load can be reduced and the processing time can be shortened (paragraph 42).
Regarding dependent claim 2, Nystad teaches wherein the compiler is configured to split the shader program into two stages, and wherein the identified instruction is the final instruction {as best interpreted} in the shader program which can affect the shader-dependent property of a fragment (paragraphs 197 – 200 and Figure 7: alpha value decision portion having at least a SKIP (to jump/keep fragment) and DISCARD fragment wherein the fragments that are not discarded are used in the TEST instruction and the blending the fragment portion. Examiner notes the SKIP/DISCARD decision of the alpha value portion is the last instruction that affect the shader-dependent property of the fragment before blending is performed).
Regarding dependent claim 3, Nystad teaches wherein the point at which the shader program is split is a point immediately after the identified instruction in the shader program (paragraphs 197 – 200 and Figure 7: sample shader program 84 having the TEST instruction 81 after comparison of alpha value decision portion and before the blending the fragment portion).
Regarding dependent claim 5, Nystad teaches wherein the shader-dependent property is shader-dependent presence, and wherein the instruction which can affect the shader-dependent presence is a discard instruction (paragraphs 197 – 200 and Figure 7: {1}alpha value decision portion{1} having at least a SKIP (to jump/keep fragment) and {2}DISCARD fragment{2}).
Regarding dependent claim 7, Nystad teaches wherein the compiler is configured to identify the instruction, split the shader program and store the stages of the shader program in the memory prior to starting a render which involves executing the shader program on the graphics processing system (paragraph 194: Once all the shader program instructions have been analysed, the compilation of the shader program can be finalised (step 69) and the compiled shader program output to the graphics processing pipeline for execution (step 70); paragraphs 60 – 62: the execution processes of the graphics processing pipeline comprise rasterizing and rendering graphics data/fragments. Examiner notes that in order for the graphics processing pipeline to execute compiled code, the methods for compiling shade program into different stages are done before execution of the graphics processing pipeline that performs rasterizing and rendering).
Regarding dependent claim 8, Nystad teaches the compiler further configured to determine whether any data from a first stage of the shader program is used in a second stage of the shader program (paragraphs 197 – 200 and Figure 7: alpha value decision portion having at least a SKIP (to jump/keep fragment) and DISCARD fragment wherein the fragments that are not discarded are used in the TEST instruction and the blending the fragment portion).
Regarding independent claim 11, Nystad teaches a method of analysing a shader program (Figure 6) for execution in a graphics processing system (intended use; paragraph 194: Once all the shader program instructions have been analysed, the compilation of the shader program can be finalised (step 69) and the compiled shader program output to the graphics processing pipeline for execution (step 70)) which comprises:
(i) hidden surface removal logic configured to perform hidden surface removal on fragments (intended use; paragraph 180: If the fragment passes the depth and stencil tests, the shader execution then proceeds to the next instruction in the shader program (step 58). Otherwise, the fragment is discarded (the shader execution for the fragment is stopped) (i.e. if the coverage for the fragment ends up as zero following the depth/stencil test, then the execution of the fragment shader for the fragment in question is stopped (killed) at that point); paragraph 175: The alpha-to-coverage operation will proportionally remove coverage for the fragment based on the alpha value for the fragment (and so will, e.g., remove sample positions from the fragment if the alpha value indicates that the fragment is at least partially transparent)), and
(ii) processing logic configured to execute shader programs for fragments (intended use; paragraph 194: Once all the shader program instructions have been analysed, the compilation of the shader program can be finalised (step 69) and the compiled shader program output to the graphics processing pipeline for execution (step 70)), wherein one or more of the fragments has a shader-dependent property (paragraph 191: The test instruction is also included in the shader program before any instructions that will output depth or stencil values (i.e. if the shader outputs depth or stencil values, that happens after the test instruction), and before any instructions that generate blend outputs (i.e. any blend outputs of the shader program happen after the test instruction is (potentially) executed)),
the method comprising:
identifying an instruction in the shader program (paragraph 187: Thus, starting at the beginning of the shader program (step 63), {1}the compiler will analyse the first shader operation (step 64) and determine if that shader operation affects the test instruction (step 65){2} (e.g. will have an effect on a value that the test instruction will use or not); paragraphs 197 – 200 and Figure 7: alpha value decision portion having at least a SKIP (to jump/keep fragment) and DISCARD fragment) which can affect the shader-dependent property of a fragment (paragraph 191: The test instruction is also included in the shader program before any instructions that will output depth or stencil values (i.e. if the shader outputs depth or stencil values, that happens after the test instruction), and before any instructions that generate blend outputs (i.e. any blend outputs of the shader program happen after the test instruction is (potentially) executed); paragraph 204: The test instruction could also or instead operate to determine if the alpha value for the fragment being processed has a particular value or values, and trigger and/or perform a particular operation in the event that the alpha value has a particular value or values);
splitting the shader program into stages by splitting the shader program at a point after the identified instruction in the shader program (paragraph 188: If it is determined that the shader operation will affect the test instruction, then that operation is moved to be executed before the test instruction if possible (step 66). Conversely, if it is determined that the shader operation in question will not affect the test instruction, then that operation is moved to be executed after the test instruction if possible (step 67). paragraphs 197 – 200 and Figure 7: Examiner notes that the inserted test instructions split the shader program into two parts, being the shader program before the inserted test instructions (alpha value decision) --> inserted test instructions --> the shader program after the inserted test instruction (blending operation)); and
storing the stages of the shader program <in a memory>, wherein the graphics processing system can read the stages of the shader program <from the memory> (paragraph 194: Once all the shader program instructions have been analysed, the compilation of the shader program can be finalised (step 69) and the compiled shader program output to the graphics processing pipeline for execution (step 70); paragraph 135: the graphics processing pipeline comprises, and/or is in communication with, one or more memories and/or memory devices that store the data described herein, and/or store software for performing the processes described herein). Though it is highly well known in the art that compiled shader program that generates machine assembly code are stored in memory (i.e. RAM), Nystad does not expressly disclose the stages of the shader program are stored in memory and read from the memory. Okubo discloses the shader code cache processing unit 204 makes a retrieval request to the GPU driver 205 to retrieve a compiled shader code, as well the shader code cache processing unit 204 stores the retrieved shader code in the nonvolatile memory (the ROM 104 or the storage unit 110) in order to skip the compiling process in the subsequent stages, and reads the stored shader code when using it (paragraph 42). Both Nystad and Okubo relate to the same field of invention of compiling shader program for a graphics processing pipeline/system. It would have been obvious for one of ordinary skill in the art at the time of the invention (pre-AIA ) or at the time of the effective filing date of the application (AIA ) to modify Nystad's system to store in memory shader program code and compiled shader codes for retrieving the necessary compiled shader code for execution by the GPU. One would be motivated to do so because the processing load can be reduced and the processing time can be shortened (paragraph 42).
Regarding dependent claim 12, Nystad teaches wherein the shader program is split into two stages, and wherein the identified instruction is the final instruction{as best interpreted} in the shader program which can affect the shader-dependent property of a fragment (paragraphs 197 – 200 and Figure 7: alpha value decision portion having at least a SKIP (to jump/keep fragment) and DISCARD fragment wherein the fragments that are not discarded are used in the TEST instruction and the blending the fragment portion. Examiner notes the SKIP/DISCARD decision of the alpha value portion is the last instruction that affect the shader-dependent property of the fragment before blending is performed).
Regarding dependent claim 13, Nystad teaches wherein the point at which the shader program is split is a point immediately after the identified instruction in the shader program (paragraphs 197 – 200 and Figure 7: sample shader program 84 having the TEST instruction 81 after comparison of alpha value decision portion and before the blending the fragment portion).
Regarding dependent claim 15, Nystad teaches wherein the shader-dependent property is {1}shader-dependent presence{1}, and wherein the instruction which can affect the shader-dependent presence is {2}a discard instruction{2} (paragraphs 197 – 200 and Figure 7: {1}alpha value decision portion{1} having at least a SKIP (to jump/keep fragment) and {2}DISCARD fragment{2}).
Regarding dependent claim 17, Nystad teaches wherein the method is performed prior to starting a render which involves executing the shader program on the graphics processing system (paragraph 194: Once all the shader program instructions have been analysed, the compilation of the shader program can be finalised (step 69) and the compiled shader program output to the graphics processing pipeline for execution (step 70); paragraphs 60 – 62: the execution processes of the graphics processing pipeline comprise rasterizing and rendering graphics data/fragments. Examiner notes that in order for the graphics processing pipeline to execute compiled code, the methods for compiling shade program into different stages are done before execution of the graphics processing pipeline that performs rasterizing and rendering).
Regarding dependent claim 18, Nystad teaches determining whether any data from a first stage of the shader program is used in a second stage of the shader program (paragraphs 197 – 200 and Figure 7: alpha value decision portion having at least a SKIP (to jump/keep fragment) and DISCARD fragment wherein the fragments that are not discarded are used in the TEST instruction and the blending the fragment portion).
Claim(s) 4 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Nystad (US 2018/0108167) in view of Okubo (US 2019/0362459) and Gierach et al. (US 2019/0206110).
Regarding dependent claim 4, Nystad does not expressly disclose wherein the graphics processing system can read the stages of the shader program from the memory separately. Okubo discloses the shader source compilation processing unit 206 of the GPU driver 205 compiles all the shader source blocks instructed by the shader source selection processing unit 203 (paragraph 89), and the shader source compilation processing unit 206 instructs the GPU 103 to store all the shader code blocks generated at S803 in the GPU 103 (paragraph 90), and the GPU 103 stores, in the GPU accessible region 201 in the RAM 105, all the shader code blocks instructed to be stored by the GPU driver 205 (paragraph 91). Gierach discloses the shader compiler 1610 of the graphics driver 1605 includes the shader splitter 1606 which splits the shader program code into logical code blocks that can be separated and executed sequentially to achieve the same results of the original shader (paragraph 148). Nystad, Okubo, and Gierach relate to the same field of invention of compiling shader program for a graphics processing pipeline/system. It would have been obvious for one of ordinary skill in the art at the time of the invention (pre-AIA ) or at the time of the effective filing date of the application (AIA ) to modify Nystad's system that split the shader program code into sections separated by TEST code (Figure 7) to store different shader code sections/blocks as taught by Okubo and to read the stored shade code section/blocks separately and executed sequentially as taught by Gierach. One would be motivated to do so because the time required for the performance check can be reduced as much as possible, and the impact on usability can be reduced (Okubo, paragraph 97).
Regarding dependent claim 14, Nystad does not expressly disclose wherein the graphics processing system can read the stages of the shader program from the memory separately. Okubo discloses the shader source compilation processing unit 206 of the GPU driver 205 compiles all the shader source blocks instructed by the shader source selection processing unit 203 (paragraph 89), and the shader source compilation processing unit 206 instructs the GPU 103 to store all the shader code blocks generated at S803 in the GPU 103 (paragraph 90), and the GPU 103 stores, in the GPU accessible region 201 in the RAM 105, all the shader code blocks instructed to be stored by the GPU driver 205 (paragraph 91). Gierach discloses the shader compiler 1610 of the graphics driver 1605 includes the shader splitter 1606 which splits the shader program code into logical code blocks that can be separated and executed sequentially to achieve the same results of the original shader (paragraph 148). Nystad, Okubo, and Gierach relate to the same field of invention of compiling shader program for a graphics processing pipeline/system. It would have been obvious for one of ordinary skill in the art at the time of the invention (pre-AIA ) or at the time of the effective filing date of the application (AIA ) to modify Nystad's system that split the shader program code into sections separated by TEST code (Figure 7) to store different shader code sections/blocks as taught by Okubo and to read the stored shade code section/blocks separately and executed sequentially as taught by Gierach. One would be motivated to do so because the time required for the performance check can be reduced as much as possible, and the impact on usability can be reduced (Okubo, paragraph 97).
Allowable Subject Matter
Claims 16, 19, and 20 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 after overcoming the 35 U.S.C. 112(b) rejections.
The following is a statement of reasons for the indication of allowable subject matter:
Claim 16 recites “wherein the shader-dependent property is shader-dependent depth, and wherein the instruction which can affect the shader-dependent depth is an instruction for modifying the depth of a fragment”. Nystad (2018/0108167) discloses reading depth values of fragments and determining to keep or discard the fragments (paragraphs 197 – 200 and Figure 7), however Nystad does not disclose modifying the depth of the fragment.
Claim 19 recites that Nystad teaches <<does not teach>> the following:
wherein when data from the first stage of the shader program is used in the second stage of the shader program then, during execution of the shader program by the graphics processing system (paragraphs 173 – 181 and Figure 5: fragments that are kept are used in the next section of the shader program 51, 53, 56), either:
(i) said data from the first stage of the shader program is stored, and said stored data is retrieved for use when executing the second stage of the shader program (paragraphs 173 – 181 and Figure 5: Update coverage based on alpha value 54), or
(ii) the first stage of the shader program is <<re->>executed when the second stage of the shader program is to be executed (paragraphs 173 – 181 and Figure 5: Has early depth/stencil test been completed 51 and is Fragment coverage zero? 52 and Progress to next instruction);
<<wherein if it is determined that data from the first stage of the shader program is used in the second stage of the shader program then the method further comprises deciding, prior to starting a render which involves executing the shader program, which of options (i) and (ii) is to be performed by the graphics processing system>>.
Nystad does not disclose re-executing the first stage nor the compiler that decides option (i) or option (ii) to be performed.
Claim 20 recites that Nystad teaches <<does not teach>> the following:
wherein when data from the first stage of the shader program is used in the second stage of the shader program then, during execution of the shader program by the graphics processing system (paragraphs 173 – 181 and Figure 5: fragments that are kept are used in the next section of the shader program 51, 53, 56), either:
(i) said data from the first stage of the shader program is stored, and said stored data is retrieved for use when executing the second stage of the shader program (paragraphs 173 – 181 and Figure 5: Update coverage based on alpha value 54), or
(ii) the first stage of the shader program is <<re->>executed when the second stage of the shader program is to be executed (paragraphs 173 – 181 and Figure 5: Has early depth/stencil test been completed 51 and is Fragment coverage zero? 52 and Progress to next instruction);
<<wherein if it is determined that data from the first stage of the shader program is used in the second stage of the shader program then the method further comprises providing a metric for use by the graphics processing system in deciding, during runtime, which of options (i) and (ii) to perform.>>
Nystad does not disclose re-executing the first stage nor the compiler that decides option (i) or option (ii) to be performed using a metric.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEFFREY J CHOW whose telephone number is (571)272-8078. The examiner can normally be reached 11AM-7PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Devona Faulk can be reached at 571-272-7515. 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.
/JEFFREY J CHOW/Primary Examiner, Art Unit 2618
Prosecution Insights