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 § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 2, 4-6, 8, 10-13, 15-17, and 19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Stich et al. (“GPU Ray Tracing”, 2013.)(Hereinafter referred to as Stich).
Regarding claim 1, Stich teaches An apparatus (The NVIDIA® OptiX™ ray tracing engine is a programmable system designed for NVIDIA GPUs and other highly parallel architectures. See abstract), comprising: a graphics processor (Historically, ray tracing has been considered slow and
rasterization fast. The simple, regular structure of depth buffer rasterization lends itself to highly parallel hardware implementations: each object moves through several stages of computation (the so-called graphics pipeline), with each stage performing similar computations in data-parallel fashion on the many objects, fragments, and pixels in flight throughout the pipeline. As graphics hardware has grown more parallel it has also grown more general, evolving from specialized fixed-function circuitry implementing the various stages of the graphics pipeline into fully programmable processors that virtualize those stages onto hundreds or even thousands of small general-purpose cores. Today’s graphics processing units, or GPUs, are massively parallel processors capable of performing trillions of floating-point math operations and rendering billions of triangles each second. The computational horsepower and power efficiency of modern GPUs has made them attractive for high performance computing, from many of the fastest supercomputers in the world to science, math, and engineering codes on the desktop. All of which raises the question: can ray tracing be implemented efficiently and flexibly on GPUs? See page 93, right col., last paragraph to page 94, first paragraph) that includes:
shader processor circuitry (The core idea behind the OptiX engine is that most ray tracing algorithms can be implemented using combinations of a small set of programmable operations. This is directly analogous to the programmable rasterization pipelines employed by OpenGL and Direct3D. At a high level, these systems expose an abstract rasterizer containing lightweight callbacks for vertex shading, geometry processing, tessellation, and pixel shading operations. An ensemble of these program types, often used in multiple passes, can be used to implement a broad variety of rasterization-based algorithms. See page 94, section 3.); and
ray acceleration circuitry (OptiX includes seven different types of these programs, each of which conceptually operates on a single ray at a time. In addition, a bounding box program operates on geometry to determine primitive bounds for acceleration structure construction. The combination of user programs and hardcoded OptiX kernel code forms the ray tracing pipeline, which is outlined in Figure 2. Unlike a feed-forward rasterization pipeline, it is more natural to think of the ray tracing pipeline as a call graph. The core operation, rtTrace, alternates between locating an intersection (Traverse) and responding to that intersection (Shade). By reading and writing data in user-defined ray payloads and in global device memory arrays called buffers, these operations are combined to perform arbitrary computation during ray tracing. See page 94, right col., section 3.1) configured to:
perform traversal operations corresponding to an acceleration data structure for a graphics scene (Intersection programs implement ray-geometry intersection tests. As the acceleration structures are traversed, the system will invoke intersection programs to perform geometric queries. The program determines if and where the ray touches the object and may compute normals, texture coordinates, or other attributes based on the hit position. An arbitrary number of attributes may be associated with each intersection. Intersection programs enable support for arbitrary surfaces beyond polygons and triangles, such as displacement maps, spheres, cylinders, high-order surfaces, or even fractal geometries like the Julia set in Figure 1. A programmable intersection operation is useful even in a triangle-only system because it facilitates direct access to native mesh formats. See page 94, right col., third to last paragraph); and in response to traversal for a first ray reaching a node in the acceleration data structure, cause the shader processor circuitry to launch a first shader program to process the node (Intersection programs implement ray-geometry intersection tests. As the acceleration structures are traversed, the system will invoke intersection programs to perform geometric queries. The program determines if and where the ray touches the object and may compute normals, texture coordinates, or other attributes based on the hit position. An arbitrary number of attributes may be associated with each intersection. Intersection programs enable support for arbitrary surfaces beyond polygons and triangles, such as displacement maps, spheres, cylinders, high-order surfaces, or even fractal geometries like the Julia set in Figure 1. A programmable intersection operation is useful even in a triangle-only system because it facilitates direct access to native mesh formats. See page 94, right col., third to last paragraph); wherein the graphics processor is configured to, in response to execution of an instruction included in the first shader program, launch and execute a second shader program to further process the node (Closest-hit programs are invoked once traversal has found the nearest intersection of a ray with the scene geometry. This program type resembles surface shaders in classical rendering systems. Typically, a closest-hit program will perform computations like shading, potentially casting new rays in the process, and store resulting data in the ray payload. Any-hit programs are called during traversal for every ray-object intersection that is found. The any-hit program allows the material to participate in object intersection decisions while keeping the shading operations separate from the geometry operations. It may optionally terminate the ray using the built-in function rtTerminateRay, which will stop all traversal and unwind the call stack to the most recent invocation of rtTrace. This is a lightweight exception mechanism that can be used to implement early ray termination for shadow rays and ambient occlusion. Alternatively, the any-hit program may ignore the intersection using rtIgnoreIntersection, allowing traversal to continue looking for other geometric objects. For instance, a program may choose to ignore an interaction based on a texture channel lookup to implement efficient alpha-mapped transparency without restarting traversal. Another use case for the any-hit program can be found in Section 6.1, where the application performs visibility attenuation for partial shadows cast by glass objects. Note that intersections may be presented out of order. The default any-hit program is a no-op, which is often the desired operation. Miss programs are executed when the ray does not intersect any geometry in the interval provided. They can be used to implement a background color or environment map lookup. See page 94, second to last paragraph right col., to page 95, second paragraph right col.).
Regarding claim 2, Stich teaches The apparatus of claim 1, wherein the node is a leaf node and the first shader program and the second shader program are both leaf shaders (See figure 3 and figure 2, external nodes intersection program and intersection program can lead to miss program, closest hit program or any hit program).
Regarding claim 4, Stich teaches The apparatus of claim 1, wherein: the shader processor circuitry is configured to issue a shader chain command to the ray acceleration circuitry in response to execution of the instruction; and the ray acceleration circuitry is configured to cause the shader processor circuitry to launch the second shader program based on the shader chain command (Intersection programs implement ray-geometry intersection tests. As the acceleration structures are traversed, the system will invoke intersection programs to perform geometric queries. The program determines if and where the ray touches the object and may compute normals, texture coordinates, or other attributes based on the hit position. An arbitrary number of attributes may be associated with each intersection. Intersection programs enable support for arbitrary surfaces beyond polygons and triangles, such as displacement maps, spheres, cylinders, high-order surfaces, or even fractal geometries like the Julia set in Figure 1. A programmable intersection operation is useful even in a triangle-only system because it facilitates direct access to native mesh formats. See page 94, right col., third to last paragraph) (Closest-hit programs are invoked once traversal has found the nearest intersection of a ray with the scene geometry. This program type resembles surface shaders in classical rendering systems. Typically, a closest-hit program will perform computations like shading, potentially casting new rays in the process, and store resulting data in the ray payload. Any-hit programs are called during traversal for every ray-object intersection that is found. The any-hit program allows the material to participate in object intersection decisions while keeping the shading operations separate from the geometry operations. It may optionally terminate the ray using the built-in function rtTerminateRay, which will stop all traversal and unwind the call stack to the most recent invocation of rtTrace. This is a lightweight exception mechanism that can be used to implement early ray termination for shadow rays and ambient occlusion. Alternatively, the any-hit program may ignore the intersection using rtIgnoreIntersection, allowing traversal to continue looking for other geometric objects. For instance, a program may choose to ignore an interaction based on a texture channel lookup to implement efficient alpha-mapped transparency without restarting traversal. Another use case for the any-hit program can be found in Section 6.1, where the application performs visibility attenuation for partial shadows cast by glass objects. Note that intersections may be presented out of order. The default any-hit program is a no-op, which is often the desired operation. Miss programs are executed when the ray does not intersect any geometry in the interval provided. They can be used to implement a background color or environment map lookup. See page 94, second to last paragraph right col., to page 95, second paragraph right col.)(see figure 2).
Regarding claim 5, Stich teaches The apparatus of claim 1, wherein the instruction identifies: the node; and the second shader program (The ray generation program creates rays and traces them against the geometry group. This initiates the Traverse stage shown in Figure 2, executing parallelogram and triangle-mesh intersection until an intersection is found (2 and 3). If the ray intersects with geometry, the closest-hit program will be called whether the intersection was found on the ground plane or on the triangle mesh. The material will recursively generate show rays to determine if the light source is unobstructed. 4. When any intersection along the shadow ray is found, the any-hit program will terminate ray traversal and return to the calling program with shadow occlusion information. 5. If a ray does not intersect with any scene geometry, the miss program will be invoked. See page 96, right col., second paragraph).
Regarding claim 6, Stich teaches The apparatus of claim 5, wherein the instruction further identifies the first ray (The program determines if and where the ray touches the object and may compute normals, texture coordinates, or other attributes based on the hit position. See page 94, right col., third to last paragraph).
Regarding claim 8, Stich teaches The apparatus of claim 1, wherein the first shader program includes one or more conditional instructions that control whether the instruction is executed (OptiX also
supports user-defined exceptions that can be thrown from any program. The exception program can react, for example, by printing diagnostic messages or visualizing the condition by writing special color values to an output pixel buffer. See page 95, right col., third paragraph).
Regarding claim 10, Stich teaches The apparatus of claim 1, wherein the node is a transform node (Transform nodes have a single child of any node type, plus an associated 4×3 matrix that is used to perform an affine transformation of the underlying geometry. See page 96, left col., 5th paragraph).
Regarding claim 11, Stich teaches The apparatus of claim 1, wherein the apparatus is a computing device that further includes: a central processing unit; a display; and network interface circuitry (After execution of the ray tracing kernel has completed, its resulting data can be used by the application. Typically, this involves reading from output buffers filled by one of the user programs or displaying such a buffer directly, for example, via OpenGL. An interactive or multi-pass application then repeats the process starting at context setup, where arbitrary changes to the context can be made, and the kernel is launched again. See page 97, left col., third paragraph)(Clear this can be implemented in a computer and displayed.).
Regarding claim 12, Stich teaches A method (The NVIDIA® OptiX™ ray tracing engine is a programmable system designed for NVIDIA GPUs and other highly parallel architectures. The OptiX engine builds on the key observation that most ray tracing algorithms can be implemented using a small set of programmable operations. Consequently, the core of OptiX is a domain-specific justin-
time compiler that generates custom ray tracing kernels by combining user-supplied programs for ray generation, material shading, object intersection, and scene traversal. This enables the implementation of a highly diverse set of ray tracing-based algorithms and applications, including interactive rendering, offline rendering, collision detection systems, artificial intelligence queries, and scientific simulations such as sound propagation. OptiX achieves high performance through a compact object model and application of several ray tracing-specific compiler optimizations. For ease of use it exposes a single-ray programming model with full support for recursion and a dynamic dispatch mechanism similar to virtual function calls. See abstract), comprising:
performing, by ray acceleration hardware of a computing system, traversal operations corresponding to an acceleration data structure for a graphics scene (Intersection programs implement ray-geometry intersection tests. As the acceleration structures are traversed, the system will invoke intersection programs to perform geometric queries. The program determines if and where the ray touches the object and may compute normals, texture coordinates, or other attributes based on the hit position. An arbitrary number of attributes may be associated with each intersection. Intersection programs enable support for arbitrary surfaces beyond polygons and triangles, such as displacement maps, spheres, cylinders, high-order surfaces, or even fractal geometries like the Julia set in Figure 1. A programmable intersection operation is useful even in a triangle-only system because it facilitates direct access to native mesh formats. See page 94, right col., third to last paragraph); causing,
by the ray acceleration hardware in response to traversal for a first ray reaching a node in the acceleration data structure, a processor of the computing system, to launch a first shader program to process the node (Intersection programs implement ray-geometry intersection tests. As the acceleration structures are traversed, the system will invoke intersection programs to perform geometric queries. The program determines if and where the ray touches the object and may compute normals, texture coordinates, or other attributes based on the hit position. An arbitrary number of attributes may be associated with each intersection. Intersection programs enable support for arbitrary surfaces beyond polygons and triangles, such as displacement maps, spheres, cylinders, high-order surfaces, or even fractal geometries like the Julia set in Figure 1. A programmable intersection operation is useful even in a triangle-only system because it facilitates direct access to native mesh formats. See page 94, right col., third to last paragraph); and
launching and executing, by the processor in response to execution of an instruction included in the first shader program, a second shader program to further process the node (Closest-hit programs are invoked once traversal has found the nearest intersection of a ray with the scene geometry. This program type resembles surface shaders in classical rendering systems. Typically, a closest-hit program will perform computations like shading, potentially casting new rays in the process, and store resulting data in the ray payload. Any-hit programs are called during traversal for every ray-object intersection that is found. The any-hit program allows the material to participate in object intersection decisions while keeping the shading operations separate from the geometry operations. It may optionally terminate the ray using the built-in function rtTerminateRay, which will stop all traversal and unwind the call stack to the most recent invocation of rtTrace. This is a lightweight exception mechanism that can be used to implement early ray termination for shadow rays and ambient occlusion. Alternatively, the any-hit program may ignore the intersection using rtIgnoreIntersection, allowing traversal to continue looking for other geometric objects. For instance, a program may choose to ignore an interaction based on a texture channel lookup to implement efficient alpha-mapped transparency without restarting traversal. Another use case for the any-hit program can be found in Section 6.1, where the application performs visibility attenuation for partial shadows cast by glass objects. Note that intersections may be presented out of order. The default any-hit program is a no-op, which is often the desired operation. Miss programs are executed when the ray does not intersect any geometry in the interval provided. They can be used to implement a background color or environment map lookup. See page 94, second to last paragraph right col., to page 95, second paragraph right col.).
Regarding claim 13, Stich teaches The method of claim 12, wherein the node is a leaf node and the first shader program and the second shader program are both leaf shaders (See figure 3 and figure 2, external nodes intersection program and intersection program can lead to miss program, closest hit program or any hit program).
Regarding claim 15, Stich teaches The method of claim 12, wherein the instruction identifies: the node; and the second shader program (The ray generation program creates rays and traces them against the geometry group. This initiates the Traverse stage shown in Figure 2, executing parallelogram and triangle-mesh intersection until an intersection is found (2 and 3). If the ray intersects with geometry, the closest-hit program will be called whether the intersection was found on the ground plane or on the triangle mesh. The material will recursively generate show rays to determine if the light source is unobstructed. 4. When any intersection along the shadow ray is found, the any-hit program will terminate ray traversal and return to the calling program with shadow occlusion information. 5. If a ray does not intersect with any scene geometry, the miss program will be invoked. See page 96, right col., second paragraph).
Regarding claim 16, Stich teaches The method of claim 15, wherein the instruction further identifies the first ray (The program determines if and where the ray touches the object and may compute normals, texture coordinates, or other attributes based on the hit position. See page 94, right col., third to last paragraph).
Regarding claim 17, Stich teaches The method of claim 12, wherein the first shader program is a single-instruction multiple-thread (SIMT) program and only a proper subset of threads of the SIMT program execute the instruction (Instead of allowing the SIMT hardware to automatically serialize a divergent switch’s execution, OptiX explicitly selects a single state for an entire SIMT unit to execute using a scheduling heuristic. Threads within the SIMT unit that do not require the state simply idle that iteration. The mechanism is outlined in Figure 5. See section 5.2).
Regarding claim 19, Stich teaches A non-transitory computer-readable medium having instructions stored thereon that are executable by a computing device to perform operations (OptiX includes seven different types of these programs, each of which conceptually operates on a single ray at a time. In addition, a bounding box program operates on geometry to determine primitive bounds for acceleration structure construction. The combination of user programs and hardcoded OptiX kernel code forms the ray tracing pipeline, which is outlined in Figure 2. See page 94, right col., second paragraph) comprising:
generating a first shader program and control information that specifies to launch the first shader program in response to a ray reaching a node during traversal of a ray tracing acceleration data structure(Intersection programs implement ray-geometry intersection tests. As the acceleration structures are traversed, the system will invoke intersection programs to perform geometric queries. The program determines if and where the ray touches the object and may compute normals, texture coordinates, or other attributes based on the hit position. An arbitrary number of attributes may be associated with each intersection. Intersection programs enable support for arbitrary surfaces beyond polygons and triangles, such as displacement maps, spheres, cylinders, high-order surfaces, or even fractal geometries like the Julia set in Figure 1. A programmable intersection operation is useful even in a triangle-only system because it facilitates direct access to native mesh formats. See page 94, right col., third to last paragraph); and
generating a second shader program; wherein the generating the first shader program includes inserting an instruction in the first shader program that specifies to launch and execute the second shader program to perform additional processing of the node (Closest-hit programs are invoked once traversal has found the nearest intersection of a ray with the scene geometry. This program type resembles surface shaders in classical rendering systems. Typically, a closest-hit program will perform computations like shading, potentially casting new rays in the process, and store resulting data in the ray payload. Any-hit programs are called during traversal for every ray-object intersection that is found. The any-hit program allows the material to participate in object intersection decisions while keeping the shading operations separate from the geometry operations. It may optionally terminate the ray using the built-in function rtTerminateRay, which will stop all traversal and unwind the call stack to the most recent invocation of rtTrace. This is a lightweight exception mechanism that can be used to implement early ray termination for shadow rays and ambient occlusion. Alternatively, the any-hit program may ignore the intersection using rtIgnoreIntersection, allowing traversal to continue looking for other geometric objects. For instance, a program may choose to ignore an interaction based on a texture channel lookup to implement efficient alpha-mapped transparency without restarting traversal. Another use case for the any-hit program can be found in Section 6.1, where the application performs visibility attenuation for partial shadows cast by glass objects. Note that intersections may be presented out of order. The default any-hit program is a no-op, which is often the desired operation. Miss programs are executed when the ray does not intersect any geometry in the interval provided. They can be used to implement a background color or environment map lookup. See page 94, second to last paragraph right col., to page 95, second paragraph right col.).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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) 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stich et al. (“GPU Ray Tracing”, 2013.)(Hereinafter referred to as Stich) in view of Rabbani Rankouhi et al. (US 2022/0036652)(Hereinafter referred to as Rabbani).
Regarding claim 7, Stich teaches the apparatus of claim 5, but is silent to wherein the instruction includes a pointer to a token buffer that identifies the node and the second shader program.
Rabbani teaches utilizing token buffers to store pointer data for primitive testing or coordinate transformation (Token buffers 810, in some embodiments, provide a scratch space for communication between the RIA 190 and SIMD groups launched on the shaders by the RIA 190. In some embodiments, these SIMD groups receive a ray identifier as part of their input data in order to access ray data already allocated in the SCS, e.g., prior to an intersect ray command. When forming a SIMD group (e.g., a clique-T for primitive testing or a clique-S for a transform), the RIA 190 may populate a buffer with the thread data needed by the SIMD group and the SIMD group may write back the results in the same buffer. In some embodiments, the token buffer stores pointers to information to be used for primitive testing or coordinate transformation. For example, this may include a pointer to a leaf address for intersection testing, along with a count of threads that share the same ray ID (which may be packed into the same clique-T) and corresponding thread identifiers. As another example, this may include a pointer to a ray for coordinate transformation. See paragraph [0097]).
Stich and Rabbani teach of shading and utilizing ray tracing and Rabbani teaches that pointer information can be stored in Token buffers, therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine the system of Stich with the pointers in Token buffers technique of Rabbani such that the system could allow for flexible custom memory layouts.
Claim(s) 9 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Stich et al. (“GPU Ray Tracing”, 2013.)(Hereinafter referred to as Stich) in view of Guenther et al. (US 2021/0287423)(Hereinafter referred to as Guenther).
Regarding claim 9, Stich teaches the apparatus of claim 1, but is silent to further comprising: bin circuitry configured to: group multiple rays that reach the node for processing by a single-instruction multiple thread (SIMT) group corresponding to the first shader program; and group multiple rays from different SIMT groups that execute the instruction into the threads of the second shader program.
Guenther teaches a ray traversal system using SIMT win which rays can be grouped with similar characteristics (A set of primary rays may be dispatched to the scheduler 4007, which schedules work to shaders executed by the cores/EUs 4001. The cores/EUs 4001 may be ray tracing cores 3150, graphics cores 3130, CPU cores 3199 or other types of circuitry capable of executing shader program code. One or more primary ray shaders 6001 process the primary rays and spawn additional work to be performed by ray tracing acceleration circuitry 6010 and/or the cores/EUs 4001 (e.g., to be executed by one or more child shaders). New work spawned by the primary ray shader 6001 or other shaders executed by the cores/EUs 4001 may be distributed to sorting circuitry 4008 which sorts the rays into groups or bins as described herein (e.g., grouping rays with similar characteristics). The scheduler 4007 then schedules the new work on the cores/EUs 4001. See paragraph [0505]).
Stich and Guenther teach of ray traversal systems and Guenther teaches that the system can group rays with similar characteristics, therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine the system of Stich with the grouping/binning technique of Guenther to perform effective scheduling of processing.
Regarding claim 18, Stich teaches The method of claim 12, but is silent to further comprising: binning, by the ray acceleration hardware, multiple rays from different SIMT groups that execute the instruction for the first shader program into SIMT threads of the second shader program.
Guenther teaches a ray traversal system using SIMT win which rays can be grouped with similar characteristics (A set of primary rays may be dispatched to the scheduler 4007, which schedules work to shaders executed by the cores/EUs 4001. The cores/EUs 4001 may be ray tracing cores 3150, graphics cores 3130, CPU cores 3199 or other types of circuitry capable of executing shader program code. One or more primary ray shaders 6001 process the primary rays and spawn additional work to be performed by ray tracing acceleration circuitry 6010 and/or the cores/EUs 4001 (e.g., to be executed by one or more child shaders). New work spawned by the primary ray shader 6001 or other shaders executed by the cores/EUs 4001 may be distributed to sorting circuitry 4008 which sorts the rays into groups or bins as described herein (e.g., grouping rays with similar characteristics). The scheduler 4007 then schedules the new work on the cores/EUs 4001. See paragraph [0505]).
Stich and Guenther teach of ray traversal systems and Guenther teaches that the system can group rays with similar characteristics, therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine the system of Stich with the grouping/binning technique of Guenther to perform effective scheduling of processing.
Allowable Subject Matter
Claims 3, 14, 20 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: The closest prior art of record is Stich et al. (“GPU Ray Tracing”, 2013.)(Hereinafter referred to as Stich).
Stich teaches a programmable ray tracing engine (The NVIDIA® OptiX™ ray tracing engine is a programmable system designed for NVIDIA GPUs and other highly parallel architectures. See abstract), (Historically, ray tracing has been considered slow and rasterization fast. The simple, regular structure of depth buffer rasterization lends itself to highly parallel hardware implementations: each object moves through several stages of computation (the so-called graphics pipeline), with each stage performing similar computations in data-parallel fashion on the many objects, fragments, and pixels in flight throughout the pipeline. As graphics hardware has grown more parallel it has also grown more general, evolving from specialized fixed-function circuitry implementing the various stages of the graphics pipeline into fully programmable processors that virtualize those stages onto hundreds or even thousands of small general-purpose cores. Today’s graphics processing units, or GPUs, are massively parallel processors capable of performing trillions of floating-point math operations and rendering billions of triangles each second. The computational horsepower and power efficiency of modern GPUs has made them attractive for high performance computing, from many of the fastest supercomputers in the world to science, math, and engineering codes on the desktop. All of which raises the question: can ray tracing be implemented efficiently and flexibly on GPUs? See page 93, right col., last paragraph to page 94, first paragraph) , but is silent to further and the second shader program is executable to perform a curve test.
The prior art of record alone or in combination is silent to the limitations “further and the second shader program is executable to perform a curve test.” Of claim 3 when read in light of the rest of the limitations in claim 3 and thus claim 3 contains allowable subject matter.
The prior art of record alone or in combination is silent to the limitations “and the second shader program performs a curve test.” Of claim 14 when read in light of the rest of the limitations in claim 14 and thus claim 14 contains allowable subject matter.
The prior art of record alone or in combination is silent to the limitations “determining whether to generate a single shader program for a set of work or to generate the first and second shader programs for the set of work based on: an expected ratio of threads expected to execute work corresponding to the second shader program; and an expected execution time of the work corresponding to the second shader program. ” Of claim 20 when read in light of the rest of the limitations in claim 20 and thus claim 20 contains allowable subject matter.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Shin et al. (US 10,497,167), generally describes acceleration structures for ray tracing.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS R WILSON whose telephone number is (571)272-0936. The examiner can normally be reached M-F 7:30-5:00PM.
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, Kee Tung can be reached at (572)-272-7794. 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.
/NICHOLAS R WILSON/Primary Examiner, Art Unit 2611
Prosecution Insights