Light buffer supporting light transformation for ray tracing

Abstract

The invention relates to a ray buffer supporting ray transformation for ray tracing. Techniques related to caching data for ray tracing in a graphics processor are disclosed. The ray intersection accelerator circuitry includes traversal circuitry configured to perform an intersection test between a ray and a surrounding area of an acceleration data structure; and transformation circuitry configured to transform a first coordinate of a ray from a first coordinate space in response to reaching a transformation node in the acceleration data structure to generate a second coordinate of the ray in a second coordinate space. The ray cache circuitry is configured to cache data accessible by the ray intersection accelerator circuitry, where entries of the ray cache circuitry are configured to cache data of rays, the data includes a first coordinate of the ray in a first coordinate space, a second coordinate of the ray in a second coordinate space, and shared data of the ray suitable for both the first coordinate and the second coordinate.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This patent application claims priority to U.S. Provisional Patent Application No. 63 / 583,928, filed on September 20, 2023, entitled “Ray Cache with Ray Transform Support for Ray Tracing,” which is incorporated herein by reference in its entirety. Technical Field

[0002] The present disclosure relates generally to computer graphics processors, and more particularly to ray tracing. Background Art

[0003] In computer graphics, ray tracing is a rendering technique for generating images by tracing the path of light as pixels in an image plane and simulating the effects of its encounters with virtual objects. Ray tracing allows for resolution of visibility in three dimensions between any two points in the scene, which is also where most of its computational cost comes from. A typical ray tracer samples the path of light through a scene in the opposite direction of light propagation, starting from the camera and propagating into the scene, rather than starting from the light source (this is sometimes called "backward ray tracing"). Starting from the camera has the beneficial effect of tracing only rays visible to the camera. The system can model a rasterizer, where the ray simply stops at the first surface and a shader (similar to a fragment shader) is called to calculate the color. More common secondary effects (where lighting exchanges between scene elements, such as diffuse reflection and transmission) are also modeled. A shader that evaluates the reflective properties of a surface can call additional intersection queries (e.g., generating new rays) to capture incident lighting from other surfaces. This recursive process has many expressions, but is generally referred to as path tracing.

[0004] Graphics processors (GPUs) that implement ray tracing generally provide more realistic scenes and lighting effects relative to traditional rasterization systems. However, ray tracing is generally computationally expensive. Improvements to ray tracing technology can improve realism in graphical scenes, improve performance (e.g., allowing more rays to be traced per frame, in more complex scenes, or both), reduce power consumption (which can be particularly important in battery-powered devices), etc.

[0005] In a typical ray tracing implementation, the graphics processor traverses the bounding box hierarchy (BVH) acceleration data structure (ADS) to determine which primitives (e.g., triangles) in the scene to test for intersection with a ray. This greatly reduces the number of ray-primitive intersection tests for a given rendering (e.g., relative to testing each ray for each primitive).

[0006] "Instancing" is a common graphics technique in which the parameters of an object or mesh are defined once and then instantiated multiple times in a graphics scene. Rather than including every instance of the object in the ADS for ray tracing, an instanced object may typically have an "instance subtree" (also known as a lower-level BVH reachable from a higher-level BVH) in the ADS. Upon reaching an instance node (the origin of the instance subtree), the GPU may transform the ray from world space to the instance space of the specific instance for further traversal. This may significantly reduce the size of the ADS (relative to duplicating the subtree at different locations in the ADS for different instances), with the tradeoff being that ray transforms may utilize processing resources.

[0007] Different GPUs may utilize different degrees of hardware acceleration for ray tracing tasks. For example, ray intersection acceleration circuitry may be configured to traverse an acceleration data structure by testing for intersection with bounding boxes (e.g., boxes) of a hierarchical arrangement of BVHs to determine a subset of primitives (e.g., triangles) in a graphics scene to be tested for intersection. Ray / triangle intersection testing may also be hardware accelerated. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1A is a diagram illustrating an overview of example graphics processing operations according to some embodiments.

[0009] Figure 1B is a block diagram illustrating an example graphics unit according to some embodiments.

[0010] Figure 2 is a block diagram illustrating an example graphics processor including a ray data buffer configured to cache data for accelerator hardware according to some embodiments.

[0011] Figure 3 is a communication diagram illustrating example messages between a shader processor, traversal circuitry, transformation circuitry, and a ray data buffer according to some embodiments.

[0012] Figure 4 is a diagram illustrating example fields of a ray data buffer entry according to some embodiments.

[0013] Figure 5 is a block diagram illustrating example multi-stage / bypass control circuitry configured to select a transformation procedure according to some embodiments.

[0014] Figure 6 is a block diagram illustrating example components of a ray intersection accelerator according to some embodiments.

[0015] Figure 7is a flow chart illustrating an example method according to some embodiments.

[0016] Figure 8 is a block diagram illustrating an example computing device according to some embodiments.

[0017] Fig. 9 is a diagram illustrating an example application of the presently disclosed systems and devices according to some embodiments.

[0018] Fig.10 is a block diagram illustrating an example computer-readable medium storing circuit design information according to some embodiments. DETAILED DESCRIPTION

[0019] The disclosed embodiments provide a low-level cache for ray data having various features that may be advantageous in the context of hardware acceleration for ADS traversal operations. In some embodiments, a ray intersection accelerator (RIA) circuitry is configured to perform such traversals. Example accelerator circuitry and techniques are discussed in U.S. patent application Ser. No. 17 / 103,433, filed on Nov. 24, 2020 and entitled “Ray Intersect Circuitry with Parallel Ray Testing.” In some embodiments, a GPU including the ray intersection accelerator circuitry also includes transformation acceleration circuitry for one or more ray transformation levels (e.g., when reaching an instance node).

[0020] Note that in implementations where the GPU executes software (e.g., a shader program) to perform ray transformations, the ray data buffer may be read-only from the perspective of the ray intersection accelerator circuitry. For example, the ray intersection accelerator circuitry may read data from the ray data buffer and use the ray data as input to a ray / bounding box intersection test, a ray / primitive intersection test, or both, but may not alter the ray data. Conversely, in an embodiment with a ray transformation accelerator circuitry, the accelerator circuitry may write to the ray data buffer (e.g., to write transformed ray data).

[0021] Thus, in some disclosed embodiments, the low-level ray data buffers are accessible only to the accelerator hardware, and not to the shader core circuitry configured to execute shader programs (although ray data may be shared with shader programs using one or more higher-level shared buffers). This may allow the accelerator hardware to fully own the ray data buffer entries when in use.

[0022] In addition, the low-level ray data buffer may include entries configured to store ray pairs (e.g., both ray data before and after a ray transform operation). Specifically, a given entry may include one or more fields specific to the original coordinate space or the transformed coordinate space and one or more fields shared by the ray before and after the transform. Thus, the ray intersection accelerator circuitry may utilize an appropriate portion of the ray data buffer entry based on the appropriate coordinate space for the current position in the ADS traversal.

[0023] When returning to the original coordinate space, the ray intersection accelerator circuitry may switch back to using the portion of the ray data buffer entries corresponding to that space. The GPU may also support bypassing the ray transform accelerator circuitry, for example to perform the transform using a custom shader. For multi-level instancing, the GPU may alternate between shader ray transforms and accelerated ray transforms.

[0024] Various techniques are disclosed to improve performance, reduce power consumption, etc. for ray tracing workloads with ray transformations.

[0025] Graphics Processing Overview refer to Figure 1A , which shows a flowchart showing an example processing flow 100 for processing graphics data. In some embodiments, the transformation and lighting procedures 110 may involve processing the lighting information of the vertices received from the application based on the defined light source position, reflectivity, etc., assembling the vertices into polygons (e.g., triangles), and transforming the polygons to the correct size and orientation based on the position in three-dimensional space. The clipping procedure 115 may involve discarding polygons or vertices outside the visible area. In some embodiments, geometry processing may utilize object shaders and mesh shaders for flexibility and efficient processing before rasterization. The rasterization procedure 120 may involve defining fragments within each polygon and assigning initial color values ​​to each fragment, for example, based on the texture coordinates of the polygon vertices. Fragments may specify the attributes of the pixels they overlap, but the actual pixel attributes may be determined based on combining multiple fragments (e.g., in a frame buffer), ignoring one or more fragments (e.g., if they are covered by other objects), or both. The shading procedure 130 may involve changing pixel components based on lighting, shadows, bump mapping, translucency, etc. The shading pixels may be assembled in a frame buffer 135. Modern GPUs typically include programmable shaders that allow application developers to customize shading and other processing routines. Thus, in various embodiments, Figure 1A The example elements of the present invention may be performed in various orders, performed in parallel, or omitted. Additional processing procedures may also be implemented.

[0026] Reference now Figure 1B, shows a simplified block diagram of an example graphics unit 150 according to some embodiments. In the illustrated embodiment, graphics unit 150 includes a programmable shader 160, a vertex pipe 185, a fragment pipe 175, a texture processing unit (TPU) 165, an image write buffer 170, and a memory interface 180. In some embodiments, graphics unit 150 is configured to process both vertex data and fragment data using programmable shader 160, which may be configured to process graphics data in parallel using multiple execution pipelines or instances.

[0027] In the illustrated embodiment, vertex pipe 185 may include various fixed-function hardware configured to process vertex data. Vertex pipe 185 may be configured to communicate with programmable shader 160 to coordinate vertex processing. In the illustrated embodiment, vertex pipe 185 is configured to send processed data to fragment pipe 175 or programmable shader 160 for further processing.

[0028] In the illustrated embodiment, the fragment pipe 175 may include various fixed function hardware configured to process pixel data. The fragment pipe 175 may be configured to communicate with the programmable shader 160 to coordinate fragment processing. The fragment pipe 175 may be configured to perform rasterization on polygons from the vertex pipe 185 or the programmable shader 160 to generate fragment data. The vertex pipe 185 and the fragment pipe 175 may be coupled to the memory interface 180 (coupling not shown) to access graphics data.

[0029] In the illustrated embodiment, the programmable shader 160 is configured to receive vertex data from the vertex pipe 185 and fragment data from the fragment pipe 175 and the TPU 165. The programmable shader 160 may be configured to perform vertex processing tasks on the vertex data, which may include various transformations and adjustments to the vertex data. For example, in the illustrated embodiment, the programmable shader 160 is also configured to perform fragment processing tasks on the pixel data, such as texturing and shading. The programmable shader 160 may include multiple sets of multiple execution pipelines for processing data in parallel.

[0030] In some embodiments, the programmable shader includes a pipeline configured to execute one or more different SIMD groups in parallel. Each pipeline may include various stages configured to perform operations (such as extraction, decoding, issuance, execution, etc.) in a given clock cycle. The concept of a processor "pipeline" is well understood and refers to the concept of dividing the "work" of the processor on the execution of instructions into multiple stages. In some embodiments, the decoding, dispatching, execution (i.e., proceeding) and withdrawal of instructions can be examples of different pipeline stages. Many different pipeline architectures may have different element / partial orderings. Various pipeline stages perform such steps on instructions during one or more processor clock cycles, and then pass the instructions or operations associated with the instructions to other stages for further processing.

[0031] The term "SIMD group" is intended to be interpreted according to its well-known meaning, which includes a group of threads for which the processing hardware processes the same instruction in parallel using different input data for different threads. SIMD groups may also be referred to as SIMT (single instruction multiple thread) groups, single instruction parallel threads (SIPT) or channel stack threads. Various types of computer processors may include multiple groups of pipelines configured to execute SIMD instructions. For example, a graphics processor typically includes a programmable shader core that is configured to execute instructions for a group of related threads in a SIMD manner. Other examples of names that can be used for SIMD groups include: wavefront, clique or warp. A SIMD group may be part of a larger thread group of threads executing the same program, which may be split into multiple SIMD groups based on the parallel processing capabilities of the computer (within these SIMD groups, threads may be executed in lockstep). In some embodiments, each thread is assigned to a hardware pipeline (which may be referred to as a "channel") that extracts operands for the thread and performs specified operations in parallel with other pipelines of the group of threads. Note that the processor may have a large number of pipelines so that multiple separate SIMD groups may also execute in parallel. In some embodiments, each thread has private operand storage, for example in a register file. Thus, reading a particular register from the register file may provide a version of the register for each thread in the SIMD group.

[0032] As used herein, the term "thread" includes its meaning as is known in the art, and refers to a sequence of program instructions that can be scheduled to execute independently of other threads. Multiple threads may be included in a SIMD group to execute in lockstep. Multiple threads may be included in a task or process (which may correspond to a computer program). Threads of a given task may or may not share resources such as registers and memory. Therefore, when switching between threads of the same task, a context switch may or may not be performed.

[0033] In some embodiments, multiple programmable shader units 160 are included in a GPU. In these embodiments, the global control circuitry can distribute work to different subsections of the GPU, which in turn can distribute work to the shader cores for processing by the shader pipeline.

[0034] In the illustrated embodiment, TPU 165 is configured to schedule fragment processing tasks from programmable shader 160. In some embodiments, TPU 165 is configured to pre-fetch texture data and assign initial colors to fragments for further processing by programmable shader 160 (e.g., via memory interface 180). TPU 165 can be configured to provide fragment components, for example, in normalized integer format or floating point format. In some embodiments, TPU 165 is configured to provide fragments in groups of four ("fragment quads") in a 2x2 format that are processed by a group of four execution pipelines in programmable shader 160.

[0035] In some embodiments, image write buffer 170 is configured to store processed tiles of an image and may perform operations on the rendered image before transferring it for display or to memory for storage. In some embodiments, graphics unit 150 is configured to perform tiled deferred rendering (TBDR). In tiled rendering, different portions of screen space (e.g., squares or rectangles of pixels) may be processed separately. In various embodiments, memory interface 180 may facilitate communication with one or more of various memory hierarchies.

[0036] As discussed above, a graphics processor typically includes dedicated circuitry configured to perform certain graphics processing operations requested by a computing system. For example, this may include fixed-function vertex processing circuitry, pixel processing circuitry, or texture sampling circuitry. A graphics processor may also perform non-graphics computing tasks that may use GPU shader cores but may not use fixed-function graphics hardware. As an example, machine learning workloads (which may include inference, training, or both) are typically assigned to a GPU due to the parallel processing capabilities of the GPU. Therefore, a computing kernel executed by a GPU may include program instructions that specify a machine learning task (such as implementing a neural network layer or other aspects of a machine learning model to be executed by a GPU shader). In some cases, a non-graphics workload may also use a dedicated graphics circuitry, for example, for a purpose different from that originally intended.

[0037] In addition, in other embodiments, the various circuit systems and techniques discussed herein with reference to the graphics processor may be implemented in other types of processors. Other types of processors may include general-purpose processors such as CPUs or machine learning or artificial intelligence accelerators with dedicated parallel processing capabilities. These other types of processors may not be configured to execute graphics instructions or perform graphics operations. For example, other types of processors may not include the fixed-function hardware included in a typical GPU. Machine learning accelerators may include dedicated hardware for certain operations (such as implementing neural network layers or other aspects of machine learning models). Generally speaking, there may be design trade-offs between memory requirements, computing power, power consumption, and programmability of machine learning accelerators. Therefore, different specific implementations may focus on different performance targets. Developers can choose from a plurality of potential hardware targets for a given machine learning application, such as choosing from a general-purpose processor, a GPU, and different dedicated machine learning accelerators.

[0038] In the illustrated example, graphics unit 150 includes a ray intersection accelerator (RIA) 190 that includes hardware configured to perform various ray intersection operations in response to instructions executed by programmable shader 160 , as described in detail below.

[0039] Overview of the ray data buffer in the accelerator hardware Figure 2 is a block diagram illustrating an example graphics processor including a ray data buffer for accelerator hardware according to some embodiments. In the illustrated example, graphics unit 150 includes programmable shader 160, ray intersection accelerator 190, and shared buffer 240.

[0040] In the illustrated embodiment, ray intersection accelerator 190 includes traversal circuitry 220 configured to traverse the ADS, for example, by performing ray / bounding box intersection tests based on intersect ray commands from programmable shader 160 .

[0041] The ray intersection accelerator 190 also includes a transformation circuit system 230 that is configured to transform ray coordinates, for example, based on a transformation node (such as an instance node) in the ADS. It is noted that including a transformation accelerator circuit system (e.g., as opposed to transforming all ray coordinates by executing a shader program on the shader processor 160) may introduce challenges or design decisions related to caching ray data. For example, from the perspective of the accelerator, the low-level ray data cache of a ray intersection accelerator that does not accelerate ray transformations may be read-only: the shader may write ray data for use by the accelerator, but the accelerator may not write ray data. Instead, the transformation circuit system 230 generates ray data based on the transformation operation, which may be stored in the ray data cache 210.

[0042] Thus, in the disclosed embodiment, the ray intersection accelerator 190 is configured to simultaneously read and write data in the ray data buffer 210, which in some embodiments is dedicated to storing ray data. Figure 4 Detailed example fields for a given ray data buffer entry are discussed. In some embodiments, a given entry in the ray data buffer is configured to store data for a ray pair (e.g., a ray in an original coordinate space and a transformed version of the ray in a target coordinate space). This "ray core pair" can be stored using the size of a cache line in shared buffer 240, which can simplify buffer 210 obtaining exclusive ownership of ray data (when needed).

[0043] In some embodiments, the ray data buffer 210 is directly mapped and indexed using ray identifier information for a given ray (although in other embodiments, various associativity configurations and access techniques are contemplated). This ray identifier information may be a hardware identifier used internally by the RIA 190 and may be available in the shader core space (e.g., using a virtual ray identifier).

[0044] In the illustrated example, the shared buffer 240 is shared by both the programmable shader 160 and the ray intersection accelerator 190. Therefore, in embodiments where the programmable shader 160 cannot access the ray data buffer 210, in the event that the programmable shader 160 needs to access dirty data, the graphics unit may write the data from the ray data buffer 210 to the shared buffer 240.

[0045] In some embodiments, ray data buffer 210 has exclusive ownership of the ray core state for a ray core pair while the ray is in RIA 190. For example, graphics unit 150 may discard (e.g., invalidate) or set the last used indicator for a cache line in shared buffer 240 after reading the line into ray data buffer 210. When a ray intersects other circuitry (e.g., a shader program executed by programmable shader 160), RIA 190 may flush the corresponding line from ray data buffer 210 to shared buffer 240.

[0046] In some embodiments, the transformation circuitry 230 is configured to operate on the following input operands: ray core 0 origin (e.g., X, Y, and Z coordinates), ray core 0 direction (e.g., X, Y, and Z components), one or more RIA flags, a visibility mask, a forced opacity mode indicator, and warping information (e.g., related to the handedness of the system with respect to triangle vertex order and ray direction). Some or all of this information may be stored in the ray data buffer 210, while other information may be stored in the associated transformation node. Figure 4 Discuss more details about this example information.

[0047] In some embodiments, the transformation circuit system 230 is configured to perform a floating-point matrix multiplication operation on the ray origin and the transformation matrix (e.g., a 4×4 world-to-object matrix for the first-level instance transformation) to generate a transformed ray origin. Similarly, the transformation circuit system 230 may be configured to perform a floating-point matrix multiplication operation on the ray direction and the transformation matrix. Therefore, the transformation circuit system may include: a plurality of floating-point multipliers, the plurality of floating-point multipliers being configured to operate in parallel; and an accumulation circuit system, the accumulation circuit system being configured to accumulate the results of the multiplication to generate a matrix multiplication result.

[0048] The transformation circuit system 230 may output the following transformation results: ray core 1 origin, ray core 1 direction, ray core 1 Kx / Ky (information associated with the normalized ray direction component), ray core 1 flag, current ray core identifier (e.g., ray core 0 or ray core 1), and updated RIA flag. In this naming convention, ray core 0 refers to the ray state in the original coordinate space, and ray core 1 refers to the transformed ray state.

[0049] Note that when traversing a lower level BVH (e.g., an instance subtree), RIA 190 may perform the following general flow. First, RIA 190 may perform an instance push, which includes reading the ray core 0 state from shared buffer 240, transforming the ray using transformation circuitry 230, and storing the resulting ray core 1 state in an entry of ray data buffer 210 along with the ray core 0 state. RIA 190 may then continue traversing the ADS using ray core 1. RIA 190 may then perform an instance pop (e.g., leaving the instance subtree) when transitioning back to a higher level BVH. As part of this flow, RIA 190 may write an updated Tmax value to the entry of ray data buffer 210.

[0050] Figure 3 is a communication diagram illustrating example messages between a shader processor, traversal circuitry, transformation circuitry, and ray data buffer according to some embodiments. In the illustrated example, shader 160 transmits intersection ray command 302 to traversal circuitry 220 based on executing a shader program.

[0051] Based on traversing the ADS in response to command 302, traversal circuitry 220 sends a transformation request 304 to transformation circuitry 230. Transformation circuitry 230 performs the transformation and stores transformed ray coordinates 306 in the ray data buffer (and also notifies traversal circuitry 220 that the transformation is complete in communication 308). In response, traversal circuitry 220 reads the transformed ray coordinates 310 from the ray data buffer. Traversal circuitry 220 may perform further traversals using the transformed ray coordinates and ultimately provide traversal results as intersection ray results 318.

[0052] Figure 3 Also shown are alternative or additional communications for situations where the shader 160 performs a transformation (shown using dashed lines). In some embodiments, the graphics unit 150 supports both shader transformations and hardware accelerated transformations. For example, the shader transformation may be performed based on a user-indicated bypass of the transformation circuit system 230 or based on the current level in a multi-level instantiation situation. In this example, the traversal circuit system 220 sends a transformation request 312 to the shader 160. The shader 160 indicates when the transformation is completed via communication 314. The traversal circuit system 220 then retrieves the transformed light coordinates 316 from the light data buffer 210. Note that while the shader circuit system 160 may not be able to store the data directly in the light data buffer 210, the shader circuit system 160 may store the data in the shared buffer 240, and the RIA 190 may fill the transformed light coordinates from the shared buffer 240 into the light data buffer 210.

[0053] In any of the illustrated ray transformation cases, the traversal circuitry may continue traversing the ADS and provide the intersection ray result 318 back to the shader. Note that the continued traversal may include traversing back through the transform / instance node and performing ray / box intersection tests in the original coordinate space using the ray core 0 state information prior to the transformation.

[0054] Example ray data buffer entry format Figure 4 is a diagram illustrating example fields of a ray data buffer entry according to some embodiments. In this example, dashed lines indicate fields shared by a ray pair (which includes ray core 0 and ray core 1 in this example), while solid lines indicate non-shared fields.

[0055] In the illustrated example, the fields for ray core 0 (RC0) include: origin X, Y, and Z values ​​402, direction X, Y, and Z components 404, flags 410, and BVH ray state 412. The fields for ray core 1 (RC1) include: origin X, Y, and Z values ​​432, direction X, Y, and Z components 434, flags 440, and BVH ray state 442.

[0056] These origin values ​​and direction components may be stored as floating point values. Flags 440 may be per-BVH flags (e.g., for a given ray, the per-BVH flags for the main BVH may be different from the per-BVH flags for the instance subtree BVH) and may include various information, such as culling mode (e.g., none, back, or front), whether early termination is allowed, Kx and Ky values ​​associated with the normalized ray direction component, winding order (e.g., clockwise or counterclockwise), and opacity mode (e.g., forced opaque without forced opacity, forced non-opaque). The BVH ray state may include various BVH-specific states for a given ray core.

[0057] In the illustrated example, the shared fields include: Tmax 408, visibility mask 422, sharing flag 424, and time 426. Tmax is a ray parameter value that indicates the interval over which the ray is valid (where the interval is a portion of a vector defined by the ray origin and direction). Visibility mask 422 can be used to determine when to terminate traversing a portion of an ADS (e.g., during a depth-first search). For example, when the visibility mask data for the ray does not match the visibility mask data associated with a node of the ADS, RIA 190 can terminate the traversal. Time 426 can be an input to a motion blur calculation and can be a quantized value.

[0058] In some embodiments, shared flags 424 may include fields such as an indication of whether to use a ray opacity flag or an opacity flag that is part of an acceleration data structure (e.g., an opacity_none parameter), a ray core identifier indicating which ray core pair field to use at the current traversal point, an indication of whether early termination of traversal of the ray is allowed, an indication of whether any any-hit queries are being performed on the ray, and an indication of whether to use a shader to process the primitive before moving back to the original coordinate space, etc.

[0059] When operating on non-instantiated content, RIA 190 may not use all fields of a given row of ray data buffer 210 to store ray data and state. Note that ray data may be stored in shader core memory space, which may store token buffer information, ray core data, ray sideband data, ray stacks, and ray extension data. In some embodiments, when instancing is not enabled, graphics firmware may store other ray data (e.g., extended ray data) in ray core 1 fields, for example to reduce the footprint of that data in shared buffer 240 by including that data in a cache line that would otherwise be used for ray core data in instantiated mode.

[0060] Note that while ray core pairs are discussed for purposes of illustration, in other embodiments, ray core triplets or a greater number of ray cores may be stored in a given cache entry, e.g., for use in multi-level instantiation (although this may increase the area of ​​the ray data cache, which may or may not be a favorable design trade-off).

[0061] Example bypass and multi-level instantiation techniques Figure 5 5 is a block diagram illustrating an example multi-stage / bypass control circuit system configured to perform transformation selection according to some embodiments. In the illustrated embodiment, the multi-stage / bypass control circuit system is configured to receive a bypass indicator signal and an instance level signal. Based on these signals, the control circuit system 510 is configured to initiate a shader transformation (e.g., via a clique-SSIMD group executed on the programmable shader 160) or initiate a hardware transformation (e.g., via the transformation circuit system 230) for a given ray transformation (e.g., based on reaching an instance node).

[0062] For example, the control circuit system 510 can be configured to always enable the shader transform when the bypass indicator is set. The bypass indicator can be set by, for example, a shader program and indicates the developer's desire to run a custom shader transform instead of using a hardware transform. For example, a custom shader can allow the shader program to perform a level of detail selection. In some embodiments, the bypass indicator can be stored in a node of the BVH.

[0063] As another example, control circuitry 510 may launch software shaders for instance levels that transformation circuitry 230 is not configured to process, depending on the number of instantiation levels supported by transformation circuitry 230. For example, if transformation circuitry 230 is configured to process a single level, control circuitry 510 may alternate back and forth between shader transformations and hardware transformations (e.g., using hardware transformations for every odd level of instantiation). As another example, if transformation circuitry 230 is configured to process two instantiation levels, control circuitry 510 may launch shader transformations every three levels, and so on.

[0064] The control circuit system 510 may implement combinatorial logic configured to perform the disclosed selection operations. For example, the bypass indicator may be an input to an OR gate of a shader transform output, such that the shader transform is always enabled when the bypass indicator is set. For example, the instance level may be input to a parity detector, or used to access a lookup table to determine whether to process the level in hardware or using a shader transform.

[0065] In embodiments where the transformation circuitry 230 supports transformations for multiple levels of instance transformations, the ray data buffer 210 may retain ray core data for the current level and parent levels in the ray data buffer 210. For example, while Figure 4 Ray core 0 and ray core 1 are shown, but other ray core pairs may be stored at other times during the traversal (e.g., ray core 1 and ray core 2, etc.). The oldest level may be pushed out to keep the current level and the parent level in the buffer 210. When rewinding a level, the system may invalidate the current level and read the parent level from the buffer 210, which may reduce reading from a backup buffer or memory (e.g., from the shared buffer 240).

[0066] Example Detailed Implementation Figure 6 is a block diagram illustrating example components of a ray intersection accelerator according to some embodiments. In the illustrated example, ray intersection accelerator 190 includes ray data buffer 210, transformation circuitry 230, node tester circuitry 620, node data buffer circuitry 630, triangle filter circuitry 640, read control circuitry 650, and write control circuitry 655.

[0067] In the illustrated embodiment, the node tester 620 is configured to receive node test commands based on the ADS traversal. For example, the tester 620 can be configured to perform bounding box tests in parallel for all child nodes of a given ADS node. For example, the tester 620 can implement a conservative flat panel test for bounding boxes. In the illustrated example, the node tester 620 receives input for ray / bounding box intersection tests from the node data buffer 630 and the ray data buffer 210.

[0068] As shown, the intersection results of certain nodes (e.g., hits in primitive leaf nodes) are provided to a triangle filter 640, which can perform reduced-precision ray / primitive intersection tests (e.g., to determine that some tests did not hit, thereby avoiding the need to perform full-precision intersection tests). The filtering results can be used to determine which primitives should be subject to full-precision intersection tests, either by hardware or by a shader.

[0069] In the illustrated embodiment, the read control 650 is configured to read data from the ray data buffer 210 based on requests from the node tester 620 and the triangle filter 640. As shown, the transformation circuit system 230 is also configured to request to read, for example, ray core 0 state information to be used to perform the transformation and generate ray core 1 state information, and then the transformation circuit system 230 writes the ray core 1 state information to the ray data buffer 210 by interacting with the write control circuit system 655. It should be noted that the transformation circuit system 230 may receive an instance transformation request in response to the RIA 190 determining that the instance node has been traversed. A given node in the ADS may include a set of boundaries of its child nodes, origin information of the quantization frame of the child boundaries, metadata of the child boundaries (e.g., indicating whether the child node is an instance node), state information, etc.

[0070] In some embodiments, in addition to writing ray core 1 data from transformation circuitry 230, write control 655 may also retrieve ray core 0 data (e.g., from shared buffer 240) and write that data to ray data buffer 210 as a line fill. Once ray core 1 data is written to ray data buffer 210, the data may be used for instance subtree traversal, including node testing by node tester 620.

[0071] Example Method Figure 7 is a flow chart illustrating an example method according to some embodiments. Figure 7The method shown can be used in conjunction with any of the computer circuits, systems, devices, elements or components disclosed herein. In various embodiments, some of the method elements shown can be performed concurrently in a different order than shown, or can be omitted. Additional method elements can also be performed as needed.

[0072] At 710 , in the illustrated embodiment, a graphics processor (eg, RIA 190 ) performs (eg, using traversal circuitry 220 ) intersection tests between rays and bounding regions of acceleration data structures for a graphics scene.

[0073] At 720, in the illustrated embodiment, the graphics processor (e.g., using the transformation circuitry 230) transforms a first coordinate of a ray from a first coordinate space in response to reaching a transformation node in the acceleration data structure to generate a second coordinate of the ray in a second coordinate space for subsequent traversal of the acceleration data structure. In some embodiments, the transformation node is an instance node. For a first-level instance, the first coordinate of the ray is in world space, and the second coordinate of the ray is in instance space. In some embodiments, the transformation circuitry is configured to use the second coordinate for traversal after the transformation node, and to switch back to using the first coordinate after traversal returns through the transformation node during a depth-first traversal.

[0074] In some embodiments, the acceleration data structure includes a nested transformation, and the graphics processor is configured to: process a first transformation level of the nested transformation using the transformation circuitry and entries of the ray cache circuitry, and process a second transformation level of the nested transformation using the shader processor circuitry. In some embodiments, the ray intersection accelerator circuitry is configured to, in response to reaching a transformation node and a bypass indicator, launch one or more threads on the shader processor circuitry to perform the transformation, rather than using the transformation circuitry to perform the transformation.

[0075] At 730, in an illustrated embodiment, the graphics processor caches (e.g., ray data buffer 210) data accessible to the ray intersection accelerator circuit system, wherein entries of the cache are configured to cache data for the ray, the data comprising: a first coordinate of the ray in a first coordinate space, a second coordinate of the ray in a second coordinate space, and shared data for the ray applicable to both the first coordinate and the second coordinate.

[0076] In some embodiments, the shared data includes one or more of: visibility mask data (wherein the ray intersection accelerator circuit system is configured to terminate traversal of a portion of the acceleration data structure in response to determining that the visibility mask data of the ray does not match visibility mask data associated with the portion of the acceleration data structure), a quantized ray timestamp value, an indication of whether to use a shader to process primitives before transforming the ray's coordinates back to the first coordinate space, a tmax value indicating a limit of a parameter interval for the ray, an indication of whether any arbitrary hit queries are being performed on the ray, an indication of whether early termination of traversal of the ray is allowed, an indication of whether to use a ray opacity tag or an opacity tag of a portion of the acceleration data structure, and an identifier for identifying whether to use the first coordinate or the second coordinate at a current traversal point of the ray.

[0077] In some embodiments, the graphics processor includes a shader processor circuit system that is configured to execute graphics programs, and the cache is not accessible to the shader processor circuit system, but is included in a cache / memory hierarchy that includes at least one higher-level cache (e.g., shared cache 240) that is accessible to the shader processor circuit system.

[0078] In some embodiments, the entry of the buffer is further configured to cache data of the light ray, the data comprising one or more of: first marker data corresponding to the first coordinate and second marker data corresponding to the second coordinate.

[0079] The concept of "execution" is broad and can refer to 1) the processing of instructions in the entire execution pipeline (e.g., through the acquisition stage, decoding stage, execution stage, and rollback stage), and 2) the processing of instructions at the execution unit or execution subsystem (e.g., integer execution unit or load storage unit) of such pipeline. The latter meaning may also be referred to as a "perform" instruction. Therefore, a "perform" sum instruction refers to adding two operands to produce a result, which can be implemented by a circuit (e.g., an execution unit) at the execution stage of the pipeline in some embodiments. On the contrary, an "perform" sum instruction can refer to the entire operation that occurs in the entire pipeline as a result of the sum instruction. Similarly, a "perform" "load" instruction may include retrieving a value (e.g., from a cache, a memory, or the storage result of another instruction) and storing the retrieved value in a register or other location.

[0080] As used herein, in the context of instructions, the terms "complete" and "completion" refer to the committal of the result of an instruction to the architectural state of a processor or processing element. For example, completion of an add instruction includes writing the result of the add instruction to a destination register. Similarly, completion of a load instruction includes writing a value (e.g., a value retrieved from a cache or memory) to a destination register or a representation thereof.

[0081] The concept of processor "pipelining" is well known and refers to the concept of dividing the "work" that a processor performs on an instruction into multiple stages. In some embodiments, decoding, dispatching, executing (i.e., proceeding), and retiring of instructions may be examples of different pipeline stages. Many different pipeline architectures may have different orderings of elements / parts. Various pipeline stages perform such steps on instructions during one or more processor clock cycles and then pass the instruction or operations associated with the instruction to other stages for further processing.

[0082] Example Device Reference now Figure 8 , which shows a block diagram of an example embodiment of device 800. In some embodiments, elements of device 800 may be included in a system on a chip. In some embodiments, device 800 may be included in a mobile device that may be battery powered. Therefore, the power consumption of device 800 may be an important design consideration. In the illustrated embodiment, device 800 includes a structure 810, a computing complex 820, an input / output (I / O) bridge 850, a buffer / memory controller 845, a graphics unit 875, and a display unit 865. In some embodiments, in addition to or in place of the components shown, device 800 may include other components (not shown), such as video processor encoders and decoders, image processing or recognition elements, computer vision elements, etc.

[0083] The structure 810 may include various interconnects, buses, MUXs, controllers, etc., and may be configured to facilitate communication between various elements of the device 800. In some embodiments, portions of the structure 810 may be configured to implement various different communication protocols. In other embodiments, the structure 810 may implement a single communication protocol, and elements coupled to the structure 810 may be internally converted from the single communication protocol to other communication protocols.

[0084] In the illustrated embodiment, the computing complex 820 includes a bus interface unit (BIU) 825, a cache 830, and cores 835 and 840. In various embodiments, the computing complex 820 may include various numbers of processors, processor cores, and caches. For example, the computing complex 820 may include 1, 2, or 4 processor cores, or any other suitable number. In one embodiment, the cache 830 is a group-associative L2 cache. In some embodiments, the cores 835 and 840 may include internal instruction and data caches. In some embodiments, a consistency unit (not shown) in the structure 810, the cache 830, or elsewhere in the device 800 may be configured to maintain consistency between the various caches of the device 800. The BIU 825 may be configured to manage communications between the computing complex 820 and other elements of the device 800. The processor cores (such as cores 835 and 840) may be configured to execute instructions of a specific instruction set architecture (ISA) that may include operating system instructions and user application instructions. These instructions may be stored in a computer readable medium, such as a memory coupled to the memory controller 845 discussed below.

[0085] As used herein, the term "coupled to" may indicate one or more connections between elements, and a coupling may include intermediate elements. Figure 8 In FIG, graphics unit 875 may be described as being "coupled to" memory via structure 810 and buffer / memory controller 845. In contrast, in Figure 8 In the illustrated embodiment, graphics unit 875 is "directly coupled" to structure 810 because there are no intervening elements.

[0086] The cache / memory controller 845 may be configured to manage data transfer between the structure 810 and one or more caches and memories. For example, the cache / memory controller 845 may be coupled to an L3 cache, which in turn may be coupled to a system memory. In other embodiments, the cache / memory controller 845 may be directly coupled to a memory. In some embodiments, the cache / memory controller 845 may include one or more internal caches. The memory coupled to the controller 845 may be any type of volatile memory, such as a dynamic random access memory (DRAM), a synchronous DRAM (SDRAM), a double data rate (DDR, DDR2, DDR3, etc.) SDRAM (including a mobile version of SDRAM, such as mDDR3, etc., and / or a low power version of SDRAM, such as LPDDR4, etc.), RAMBUS DRAM (RDRAM), a static RAM (SRAM), etc. One or more memory devices may be coupled to a circuit board to form a memory module, such as a single inline memory module (SIMM), a dual inline memory module (DIMM), etc. Alternatively, these devices may be mounted with the integrated circuit in a chip stack configuration, a package stack configuration, or a multi-chip module configuration. The memory coupled to the controller 845 may be any type of non-volatile memory, such as NAND flash memory, NOR flash memory, nano RAM (NRAM), magnetoresistive RAM (MRAM), phase change RAM (PRAM), racetrack memory, memristor memory, etc. As described above, the memory may store program instructions that can be executed by the computing complex 820 to cause the computing device to perform the functionality described herein.

[0087] Graphics unit 875 may include one or more processors, such as one or more graphics processing units (GPUs). For example, graphics unit 875 may receive graphics-oriented instructions, such as OPENGL ® 、Metal ® or DIRECT3D ®Instructions. The graphics unit 875 may execute dedicated GPU instructions or perform other operations based on the received graphics-oriented instructions. The graphics unit 875 may generally be configured to process large blocks of data in parallel and may build images in a frame buffer for output to a display, which may be included in the device or may be a separate device. The graphics unit 875 may include transformation, lighting, triangle, and rendering engines in one or more graphics processing pipelines. The graphics unit 875 may output pixel information for displaying an image. In various embodiments, the graphics unit 875 may include a programmable shader circuit system, which may include a highly parallel execution core configured to execute graphics programs, which may include pixel tasks, vertex tasks, and computational tasks (which may be graphics-related or may not be graphics-related).

[0088] In some embodiments, the disclosed techniques may advantageously improve the performance of, reduce the power consumption of, or both, ray tracing workloads executed by graphics unit 875 .

[0089] The display unit 865 may be configured to read data from the frame buffer and provide a stream of pixel values ​​for display. In some embodiments, the display unit 865 may be configured as a display pipeline. In addition, the display unit 865 may be configured to blend multiple frames to produce an output frame. In addition, the display unit 865 may include one or more interfaces (e.g., MIPI) for coupling to a user display (e.g., a touch screen or an external display). ® or embedded DisplayPort (eDP).

[0090] The I / O bridge 850 may include various elements configured to implement, for example, universal serial bus (USB) communications, security, audio, and low-power always-on functionality. The I / O bridge 850 may also include, for example, interfaces such as pulse width modulation (PWM), general purpose input / output (GPIO), serial peripheral interface (SPI), and inter-integrated circuit (I2C). Various types of peripherals and devices may be coupled to the device 800 via the I / O bridge 850.

[0091] In some embodiments, the device 800 includes a network interface circuit system (not explicitly shown) that can be connected to the structure 810 or the I / O bridge 850. The network interface circuit system can be configured to communicate via various networks, which can be wired networks, wireless networks, or both. For example, the network interface circuit system can be configured to communicate via a wired local area network, a wireless local area network (e.g., via Wi-Fi ™) or a wide area network (e.g., the Internet or a virtual private network). In some embodiments, the network interface circuit system is configured to communicate via one or more cellular networks using one or more radio access technologies. In some embodiments, the network interface circuit system is configured to use device-to-device communication (e.g., Bluetooth ® or Wi-Fi ™ In various embodiments, the network interface circuit system can provide the device 800 with connectivity to various types of other devices and networks.

[0092] Sample Application Now go to Fig. 9 , various types of systems that may include any of the circuits, devices, or systems discussed above are shown. The system or device 900, which may incorporate or otherwise utilize one or more of the techniques described herein, may be used in a wide variety of fields. For example, the system or device 900 may be used as part of the hardware of a system such as a desktop computer 910, a laptop computer 920, a tablet computer 930, a cellular or mobile phone 940, or a television 950 (or a set-top box coupled to a television).

[0093] Similarly, the disclosed elements can be used in a wearable device 960, such as a smart watch or a health monitoring device. In many embodiments, a smart watch can implement a variety of different functions—for example, access to email, cellular service, calendar, health monitoring, etc. The wearable device can also be designed to perform only health monitoring functions, such as monitoring the user's vital signs, performing epidemiological functions such as contact tracing, providing communications to emergency medical services, etc. Other types of devices are also contemplated, including devices worn around the neck, devices that can be implanted in the human body, glasses or helmets designed to provide computer-generated reality experiences, such as those based on augmented reality and / or virtual reality, etc.

[0094] The system or device 900 may also be used in various other contexts. For example, the system or device 900 may be used in the context of a server computer system (such as a dedicated server) or on shared hardware that implements a cloud-based service 970. Further, the system or device 900 may be implemented in a wide range of dedicated everyday devices, including devices 980 commonly found in the home, such as refrigerators, thermostats, security cameras, etc. The interconnection of such devices is generally referred to as the "Internet of Things" (IoT). The elements may also be implemented in various modes of transportation. For example, the system or device 900 may be used in control systems, guidance systems, entertainment systems, etc., for various types of vehicles 990.

[0095] Fig. 9The applications shown in are merely exemplary and are not intended to limit the potential future applications of the disclosed system or device. Other example applications include, but are not limited to: portable game devices, music players, data storage devices, unmanned aerial vehicles, etc.

[0096] Example Computer Readable Medium The present disclosure has described various example circuits in detail above. It is intended that the present disclosure covers not only embodiments including such circuit systems, but also computer-readable storage media including design information specifying such circuits. Therefore, the present disclosure is intended to support claims covering not only devices including the disclosed circuit systems, but also storage media that specify the circuit systems in a format that is used to program a computing system to generate a simulation model of a hardware circuit, to program a computing system configured to generate hardware (e.g., an integrated circuit) including the disclosed circuit systems, and the like. Claims to such storage media are intended to cover, for example, entities that generate circuit designs but do not perform complete operations themselves (such as design simulation, design synthesis, circuit manufacturing, etc.).

[0097] Fig.10 1 is a block diagram illustrating an exemplary non-transitory computer-readable storage medium storing circuit design information according to some embodiments. In the illustrated embodiment, computing system 1040 is configured to process the design information. This may include executing instructions included in the design information, interpreting instructions included in the design information, compiling, transforming or otherwise updating the design information, etc. Thus, in some embodiments, the design information (e.g., by programming computing system 1040) controls computing system 1040 to perform various operations discussed below.

[0098] In the illustrated example, computing system 1040 processes the design information to generate both a computer simulation model of hardware circuit 1060 and lower-level design information 1050. In other embodiments, computing system 1040 may generate only one of these outputs, may generate other outputs based on the design information, or both. With respect to computer simulation, computing system 1040 may execute instructions of a hardware description language that includes register transfer level (RTL) code, behavioral code, structural code, or some combination thereof. The simulation model may perform the functionality specified by the design information, facilitate verification of the functional correctness of the hardware design, generate power consumption estimates, generate timing estimates, and the like.

[0099] In the illustrated example, computing system 1040 also processes the design information to generate lower-level design information 1050 (e.g., gate-level design information, netlists, etc.). As shown, this may include synthesis operations such as building a multi-level network, optimizing the network using technology-independent techniques, technology-dependent techniques, or both, and outputting a gate network (with potential constraints based on available gate-to-technology libraries, sizing, delay, power, etc.). Based on the lower-level design information 1050 (possibly among other inputs), semiconductor manufacturing system 1020 is configured to manufacture integrated circuit 1030 (which may correspond to the functionality of simulation model 1060). Note that computing system 1040 may generate different simulation models based on various levels of description of design information (including information 1050, 1015, etc.). Data representing design information 1050 and model 1060 may be stored on medium 1010 or on one or more other media.

[0100] In some embodiments, lower-level design information 1050 controls (eg, programs) semiconductor fabrication system 1020 to fabricate integrated circuit 1030. Thus, when processed by the fabrication system, the design information may program the fabrication system to fabricate circuits including the various circuitry disclosed herein.

[0101] The non-transitory computer-readable storage medium 1010 may include any of a variety of suitable types of memory devices or storage devices. The non-transitory computer-readable storage medium 1010 may be an installation medium, for example, a CD-ROM, a floppy disk, or a tape device; a computer system memory or random access memory such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; a non-volatile memory such as flash memory, a magnetic medium, for example, a hard drive or an optical storage device; a register, or other similar type of memory element, etc. The non-transitory computer-readable storage medium 1010 may also include other types of non-transitory memory or combinations thereof. Therefore, the non-transitory computer-readable storage medium 1010 may include two or more memory media; such media may reside in different locations—for example, in different computer systems connected by a network.

[0102] The design information 1015 may be specified using any of a variety of appropriate computer languages, including hardware description languages, such as, but not limited to, VHDL, Verilog, SystemC, SystemVerilog, RHDL, M, MyHDL, etc. The formats of the various design information may be identified by one or more applications executed by the computing system 1040, the semiconductor manufacturing system 1020, or both. In some embodiments, the design information may also include one or more cell libraries that specify the synthesis, layout, or both of the integrated circuit 1030. In some embodiments, the design information is specified in whole or in part in the form of a netlist of specified cell library elements and their connectivity. Taken alone, the design information discussed herein may or may not include sufficient information for manufacturing the corresponding integrated circuit. For example, the design information may specify the circuit elements to be manufactured, but not their physical layout. In this case, the design information may need to be combined with the layout information to actually manufacture the specified circuit system.

[0103] In various embodiments, the integrated circuit 1030 may include one or more custom macrocells, such as memory, analog or mixed signal circuits, etc. In this case, the design information may include information related to the included macrocells. Such information may include, but is not limited to, a schematic capture database, mask design data, behavioral models, and device or transistor level netlists. The mask design data may be formatted according to a graphic data system (GDSII) or any other suitable format.

[0104] Semiconductor manufacturing system 1020 may include any of a variety of suitable elements configured to manufacture integrated circuits. This may include, for example, elements for depositing semiconductor material (e.g., on a wafer that may include a mask), removing material, changing the shape of deposited material, modifying material (e.g., by doping the material or using ultraviolet treatment to modify the dielectric constant), etc. Semiconductor manufacturing system 1020 may also be configured to perform various tests of the manufactured circuits for proper operation.

[0105] In various embodiments, integrated circuit 1030 and model 1060 are configured to operate according to the circuit design specified by design information 1015, which may include performing any of the functionality described herein. For example, integrated circuit 1030 may include Figure 1B , Figure 2 , Figures 5 and 6 and Figure 8 Any of the various elements shown in . In addition, integrated circuit 1030 can be configured to perform various functions described herein in conjunction with other components. In addition, the functionality described herein can be performed by multiple connected integrated circuits.

[0106] As used herein, a phrase of the form “design information specifying a design of a circuit configured to…” does not imply that the circuit in question must be manufactured in order to satisfy the element. Rather, the phrase indicates that the design information describes a circuit that, when manufactured, will be configured to perform the indicated actions or will include the specified components. Similarly, the statement “instructions of a hardware description programming language are “executable” to program a computing system to generate a computer simulation model” does not mean that the instructions must be executed in order to satisfy the element, but rather that the characteristics of those instructions are specified. In this case, additional features associated with the model (or the circuit represented by the model) may similarly be related to the characteristics of those instructions. Thus, an entity that sells a computer-readable medium with instructions that satisfy the stated characteristics may be providing an infringing product even if another entity actually executes those instructions on the medium.

[0107] Note that a given design, at least in the context of digital logic, may be implemented using a number of different gate arrangements, circuit technologies, etc. As one example, different designs may select or connect gates based on design tradeoffs (e.g., to focus on power consumption, performance, circuit area, etc.). Furthermore, different manufacturers may have proprietary libraries, gate designs, physical gate implementations, etc. Different entities may also use different tools to process design information at various levels (e.g., from behavioral specifications to physical layout of gates).

[0108] However, once a digital logic design is specified, those skilled in the art do not need to perform extensive experimentation or research to determine these implementations. Instead, those skilled in the art understand procedures for reliably and predictably generating one or more circuit implementations that provide the functionality described by the design information. Different circuit implementations may affect the performance, area, power consumption, etc. of a given design (potentially with tradeoffs between different design goals), but the logic functionality does not change between different circuit implementations of the same circuit design.

[0109] In some embodiments, the instructions included in the design information instructions provide RTL information (or other higher-level design information) and can be executed by the computing system to synthesize a gate-level netlist representing a hardware circuit based on the RTL information as input. Similarly, these instructions can provide behavioral information and can be executed by the computing system to synthesize a netlist or other lower-level design information. The lower-level design information can program the manufacturing system 1020 to manufacture the integrated circuit 1030.

[0110] *** The various techniques described herein may be performed by one or more computer programs. The term "program" will be broadly interpreted to encompass a sequence of instructions in a programming language that is executable by a computing device. These programs may be written in any suitable computer language, including lower-level languages ​​such as assembly and higher-level languages ​​such as Python. The program may be written in a compiled language such as C or C++ or an interpreted language such as JavaScript.

[0111] Program instructions may be stored on a "computer-readable storage medium" or "computer-readable medium" to facilitate execution of the program instructions by a computer system. In general, these phrases include any tangible or non-transitory storage medium or memory medium. The terms "tangible" and "non-transitory" are intended to exclude propagating electromagnetic signals, but do not otherwise limit the type of storage medium. Thus, the phrases "computer-readable storage medium" or "computer-readable medium" are intended to cover types of storage devices that do not necessarily store information permanently (e.g., random access memory (RAM)). Thus, the term "non-transitory" is a limitation on the nature of the medium itself (i.e., the medium cannot be a signal), as opposed to limitations on the data storage persistence of the medium (e.g., RAM vs. ROM).

[0112] The phrases "computer-readable storage medium" and "computer-readable medium" are intended to refer to storage media within a computer system as well as removable media such as a CD-ROM, memory stick, or portable hard drive. These phrases encompass any type of volatile memory within a computer system, including DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc., as well as non-volatile memory such as magnetic media (e.g., hard drive) or optical storage devices. These phrases are expressly intended to encompass the memory of a server that facilitates the download of program instructions, the memory within any intermediate computer systems involved in the download, and the memory of all destination computing devices. Still further, these phrases are intended to encompass combinations of different types of memory.

[0113] In addition, a computer-readable medium or storage medium may be located in a first set of one or more computer systems in which the program is executed, and in a second set of one or more computer systems connected to the first set via a network. In the latter instance, the second set of computer systems may provide program instructions to the first set of computer systems for execution. In short, the phrases "computer-readable storage medium" and "computer-readable medium" may include two or more media that may reside in different locations (e.g., in different computers connected via a network).

[0114] This disclosure includes references to "embodiments" or groups of "embodiments" (e.g., "some embodiments" or "various embodiments"). Embodiments are different specific implementations or examples of the disclosed concepts. References to "an embodiment," "one embodiment," "a particular embodiment," etc. do not necessarily refer to the same embodiment. Numerous possible embodiments are contemplated, including those specifically disclosed, as well as modifications or alternatives that fall within the spirit or scope of the present disclosure.

[0115] The present disclosure may discuss potential advantages that may result from the disclosed embodiments. Not all implementations of these embodiments will necessarily exhibit any or all of the potential advantages. Whether a particular implementation achieves an advantage depends on many factors, some of which are outside the scope of the present disclosure. In fact, there are many reasons why an implementation that falls within the scope of the claims may not exhibit some or all of any of the disclosed advantages. For example, a particular implementation may include other circuit systems outside the scope of the present disclosure that, in combination with one of the disclosed embodiments, negate or reduce one or more of the disclosed advantages. In addition, suboptimal design execution of a particular implementation (e.g., a specific implementation technique or tool) may also negate or reduce the disclosed advantages. Even assuming a specific implementation of the technology, the realization of the advantages may still depend on other factors, such as the environmental conditions in which the specific implementation is deployed. For example, the input provided to a particular implementation may prevent one or more problems solved in the present disclosure from occurring in a particular occasion, and as a result, the benefits of its solution may not be realized. In view of the existence of possible factors external to the present disclosure, it is hereby made clear that any potential advantages described herein should not be construed as claim limitations that must be met in order to prove infringement. Instead, the identification of such potential advantages is intended to illustrate the types of improvements available to designers who benefit from the present disclosure. Permanently describing such advantages (e.g., stating that a particular advantage "may occur") is not intended to convey a doubt as to whether such advantage can actually be achieved, but rather to recognize that achievement of such advantage will often depend on the technical realities of additional factors.

[0116] Unless otherwise stated, the embodiments are non-limiting. That is, the disclosed embodiments are not intended to limit the scope of the claims drafted based on the present disclosure, even if only a single example is described with respect to a particular feature. The embodiments disclosed by the present invention are intended to be illustrative and non-restrictive, without any contrary statement in the present disclosure. Therefore, the present application is intended to allow claims covering the disclosed embodiments, as well as such alternatives, modifications and equivalents, which will be apparent to those skilled in the art who are aware of the beneficial effects of the present disclosure.

[0117] For example, features in this application may be combined in any suitable manner. Accordingly, new claims may be made during the prosecution of this application (or an application claiming priority thereto) for any such combination of features. In particular, with reference to the appended claims, features of dependent claims may be combined, where appropriate, with features of other dependent claims, including claims that are dependent on other independent claims. Similarly, features from corresponding independent claims may be combined, where appropriate.

[0118] Thus, while the appended dependent claims may be drafted such that each dependent claim is dependent upon a single other claim, additional dependencies are also contemplated. Any combination of dependent features consistent with the present disclosure is contemplated and may be claimed in this or another application. In short, the combinations are not limited to those specifically recited in the appended claims.

[0119] It is also contemplated that claims drafted in one format or legal type (eg, apparatus) are intended to support corresponding claims in another format or legal type (eg, method), where appropriate.

[0120] *** Because this disclosure is a legal document, various terms and phrases may be subject to regulatory and judicial interpretation. Notice is hereby given that the definitions provided in the following paragraphs and throughout this disclosure will be used to determine how to interpret claims drafted based on this disclosure.

[0121] Unless the context clearly dictates otherwise, reference to an item in the singular (i.e., a noun or noun phrase preceded by "a," "an," or "the") is intended to mean "one or more." Thus, reference to "an item" in a claim does not exclude additional instances of that item without the accompanying context. A "plurality" of an item refers to a group of two or more items.

[0122] The word “may” is used herein in a permissive sense (ie, having the potential to, being able to), rather than the mandatory sense (ie, must).

[0123] The terms "including" and "comprising" and forms thereof are open ended and mean "including, but not limited to."

[0124] When the term "or" is used in this disclosure with respect to a list of options, it will generally be understood to be used in an inclusive sense unless the context provides otherwise. Thus, the expression "x or y" is equivalent to "x or y, or both," and thus encompasses 1) x but not y, 2) y but not x, and 3) both x and y. On the other hand, phrases such as "either x or y, but not both" make it clear that "or" is used in an exclusive sense.

[0125] The expressions "w, x, y, or z, or any combination thereof" or "... at least one of w, x, y, and z" are intended to cover all possibilities involving individual elements up to the total number of elements in the set. For example, given the set [w, x, y, z], these phrases cover any single element in the set (e.g., w but not x, y, or z), any two elements (e.g., w and x, but not y or z), any three elements (e.g., w, x, and y, but not z), and all four elements. The phrase "... at least one of w, x, y, and z" thus refers to at least one element in the set [w, x, y, z], thereby covering all possible combinations in the list of elements. The phrase should not be interpreted as requiring the presence of at least one instance of w, at least one instance of x, at least one instance of y, and at least one instance of z.

[0126] In this disclosure, various "labels" may precede a noun or noun phrase. Unless the context provides otherwise, different labels used for a feature (e.g., "first circuit," "second circuit," "particular circuit," "given circuit," etc.) refer to different instances of the feature. Additionally, unless otherwise stated, the labels "first," "second," and "third" do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) when applied to features.

[0127] The phrase "based on" is used to describe one or more factors that influence a determination. This term does not exclude the possibility that additional factors may influence a determination. That is, a determination may be based only on specified factors or on specified factors and other unspecified factors. Consider the phrase "A is determined based on B." This phrase specifies that B is a factor used to determine A or that B influences the determination of A. This phrase does not exclude that the determination of A may also be based on some other factor such as C. This phrase is also intended to cover embodiments in which A is determined based only on B. As used herein, the phrase "based on" is synonymous with the phrase "based at least in part on."

[0128] The phrases "in response to" and "in response to" describe one or more factors that trigger an effect. The phrase does not exclude the possibility that additional factors may influence or otherwise trigger the effect, either in conjunction with the specified factors or independently of the specified factors. That is, the effect may be responsive to these factors alone, or may be responsive to the specified factors as well as other unspecified factors. Consider the phrase "A is performed in response to B." The phrase specifies that B is a factor that triggers the execution of A or triggers a specific result of A. The phrase does not exclude that the execution of A may also be responsive to certain other factors, such as C. The phrase also does not exclude that the execution of A may be performed jointly in response to B and C. This phrase is also intended to cover embodiments in which A is performed only in response to B. As used herein, the phrase "in response to" is synonymous with the phrase "at least partially in response to." Similarly, the phrase "in response to" is synonymous with the phrase "at least partially in response to."

[0129] *** Within the present disclosure, different entities (which may be variously referred to as "units," "circuits," other components, etc.) may be described or claimed as being "configured to" perform one or more tasks or operations. This expression—[an entity] configured to [perform one or more tasks]—is used herein to refer to a structure (i.e., a physical thing). More specifically, this expression is used to indicate that this structure is arranged to perform one or more tasks during operation. A structure may be considered to be "configured to" perform a task even if the structure is not currently being operated. Therefore, an entity described or stated as "configured to" perform a task refers to a physical thing used to implement the task, such as a device, a circuit, a system with a processor unit, and a memory storing executable program instructions, etc. This phrase is not used herein to refer to an intangible thing.

[0130] In some cases, various units / circuits / components may be described herein as performing a set of tasks or operations. It should be understood that these entities are "configured to" perform those tasks / operations, even if not specifically stated.

[0131] The term "configured to" is not intended to mean "configurable to". For example, an unprogrammed FPGA would not be considered "configured to" perform a particular function. However, the unprogrammed FPGA may be "configurable to" perform that function. After being appropriately programmed, the FPGA may then be considered "configured to" perform the particular function.

[0132] For purposes of a U.S. patent application based on the present disclosure, reciting in a claim that a structure is “configured to” perform one or more tasks is expressly intended not to invoke 35 USC § 112(f) for that claim element. If the applicant wishes to invoke section 112(f) during prosecution of a U.S. patent application based on the present disclosure, it would use the “means for [performing the function]” structure to phrase the claim element.

[0133] Different "circuits" may be described in the present disclosure. These circuits or "circuitry" constitute hardware, which includes various types of circuit elements, such as combinational logic, clock storage devices (e.g., flip-flops, registers, latches, etc.), finite state machines, memories (e.g., random access memory, embedded dynamic random access memory), programmable logic arrays, etc. The circuit system can be custom designed or taken from a standard library. In various specific implementations, the circuit system may include digital components, analog components, or a combination of both as appropriate. Certain types of circuits may be generally referred to as "units" (e.g., decoding units, arithmetic logic units (ALUs), functional units, memory management units (MMUs), etc.). Such units are also referred to as circuits or circuit systems.

[0134] Thus, the disclosed circuits / units / components and other elements illustrated in the drawings and described herein include hardware elements, such as those described in the preceding paragraphs. In many cases, the internal arrangement of hardware elements in a particular circuit can be specified by describing the functionality of the circuit. For example, a particular "decode unit" may be described as performing the function of "processing an opcode for an instruction and routing the instruction to one or more of a plurality of functional units," meaning that the decode unit is "configured to" perform that function. For one skilled in the computer arts, this functional specification is sufficient to suggest a set of possible structures for the circuit.

[0135] In various embodiments, as described in the preceding paragraphs, circuits, units, and other elements may be defined by the functions or operations they are configured to implement. The arrangement of such circuits / units / components relative to each other and the way they interact form a microarchitecture definition of hardware, which is ultimately manufactured in an integrated circuit or programmed into an FPGA to form a physical implementation of the microarchitecture definition. Therefore, the microarchitecture definition is considered by those skilled in the art to be a structure from which many physical implementations can be derived, all of which fall into a broader structure described by the microarchitecture definition. That is, a technician with a microarchitecture definition provided in accordance with the present disclosure can implement the structure by coding a description of a circuit / unit / component in a hardware description language (HDL) such as Verilog or VHDL without excessive experimentation and using the application of ordinary technicians. HDL descriptions are often expressed in a way that can be displayed as functional. However, for those skilled in the art, the HDL description is a way to transform the structure of a circuit, unit, or component into the next level of specific implementation details. Such HDL descriptions may take the form of behavioral code (which is generally non-synthesizable), register transfer language (RTL) code (which is generally synthesizable compared to behavioral code), or structural code (e.g., a netlist specifying logic gates and their connectivity). The HDL description may be sequentially synthesized for a cell library designed for a given integrated circuit manufacturing technology, and may be modified for timing, power, and other reasons to obtain a final design database that is transmitted to the factory to generate masks and ultimately produce integrated circuits. Some hardware circuits or portions thereof may also be custom designed in a schematic editor and captured into an integrated circuit system design along with the synthesized circuit system. The integrated circuit may include transistors and other circuit elements (e.g., passive elements such as capacitors, resistors, inductors, etc.), as well as interconnects between transistors and circuit elements. Some embodiments may implement multiple integrated circuits coupled together to implement hardware circuits, and / or discrete elements may be used in some embodiments. Alternatively, the HDL design may be synthesized into a programmable logic array such as a field programmable gate array (FPGA), and may be implemented in an FPGA. This decoupling between the design of a set of circuits and the subsequent low-level implementation of those circuits often leads to a situation where a circuit or logic designer never specifies a specific set of structures for the low-level implementation beyond a description of what the circuits are configured to do, because that process is performed at different stages of the circuit implementation process.

[0136] The fact that many different low-level combinations of circuit elements can be used to achieve the same specification of a circuit results in a large number of equivalent structures for that circuit. As noted, these low-level circuit implementations can vary depending on variations in manufacturing technology, the foundry selected to manufacture the integrated circuit, the cell libraries provided for a particular project, etc. In many cases, the selection made by different design tools or methodologies to produce these different implementations can be arbitrary.

[0137] Furthermore, for a given embodiment, a single implementation of a particular functional specification of a circuit typically includes a large number of devices (e.g., millions of transistors). Thus, the shear volume of this information makes it impractical to provide a complete description of the low-level structure used to implement a single embodiment, let alone the large number of equivalent possible implementations. For this reason, the present disclosure describes the structure of the circuit using functional shorthand commonly used in the industry.

Claims

1. A device comprising: shader processor circuitry configured to execute a graphics program; A light ray intersection accelerator circuit system, the light ray intersection accelerator circuit system comprising: traversal circuitry configured to perform intersection tests between rays and bounding regions of acceleration data structures for a graphics scene; and transformation circuitry configured to transform a first coordinate of a ray from a first coordinate space in response to reaching a transformation node in the acceleration data structure to generate a second coordinate of the ray in a second coordinate space for a subsequent traversal of the acceleration data structure; and a ray cache circuit system configured to cache data accessible by the ray intersection accelerator circuit system, wherein an entry of the ray cache circuit system is configured to cache data for the ray, the data comprising: The first coordinate of the light ray in the first coordinate space; the second coordinate of the light ray in the second coordinate space; and Shared data for the ray applies to both the first coordinate and the second coordinate.

2. The apparatus according to claim 1, wherein the shared data comprises: visibility mask data, wherein the ray intersection accelerator circuitry is configured to terminate traversal of a portion of the acceleration data structure in response to determining that the visibility mask data for the ray does not match visibility mask data associated with the portion of the acceleration data structure.

3. The apparatus according to claim 1, wherein the shared data comprises: Quantized ray timestamp value; an indication of whether to process a primitive using a shader before transforming the coordinates of the ray back into the first coordinate space; a tmax value indicating a limit of a parameter interval of the ray; an indication of whether any arbitrary hit queries are being performed on the ray; an indication of whether to allow early termination of the traversal of the ray; an indication of whether to use a ray opacity flag or an opacity flag that is part of the acceleration data structure; and An identifier that identifies whether to use the first coordinate or the second coordinate at a current traversal point of the ray.

4. The device according to claim 1, wherein: The ray cache circuitry is inaccessible to the shader processor circuitry; and The ray buffer circuitry is included in a buffer / memory hierarchy including at least one higher level buffer accessible by the shader processor circuitry.

5. The device according to claim 1, wherein: The transformation node is an instance node; The first coordinate of the ray is in world space; and The second coordinate of the ray is in instance space.

6. The apparatus of claim 1 , wherein the entry of the ray cache circuitry is further configured to cache data of the ray, the data comprising: first marking data corresponding to the first coordinates; and Second marking data corresponding to the second coordinate.

7. The apparatus of claim 1, wherein the traversal circuitry is configured to use the second coordinates for traversal after the transform node and to transition back to using the first coordinates after traversal returns through the transform node during a depth-first traversal.

8. The apparatus of claim 1 , wherein the acceleration data structure comprises nested transformations, and the apparatus is configured to: processing a first transform level of the nested transform using the transform circuitry and entries of the ray cache circuitry; and A second transform level of the nested transform is processed using the shader processor circuitry.

9. The apparatus of claim 1 , wherein the ray intersection accelerator circuitry is configured to, in response to reaching the transform node and a bypass indicator, launch one or more threads on the shader processor circuitry to perform the transform rather than using the transform circuitry to perform the transform.

10. The apparatus of claim 1, wherein the acceleration data structure comprises a nested transformation, and the apparatus is configured to: using the transform circuitry to process a plurality of nested transforms; and For a given transform level, a pair of coordinates for the ray corresponding to the current level and the parent level is maintained in the ray cache circuitry.

11. The apparatus of claim 1 , wherein the apparatus is a computing device, the computing device further comprising: Central processing unit; monitor; and Network interface circuitry.

12. A method comprising: performing, by the graphics processor, an intersection test between the ray and the bounding region of the acceleration data structure for the graphics scene; transforming, by the graphics processor in response to reaching a transform node in the acceleration data structure, a first coordinate of a ray from a first coordinate space to generate a second coordinate of the ray in a second coordinate space for a subsequent traversal of the acceleration data structure; as well as The graphics processor caches the light data used for the intersection test in a light buffer, wherein the light data includes: The first coordinate of the light ray in the first coordinate space; the second coordinate of the light ray in the second coordinate space; and Shared data for the ray applies to both the first coordinate and the second coordinate.

13. The method according to claim 12, wherein the shared data comprises: a tmax value indicating a limit of a parameter interval of the ray; an indication of whether any arbitrary hit queries are being performed on the ray; and An identifier that identifies whether to use the first coordinate or the second coordinate at a current traversal point of the ray.

14. The method according to claim 12, wherein the cached light data further comprises: first marking data corresponding to the first coordinates; and Second marking data corresponding to the second coordinate.

15. The method according to claim 12, further comprising: A determination is made based on the bypass indicator whether to use hardware transform circuitry or shader transform to perform the transform.

16. A non-transitory computer readable medium having stored thereon instructions in a hardware description programming language, which when processed by a computing system, program the computing system to generate a computer simulation model, wherein the model represents a hardware circuit, the hardware circuit comprising: shader processor circuitry configured to execute a graphics program; A light ray intersection accelerator circuit system, the light ray intersection accelerator circuit system comprising: traversal circuitry configured to perform intersection tests between rays and bounding regions of acceleration data structures for a graphics scene; and transformation circuitry configured to transform a first coordinate of a ray from a first coordinate space in response to reaching a transformation node in the acceleration data structure to generate a second coordinate of the ray in a second coordinate space for a subsequent traversal of the acceleration data structure; and a ray cache circuit system configured to cache data accessible by the ray intersection accelerator circuit system, wherein an entry of the ray cache circuit system is configured to cache data for the ray, the data comprising: The first coordinate of the light ray in the first coordinate space; the second coordinate of the light ray in the second coordinate space; and Shared data for the ray applies to both the first coordinate and the second coordinate.

17. The non-transitory computer readable medium of claim 16, wherein the shared data comprises: visibility mask data, wherein the ray intersection accelerator circuitry is configured to terminate traversal of a portion of the acceleration data structure in response to determining that the visibility mask data for the ray does not match visibility mask data associated with the portion of the acceleration data structure.

18. The non-transitory computer readable medium of claim 16, wherein the shared data comprises: a tmax value indicating a limit of a parameter interval of the ray; an indication of whether any arbitrary hit queries are being performed on the ray; and An identifier that identifies whether to use the first coordinate or the second coordinate at a current traversal point of the ray.

19. The non-transitory computer readable medium of claim 16, wherein: The ray cache circuitry is inaccessible to the shader processor circuitry; and The ray buffer circuitry is included in a buffer / memory hierarchy including at least one higher level buffer accessible by the shader processor circuitry.

20. The non-transitory computer-readable medium of claim 16, wherein the traversal circuitry is configured to use the second coordinates for traversal after the transform node and to transition back to using the first coordinates after traversing back through the transform node during a depth-first traversal.

Images