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 .
Response to Amendment
The Amendment filed February 26th, 2026 has been entered. Claims 1 and 3-13 are pending in the application. Applicant’s amendments to the Claims 1 and 9 have overcome the rejections previously set forth in the Final Office Action mailed August 27th, 2025. Further search has been performed to address the material amended in the aforementioned claims. Newly found references Yoon (US 20140347355 A1), and Mejdrich (US 20100188396 A1) were used for the amended limitations.
Response to Arguments
Applicant’s arguments with respect to claims 1 and 3-13 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Claims 1 and 3 are rejected under 35 U.S.C. 103 as being unpatentable over Doyle (US 20200320776 A1) in view of Bakalash (US 20090027402 A1), Chen (CN 101819684 A), Zhang (CN 102184517 A), Yoon (US 20140347355 A1), and Mejdrich (US 20100188396 A1).
Regarding claim 1:
Doyle teaches:
A multi-chip based ray tracing device (Doyle: processing system 100 [0046]), the device comprising:
a system memory (Doyle: One or more combined level 1 (L1) caches and shared memory units 247 [0077]) configured to store geometry data (Doyle: graphics data such as […] vertex data [0077]) and an acceleration structure (AS) (Doyle: graphics data such as […] bounding volume data [0077]) for scene generation, wherein the system memory includes:
a plurality of ray tracing cores (Doyle: ray tracing cores 245 [0076]) wherein each of the plurality of ray tracing cores includes:
a local memory configured to store data from the system memory (Doyle: For example, two or more of the nodes may share a common memory or the local memories of the nodes may already have stored data from prior ray tracing operations [0254]; see Note 1A) and
a ray tracing unit configured to perform independent ray tracing (Doyle: accelerate ray tracing operations for both real-time ray tracing and non-real-time ray tracing implementations [0084]) based on the geometry data (Doyle: graphics data and/or instructions [0077]) and the acceleration structure (Doyle: BVH traversal [0086]); and
a central processing unit (Doyle: CPU [0258]) configured to execute and manage a ray tracing application (Doyle: graphics application 1010 [0181]; interactive [or] non-interactive ray tracing application [0235]) and a scene manager (Doyle: manager node 2201 [0257]; the manager node 2201 described above may be a CPU and/or software executed on the CPU [0258]) and delivering the geometry data and the acceleration structure to the plurality of ray tracing cores (Doyle: the L2 cache 253 may be shared across a plurality of multi-core groups 240A-240N [0077]).
Note 1A: Doyle teaches: “Memory interface 314 can be an interface to local memory, one or more internal caches, one or more shared external caches, and/or to system memory,” [0103]. Therefore, the local memory is configured to interface with the memory interface 314 which may also interface with system memory.
Doyle fails to explicitly teach:
A multi-chip based ray tracing device using frame partitioning, the device comprising:
a plurality of ray tracing cores wherein each of the plurality of ray tracing cores includes a ray tracing unit configured to perform independent ray tracing for an assigned frame;
a primitive static scene (PSS) area configured to store primitive data for static scenes,
a primitive dynamic scene (PDS) area configured to store primitive data for dynamic scenes, and
an AS area, configured to store a static AS generated through a single tree build in case of a static scene and a dynamic AS generated as a tree build is performed for primitive information changes in case of a dynamic scene;
wherein each of the plurality of ray tracing cores includes:
a local memory configured to store the static AS and the dynamic AS delivered from the system memory, and
the acceleration structure including the static AS and the dynamic AS; and
a tree build unit (TBU) configured to build the dynamic AS by performing spatial partitioning on the primitive data for dynamic scenes delivered from the PDS area; and
wherein the building of the dynamic AS is performed by the TBU of each of the plurality of ray tracing cores independently for the assigned frame when the primitive data for dynamic scenes is changed.
Bakalash teaches:
A multi-chip based ray tracing device (Bakalash: multi-mode parallel graphics processing system) using frame partitioning (Bakalash: Time Division (DPlex) Method of Parallel Graphics Rendering [0034]), the device comprising:
a system memory (Bakalash: geometry buffer 222 [0014]) configured to store geometry data (Bakalash: through which all geometric (i.e. polygonal) data is transferred [0014]) for scene generation;
a plurality of ray tracing cores (Bakalash: GPUs [0020]), wherein each of the plurality of ray tracing cores includes:
a ray tracing unit configured to perform independent ray tracing for an assigned frame (Bakalash: each graphics pipeline (and its individual rendering node or GPU) handles the processing of a full, alternating image frame [0034]; see Note 1B) based on the geometry data (Bakalash: graphics display list data [0034]); and
a central processing unit (Bakalash: one or more CPUs [0043]) configured to execute and manage a ray tracing application (Bakalash: graphics-based applications [0043]) and a scene manager (Bakalash: Decomposition Module 401 [0156]; Decomposition Phase [0024]) and deliver the geometry data (Bakalash: graphic commands and data [0156]) to the plurality of ray tracing cores (Bakalash: to the multiple GPUs on board [0156]).
Note 1B: Bakalash teaches effectively assigning frames in an alternating manner between individual rendering nodes in [0034] as cited above.
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Bakalash with Doyle. Having a multi-chip based ray tracing device using frame partitioning, a plurality of ray tracing cores performing independent ray tracing for individual frames based on the geometry data; and a central processing unit executing and managing a ray tracing application and a scene manager and delivering the geometry data to the plurality of ray tracing cores, as in Bakalash, would benefit the Doyle teachings by enabling a ray-tracing application to use a mode of parallelizing that “scales very well” (Bakalash, [0034]) with multiple GPUs.
Doyle in view of Bakalash still fails to teach:
a primitive static scene (PSS) area configured to store primitive data for static scenes,
a primitive dynamic scene (PDS) area configured to store primitive data for dynamic scenes, and
an AS area, configured to store a static AS generated through a single tree build in case of a static scene and a dynamic AS generated as a tree build is performed for primitive information changes in case of a dynamic scene;
wherein each of the plurality of ray tracing cores includes:
a local memory configured to store the static AS and the dynamic AS delivered from the system memory, and
the acceleration structure including the static AS and the dynamic AS; and
a tree build unit (TBU) configured to build the dynamic AS by performing spatial partitioning on the primitive data for dynamic scenes delivered from the PDS area; and
wherein the building of the dynamic AS is performed by the TBU of each of the plurality of ray tracing cores independently for the assigned frame when the primitive data for dynamic scenes is changed.
Chen teaches:
a primitive static scene (PSS) area configured to store primitive data for static scenes (Chen (CN 101819684 A): all the static geometry primitive object (A006) is stored in a static primitive list (A008) [0011]),
a primitive dynamic scene (PDS) area configured to store primitive data for dynamic scenes (Chen (CN 101819684 A): all dynamic geometric objects (A007) stored in a dynamic geometric object list [0011]), and
an AS areas, configured to store a static AS (Chen: the non-leaf node (A001) comprises a static primitive bounding box variable (101) (variable name is staticAABB) [0006]) in case of a static scene and a dynamic AS (Chen: dynamic primitive bounding box variable (102) (variable name is dynamicAABB) [0006]) in case of a dynamic scene;
a local memory configured to store the static AS and the dynamic AS delivered from the system memory (see Note 1C), and
the acceleration structure including the static AS and the dynamic AS (see Note 1D); and
Note 1C: When Chen is combined with the teachings of Doyle and Bakalash, it would be obvious to one of ordinary skill in the art to store the static acceleration structure and dynamic acceleration structure in a local memory.
Note 1D: Chen teaches AABB bounding box variables for static and dynamic objects. AABB bounding boxes are a type of acceleration structure well known in the art, and therefore, it would be obvious to one of ordinary skill in the art to construct an acceleration structure comprising the static and dynamic AABB bounding boxes.
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Chen (CN 101819684 A) with Doyle in view of Bakalash. Including a primitive static scene (PSS) area storing PSSs, a primitive dynamic scene (PDS) area storing PDSs, and AS areas, each of which stores a static acceleration structure and dynamic acceleration structures, as in Chen (CN 101819684 A), would benefit the Doyle in view of Bakalash teachings by enabling the ray-tracing software to use the optimal acceleration structure depending on whether the mesh is static or animated, thereby improving the performance of the ray-tracing software.
Doyle in view of Bakalash and Chen still fails to teach:
an AS area, configured to store a static AS generated through a single tree build in case of a static scene and a dynamic AS generated as a tree build is performed for primitive information changes in case of a dynamic scene
a tree build unit (TBU) configured to build the dynamic AS by performing spatial partitioning on the primitive data for dynamic scenes delivered from the PDS area; and
wherein the building of the dynamic AS is performed by the TBU of each of the plurality of ray tracing cores independently for the assigned frame when the primitive data for dynamic scenes is changed.
Zhang teaches:
an AS area, configured to store a static AS generated through a single tree build (Zhang: constructing the static KD-tree corresponding to the static data […] not changing the static part (Abstract)) in case of a static scene and a dynamic AS generated as a tree build is performed for primitive information changes (Zhang: constructing […] the dynamic KD-tree corresponding to the dynamic data […] updating the acceleration structure of the dynamic part by using the coordinate change method (Abstract)) in case of a dynamic scene.
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Zhang with Doyle in view of Bakalash and Chen. Generating a static AS through a single tree build and generating a dynamic AS for primitive information changes, as in Zhang, would benefit the Doyle in view of Bakalash and Chen teachings by preventing unnecessary updates to static elements of the scene that do not require updating.
Doyle in view of Bakalash, Chen, and Zhang still fails to teach:
a tree build unit (TBU) configured to build the dynamic AS by performing spatial partitioning on the primitive data for dynamic scenes delivered from the PDS area; and
wherein the building of the dynamic AS is performed by the TBU of each of the plurality of ray tracing cores independently for the assigned frame when the primitive data for dynamic scenes is changed.
Yoon teaches:
a tree build unit (TBU) configured to build the dynamic AS by performing spatial partitioning (Yoon: the tree build unit may build the spatial partitioning structure [0007]) on the primitive data for dynamic scenes delivered from the PDS area (Yoon: an acceleration structure of the spatial partitioning structure built according to a corresponding static scene and/or dynamic scene built in the tree build unit [0008]; see Note 1E); and
wherein the building of the dynamic AS is performed by the TBU of each of the plurality of ray tracing cores independently (Yoon: A ray tracing core comprises […] a tree build unit (TBU), Abstract; see Note 1F) for the assigned frame.
Note 1E: Yoon teaches: “The system memory 220 may store graphic data information necessary for the three-dimensional application and may include a primitive static scene (PSS) area 221 to store a PSS, a primitive dynamic scene (PDS) area 222 to store a PDS,” [0041]. In [0008] cited above, Yoon teaches that the acceleration structure is built by the TBU based on a dynamic scene. When the teachings of Yoon are combined with Doyle in view of Bakalash, Chen, and Zhang, it would be obvious to one of ordinary skill in the art for the primitive data for dynamic scenes to be included in the PDS area and furthermore use data from the PDS area to build the dynamic acceleration structure.
Note 1F: Yoon teaches that a ray tracing core comprises “a tree build unit”. The Examiner submits that one of ordinary skill in the art would understand Yoon to teach that one core may contain one tree build unit, because Yoon does not expressly define “a” to include plurals. Therefore, when the teachings of Yoon are combined with Doyle in view of Bakalash, Chen, and Zhang, it would be obvious for the building of the dynamic AS to be performed by the TBU of each of the plurality of ray tracing cores independently.
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Yoon with Doyle in view of Bakalash, Chen, and Zhang. Including a tree build unit (TBU) configured to build the dynamic AS by performing spatial partitioning for each ray tracing core, as in Yoon, would benefit the Doyle in view of Bakalash, Chen and Zhang teachings by enabling multiple cores to be utilized to increase ray tracing performance.
Doyle in view of Bakalash, Chen, Zhang, and Yoon still fails to teach:
wherein the building of the dynamic AS is performed by the TBU of each of the plurality of ray tracing cores independently for the assigned frame when the primitive data for dynamic scenes is changed.
Mejdrich teaches:
wherein the building of the dynamic AS is performed for the assigned frame (Mejdrich: Where the old ADS 120 is to be kept at block 218, the system 10 may essentially skip construction of a new ADS for the new frame(s). While this may be accomplished on a frame-by-frame basis, the system 10 may alternatively skip a preset number of frames, e.g., every nth frame. [0089]) when the primitive data for dynamic scenes is changed (see Note 1G).
Note 1G: Mejdrich teaches: “Embodiments of the present invention may determine when to partition using change determination information relating to a change in viewpoint over multiple frames. One criterion for determining when to partition a bounding volume into smaller volumes may be the number of primitives contained within the bounding volume” and that “The determination to partition, or divide, a larger bounding volume into two smaller bounding volumes may be made by the image processing system 10 using the ADS construction algorithm 45.” [0071]. In other words, based on the number of primitives in a scene area changing, the acceleration data structure may be reconstructed: “That is, as long as a bounding volume contains more primitives than a predetermined leaf node threshold, the ADS construction algorithm 45 may continue to divide volumes by drawing more splitting planes” [0072].
The closest support found in the specification of the present application for building of an AS when primitive data changes is the quotation “AS may be generated as a tree build is performed for each frame since primitive information changes for each frame in the case of a dynamic scene” (Pg. 11). Because the specification does not expressly define “primitive data”, the Examiner interpreted a number of primitives as described in Mejdrich as primitive data.
Mejdrich also teaches that: “Some examples of different spatial index ADS' include octrees, kd-trees, and binary space partitioning trees (BSP trees)” [0069]. The Examiner submits that it would be obvious to perform the method taught by Mejdrich on a tree build unit, as Mejdrich teaches building and re-building tree acceleration structures.
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Mejdrich with Doyle in view of Bakalash, Chen, Zhang, and Yoon. Building an AS for the assigned frame when the primitive data for dynamic scenes is changed, as in Mejdrich, would benefit the Doyle in view of Bakalash, Chen, Zhang, and Yoon teachings by intelligently updating the ADS on certain frames when the system has computing resources to spare: “algorithms used to build the ADS may experience slow setup of an ADS, as well as require relatively large amounts of processing and memory. These computing resources are thus unavailable to other aspects of a scene rendering processes. In some cases, more time may be spent building a tree than rendering the image. There are consequently diminishing returns for intelligently building an ADS. Such challenges are exacerbated where a system must handle a series of frames to create a scene. Besides the change in objects of the image data, the perspective of the viewer relative to the object may change from frame-to-frame. Such may be the case where a camera pans or moves across a scene of objects. Such changes conventionally require rapid reconstitution of the ADS, which can burden the system” (Mejdrich, [0008]).
Regarding claim 3:
Doyle in view of Bakalash, Chen, Zhang, Yoon, and Mejdrich teaches:
The device of claim 1 (as shown above), wherein each of the plurality of ray tracing cores (Doyle: ray tracing cores 245 [0076]; processors 102 [0050]) includes:
a bus interface unit (Doyle: interface bus(es) 110 [0050]) processing data transmission and reception (Doyle: to transmit communication signals [0050]),
wherein the local memory (Doyle: The graphics sub-cores 221A-221F include […] shared local memory (SLM) 228A-228F [0074]) temporarily stores the geometry data and the AS for the ray tracing (Doyle: texture or other 3D graphics related data [0074]).
Claims 4, 5, and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Doyle (US 20200320776 A1) in view of Bakalash (US 20090027402 A1), Chen (CN 101819684 A), Zhang (CN 102184517 A), Yoon (US 20140347355 A1), and Mejdrich (US 20100188396 A1) and Luo (CN 111737015 A).
Regarding claim 4:
Doyle in view of Bakalash, Chen, Zhang, Yoon, and Mejdrich teaches:
The device of claim 1 (as shown above), further including a frame unit outputting frames received from the plurality of ray tracing cores (Doyle: the system agent core 210 also includes a display controller 211 to drive graphics processor output to one or more coupled displays [0062])
Doyle in view of Bakalash, Chen, Zhang, Yoon, and Mejdrich fails to teach:
further including a frame unit arranging and outputting frames received from the plurality of ray tracing cores in a predetermined order.
Luo teaches:
further including a frame unit arranging (Luo: each element of the queue is inserted into the queue according to the time line frame number Pg. 5, par. 5) and outputting (Luo: the data after finishing the plurality of GPU rendering is sent to the display to display, Pg. 5, par. 2) frames received from the plurality of ray tracing cores (Luo: a plurality of GPU binding the same display window, Pg. 5, par. 7) in a predetermined order (Luo: orderly alternately sending to a plurality of GPU for video rendering according to the time line frame number order, Pg. 5, par. 2).
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Luo with Doyle in view of Bakalash, Chen, Zhang, Yoon, and Mejdrich. Including a frame unit arranging and outputting frames received from the plurality of ray tracing cores in a predetermined order, as in Luo, would benefit the Doyle in view of Bakalash, Chen, Zhang, Yoon, and Mejdrich teachings by ensuring that the output from the plurality of ray tracing cores is presented in the right order.
Regarding claim 5:
Doyle in view of Bakalash, Chen, Zhang, Yoon, Mejdrich, and Luo teaches:
The device of claim 4 (as shown above), wherein the frame unit includes a plurality of frame buffers (Luo: each element […] comprising […] GPU memory address pointer (storing the rendered frame data), Pg. 5, par. 5) assigned to each of the plurality of ray tracing cores (Bakalash: The Decomposition Module aligns a queue of GPPLs 6130, appoints the next frame to the next available GPPL 6131, and monitors the stream of commands and data to all GPPLs 6132 [0384]; Luo: GPU number, Pg. 5, par. 5) and storing the frames in the order in which the frames are processed (Luo: orderly alternately sending to a plurality of GPU for video rendering according to the time line frame number order, Pg. 5, par. 2); and a frame queue (Luo: frame queue, Pg. 5, par. 5) storing frames received from the plurality of frame buffers according to frame numbers regardless of the processing order (Luo: each element of the queue is inserted into the queue according to the time line frame number, Pg. 5, par. 5).
Regarding claim 7:
Doyle in view of Bakalash, Chen, Zhang, Yoon, Mejdrich, and Luo teaches:
The device of claim 5, wherein the frame unit stores a specific frame stored in the frame buffer into the frame queue by mapping the corresponding frame number to a queue index (Luo: each element of the queue is inserted into the queue according to the frame number of the time line, Pg. 5, par. 5; see Note 7A).
Note 7A: Because Luo is mapping to a frame queue “according to the time line frame number”, the queue index is implied, as any element inserted in the queue would have a respective position or “index” in said queue.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Doyle (US 20200320776 A1) in view of Bakalash (US 20090027402 A1), Luo (CN 111737015 A), Chen (CN 101819684 A), Zhang (CN 102184517 A), Yoon (US 20140347355 A1), and Mejdrich (US 20100188396 A1), and cppreference.com (NPL: Struct declaration).
Doyle in view of Bakalash, Chen, Zhang, Yoon, Mejdrich, and Luo teaches:
The device of claim 5 (as shown above), wherein each of the plurality of frame buffers has the same size, and the size of the frame queue is determined according to the number and size of frame buffers (Luo: each element recorded is a structure, comprising a time line frame number, GPU number and GPU memory address pointer (storing the rendered frame data), Pg. 5, par. 5; see Note 6A).
Note 6A: It is well known in the art that size of a frame buffer is dependent on the color depth of the pixel data it contains and the resolution (width, height) of the image the data encodes. In the Time Division mode described by Bakalash, each GPU handles a “full, alternating image frame” [0034]. A person of ordinary skill in the art would want to avoid providing each GPU pixel data with differing resolutions and color depth, because Bakalash teaches that the Time Division mode utilizes a “non-compositing option which involves moving the incoming Frame Buffer to the display” [0258]. Because obvious visual glitches would occur if they did not, one of ordinary skill in the art would maintain the color depth and resolution of the image in the frame buffer, meaning that each GPU would operate on a frame buffer of the same size. Therefore, Doyle in view of Bakalash and Luo teaches the limitation “each of the plurality of frame buffers has the same size”.
Luo utilizes Direct X, which is implemented in C++. The size of a structure in C++ is determined by the size and number of the data elements it contains (with occasional padding) (cppreference.com, The size of a struct is at least as large as the sum of the sizes of its members, Pg. 1, par. 2). Therefore, Doyle in view of Bakalash and Luo teaches the limitation “the size of the frame queue is determined according to the number and size of frame buffers”.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Doyle (US 20200320776 A1) in view of Bakalash (US 20090027402 A1), Luo (CN 111737015 A), Chen (CN 101819684 A), Zhang (CN 102184517 A), Yoon (US 20140347355 A1), and Mejdrich (US 20100188396 A1), and Braghetto (NPL: a-simple-triangle / Part 24 - Vulkan render loop).
Doyle in view of Bakalash, Luo, Chen, Zhang, Yoon, and Mejdrich teaches:
The device of claim 7 (as shown above),
Doyle in view of Bakalash, Luo, Chen, Zhang, Yoon, and Mejdrich fails to teach:
wherein the frame unit operates by reading a current draw number; comparing the draw number with frame numbers of frames stored in the frame queue; if the draw number is equal to the frame number, outputting the corresponding frame; increasing the draw number by 1 when the outputting is successful; and repeating the above process until the frame queue becomes empty.
Braghetto teaches:
wherein the frame unit operates by reading a current draw number (Braghetto: calculate which swapchain image index we should be using as a frame index, Pg. 2, par. 2); comparing the draw number with frame numbers of frames stored in the frame queue; if the draw number is equal to the frame number (Braghetto: for the current frame index, Pg. 2, par. 2), outputting the corresponding frame (Braghetto: issue another submit object with the swapchain to the presentation queue, Pg. 2, par. 2); increasing the draw number by 1 (Braghetto: increment the current frame index, Pg. 2, par. 2) when the outputting is successful (Braghetto: wait for the presentation submission to be completed, Pg. 2, par. 2); and repeating the above process until the frame queue becomes empty (Braghetto: the loop, Pg. 2, par. 2).
Note 8A: Braghetto teaches outputting the corresponding frame when the draw number is equal to the frame number. Comparison of the draw number with frame numbers of frames stored in the frame queue is inherent to the outputting described by Braghetto. Therefore, Braghetto teaches the limitation “comparing the draw number with frame numbers of frames stored in the frame queue”. Additionally, the process described by Braghetto requires that there be content in the frame queue to output, and therefore, the process can only be repeated if the frame queue is not empty. Thus, Braghetto teaches the limitation “repeating the above process until the frame queue becomes empty”.
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Braghetto with Doyle in view of Bakalash Luo, Chen, Zhang, Yoon, and Mejdrich. Reading a current draw number; comparing the draw number with frame numbers of frames stored in the frame queue; if the draw number is equal to the frame number, outputting the corresponding frame; increasing the draw number by 1 when the outputting is successful; and repeating the above process until the frame queue becomes empty, as in Braghetto, would benefit the Doyle in view of Bakalash, Luo, Chen, Zhang, Yoon, and Mejdrich teachings by ensuring that every output produced by the ray tracing cores is output, and that they are output in a specific order.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Doyle (US 20200320776 A1) in view of Bakalash (US 20090027402 A1), and Luo (CN 111737015 A), Chen (CN 101819684 A), Zhang (CN 102184517 A), Yoon (US 20140347355 A1), and Mejdrich (US 20100188396 A1).
Doyle teaches:
A multi-chip (Doyle: graphics processing resources arranged into multi-core groups 240A-240N [0075]) based ray tracing (ray tracer 505 [0133]) method, the method comprising:
determining a total number of a plurality of ray tracing cores (Doyle: graphics core array 414 is scalable, such that the array includes a variable number of graphics cores [0119]) for performing ray tracing on a plurality of frames constituting a specific scene (Doyle: accelerate ray tracing operations for both real-time ray tracing and non-real-time ray tracing implementations [0084]), wherein each of the plurality of ray tracing cores includes:
a local memory configured to store data from the system memory (Doyle: For example, two or more of the nodes may share a common memory or the local memories of the nodes may already have stored data from prior ray tracing operations [0254]; see Note 1A) and
a ray tracing unit configured to perform independent ray tracing (Doyle: accelerate ray tracing operations for both real-time ray tracing and non-real-time ray tracing implementations [0084]) based on the geometry data of the system memory (Doyle: graphics data and/or instructions [0077]) and an acceleration structure (Doyle: BVH traversal [0086]);
transmitting the geometry data of the system memory (Doyle: vertex and geometry data for the 3D pipeline 312) to each of the plurality of ray tracing cores; and outputting frames (Doyle: drive graphics processor output to one or more coupled displays [0062]).
Doyle fails to teach:
a local memory configured to store a static acceleration structure (AS) generated through a single tree build in case of a static scene and a dynamic AS generated as a tree build is performed for primitive information changes in case of a dynamic scene delivered from a system memory, and
a ray tracing unit configured to perform independent ray tracing for an assigned frame based on geometry data of the system memory and an acceleration structure including the static AS and dynamic AS; and
a tree build unit (TBU) configured to build the dynamic AS by performing spatial partitioning on the primitive data for dynamic scenes delivered from the PDS area; and
wherein the system memory includes:
a primitive static scene (PSS) area configured to store primitive data for static scenes,
a primitive dynamic scene (PDS) area configured to store primitive data for dynamic scenes, and
AS areas, configured to store the static AS and the dynamic AS;
assigning the plurality of frames to each of the plurality of ray tracing cores by partitioning the plurality of frames in frame units;
determining whether ray tracing is completed in units of frames for each of the plurality of ray tracing cores; when a specific ray tracing core completes ray tracing,
storing the corresponding frame in the corresponding frame buffer;
storing the corresponding frame in a frame queue; and
outputting frames of the frame queue sequentially,
wherein the building of the dynamic AS is performed by the TBU of each of the plurality of ray tracing cores independently for the assigned frame when the primitive data for dynamic scenes is changed.
Bakalash teaches:
a ray tracing unit configured to perform independent ray tracing for an assigned frame (Bakalash: each graphics pipeline (and its individual rendering node or GPU) handles the processing of a full, alternating image frame [0034]; see Note 1B) based on the geometry data (Bakalash: graphics display list data [0034]); and
assigning the plurality of frames to each of the plurality of ray tracing cores by partitioning the plurality of frames in frame units (Bakalash: The Decomposition Module aligns a queue of GPPLs 6130, appoints the next frame to the next available GPPL 6131, and monitors the stream of commands and data to all GPPLs 6132 [0384]; Bakalash: each graphics pipeline (and its individual rendering node or GPU) handles the processing of a full, alternating image frame [0034]);
transmitting geometry data of a system memory to each of the plurality of ray tracing cores (Bakalash: Rendering distributes all display list graphics data and commands associated with a first scene to the first graphics pipeline, and all graphics display list data and commands associated with a second/subsequent scene to the second graphics pipeline [0034]);
determining whether ray tracing is completed in units of frames for each of the plurality of ray tracing cores (Bakalash: parallel rendering methods have been applied to PC-based dual GPU graphics systems of the kind illustrated in FIGS. 2A through 2C [0021]; see Fig. 2C).
when a specific ray tracing core completes ray tracing, storing the corresponding frame in the corresponding frame buffer (Bakalash: The composed set of pixel data is stored within a 2D frame buffer [0007]); and
outputting frames (Bakalash: transmitted to and displayed on the surface of a display screen [0007]).
Bakalash teaches that the frames stored in the frame buffer are “composed” [0007]. A composed image as described by Bakalash is composed of “multiple sets of pixel data generated by each graphics pipeline” [0027]. In the Time Division mode described by Bakalash, “each graphics pipeline (and its individual rendering node or GPU) handles the processing of a full, alternating image frame [0034]”, and therefore in order for a frame to have been composed, the GPU must have finished generating pixel data to output. Therefore, when the device taught by Bakalash is used for ray tracing [0006], composing a frame requires that ray tracing is completed.
Because determining the frame has been composed is analogous to determining that a frame has finished ray tracing, before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Bakalash with Doyle. Assigning the plurality of frames to each of the plurality of ray tracing cores by partitioning the plurality of frames in frame units; transmitting geometry data of a system memory to each of the plurality of ray tracing cores; when a specific ray tracing core completes ray tracing, storing the corresponding frame in the corresponding frame buffer; and outputting frames, as in Bakalash, would benefit the Doyle teachings by ensuring the GPU has access to the resources necessary to execute ray tracing, while also ensuring the work is spread among the plurality of GPUs efficiently.
Doyle in view of Bakalash still fails to explicitly teach:
a local memory configured to store a static acceleration structure (AS) generated through a single tree build in case of a static scene and a dynamic AS generated as a tree build is performed for primitive information changes in case of a dynamic scene delivered from a system memory, and
a ray tracing unit configured to perform independent ray tracing for an assigned frame based on geometry data of the system memory and an acceleration structure including the static AS and dynamic AS;
a tree build unit (TBU) configured to build the dynamic AS by performing spatial partitioning on the primitive data for dynamic scenes delivered from the PDS area; and
wherein the system memory includes:
a primitive static scene (PSS) area configured to store primitive data for static scenes,
a primitive dynamic scene (PDS) area configured to store primitive data for dynamic scenes, and
AS areas, configured to store the static AS and the dynamic AS;
storing the corresponding frame in a frame queue; and
outputting frames of the frame queue sequentially,
wherein the building of the dynamic AS is performed by the TBU of each of the plurality of ray tracing cores independently for the assigned frame when the primitive data for dynamic scenes is changed.
Luo teaches:
assigning the plurality of frames to each of the plurality of ray tracing cores (Luo: judging the frame on which GPU, Pg. 4, par. 9); when a specific core completes, storing the corresponding frame in the corresponding frame buffer (Luo: each element […] comprising […] GPU memory address pointer (storing the rendered frame data), Pg. 5, par. 5);
storing the corresponding frame in a frame queue (Luo: frame queue, Pg. 5, par. 5); and
outputting frames of the frame queue sequentially (Luo: in order fetch frame in the queue, calling the Present interface function of the DirectX, automatically realizing the frame data drawn out in the display window by the DirectX, Pg. 5, par. 7).
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Luo with Doyle in view of Bakalash. Assigning the plurality of frames to each of the plurality of ray tracing cores; when a specific core completes, storing the corresponding frame in the corresponding frame buffer; and storing the corresponding frame in a frame queue, as in Luo, would benefit the Doyle in view of Bakalash teachings by enabling the software to queue frames before they need to actually be rendered on the display, allowing the GPU continue work that has been given to it by a CPU or any other processor, instead of idling.
Doyle in view of Bakalash and Luo still fails to explicitly teach:
a local memory configured to store a static acceleration structure (AS) generated through a single tree build in case of a static scene and a dynamic AS generated as a tree build is performed for primitive information changes in case of a dynamic scene delivered from a system memory, and
a ray tracing unit configured to perform independent ray tracing for an assigned frame based on geometry data of the system memory and an acceleration structure including the static AS and dynamic AS;
a tree build unit (TBU) configured to build the dynamic AS by performing spatial partitioning on the primitive data for dynamic scenes delivered from the PDS area; and
wherein the system memory includes:
a primitive static scene (PSS) area configured to store primitive data for static scenes,
a primitive dynamic scene (PDS) area configured to store primitive data for dynamic scenes, and
AS areas, configured to store the static AS and the dynamic AS;
wherein the building of the dynamic AS is performed by the TBU of each of the plurality of ray tracing cores independently for the assigned frame when the primitive data for dynamic scenes is changed.
Chen teaches:
a primitive static scene (PSS) area configured to store primitive data for static scenes (Chen (CN 101819684 A): all the static geometry primitive object (A006) is stored in a static primitive list (A008) [0011]),
a primitive dynamic scene (PDS) area configured to store primitive data for dynamic scenes (Chen (CN 101819684 A): all dynamic geometric objects (A007) stored in a dynamic geometric object list [0011]), and
an AS area, configured to store a static AS (Chen: the non-leaf node (A001) comprises a static primitive bounding box variable (101) (variable name is staticAABB) [0006]) in case of a static scene and a dynamic AS (Chen: dynamic primitive bounding box variable (102) (variable name is dynamicAABB) [0006]) in case of a dynamic scene;
a local memory configured to store the static AS and the dynamic AS delivered from the system memory (see Note 1C), and
the acceleration structure including the static AS and the dynamic AS (see Note 1D); and
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Chen with Doyle in view of Bakalash. Including a primitive static scene (PSS) area storing PSSs, a primitive dynamic scene (PDS) area storing PDSs, and AS areas, each of which stores a static acceleration structure and dynamic acceleration structures, as in Chen (CN 101819684 A), would benefit the Doyle in view of Bakalash teachings by enabling the ray-tracing software to use the optimal acceleration structure depending on whether the mesh is static or animated, thereby improving the performance of the ray-tracing software.
Doyle in view of Bakalash, Luo, and Chen still fails to explicitly teach:
a local memory configured to store a static acceleration structure (AS) generated through a single tree build in case of a static scene and a dynamic AS generated as a tree build is performed for primitive information changes in case of a dynamic scene delivered from a system memory, and
a tree build unit (TBU) configured to build the dynamic AS by performing spatial partitioning on the primitive data for dynamic scenes delivered from the PDS area;
wherein the building of the dynamic AS is performed by the TBU of each of the plurality of ray tracing cores independently for the assigned frame when the primitive data for dynamic scenes is changed.
Zhang teaches:
AS areas configured to store a static AS generated through a single tree build (Zhang: constructing the static KD-tree corresponding to the static data […] not changing the static part (Abstract)) in case of a static scene and a dynamic AS generated as a tree build is performed for primitive information changes (Zhang: constructing […] the dynamic KD-tree corresponding to the dynamic data […] updating the acceleration structure of the dynamic part by using the coordinate change method (Abstract)) in case of a dynamic scene
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Zhang with Doyle in view of Bakalash, Luo, and Chen. Generating a static AS through a single tree build and generating a dynamic AS for primitive information changes, as in Zhang, would benefit the Doyle in view of Bakalash and Chen teachings by preventing unnecessary updates to static elements of the scene that do not require updating.
Doyle in view of Bakalash, Luo, Chen, and Zhang still fails to teach:
a tree build unit (TBU) configured to build the dynamic AS by performing spatial partitioning on the primitive data for dynamic scenes delivered from the PDS area; and
wherein the building of the dynamic AS is performed by the TBU of each of the plurality of ray tracing cores independently for the assigned frame when the primitive data for dynamic scenes is changed.
Yoon teaches:
a tree build unit (TBU) configured to build the dynamic AS by performing spatial partitioning (Yoon: the tree build unit may build the spatial partitioning structure [0007]) on the primitive data for dynamic scenes delivered from the PDS area (Yoon: an acceleration structure of the spatial partitioning structure built according to a corresponding static scene and/or dynamic scene built in the tree build unit [0008]; see Note 1E); and
wherein the building of the dynamic AS is performed by the TBU of each of the plurality of ray tracing cores independently (Yoon: A ray tracing core comprises […] a tree build unit (TBU), Abstract; see Note 1F) for the assigned frame.
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Yoon with Doyle in view of Bakalash, Luo, Chen, and Zhang. Including a tree build unit (TBU) configured to build the dynamic AS by performing spatial partitioning for each ray tracing core, as in Yoon, would benefit the Doyle in view of Bakalash, Luo, Chen and Zhang teachings by enabling multiple cores to be utilized to increase ray tracing performance.
Doyle in view of Bakalash, Luo, Chen, Zhang, and Yoon still fails to teach:
wherein the building of the dynamic AS is performed by the TBU of each of the plurality of ray tracing cores independently for the assigned frame when the primitive data for dynamic scenes is changed.
Mejdrich teaches:
wherein the building of the dynamic AS is performed for the assigned frame (Mejdrich: Where the old ADS 120 is to be kept at block 218, the system 10 may essentially skip construction of a new ADS for the new frame(s). While this may be accomplished on a frame-by-frame basis, the system 10 may alternatively skip a preset number of frames, e.g., every nth frame. [0089]) when the primitive data for dynamic scenes is changed (see Note 1G).
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Mejdrich with Doyle in view of Bakalash, Luo, Chen, Zhang, and Yoon. Building an AS for the assigned frame when the primitive data for dynamic scenes is changed, as in Mejdrich, would benefit the Doyle in view of Bakalash, Luo, Chen, Zhang, and Yoon teachings by intelligently updating the ADS on certain frames when the system has computing resources to spare: “algorithms used to build the ADS may experience slow setup of an ADS, as well as require relatively large amounts of processing and memory. These computing resources are thus unavailable to other aspects of a scene rendering processes. In some cases, more time may be spent building a tree than rendering the image. There are consequently diminishing returns for intelligently building an ADS. Such challenges are exacerbated where a system must handle a series of frames to create a scene. Besides the change in objects of the image data, the perspective of the viewer relative to the object may change from frame-to-frame. Such may be the case where a camera pans or moves across a scene of objects. Such changes conventionally require rapid reconstitution of the ADS, which can burden the system” (Mejdrich, [0008]).
Claims 10, 11 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over in view of Doyle (US 20200320776 A1) in view of Bakalash (US 20090027402 A1), Luo (CN 111737015 A), Chen (CN 101819684 A), Zhang (CN 102184517 A), Yoon (US 20140347355 A1), and Mejdrich (US 20100188396 A1), and Braghetto (NPL: a-simple-triangle / Part 24 - Vulkan render loop).
Regarding claim 10:
Doyle in view of Bakalash, Luo, Chen, Zhang, Yoon, and Mejdrich teaches:
The method of claim 9 (as shown above),
Doyle in view of Bakalash, Luo, Chen, Zhang, Yoon, and Mejdrich fails to teach:
wherein the determining of the total number of the plurality of ray tracing cores includes initializing a draw number, and the outputting includes outputting a frame having the same frame number as a current draw number from the frame queue.
Braghetto teaches:
wherein the determining of the total number of the plurality of ray tracing cores includes initializing a draw number (Braghetto: We don’t yet have a currentFrameIndex property so we should add that first as a member field, initialising it to 0, Pg. 20, par. 3), and the outputting includes outputting a frame having the same frame number as a current draw number (Braghetto: for the current frame index, issue another submit object with the swapchain to the presentation queue, Pg. 2, par. 2) from the frame queue (Braghetto: swapchain, Pg. 2, par. 2).
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Braghetto with Doyle in view of Bakalash, Luo, Chen, Zhang, Yoon, and Mejdrich. Having the determining of the total number of the plurality of ray tracing cores include initializing a draw number, and the outputting include outputting a frame having the same frame number as a current draw number from the frame queue, as in Braghetto, would benefit the Doyle in view of Bakalash, Chen, Zhang, Yoon, and Mejdrich teachings by ensuring that the correct frame is output and that it is retrieved quickly.
Regarding claim 11:
Doyle in view of Bakalash, Luo, Chen, Zhang, Yoon, Mejdrich, and Braghetto teaches:
The method of claim 10 (as shown above), wherein the outputting includes increasing the current draw number by 1 (Braghetto: increment the current frame index) when the outputting is successful (Braghetto: wait for the presentation submission to be completed).
Regarding claim 12:
Doyle in view of Bakalash, Luo, Chen, Zhang, Yoon, Mejdrich teaches:
The method of claim 9 (as shown above), wherein the assigning of the plurality of frames into each of the plurality of ray tracing cores includes assigning a frame number to an assigned frame (Luo: the structure body comprises a time line frame number, Pg. 5, par. 5), wherein the frame number is set for each ray tracing core (Luo: the frame decoded by the CPU alternately uplinks to a plurality of GPUs according to the frame number, Pg. 2, par. 10) and set at an interval equal to the total number of frames (Bakalash: Each GPU is give extra time of N time frames (for N parallel GPUs) to process a frame [0034])
Bakalash teaches: “Each GPU is give [sic] extra time of N time frames (for N parallel GPUs) to process a frame” [0034]. Each GPU processes one frame, so the total number of frames is equivalent to the number of parallel GPUs. Therefore because processing within each GPU will occur every N time frames, the frame number will be set at an interval equal to the total number of frames, and therefore Doyle in view of Bakalash, Luo, Chen, Zhang, Yoon, and Mejdrich teaches the limitation: “wherein the frame number is set for each ray tracing core and set at an interval equal to the total number of frames”.
Doyle in view of Bakalash, Luo, Chen, Zhang, Yoon, and Mejdrich fails to teach:
wherein the frame number is set for each ray tracing core and set at an interval equal to the total number of frames with respect to a previous frame number.
Braghetto teaches:
wherein the frame number is set with respect to a previous frame number (Braghetto: Before leaving the renderEnd function we will increment our current render frame index, setting it back to 0 if it exceeds our maximum number of render frames, Pg. 31, par. 1).
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Braghetto with Doyle in view of Bakalash, Luo, Chen, Zhang, Yoon, and Mejdrich. Having the frame number be set with respect to a previous frame number, as in Braghetto, would benefit the Doyle in view of Bakalash, Luo, Chen, Zhang, Yoon, and Mejdrich teachings by ensuring that the GPU can access different frames when using the frame number to retrieve frames from the frame queue.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over in view of Doyle (US 20200320776 A1) in view of Bakalash (US 20090027402 A1), Luo (CN 111737015 A), Chen (CN 101819684 A), Zhang (CN 102184517 A), Yoon (US 20140347355 A1), and Mejdrich (US 20100188396 A1), Braghetto (NPL: a-simple-triangle / Part 24 - Vulkan render) and Uno (US 20200250792 A1).
Doyle in view of Bakalash, Luo, Chen, Zhang, Yoon, Mejdrich, and Braghetto teaches:
The method of claim 12 (as shown above),
Doyle in view of Bakalash, Luo, Chen, Zhang, Yoon, Mejdrich, and Braghetto fails to explicitly teach:
wherein, when the frame number is larger than the total number of the plurality of frames, rendering of the specific scene is terminated.
Uno teaches:
wherein, when the frame number is larger than the total number of the plurality of frames, rendering of the specific scene is terminated (Uno: the frame number indicated by the playback end position icon 242 is represented by FEND [0045]; If it is determined that the variable F is less than or equal to FEND, the CPU 110 returns the process to step S801, and if not, the CPU 110 ends the playback process. [0085]).
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Uno with Doyle in view of Bakalash, Luo, Chen, Zhang, Yoon, Mejdrich and Braghetto. When the frame number is larger than the total number of the plurality of frames, rendering of the specific scene is terminated, as in Uno, would benefit the Doyle in view of Bakalash, Luo, Chen, Zhang, Yoon, Mejdrich and Braghetto teachings by ensuring that only valid frames are rendered.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINCENT ALEXANDER PROVIDENCE whose telephone number is (571)270-5765. The examiner can normally be reached Monday-Thursday 8:30-5:00.
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, King Poon can be reached on (571)270-0728. 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.
/VINCENT ALEXANDER PROVIDENCE/Examiner, Art Unit 2617 /KING Y POON/Supervisory Patent Examiner, Art Unit 2617
Prosecution Insights