Ray intersection circuit with parallel ray testing

Abstract

This disclosure relates to a ray intersection circuit with parallel ray testing. The disclosed technique relates to ray intersection processing for ray tracing. In some embodiments, the ray intersection circuit traverses an accelerated data structure organized in a spatial form and includes boundary region circuitry configured to test in parallel whether a ray intersects with multiple distinct boundary regions indicated by nodes of the data structure. Shader circuitry can execute ray intersection instructions to invoke the traversal of the ray intersection circuitry, and the traversal can generate intersection results. The shader circuitry can shade the intersection primitives based on the intersection results. Compared to conventional techniques, the disclosed technique, by sharing processing between the intersection circuitry and the shader processor, can improve performance, reduce power consumption, or achieve both.

Description

[0001] This application is a divisional application of the invention patent application filed on July 30, 2021, with application number 202110869849.2 and invention title "Light Intersection Circuit with Parallel Light Detection". Technical Field

[0002] This disclosure relates generally to ray tracing in a graphics processor, and more specifically to circuitry configured to detect the intersection between rays and graphics primitives. Background Technology

[0003] In computer graphics, ray tracing is a rendering technique used to generate images by tracing the paths of light as pixels in an image plane and simulating the effects of their encounters with virtual objects. Ray tracing allows for resolution of visibility in 3D between any two points in a scene, which is also where most of its computational cost comes from. A typical ray tracer samples the path of light across the scene in the opposite direction of its propagation, starting from the camera and spreading 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 only tracing the light visible to the camera. The system can be modeled on a rasterizer, where the light simply stops at a first surface and a shader (similar to a fragment shader) is invoked to calculate the color. More common secondary effects (where the exchange of lighting between scene elements, such as diffuse reflection and transmission) are also modeled. Shaders that evaluate the surface reflection properties can invoke additional intersection queries (e.g., to generate new rays) to capture incident lighting from other surfaces. This recursive process has many expressions, but is commonly referred to as path tracing.

[0004] Compared to traditional rasterization systems, graphics processors that implement ray tracing typically deliver more realistic scenes and lighting effects. However, ray tracing is often computationally expensive. Improvements to ray tracing techniques can enhance the realism of graphical scenes, improve performance (e.g., allowing more rays to be traced per frame, tracing in more complex scenes, or both), and reduce power consumption (which can be particularly important in battery-powered devices). Summary of the Invention

[0005] According to one aspect of this disclosure, an apparatus is provided, comprising: a shader circuit configured to execute a ray intersection instruction for a first SIMD group, wherein the instruction indicates coordinate information of a first ray set in a graphics scene; and a ray intersection circuit configured to execute the ray intersection instruction in hardware, wherein executing the ray intersection instruction by the ray intersection circuit includes performing the following operations: traversing a plurality of nodes in a spatially organized accelerated data structure, wherein the nodes include nodes indicating coordinates of boundary regions and nodes indicating primitives in the graphics scene, wherein the ray intersection circuit includes a plurality of node tester circuits, the plurality of node testers... The circuit is configured to perform arithmetic operations for intersecting a ray with a boundary region corresponding to a node; and in response to the traversal of the ray intersection circuit reaching a leaf node indicating one or more primitives of the accelerated data structure, to invoke the formation of a second SIMD group for processing by the shader circuit, wherein the second SIMD group operates on a second ray set that only partially overlaps with the first ray set, wherein the second SIMD group includes one or more additional instructions to determine whether a ray in the second ray set intersects with the one or more primitives; and wherein the shader circuit is configured to shade one or more primitives indicated as intersecting based on the execution result of the second SIMD group.

[0006] According to another aspect of this disclosure, a method is provided comprising: executing a ray intersection instruction for a first SIMD group by shader circuitry, wherein the instruction indicates coordinate information of a first ray set in a graphics scene, wherein executing the ray intersection instruction comprises: traversing a plurality of nodes in a spatially organized accelerated data structure by ray intersection circuitry implementing the ray intersection instruction in hardware, wherein the nodes include a plurality of nodes indicating coordinates of a boundary region and a plurality of nodes indicating primitives in the graphics scene, wherein the traversal comprises performing an intersection test between the boundary region and rays in the first ray set using a plurality of node tester circuitry of the ray intersection circuitry; and, in response to the traversal reaching a leaf node indicating one or more primitives in the accelerated data structure, invoking the formation of a second SIMD group by the ray intersection circuitry for processing by the shader circuitry, wherein the second SIMD group operates on a second ray set that only partially overlaps with the first ray set, wherein the second SIMD group executes one or more other instructions to determine whether rays in the second ray set intersect with the one or more primitives; and shading one or more primitives indicated as intersecting based on the execution result of the second SIMD group by the shader circuitry.

[0007] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided thereon storing design information specifying at least a portion of a design of a hardware integrated circuit in a format recognizable by a semiconductor manufacturing system, the semiconductor manufacturing system being configured to use the design information to manufacture the circuit according to the design, wherein the design information specifies the circuit comprising: a shader circuit configured to execute ray intersection instructions for a first SIMD group, wherein the instructions indicate coordinate information of a first ray set in a graphical scene; and a ray intersection circuit configured to execute the ray intersection instructions in hardware, wherein executing the ray intersection instructions by the ray intersection circuit comprises performing the following operations: traversing a plurality of nodes in a spatially organized accelerated data structure, wherein the nodes include coordinates indicating boundary regions. The target node and the node indicating the primitives in the graphics scene, wherein the ray intersection circuit includes a plurality of node tester circuits configured to perform arithmetic operations for intersecting ray with boundary regions corresponding to nodes; and in response to the traversal of the ray intersection circuit reaching a leaf node indicating one or more primitives in the accelerated data structure, invoking the formation of a second SIMD group for processing by the shader circuit, wherein the second SIMD group operates on a second ray set that only partially overlaps with the first ray set, wherein the second SIMD group includes one or more other instructions to determine whether a ray in the second ray set intersects with the one or more primitives; and wherein the shader circuit is configured to shade one or more primitives indicated as intersecting based on the execution result of the second SIMD group. Attached Figure Description

[0008] Figure 1A This is an illustration showing an overview of exemplary graphics processing operations according to some implementation schemes.

[0009] Figure 1B This is a block diagram illustrating exemplary graphical units according to some implementation schemes.

[0010] Figure 2 This is a diagram illustrating an exemplary ray tracing process using ADS according to some implementation schemes.

[0011] Figure 3A This is a block diagram illustrating an exemplary graphics processor including shader processor circuitry and intersecting circuitry according to some embodiments.

[0012] Figure 3B This is a flowchart illustrating an exemplary method for detecting ray intersections using a ray intersection circuit according to some implementation schemes.

[0013] Figure 4 This is a block diagram illustrating an exemplary ADS tree structure according to some implementation schemes.

[0014] Figure 5 This is a diagram illustrating an exemplary depth-first traversal of a BVH tree using a ray stack according to some implementations.

[0015] Figure 6 This is a block diagram illustrating exemplary connectivity between a ray-intersecting circuit and other graphic circuits according to some embodiments.

[0016] Figure 7 This is a block diagram illustrating a detailed exemplary parallel boundary region test circuit according to some implementation schemes.

[0017] Figure 8 This is a diagram illustrating an exemplary organization of a ray shader core space (SCS) for storing ray data according to some embodiments.

[0018] Figure 9 This is a diagram illustrating an exemplary node data structure according to some implementation schemes.

[0019] Figure 10 This is a diagram illustrating an exemplary size-configurable leaf data structure according to some implementations.

[0020] Figure 11 This is a diagram illustrating an exemplary memory layout of an ADS tree structure with variable-size leaf nodes according to some embodiments.

[0021] Figure 12 This is a diagram illustrating an exemplary data flow between intersecting circuits, node test circuits, memory regions, and SIMD groups executed by shader circuits according to some embodiments.

[0022] Figure 13 This illustrates the relationship with some implementation schemes. Figure 12 A flowchart of an exemplary method associated with the data flow.

[0023] Figure 14A This is a block diagram illustrating an exemplary technique for dynamically forming a SIMD group for primitive testing, according to some implementation schemes.

[0024] Figure 14B This is a flowchart illustrating an exemplary method for dynamically forming a SIMD group for primitive testing, according to some implementation schemes.

[0025] Figure 15 This is a diagram illustrating an exemplary many-to-many mapping between boundary regions and primitives according to some implementation schemes.

[0026] Figure 16This is a flowchart illustrating an exemplary method for generating spatially organized data structures with many-to-many mappings, according to some implementation schemes.

[0027] Figure 17 This is an illustration showing an exemplary dynamic formation of a SIMD group used for ray transformation when traversing an accelerated data structure, according to some implementations.

[0028] Figure 18 This is a flowchart illustrating an exemplary method for dynamically forming a SIMD group for ray coordinate transformation, according to some implementation schemes.

[0029] Figure 19A This is an illustration showing an exemplary case where, according to some implementations, different rays are currently pointing to different nodes in the ADS during traversal.

[0030] Figure 19B This is a block diagram illustrating an exemplary group control circuit according to some implementation schemes.

[0031] Figure 19C This is an illustration of a specific implementation of an exemplary list of separate links for grouping light rays, according to some embodiments.

[0032] Figure 20 This is a flowchart illustrating an exemplary method for grouping rays during ADS traversal according to some implementation schemes.

[0033] Figure 21 This is a flowchart illustrating an exemplary method for processing light according to some implementation schemes.

[0034] Figure 22A This is a block diagram illustrating an exemplary cache memory hierarchy accessible to the shader core according to some implementations.

[0035] Figure 22B This is a block diagram illustrating an exemplary cache memory hierarchy accessible to multiple shader cores and their coprocessors according to some implementations.

[0036] Figure 23 This is a diagram illustrating exemplary thread groups, shader cores, and device memory space according to some implementation schemes.

[0037] Figure 24 This is a block diagram illustrating exemplary cache organization and coherence points for different memory spaces according to some implementation schemes.

[0038] Figure 25 This is a flowchart illustrating an exemplary method of using shader memory space according to some implementation schemes.

[0039] Figure 26 This is a block diagram illustrating an exemplary computing device according to some implementation schemes.

[0040] Figure 27 This is an illustration showing an exemplary application of a system or device according to some implementation schemes.

[0041] Figure 28 This is a block diagram illustrating an exemplary computer-readable medium for storing circuit design information according to some embodiments. Detailed Implementation

[0042] This disclosure describes various ray tracing techniques, and specifically describes ray intersection techniques. Figures 1A to 2 It provides an overall overview of graphics processing and ray tracing. Figures 3A to 6 An exemplary implementation of a light-intersecting accelerator circuit is provided.

[0043] Figures 7 to 21 Additional details are provided regarding the implementation scheme of the ray intersection circuit and its interaction with other graphics circuits. Specifically, Figure 7 A parallel node test circuit is shown. Figure 8 The memory space used for sharing ray data between shaders and intersection circuits is shown. Figures 9 to 11 An exemplary data structure and memory space are shown. Figures 12 to 13 An exemplary overall data flow is shown. Figures 14A to 14B An exemplary technique for dynamically forming SIMD groups for primitive testing is shown. Figures 15 to 16 It provides a many-to-many mapping between boundary regions and primitives. Figures 17 to 18 Exemplary techniques for dynamically forming SIMD groups during traversal (e.g., for ray transformation) are provided, as shown in Figures 19 to 19. Figure 20 Exemplary ray grouping techniques for node testing are provided, and Figure 21 A general flowchart for ray intersection operations is provided. Figures 21 to 25 Details about the extent of the shader core memory space are provided.

[0044] Figure 26 An exemplary computing device, which may include a graphics processor, is shown. Figure 27 An exemplary application is shown, and Figure 28 An exemplary computer-readable medium for storing circuit design information is shown.

[0045] Overview of Graphics Processing

[0046] See Figure 1AThe diagram illustrates a flowchart of an exemplary processing flow 100 for processing graphics data. In some embodiments, the transformation and lighting process 110 may involve processing lighting information of vertices received from an application based on defined light source positions, reflectivity, etc., assembling vertices into polygons (e.g., triangles), and / or converting polygons to the correct size and orientation based on their position in three-dimensional space. The clipping process 115 may involve discarding polygons or vertices outside the visible area. The rasterization process 120 may involve defining segments within each polygon and assigning initial color values ​​to each segment, for example, based on the texture coordinates of the polygon vertices. Segments may specify the properties of the pixels they overlap, but the actual pixel properties may be determined based on combining multiple segments (e.g., in a frame buffer) and / or ignoring one or more segments (e.g., if they are covered by other objects). The shading process 130 may involve altering pixel components based on lighting, shadows, bump mapping, translucency, etc. Shaded 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 procedures. Therefore, in various embodiments, Figure 1A The exemplary elements can be executed in various sequences, in parallel, or omitted. Additional processing procedures can also be implemented.

[0047] See now Figure 1B A simplified block diagram of an exemplary graphics unit 150 according to some embodiments is shown. In the exemplary embodiments, the graphics unit 150 includes a programmable shader 160, a vertex pipe 185, a fragment pipe 175, a texture processing unit (TPU) 165, an image writing unit 170, and a memory interface 180. In some embodiments, the graphics unit 150 is configured to use the programmable shader 160 to process both vertex data and fragment data, and the programmable shader may be configured to process the graphics data in parallel using multiple execution pipelines or instances.

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

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

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

[0051] In the illustrated implementation, TPU 165 is configured to schedule fragment processing tasks from programmable shader 160. In some implementations, TPU 165 is configured to prefetch texture data and assign initial colors to fragments for further processing by programmable shader 160 (e.g., via memory interface 180). TPU 165 may be configured to provide fragment components, for example, in normalized integer or floating-point format. In some implementations, TPU 165 is configured to provide fragments in a 2x2 format, grouped into sets of four (“fragment quadruples”), which are pipelined by a set of four programmable shaders 160.

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

[0053] In the illustrated example, graphics unit 150 includes a ray intersection accelerator (RIA) 190, which may include hardware configured to perform various ray intersection operations, as detailed below.

[0054] Ray Tracing Overview

[0055] Ray tracing typically samples the path of light across a scene in the reverse direction of its propagation, starting from the camera and spreading into the scene, rather than from the light source (this is sometimes called "backward ray tracing"). A ray can be defined using the origin (O), direction (D), and parameter interval (T) that define the active part of the ray. Therefore, a ray can be thought of as a line segment. The graphics processor can perform various queries on a given ray. For example, a "closest hit" query locates the nearest intersecting geometry along the ray within the parameter interval (this is perhaps the most common type of query). A "any hit" query locates any intersecting geometry along the ray within the parameter interval. This type of query can be used for shadow rays, for example, to determine whether a point in the scene is visible to light or occluded. Once the intersecting geometry is determined, it can be shaded based on the intersection, and more rays can then be generated, for example, from reflective surfaces for intersection testing.

[0056] Ray intersection computation is typically facilitated through Accelerated Data Structures (ADS). To efficiently perform ray intersection queries, spatial data structures can reduce the number of surface intersection tests for rays, thus accelerating the query process. A common type of ADS is the Boundary Volume Hierarchical Structure (BVH), where surface primitives are enclosed in a hierarchical structure of geometric surrogate volumes (e.g., boxes) that test intersections more cheaply. These volumes may be referred to as boundary regions. By traversing the data structure and performing surrogate intersection tests along the path, the graphics processor locates a conservative set of candidate intersecting primitives for a given ray. A common form of BVH uses 3D Axis-Aligned Bounding Boxes (AABBs). Once constructed, an AABB BVH is available for all ray queries and is a viewpoint-independent structure. In some implementations, for each distinct mesh in the scene, these structures are constructed once in the object space or model space of that object, and the rays are transformed from world space to local space before traversing the BVH. This allows for the geometric instantiation of a single mesh with many rigid transformations and material properties (similar to instantiation in rasterization). Animated geometry often requires reconstructing the data structure (sometimes with a less expensive update operation called "refit"). For non-real-time use cases where millions or billions of rays are tracked for a single scene in a single frame, the cost of ADS construction is entirely amortized to the point of being "free." However, in real-time environments, there is often a subtle trade-off between construction and traversal costs, where constructing a more efficient structure is typically more expensive.

[0057] In some implementations discussed in detail below, the intersecting circuit is configured to traverse a BVH ADS that uses a 3D axis-aligned box as its boundary volume. The ADS may have a maximum branching factor (e.g., 2, 4, 8, 16, etc.) that does not assume triangular geometry and flexible user-defined payloads (e.g., the content at the foliage).

[0058] Figure 2 This is an illustration of an exemplary ray tracing process using ADS according to some implementations. ADS building element 215 receives geometric data 210 from the graphics scene and generates ADS 220. ADS building element 215 can update a previous ADS by temporarily building the ADS or, for example, based on changes in the position of animated objects. Camera shader element 225 (which may also be referred to as a source shader) generates rays originating from the viewpoint (which may be referred to as master rays, camera rays, or eye rays). These rays are processed by ADS traversal element 230. Traversal includes operations performed through boundary region (e.g., box) test element 235 and primitive test element 240, and provides the intersection results of the resulting shader element 245 (which may be referred to as a hit shader). Shading can generate additional new rays for ADS traversal. Shading can generate fragment data for building a frame buffer at element 250.

[0059] In various disclosed embodiments, the intersecting circuitry (e.g., a ray intersection coprocessor or dedicated circuitry included in the graphics processor) is configured to perform ADS traversal 230 and boundary region testing 235. In some embodiments, the ray intersection circuitry generates work for the shader processor during traversal, for example, for coordinate transformation or primitive testing. The shader processor may execute SIMD sets to perform the various operations described below.

[0060] Because there are multiple types of SIMD groups discussed in this paper, the following labels will be used: "clique-A" refers to the conventional SIMD group that executes graphics programs (and can execute ray intersection instructions), "clique-S" refers to the SIMD group for coordinate transformation formed by ray intersection circuits, and "clique-T" refers to the SIMD group for primitive testing formed by ray intersection circuits, as detailed below.

[0061] Exemplary light intersecting circuit

[0062] Figure 3A This is a block diagram illustrating an exemplary graphics processor including shader processor circuitry and intersecting circuitry according to some embodiments. In the illustrated embodiment, the system includes a programmable shader 160 (which executes a graphics program) and a ray intersection accelerator (RIA) 190 (which is an example of a dedicated intersecting circuitry).

[0063] In the illustrated example, programmable shader 160 receives and executes intersecting ray instructions included in the graphics program. Intersecting ray instructions may be, for example, single instruction multiple data (SIMD) instructions and may specify multiple rays. In response, programmable shader 160 sends an intersecting ray command to RIA 190. The command may include a pointer to a data structure pointing to the ray being processed.

[0064] In the illustrated example, RIA 190 is configured to produce intersection results based on traversal of a spatially organized data structure (e.g., BVH) for the scene. RIA 190 includes boundary region testing circuitry that can be configured to test rays in parallel against multiple boundary regions (e.g., boxes). In some implementations, the intersection results indicate the set of primitives to be tested against the intersection; for example, RIA 190 can initiate one or more SIMD groups to execute on programmable shader 160 for primitive testing, as referenced below. Figures 14A to 14B As discussed. In other implementations, RIA 190 can perform primitive tests, and the intersection results can directly indicate the intersecting primitives.

[0065] The term "SIMD group" is intended to be interpreted in its well-known sense, referring to a set of threads for which processing hardware processes the same instructions in parallel using different input data for different threads. Various types of computer processors may include a collection of pipelines configured to execute SIMD instructions. For example, graphics processors typically include programmable shader cores configured to execute instructions in a SIMD manner for a set of associated threads. Other examples of names commonly used for SIMD groups include: wavefront, clique, or warp. A SIMD group can be part of a larger group of threads, which can be split into multiple SIMD groups based on the computer's parallel processing capabilities. In some implementations, each thread is assigned to a hardware pipeline that fetches operands for that thread and executes the specified operation in parallel with other pipelines in the set of threads. It should be noted that a processor can have a large number of pipelines, allowing multiple individual SIMD groups to execute in parallel. In some implementations, each thread has a private operand storage device, for example, in a register file. Thus, reading a specific register from the register file provides a version of the register for each thread in the SIMD group.

[0066] It should be noted that in other implementations, various techniques disclosed as being executed using SIMD groups can be performed using a single thread. Therefore, the SIMD examples discussed herein are not intended to limit the scope of this disclosure. In various implementations, however, SIMD techniques can improve performance relative to non-SIMD techniques, especially considering that graphics processors typically include a large amount of parallel hardware.

[0067] Figure 3B This is a flowchart illustrating an exemplary method for detecting ray intersections using a ray intersection circuit according to some implementation schemes. Figure 3B The methods shown can be used in conjunction with any of the computer circuit systems, systems, devices, elements, or components (and other devices) disclosed herein. In various embodiments, some of the method elements shown may be performed concurrently in a different order than that shown, or may be omitted. Additional method elements may also be performed as needed.

[0068] At 350, in the illustrated implementation, the graphics shader circuitry (e.g., programmable shader 160) executes a ray intersection instruction that indicates the origin and direction information for a set of one or more rays in the graphics scene.

[0069] At 360, in the illustrated implementation, the ray intersection circuit (e.g., RIA 190) traverses multiple nodes in an accelerated data structure organized in a spatial form in response to a ray intersection command, wherein the nodes of the data structure indicate coordinates corresponding to boundary regions in the graphics scene.

[0070] At 370, in the illustrated implementation, the boundary region test circuit (e.g., circuit 310) tests in parallel during traversal whether a ray in the ray set intersects with a boundary region in the boundary region indicated by the node of the data structure.

[0071] At 380, in the illustrated implementation, the device determines information about one or more graphic primitives that intersect with a corresponding ray in a set of one or more rays.

[0072] At 390, in the illustrated implementation, the graphics shader circuit shades one or more specified graphics primitives based on intersecting rays.

[0073] and Figure 3B The following discussion of various implementation schemes of the method provides a high-level overview of the various ray intersection techniques that will be discussed in more detail below.

[0074] In some embodiments, the boundary region testing circuit includes multiple boundary region testers configured to determine whether a ray intersects a boundary region and configured to perform tests on multiple boundary regions in parallel. The boundary region testing circuit may also include a common computing circuit configured to perform one or more operations whose outputs are shared by the boundary region testers. In some embodiments, the boundary region testing circuit further includes a boundary region data cache, a ray data cache, and a result sorting circuit configured to sort intersection results from the multiple boundary region testers based on their distance to the origin of the ray being tested.

[0075] In some implementations, the boundary region test circuit is configured to test multiple rays in parallel for multiple different boundary regions. In these implementations, the boundary region test circuit can simultaneously test N rays for M boundary regions.

[0076] In some embodiments, the apparatus is configured to store ray data for the set of one or more rays in a shader memory space (which may be referred to as the ray shader core space) accessible to the graphics shader circuitry and the ray intersection circuitry. In some embodiments, the graphics shader circuitry is configured to generate one or more additional rays based on the shading of one or more specified graphics primitives, and to execute ray intersection instructions for the one or more additional rays.

[0077] In some implementations, the accelerated data structure is hierarchical, and the first node is a leaf node of the upper-level accelerated data structure, which has child nodes in the lower-level accelerated data structures. (See below for reference) Figure 4 Examples of such hierarchical structures will be discussed in more detail. Lower-level accelerated data structures can correspond to a graphical model that is instantiated multiple times in a graphical scene. Ray intersection circuits can be configured to form SIMD groups (which may be referred to as clique-S) to transform the coordinates of one or more rays arriving at the first node to the model space of the graphical model instance.

[0078] In some implementations, ADS has a relatively high branching factor, for example, such that one or more nodes of the accelerated data structure include four or more boundary regions and four or more child nodes. In some implementations, even larger branching factors, such as octet, decetet, twelfth, sixteenth, etc., can be supported. In some implementations, ADS supports many-to-many mappings between boundary regions and primitives, for example, such that the accelerated data structure includes nodes with at least one boundary region for which multiple primitives are designated as children, and the accelerated data structure includes at least one primitive for which multiple boundary regions are designated as parents.

[0079] In some implementations, the ray-crossing circuit is configured to form a SIMD group (clique-T) to test the ray set for the primitives corresponding to the leaf nodes of the data structure.

[0080] In some implementations, the ray intersection circuit system is configured to group portions of the ray set into multiple groups using a grouping circuit based on the next target data structure of the ray, where testing is performed based on these groups. This improves the temporal location of access to the node data.

[0081] An overview of an exemplary tree structure and depth-first traversal.

[0082] Figure 4 This is a block diagram illustrating a simplified exemplary ADS tree structure according to some embodiments. In the illustrated example, the tree includes nodes 0-5 and leaves L0-L8. Each node may include two or more boundary regions, each pointing to a child node or one or more primitives. Conceptually, each node may store the boundaries of its children, but not its own boundaries (this may be implied based on its parent node). In some embodiments, each leaf represents a primitive, such as a triangle, which is included in the boundary region of its parent node. Detailed exemplary data structures for nodes and leaves are referenced below. Figures 9 to 10 Let's have a discussion.

[0083] In the illustrated example, each node has at most two child nodes, but a larger branching factor can be achieved in various implementations. In some implementations, the “node test” of a node includes boundary tests corresponding to multiple boundary regions of its child nodes. An internal node is a node whose children are all nodes, such as… Figure 4 Nodes 0 and 2 in the example. Leaf nodes are nodes whose children are all leaves, such as... Figure 4 Nodes 1, 3, and 5 in the example. Mixed nodes have a mixture of leaves and child nodes, such as... Figure 4 Node 4 in the diagram. Tree-based ADS structures can be traversed using breadth-first search, depth-first search, or a combination of both, for example, to determine one or more primitives for which test rays should intersect.

[0084] Figure 5 This is a diagram illustrating an exemplary depth-first traversal of a BVH tree using a ray stack according to some implementations. In the illustrated example, nodes shown with dashed lines do not intersect with the ray being tested, and solid triangles represent intersecting primitives.

[0085] Consider corresponding to Figure 5The following is an exemplary traversal of the situation. First, the ray is tested against the root node 0, which corresponds to the root boundary region of the scene extent. Whenever a hit occurs, the children of that node are tested. In this example, both nodes 1 and 2 are hits, so the traversal continues to the children of node 2, and node 1 is pushed onto the ray stack of the tested ray. Boxes 5 and 6 are both hits, and node 6 is pushed onto the stack. When testing the children of node 5, node 7 is a hit, while node 8 is a miss, so nothing is pushed onto the stack, and the traversal proceeds to the children of node 7. The boundary region of node 11 and the leaf of node 7 are both hits, so node 11 is pushed onto the stack, and the leaf is tested for primitive intersection.

[0086] Figure 5 The ray stack illustrates the state of the stack during an exemplary traversal, with nodes 11, 6, and 1 on the stack. At this point, a leaf has been reached, and the deferred portion of the tree should be traversed next; this can be called backtracking. The intersection circuit pops a leaf from the stack and performs an intersection test on the primitive node 11. Then, the intersection circuit system pops a child node 6 from the stack, both of which are missed. Nodes 12 and 13 are not reached during the traversal because their parent node 9 is not hit. The intersection circuit then pops node 1, and its child nodes 3 and 4 are both missed.

[0087] It's important to note that the presence of a parent node could be a hit for several reasons, even if its child nodes don't exist. First, due to the nature of ADS, the parent boundary region has a larger combined volume than its child, so a ray intersecting the parent boundary region might not intersect the child region. Another reason is that rays can be shortened based on detected intersections with primitives. For example, after hitting a primitive child of node 7, the length of the active portion of the array can be clipped so that it doesn't advance through the intersection. In some cases, this might result in nodes 3 and 4 being missed. The traversal can end when the stack is empty and there are no other paths to search, and the intersection circuit can return a result.

[0088] It should be noted that the various techniques disclosed can be applied to other data structure organizations (e.g., non-tree acceleration or non-BVH data structures). The disclosed data structures are included for illustrative purposes and are not intended to limit the scope of this disclosure. Similarly, various node structures can be implemented using one or more different node types.

[0089] Exemplary RIA connectivity and area test circuit

[0090] Figure 6This is a block diagram illustrating exemplary connectivity between a ray-intersecting circuit and other graphics circuitry according to some embodiments. In the illustrated embodiment, the graphics processor includes instruction fetching and scheduling circuitry 610, a shader pipeline 660 (e.g., which may be included in a programmable shader 160), L0 memory circuitry 615, a routing network 620, L1 memory device 630, advanced cache / memory circuitry 640, a texture processing unit 190, and a texture processing unit 165.

[0091] The L0 storage device can be configured to store operands processed by the shader pipeline 660. The L1 storage device 630 can be configured to store graphics data at a higher level, also available to the texture processing unit 165 and the RIA 190. The routing network 620 facilitates the movement of operands between channels in the shader pipeline (e.g., between threads within a SIMD group), between different storage levels, and between the L1 storage device and different units (such as the RIA 190 and the texture processing unit 165). For example, the advanced cache / memory circuitry 640 may include one or more L2 caches or system memories. Various storage or cache elements can implement appropriate addressing or cache organization schemes. Data can be stored... Figure 6 Exemplary data structures in one or more storage elements are referenced below. Figures 8 to 11 Let's have a discussion.

[0092] In some implementations, the graphics program acquired by circuitry 610 may include ray intersection instructions. Based on these instructions, shader pipeline 660 may send ray intersection commands to RIA 190, which may access associated ray and geometry data via L1 storage 630. RIA 190 may also dynamically form SIMD groups for shader pipeline 660 using communications via routing network 620.

[0093] Notice, Figure 6 The circuit organization disclosed herein is included for illustrative purposes and is not intended to limit the scope of this disclosure. In other embodiments, any of a variety of organization of dedicated circuitry for ray intersection and programmable shader circuitry may be implemented.

[0094] Figure 7 This is a block diagram illustrating a detailed exemplary parallel boundary region test circuit according to some embodiments. In the illustrated example, the parallel tester circuit 710 receives ray data and boundary region data for multiple boundary regions and outputs results indicating whether the rays intersect with the boundary regions. The parallel tester 710 includes a boundary region data cache 717, a ray data cache 720, a common computing circuit 725, a boundary region tester 730A-703N, and a result sorting circuit 735.

[0095] In some implementations, the parallel tester 710 is a node tester configured to test up to N boundary regions, where each node in the ADS includes up to N child nodes. In implementations with M programmable shader instances, the RIA 190 may include multiple parallel testers 710, for example, for each programmable shader 2, 4, 8, etc. In these implementations, each node tester may test up to M nodes per clock cycle, per programmable shader core. In some implementations (e.g., depth-first traversal discussed herein), a given ray is tested against at most one node at a time.

[0096] In some implementations, the boundary region data cache 715 and the ray data cache 720 are configured to store node and ray data, respectively, for use in the current test and for potential reuse in subsequent tests. These caches are capable of maintaining throughput for node tests corresponding to each clock cycle of each tester. For testing, both ray and boundary region information may be required, therefore cache entries can be locked for reading until both information becomes available. This is discussed in detail below. Figure 9 Detailed exemplary encoding for boundary region data is provided. In some implementations, grouping rays targeting the same next node can improve cache performance and reduce bandwidth to the advanced cache, as described in references 19A to 19B below. Figure 19C As detailed above.

[0097] In some implementations, the common computation circuit 725 is configured to perform computations common to all tested boundary regions. This may include determining boundaries represented using a compressed quantization format. Alternatively, this may include common ray calculations, such as determining the reciprocal of a ray and the test point of the ray. In some implementations, the common computation is performed with higher floating-point precision than the boundary region testing.

[0098] In some implementations, the boundary region tester 730 is configured to test whether a ray intersects with a representation of the boundary region (however, it should be noted that false positives may be included in implementations with quantization). For box-shaped boundary regions, these testers may perform a planar test (e.g., finding the distance of each ray to the six sides of each box and comparing these values ​​to determine whether the ray has hit the box). Generally, the boundary region tester 730 may include circuitry configured to perform arithmetic operations associated with the type of test being performed, and this circuitry may be pipelined. In some implementations, the boundary region tester 730 utilizes low-precision floating-point arithmetic and selects a rounding mode such that the calculated intersection result of the three planes is rounded down toward the ray (towards the ray) and the intersection result of the three opposing planes is rounded up away (away from the ray), to ensure that the boundary region test is conservative and does not produce false negatives.

[0099] In some implementations, the result sorting circuit 735 is configured to sort the hit results (e.g., based on their distance from the ray origin) and output the results for further traversal. Therefore, non-leaf nodes can be pushed onto a stack based on this sorting. In some implementations, any leaf node can be grouped into a single stack entry. In some implementations, the sorting can affect the traversal of the ADS; for example, child nodes corresponding to closer hits can be traversed preferentially during depth-first search.

[0100] In some implementations, the parallel tester circuit 710 is configured to store the value of the internal (T) parameter of the intersecting ray with the boundary region (and this value can be stored with higher precision than that of a planar test). This value may be referred to as the T local value and can be stored in a stack entry and retrieved for use as the digital ray origin for a sub-boundary region planar test.

[0101] In some implementations, multiple rays can be tested in parallel for the same node, rays can be tested in parallel for multiple nodes, or both. For example, RIA 190 may include multiple parallel testers 710 to process all or a portion of a set of rays in parallel. In some implementations, each boundary region tester 730 may be configured to test multiple rays in parallel for a boundary region.

[0102] Exemplary data structures and overall data flow

[0103] Figure 8 This is an illustration of an exemplary organization of a ray shader core space (SCS) for storing ray data, according to some embodiments. The ray SCS is a dynamically allocable private memory space that allows data to be shared between different thread groups. Furthermore, the ray SCS allows data to be shared between different SIMD groups (e.g., between clique-A, clique-S, clique-T, etc.) from the same data master and startup slot. The following is further elaborated... Figure 8 The discussion concludes with a more detailed explanation of the concepts of data master device and graphics initiation. A graphics processor may also include other memory spaces, such as thread-private address spaces, thread group address spaces, and device address spaces.

[0104] For example, the ray shader core space can be allocated at the start of graphics startup. The shader core space can advantageously allow sharing between different types of SIMD groups (e.g., clique-A type and clique-T or clique-S type), allow fewer bits to be used for addressing ray data (relative to addresses using larger memory spaces), allow dynamic allocation of pages of data, or any combination thereof. For example, the technique for dynamic private memory allocation discussed in U.S. Patent Application No. 16 / 804,128, filed February 28, 2020, can be used to dynamically allocate pages for the ray shader core space.

[0105] In the illustrated implementation, the shader core space includes areas for ray core data 820, ray stack data 830, ray extension data 840, and a token buffer 810. In some implementations, the SCS may also include a context switching buffer (not shown) to handle context saving. The shader may allocate space in the SCS using explicit instructions (e.g., allocate ray instructions) and allocate free space via another explicit instruction (e.g., release ray instructions after processing of the ray is complete).

[0106] In some implementations, the token buffer 810 provides temporary space for communication between the RIA 190 and the SIMD groups initiated by the RIA 190 on the shader. In some implementations, these SIMD groups receive ray identifiers as part of their input data to access ray data already allocated in the SCS, for example, before intersecting ray commands. When a SIMD group is formed (e.g., a clique-T for primitive testing or a clique-S for transformation), the RIA 190 can populate the buffer with the thread data required by the SIMD group, and the SIMD group can write the results back to the same buffer. In some implementations, the token buffer stores pointers to information used for primitive testing or coordinate transformation. For example, this could include pointers to leaf addresses for intersecting tests, and a count of threads sharing the same ray ID (which may be packed into the same clique-T) and their corresponding thread identifiers. As another example, this could include pointers to rays used for coordinate transformation.

[0107] In some implementations, the ray stack data 830 contains stack entries of rays during traversal, for example, as referenced above. Figure 5 The discussion focuses on the fact that each ray can have dedicated space for its stack, but the stacks of all rays can be interleaved, which reduces the footprint and the total number of pages used for the stack SCS. The maximum size of the stack SCS can be determined based on one or more of the following: the size of the ray population, the number of levels in the ADS, and the branching factor of the ADS.

[0108] Ray core data 820 indicates the origin, direction, and active portion of each ray and can be indexed using ray identifiers. This area may also include other data, such as ε and axis for watertight ray traversal. Ray extension data 840 may include additional data, such as intersection results, ray differences, performance counters, etc., that are less frequently accessed by the software shader. Separating ray core data 820 and extension data 840 improves cache utilization.

[0109] Multiple “startups” can be executed to render graphics data frames. In some implementations, a startup is a unit of work from a single context, which may include multiple threads to be executed (and potentially other types of graphics work not executed by shaders). Startups may not provide any guarantees regarding memory synchronization between threads (other than those specified by the threads themselves), concurrency between threads, or the start order between threads. In some implementations, a startup can be identified based on the result of another startup, which can allow memory synchronization without requiring hardware memory coherence support. Typically, the graphics firmware or hardware program is configured to register each startup before sending work to the pipeline for processing. Typically, once started, it will not access memory hierarchies above a certain level until the startup is complete (at which point the result can be written to a higher level in the hierarchy). Information for a given startup may include state information required to complete the corresponding graphics operation, the location of the shader program to be executed, buffer information, the location of texture data, available address space, etc. For example, when a startup is complete, the graphics firmware or hardware may schedule a startup and detect an interrupt. In some implementations, portions of graphics unit 150 are configured to work on a single startup at a time. This group of resources may be referred to as a “startup slot.” Therefore, in some implementations, any data required for a given startup is read from memory shared among multiple processing elements at the start of startup, and the results are written back to the shared memory at the end of startup. Thus, other hardware may not see the startup results until startup is complete, at which point the results are available in the shared memory and accessible to other startups (including startups from other data master devices). A startup may include a set of one or more rendering commands, which may include commands for drawing procedural geometry, commands for setting shadow sampling methods, commands for drawing meshes, commands for retrieving textures, commands for performing generative calculations, etc. A startup may be performed at one of the various stages during frame rendering. Examples of rendering stages include, but are not limited to, camera rendering, lighting rendering, projection, texturing, fragment shading, etc. For example, a startup may be scheduled for computational work, vertex work, or pixel work.

[0110] Figure 9This is a diagram illustrating an exemplary node data structure according to some implementations. In the illustrated example, the node data structure includes the boundaries 0-N of multiple boundary regions associated with the child of the node, metadata for each boundary region, opcode, exponent information, origin information, child basic information, state information, and shader index information.

[0111] In some implementations, boundaries 0-N define boundary regions corresponding to at most N-1 child nodes. In some implementations, these are quantized, axis-aligned bounding boxes (e.g., each box has six values ​​in the X, Y, Z coordinate space) defined by their upper and lower corners. In some implementations, these values ​​are represented as fixed-point offsets relative to a common origin (specified by the origin X, Y, Z fields) and scaling factors (e.g., scaling factors raised to the power of 2, specified by the exponent X, Y, Z fields). For example, the origin value can be represented as a signed floating-point value. This allows all child nodes to be encoded relative to the parent boundary, avoiding gradual loss of precision as the boxes become smaller deeper in the tree. The parent container (origin and exponent) can be referred to as the quantized frame of the node.

[0112] Information indicating each boundary region can be referred to as a child, and can indicate an internal child, a leaf child, or an invalid child. The state and content of a given child can be jointly determined based on its corresponding metadata fields and state fields. For example, the state field can include bits indicating whether the child is an internal node or a leaf node for each child. Alternatively, the state field can separately encode the number of internal nodes and the number of leaf nodes. Metadata fields can indicate whether a child is invalid.

[0113] The child base field indicates the child base address of a node relative to the base address of the BVH tree, after which the node's children can be stored. For leaves, the metadata field indicates the number of leaves within a given boundary and the offset of the child position relative to the child base address of the entire node at the location where the number of leaves is stored. For non-leaf nodes, the metadata field can similarly specify the offset relative to the child base address (in some implementations, for hybrid nodes, child nodes are stored first at the offset position, then leaves). See below for reference. Figure 15 Each boundary may refer to one or more leaves, and each leaf may be referred to by one or more boundaries.

[0114] The opcode field can define information and performance hints about nodes and their children. For example, in a variable-size leaf implementation, leaf stride information can define the stride between consecutive leaves. Another field in the opcode can indicate whether a child is associated with a transformation, for example, such that a clique-S should be formed to transform the light when traversing a child (the technique for this is referenced below). Figures 17 to 18 discuss).

[0115] In some implementations, the boundary coordinates are quantized to, for example, six, seven, or eight bits per coordinate, resulting in a 36, ​​42, or 48-bit boundary field to represent the six coordinates defining the box-shaped boundary region. In some implementations, the quantization techniques used to generate the quantized coordinate values ​​(from initial values ​​that can be represented with more bits) ensure that false positive intersection results may exist, but false negatives do not. For example, quantization can be performed in a manner where the quantized box representation is greater than or equal to the non-quantized box representation. For example, quantization arithmetic can be configured to round down for each corner in different directions (or, if rounding is performed, in the direction corresponding to the extended box). This advantageously reduces the amount of data used per node without affecting accuracy and with limited test increases during traversal.

[0116] Figure 10 This is an illustration of an exemplary size-configurable leaf data structure according to some embodiments. In the illustrated embodiment, each leaf includes a header and a payload, having multiple available payload sizes A to N. As described above, the leaf stride of a leaf at a given node can be defined by the header data of that node. The header may include information required to initiate a SIMD group for intersection testing of primitives or to perform coordinate transformations of primitives. The payload may include variation information for different types of primitives (e.g., default triangle, α-mapped triangle, moving triangle, etc.). Examples of payload information include, but are not limited to, primitive identifiers, geometry identifiers, one or more vectors, etc. In some embodiments, all sub-leaves at a given boundary have the same size. In other embodiments, the size of the leaves at a given boundary may be encoded individually.

[0117] Figure 11 This is a diagram illustrating an exemplary memory layout of an ADS tree structure with variable-size leaf nodes according to some embodiments. Figure 11 The left side shows a tree with a root node R, node AD, and variable-sized leaf nodes 0-9. Figure 11 The right side shows an exemplary layout of these tree elements in memory. As shown, each node includes information indicating the offset in memory to any node child, followed by any leaves. For example, for node A, the offset pointing to the location in memory where node D is stored, followed by leaves 5 and 6.

[0118] In some implementations, the disclosed encoding enables undefined areas of memory to follow leaf blocks that the graphics driver can use for various purposes (e.g., Figure 11 (As shown in the ellipse in the diagram). For example, a driver can insert debugging information, extended primitive information, performance counters, etc., into these parts of the tree structure.

[0119] In some implementations, the processor is configured to divide the leaf data into multiple parts. For example, a leaf may be associated with a geometric primitive for which some data is always accessed for intersection testing, and some content is rarely needed for intersection testing (e.g., uv coordinates for traversing alpha texture lookup). These different types of data may be stored in the core and extended portions of the leaf data structure. In some implementations, the extended portion is stored in an undefined memory region following the leaf blocks as described above.

[0120] It should be noted that the various node, leaf, and tree data structures described herein are for illustrative purposes and are not intended to limit the scope of this disclosure. Various different structures and organizations may be implemented in other embodiments.

[0121] Figure 12 This is a diagram illustrating an exemplary data flow between intersecting circuits, node test circuits, memory regions, and SIMD groups executed by shader circuitry according to some embodiments. Figure 12 As shown, in some embodiments, the graphics processor includes a ray intersection accelerator 190 and a node tester 1210 (e.g., Figure 7 The parallel tester 710 and shader circuitry (such as programmable shader circuitry 160, not explicitly shown) are configured to execute different types of SIMD groups: clique-A1220 and clique-T / clique-S 1230. Furthermore, the graphics processor implements shader core space 1240 and device memory space 1250, in which ADS are stored.

[0122] Figure 13 This illustrates the relationship with some implementation schemes. Figure 12 A flowchart of an exemplary method associated with the data flow is provided. At 1310, in the illustrated embodiment, clique-A, executed on the shader, allocates ray resources (e.g., by sending a request to RIA 190 in response to an allocation ray instruction executed in the shader program executed by clique-A). At 1315, in the illustrated embodiment, RIA 190 returns one or more ray IDs in one or more general-purpose registers (note that, for example, this ray allocation may be performed for multiple rays processed by clique-A). At 1320, in the illustrated embodiment, clique-A writes the ray data of one or more allocated rays into the ray shader core space based on the provided one or more ray IDs.

[0123] At 1325, in the illustrated implementation, clique-A issues an intersecting ray command (e.g., based on executing an intersecting ray instruction) with ray IDs (possibly along with other ray IDs) to RIA 190. This can initiate the ADS traversal process. After this point, rays from a given clique-A can eventually occupy different paths through the ADS and can be processed individually until all rays of clique-A have completed their traversal.

[0124] At 1330, in the illustrated implementation, RIA 190 finds the next ADS node of the ray and issues a test for that node to the node tester 1210. If this is the first time testing the ray, RIA 190 selects the root node. At 1335, in the illustrated implementation, the node tester 1210 reads node data and ray data from the shader core space and performs node tests. It returns the miss / hit information of the node's children to RIA 190.

[0125] At 1340, in the illustrated implementation, RIA 190 traverses to the next node based on the test result until a leaf node is reached. If the next node is an internal node, the flow returns to 1330. If a leaf node is reached, the flow proceeds to 1345. If the traversal is complete, the flow proceeds to 1355.

[0126] At 1345, in the illustrated implementation, a leaf node has been reached, and RIA 190 generates a clique-T and sends a token buffer ID with information for the clique-T. At 1350, in the illustrated implementation, clique-T uses the token ID to read thread data (e.g., ray ID and primitive ID) from the shader core space, reads primitive data from device memory, and reads ray data from the shader core space using the ray ID. clique-T also performs a primitive test, updates the ray data based on the primitive test (e.g., if a hit exists), and then notifies RIA 190 whether to continue traversal (e.g., end traversal for the most recent hit query when a hit is detected).

[0127] It should be noted that operations similar to those described with reference to elements 1345 and 1350 regarding clique-T can also be performed on clique-S. At 1340, when the S node is reached, RIA 190 can generate clique-S, read data from device memory, read ray data, perform transformations on the shader to transform the rays (e.g., using parameters specified for them using leaf payloads), and update a portion of the ray data appropriately. clique-S can then notify RIA 190 to continue traversal.

[0128] At 1355, in the illustrated implementation, the traversal is complete, and RIA 190 notifies clique-A that clique-A reads the ray data with intersection results from the ray shader core space and releases the ray resource command (after which the ray ID can be used for another ray). The processor can decrement the fence counter, for example, so that clique-A can wait until all its rays have completed the traversal before continuing. clique-A can then perform fragment shading based on the intersection results, which in turn can generate additional rays in some cases.

[0129] Dynamically forming SIMD groups for primitive testing

[0130] Figure 14A This is a block diagram illustrating an exemplary technique for dynamically forming a SIMD group for primitive testing, according to some embodiments. In the illustrated embodiment, a programmable shader 160 sends an intersecting ray command to a ray intersection accelerator (RIA) 190. The intersecting ray command can be used, for example, to process a clique-A SIMD group of multiple rays. The RIA 190 traverses the acceleration data structure to generate the intersecting ray results (which may come from various clique-As and may take different paths through the data structure).

[0131] In the illustrated example, once a leaf is reached, RIA 190 does not actually perform primitive tests, but instead dynamically forms a set 1405 of primitive test SIMDs (e.g., for a group of rays being tested relative to the same primitive) that will be performed by programmable shader 160. Programmable shader 160 performs the primitive test SIMDs (clique-T) and may provide the primitive test results to RIA 190 (not explicitly shown). RIA 190 may aggregate the test results for a given clique-A and provide the results back to programmable shader 160 when the results are ready, or RIA 190 may provide the results when the results are complete, and clique-T may aggregate the results (e.g., using fence instructions).

[0132] It should be noted that the primitive test results can also indicate to the RIA190, for example, whether it should continue traversing for a given ray based on whether a hit exists and the requested intersection type. For the most recent hit query, the traversal ends when a hit exists.

[0133] In some implementations, the processor is configured to group multiple leaves sharing the same shader into the same clique-T, so that they can be tested together. This can advantageously reduce the average latency of primitive testing. In some implementations, the processor designates a thread for each ray as a main thread, which responds to operations that are not parallelized among multiple leaf tests (e.g., operations such as determining the winner and updating the ray, finding the minimum of all distances, and possibly performing a link interrupt operation for the most recent hit). Thus, the clique can receive data indicating the ray ID of the ray being tested by the clique, the primitive address of the primitive being tested, and information indicating a "thread segment" (e.g., a count and thread ID information of thread segments), which is a thread operating on the same ray.

[0134] For example, consider the following information regarding three rays and ten different primitives being tested:

[0135] primitive 9 8 7 6 5 4 3 2 1 0 count 5 5 5 5 5 2 2 3 3 3 TID 4 3 2 1 0 1 0 2 1 0

[0136] In this example, ray 2 is tested against primitives 5-9, where for ray 2, the count value of the five threads in the thread segment, and the five threads within that thread segment have different thread IDs (TIDs) 0-4. Similarly, ray 1 is tested against primitives 3 and 4, which have two threads in the thread segment. (See above reference.) Figure 8 As discussed, the RAI 190 can store this information in a token buffer 810 for clique-T.

[0137] In some implementations, clique-T executes SIMD-wide reduction instructions to perform non-parallel operations involved in the transformation. In these implementations, the SIMD reduction instructions can access data from multiple threads within a SIMD group to generate output. For example, this can replace a loop in the main thread that iterates through the threads to find the minimum distance for a hit between threads in a thread segment. Using SIMD reduction instructions instead of a loop can advantageously improve throughput.

[0138] In these implementations, the clique-T information may include a fragment mask (SM) representing the boundaries between fragments. In this example, a logical "1" in the fragment mask indicates that this is the first thread in a new thread fragment.

[0139] primitive 9 8 7 6 5 4 3 2 1 0 count 5 5 5 5 5 2 2 3 3 3 TID 4 3 2 1 0 1 0 2 1 0 SM 0 0 0 0 1 0 1 0 0 0

[0140] SIMD reduction instructions can use this information to operate within each thread segment without using input data from other thread segments.

[0141] U.S. Patent Application No. 16 / 597,625, filed October 9, 2019, is incorporated herein by reference in its entirety and explains various exemplary SIMD reduction operations and channel connection networks. These operations typically employ result registers and input registers, and find the result based on different instances of the input registers corresponding to different threads within a SIMD group. In some embodiments, the SIMD reduction instructions employ additional arguments indicating a fragment mask. This allows the execution pipeline to avoid carrying reduction results across thread fragments, thereby providing a separate reduction result for each thread fragment. Therefore, shader circuitry may include control circuitry configured to limit SIMD reduction operations within a thread fragment based on the fragment mask.

[0142] In some implementations, all threads in a thread segment receive the same result from the SIMD reduction operation (e.g., an indication of the primitive with the most recent hit). The SIMD reduction operation can support a variety of arithmetic operations, such as minimum, maximum, summation, etc.

[0143] Therefore, in some implementations, different threads of clique-T operate with respect to different rays. Furthermore, for the same or different rays, different threads of clique-T can operate with respect to different primitives. Additionally, clique-T can execute SIMD reduction instructions that perform operations based on input values ​​from multiple threads operating with respect to the same ray, and can generate the same result for each of the multiple threads in a thread segment.

[0144] Figure 14B This is a flowchart illustrating an exemplary method for dynamically forming a SIMD group for primitive testing, according to some implementation schemes. Figure 14B The methods shown can be used in conjunction with any of the computer circuit systems, systems, devices, elements, or components (and other devices) disclosed herein. In various embodiments, some of the method elements shown may be performed concurrently in a different order than that shown, or may be omitted. Additional method elements may also be performed as needed.

[0145] At 1410, in the illustrated implementation, the shader circuit executes a ray intersection instruction for the first SIMD group, wherein the instruction indicates the coordinate information of the first group of rays in the graphics scene.

[0146] At 1420, in the illustrated implementation, the ray intersection circuit traverses multiple nodes in an accelerated data structure organized in a spatial form in response to a ray intersection command, wherein the nodes include multiple nodes indicating the coordinates of a boundary region and multiple nodes indicating primitives in a graphical scene.

[0147] At 1430, in the illustrated embodiment, in response to the arrival of a node indicating one or more primitives of the accelerated data structure, the device forms a second SIMD group that operates on a second set of rays that only partially overlap with the first set of rays, wherein the second SIMD group executes one or more instructions to determine whether a ray in the second set of rays intersects with one or more primitives.

[0148] In some embodiments, RIA 190 forms a second SIMD group, and the shader circuitry executes this second SIMD group. The first and second SIMD groups can operate on a first data structure storing information about a first ray in one or more rays, wherein the first data structure is stored in shader memory space that is also accessible by the ray intersection circuitry. For example, the first data structure may include ray core data 920, ray extension data 840, or both. In some embodiments, the second SIMD group accesses thread data from a buffer (e.g., token buffer 810) in the shader memory space identified by the ray intersection circuitry of the second SIMD group. The shader memory space may also include a memory region for ray stack data used by the intersection circuitry. In some embodiments, primitive coordinate data of one or more primitives and coordinates of boundary regions are stored in device memory space (e.g., as part of an ADS stored in device memory 1250).

[0149] In some implementations, the shader circuitry suspends the execution of the first SIMD group (e.g., just after the intersecting ray instruction or later in the program) and resumes the execution of the first SIMD group to shade one or more primitives after receiving the intersection result from the second SIMD group (and possibly from other clique-Ts).

[0150] At 1440, in the illustrated implementation, the shader circuitry shades one or more primitives indicated as intersecting based on the execution result of the second SIMD group. Shading can be performed by continuing to execute the first SIMD group.

[0151] In various implementation schemes, Figure 14A and Figure 14B The technology can advantageously provide performance and power consumption benefits for dedicated boundary region test circuits, while using shader processors to perform more complex operations, such as primitive testing.

[0152] Many-to-many mapping between boundary regions and primitives

[0153] Figure 15 This is a diagram illustrating an exemplary many-to-many mapping between boundary regions and primitives according to some implementation schemes. In the illustrated example, Figure 15The upper part shows a two-dimensional view of four primitives and eight boundary regions, while Figure 15 The lower part shows four leaf nodes corresponding to the four primitives and an exemplary ADS node with eight boundary regions.

[0154] Primitive elements P0-P3 are triangular primitives. Boundary regions 0-7 can be, for example, bounding boxes. Although in various implementations, the primitive vertices in the boundary regions are specified in three or more dimensions, Figure 15 A simplified example is shown in two dimensions for ease of explanation.

[0155] As shown in the figure, in some implementations, the graphics processor generates and uses an accelerated data structure that supports many-to-many mappings between boundary regions and primitives. For example, boundary regions 0 to 3 are all parents of primitive P0, so a primitive can have multiple parent boundary regions. Furthermore, boundary region 3, for example, has multiple primitive children.

[0156] Where conventional ADS creation techniques may have already created leaf nodes for primitive P0 at a higher level (e.g., children of nodes that are ancestors of boundary regions 0-3 and have larger boundary regions), the disclosed technique can wait to create leaves for the primitive at a lower level, making them children of multiple smaller boundary regions. In various implementations, the many-to-many mapping structure combined with a relatively high branching factor allows the boundary regions to provide tight fit around the primitive. In various implementations, this reduces negative primitive test results. Node testing may be relatively cheaper than primitive testing in terms of processing resources, so this reduction in primitive testing can improve performance, reduce power consumption, or both. For example, fewer clique-Ts can be formed for a given scenario when fewer negative primitive tests are published.

[0157] Figure 16 This is a flowchart illustrating an exemplary method for generating spatially organized data structures with many-to-many mappings, according to some implementation schemes. Figure 16 The methods shown can be used in conjunction with any of the computer circuits, systems, devices, components, or parts disclosed herein. In various embodiments, some of the method elements shown may be executed concurrently in a different order than that shown, or may be omitted. Additional method elements may also be executed as needed.

[0158] At 1610, in the illustrated implementation, the graphics processor accesses data of multiple graphics primitives in the graphics scene to be rendered.

[0159] At 1620, in the illustrated implementation, the graphics processor generates a spatially organized data structure, wherein nodes of the data structure indicate the coordinates of graphics primitives or boundary regions in the graphics scene. In the illustrated implementation, the spatially organized data structure includes nodes with boundary regions for which multiple primitives are indicated as children. Furthermore, the spatially organized data structure includes primitives for which multiple boundary regions are indicated as parents.

[0160] In some implementations, the graphics processor quantizes information about a first boundary region in a spatially organized data structure to represent the first boundary region using fewer bits than the original representation. This quantization reduces the overall storage requirements of the ADS. In some implementations, quantization is performed such that the quantized representation indicates a region greater than or equal to the first boundary region in each direction, thereby preventing false negative intersection results for the first boundary region. In some implementations, the spatially organized data structure encodes the location of a node (e.g., an offset from the root location of the ADS), where all child nodes of the node are consecutively located. In some implementations, the spatially organized data structure specifies primitive information in leaf nodes and boundary region information in internal nodes.

[0161] In some implementations, for a first node indicating one or more primitives, a spatially organized data structure includes one or more fields indicating: the offset where the one or more primitives are located and the number of primitives of the first node located at that offset.

[0162] In some implementations, the data structure has a relatively high branching factor. For example, a spatially organized data structure may include nodes with at least four child nodes. In some implementations, the data structure supports variable-sized leaf nodes. Thus, the first leaf node and the second leaf node in a spatially organized data structure can have different data sizes, and the corresponding parent nodes of the first leaf node and the second leaf node can encode different data sizes.

[0163] At 1630, in the illustrated implementation, the graphics processor traverses a data structure organized in spatial form to determine whether rays in the graphics scene intersect with primitives and shades the intersecting primitives based on this determination. As described above, the processor can form a clique-T for primitive testing based on the intersection result and resume execution of a clique-A for shading.

[0164] During traversal, a SIMD group is dynamically formed for ray coordinate transformation.

[0165] Figure 17This is an illustration of an exemplary dynamic formation of a SIMD group used for ray transformation when traversing an accelerated data structure, according to some implementations. In the illustrated example, the ADS includes ten nodes 0-9. Two nodes (nodes 5 and 6, which may be referred to as S nodes) have boundaries with the same child node (node ​​7, which may be the root of the lower-level ADS, as detailed below). These nodes may have fields indicating that a transformation should be performed when traversing to the child node. For example, in the illustrated example, the above references... Figure 9 The opcode field discussed can indicate whether a transformation should be performed on this field for nodes 5 and 6 (in...). Figure 17 The value is indicated as “(T)”.

[0166] RIA 190 can form clique-S to transform the coordinates of one or more rays being traversed (e.g., hits in corresponding boundary regions). Programmable shader 160 can execute one or more instructions specifying mathematical operations for performing the transformed clique-S. In some embodiments, the clique-S operates on ray data in shader core space 1240 such that when the transformation is complete, RIA 190 can continue traversing based on the transformed ray data. At some point during traversal, RIA 190 can transform the rays back to their original coordinates for further traversal, for example, by forming another clique-S or restoring to the stored original coordinates.

[0167] The aforementioned ray coordinate transformations can be used in various scenarios. As an example, geometry instantiation is a technique that allows rendering multiple copies of the same model within the same scene. For instance, consider a model of houses that can be instantiated multiple times in a scene to create a row of houses on a street. For each case, a transformation matrix can be defined to transform the model from model space to world space. Ray tracing processors can support instantiation using different techniques. As an example, the system can transform the model for each instance and construct an ADS that includes the world space geometry of all instances. Alternatively, the system can create a single sub-part (e.g., a tree) of an accelerated data structure in model space for the geometry being instantiated, and perform the transformation to world space during traversal of the ADS, such as... Figure 17 As shown. The latter technique can provide a relatively small ADS because there is no copy of the model that is instantiated in the ADS.

[0168] In some implementations, for each instance of the model space tree (e.g., Figure 17Nodes 7-9 in the model space tree (which provides BVH trees for multiple instances of the model) are used to transform a copy of the root boundary region into world space, and a hierarchical structure is constructed using the root boundary region of the model as leaves with multiple parents in the ADS. The upper-level hierarchical structure contains all boundary regions of all instances of the model space tree and can be called the top-level ADS. The model space BVH tree that is included in the ADS and is being instantiated can be called the lower-level ADS.

[0169] The system can perform transformations when traversing from the top-level ADS to the lower-level ADS. The incoming rays or boundary regions themselves can be transformed. In some implementations, as described above, rays are transformed because this may be less computationally expensive. For example, for affine transformations, only the origin and direction of the ray (rather than the direction) can be transformed. In some implementations, a reverse transformation (e.g., using a reverse transformation matrix) can be performed to perform reverse tracing during traversal. In other implementations, the processor can record the original ray coordinates (e.g., origin and direction), thereby avoiding the need to perform a reduction transformation. For example, this can reduce errors due to floating-point calculations.

[0170] In some implementations, the ADS may include more than two levels, with transformations relative to the current level each time traversal progresses to a lower level. The processor may store coordinate information before each transformation for use when traversing back to the previous level's transformation stack. The ADS may indicate whether a transformation should be performed at various granularities. As an example, a node may include a single field indicating whether a transformation should be performed when traversing to any of its child nodes. Alternatively, a node may independently encode whether a transformation should be performed when transitioning to different child nodes.

[0171] exist Figure 17 In the example shown, a model may have already been generated with three meshes corresponding to nodes 7-9 respectively. In the illustrated example, the model has been instantiated twice, and in the top-level ADS (corresponding to nodes 0-6), there are nodes (nodes 5 and 6) marked as requiring transformation for each instance. These nodes (nodes 5 and 6) are effectively leaves of the top-level hierarchical structure.

[0172] Although the disclosed technique utilizes a clique-S SIMD group executed by the shader pipeline, in other embodiments, a dedicated RIA circuit can be configured to perform S-node transformations.

[0173] Figure 18 This is a flowchart illustrating an exemplary method for dynamically forming a SIMD group for ray coordinate transformation, according to some implementation schemes. Figure 18The methods shown can be used in conjunction with any of the computer circuits, systems, devices, components, or parts disclosed herein. In various embodiments, some of the method elements shown may be executed concurrently in a different order than that shown, or may be omitted. Additional method elements may also be executed as needed.

[0174] At 1810, in the illustrated implementation, the shader circuitry (e.g., programmable shader 160) executes a ray intersection instruction for a first SIMD group, wherein the instruction indicates coordinate information for a set of rays in the graphics scene.

[0175] At 1820, in the illustrated implementation, the ray intersection circuit (e.g., RIA 190) traverses multiple nodes in an accelerated data structure organized in a spatial form in response to a ray intersection command, wherein the nodes of the data structure indicate coordinates corresponding to boundary regions in the graphics scene, and the traversal determines whether a ray intersects with a boundary region.

[0176] In some implementations, the accelerated data structure is hierarchical, and the first node is a leaf node of the parent accelerated data structure, which has child nodes in the lower accelerated data structures. In some implementations, the transformation positions one or more rays in model space for instances of a graphics model that are instantiated multiple times in the graphics scene. Therefore, in some implementations, the child nodes of the first node (e.g., the root node of the model space) also have another parent node in the parent accelerated data structure, where the other parent node indicates different transformations as it traverses the child nodes, wherein the different transformations are associated with the model spaces of different instances of the graphics model.

[0177] In some implementations, the accelerated data structure is a boundary volume hierarchical structure.

[0178] At 1830, in the illustrated embodiment, the device forms a second SIMD group (e.g., clique-S) in response to arrival at a first node indicating a transformation to be executed on the shader circuitry, thereby transforming the coordinates of one or more rays in the ray set.

[0179] In some implementations, the ray-intersecting circuit stores the original coordinates of one or more rays and recovers the original coordinates in response to traversing back through the first node via an accelerated data structure.

[0180] In some implementations, a first SIMD group and a second SIMD group access ray data for one or more rays in the shader memory space. The first SIMD group may include instructions to allocate memory space for a set of rays in the shader memory space before executing ray intersection instructions.

[0181] In some implementations, the second SIMD group includes one or more rays from another SIMD group that execute ray intersection commands. Generally, when different paths from the traversal are used, rays from clique-A can be split so that clique-S or clique-T can operate with respect to rays from multiple different clique-A.

[0182] Example grouping of rays during traversal

[0183] Figure 19A This is an illustration showing an exemplary case where different rays are currently pointing to different nodes in the ADS during traversal, according to some embodiments. In the illustrated example, rays A, C, and E are directed to node 1, rays B and D to node 2, rays X and Y to node 3, and ray Z to node 4.

[0184] In some implementations, the graphics processor is configured to group rays to increase the number of rays tested against a node at a given time. This is also known as merging or consistent collection. The disclosed grouping techniques, discussed in detail below, can reduce bandwidth consumption, for example, at the L1 data cache storing node data.

[0185] In some implementations, the graphics processor assigns each ray to a group before allowing it to be tested. This group can be a list of rays sharing the same key. For boundary region testing, the key can be the address of the node that is the next target in the ray's traversal. As another example, the key can be the address of a parent or grandparent node. For leaf testing, the key can be the leaf header virtual address. The key may also include the data master device and other contextual information about the launch slot associated with the ray.

[0186] The information for each group indicates a list of rays within that group. In some embodiments, dedicated circuitry is configured to store the ray list for each box. In these embodiments, various numbers of entries can be used for grouping, for example, 64, 128, 256, or 512 groups, each with 4, 8, 16, 32, or 64 entries.

[0187] In some implementations, whenever the top of the stack is traversed for a given ray change, the RIA searches the assigned groups to find a match for the corresponding key. The RIA may include group control circuitry 1910, such as... Figure 19BAs shown, the grouping control circuit is configured to allocate light to groups. The grouping circuit 1910 may search for groups analogous to cache lines in a cache associated with a setting, for example, by hashing a key to determine the set of groups and searching for any allocated group in the set for a key match. In these embodiments, the grouping circuit 1910 may include a content-addressable memory structure. If a match is found, the RIA 190 is configured to attach light to the matching group. If no match is found but an unassigned group is available, the RIA 190 may create a new group and allocate light to the new group. If no match is found and all groups are currently assigned, grouping may stop until a group becomes available.

[0188] Similar techniques can be used to group leaf nodes associated with primitives, for example, by using separate dedicated circuitry to store a list of rays for the same leaf node (or the same type of leaf, for example, for color consistency). In some implementations, different numbers of groups, different numbers of entries per group, or both can be implemented for leaf nodes and internal nodes.

[0189] In some implementations, the RIA 190 also tracks the age of the oldest ray within each group. For example, the RIA 190 may maintain an age field in the control register of each group. The age field can be quantized. In each cycle, the RIA may select up to N groups with the oldest ray and emit rays from the selected groups for scheduling deployments for node or primitive testing. In some implementations, the RIA 190 may disregard groups used for scheduling until they include a threshold number of rays. In other implementations, various different techniques can be implemented for selection among available groups.

[0190] In some implementations, the matching groups determined by the grouping circuit 1910 are indexes of a dedicated circuit configured to store a list of rays for each allocation group. In other implementations, attributes of a data structure can be used to indicate matching groups, for example, as referenced below. Figure 19C The one or more pointers to the entries in the list discussed.

[0191] Figure 19C This is an illustration of a specific implementation of an exemplary list of separate links for grouping rays according to some embodiments. In the illustrated embodiment, each ray queue entry indicates a ray ID (e.g., for rays A, C, and E), a stack top field indicating the next target node (e.g., where 0x2C is an identifier), and a stack top field indicating the next target node. Figure 19AThe example includes a node identifier for node 1, and a next ray field indicating the position of the next ray in the list. In some implementations, this technique allows groups to grow indefinitely without stagnation. In some implementations, the RIA supports up to a threshold number of groups at a time. When a ray is grouped, it can be added to the end of the group list, and the tail pointer maintained by the grouping circuit 1910 can be updated. When a group is scheduled for testing, the RIA can use pointer chopper to iterate through the list and find all rays in the group. Although a single linked list has been discussed for illustrative purposes, any of a variety of other data structures can be implemented for ray grouping. Note that while a single linked list is shown for illustrative purposes, other data structures are also envisioned.

[0192] The disclosed grouping technique can advantageously improve the temporal location of data extraction from boundary regions. This can reduce cache thrashing and bandwidth of one or more data caches.

[0193] Figure 20 This is a flowchart illustrating an exemplary method for grouping rays during ADS traversal according to some implementation schemes. Figure 20 The methods shown can be used in conjunction with any of the computer circuits, systems, devices, components, or parts disclosed herein. In various embodiments, some of the method elements shown may be executed concurrently in a different order than that shown, or may be omitted. Additional method elements may also be executed as needed.

[0194] In 2010, in the illustrated implementation, the ray intersection circuit (e.g., RIA 190) receives one or more ray intersection requests that indicate the origin and direction information of multiple rays in a ray set in a graphical scene.

[0195] At 2020, in the illustrated implementation, the ray intersection circuit traverses multiple nodes of an accelerated data structure organized in space, the nodes of which indicate coordinates corresponding to boundary regions of the graphics scene, to determine whether a ray intersects with a boundary region. In the illustrated implementation, the traversal movement of 2020 includes elements 2030 and 2040.

[0196] At 2030, in the illustrated embodiment, the ray intersection circuit (e.g., using grouping circuit 1910) groups portions of the ray set into multiple groups based on the nodes of the data structure of the next target of the ray. In some embodiments, the ray intersection circuit includes separate grouping circuits for accelerating leaf nodes of the data structure and accelerating internal nodes of the data structure.

[0197] In some implementations, the ray intersection circuit assigns a ray to a new group whenever a ray traverses between levels of the accelerated data structure. For example, the ray intersection circuit can implement a ray traversal stack for depth-first search of ADS, and assign a ray to a new group whenever the top of the traversal stack changes.

[0198] In some implementations, to determine groups of rays, the ray-intersecting circuit uses the key of the next node targeted by the ray as input to a hash function to determine a set of groups, and searches this set to determine whether the assigned groups in the set match the key. The ray-intersecting circuit can assign new groups to rays that do not match any currently assigned groups.

[0199] At 2040, in the illustrated implementation, the ray intersection circuitry system processes a first group (e.g., using a parallel tester 710) based on grouping (a subset of rays targeting the first node) to determine whether rays in the first group intersect one or more boundary regions of the first node. In some implementations, this processing is based on the selection of one or more ray groups during a clock cycle used for scheduling to publish to the boundary region test circuitry. In these implementations, these groups may be discarded before processing other groups, thus providing temporal location for accessing boundary region data cached in one or more data caches. The selection of one or more groups may be based on the oldest ray in the assigned ray group, which provides fairness and avoids starvation.

[0200] The first group may be specified by a linked list. In some implementations, entries in the ray queue include a field pointing to the next ray in the linked list for the current group of the corresponding ray. In some implementations, the first group includes rays from multiple different SIMD groups processed by the shader processor, for example, because rays from a given SIMD group take different paths through the ADS and combine with rays from other groups. The ray intersection circuit may include parallel test circuitry configured to test rays in parallel for multiple boundary regions of the node. Multiple instances of the parallel test circuitry may be configured to process multiple rays in parallel.

[0201] Detailed example of total intersection traversal

[0202] Figure 21 This is a flowchart illustrating an exemplary method for processing light according to some implementation schemes. Figure 21 The methods shown can be used in conjunction with any of the computer circuits, systems, devices, components, or parts disclosed herein. In various embodiments, some of the method elements shown may be executed concurrently in a different order than that shown, or may be omitted. Additional method elements may also be executed as needed.

[0203] At 2110, in the illustrated example, clique-A, executed by the shader processor, allocates a ray. At 2112, RIA 190 allocates ray shader core space for the ray and returns the ray ID. At 2114, clique-A writes the ray's data to the shader core space. At 2116, clique-A issues an intersecting ray instruction.

[0204] At 2118, RIA 190 begins traversing the ADS of the ray, for example, starting from the BVH root node. At 2120, the RIA assigns the ray to a group (e.g., using a grouping circuit) and waits for the group to be discharged (e.g., due to having one of the N oldest rays in the active group, or according to some other appropriate arbitration scheme in the group). Once the group is published, RIA 190 determines the node type at 2122. If the node targeted by the group is an internal node, the process proceeds to 2124. If the node is a leaf node, the process proceeds to 2140.

[0205] At 2124, in the illustrated example, the parallel tester 710 performs node testing and returns hit information for the node's boundary region. If a hit exists at 2126, the process proceeds to 2128, and RIA 190 pushes any untraced nodes onto the ray stack, and the process proceeds back to 2120 (e.g., traversing to the next node in ADS). If no hit exists at 2126, the process proceeds to 2130.

[0206] At 2130, if the stack is not empty, RIA 190 pops a node from the stack at 2120 and moves to 2120 (e.g., traversing to the next node in ADS). If the stack is empty, RIA 190 ends the traversal at 2134.

[0207] At 2140, in the illustrated example (for a leaf node), RIA 190 generates a token ID (a pointer to a buffer in the shader core space) for communication between RIA 190 and the clique-T or clique-S to be generated for the leaf node. Each thread can use its thread ID combined with the token ID to retrieve its ray ID and primitive address. The shader then schedules either a clique-T (for primitive testing) or a clique-S (for ray coordinate transformation) at 2142 and executes the clique, which updates the ray data. Once the clique has finished, RIA 190 wakes up the ray at 2144 to continue traversal. If the ray is to be terminated (e.g., due to the detection of an intersection of recently hit queries), the flow advances to 2134 and the traversal ends. Otherwise (e.g., for any hit query), the flow advances to 2130, and traversal can continue if the stack is not empty.

[0208] After the traversal is complete, clique-A can read the resulting data from the ray shader core space. RIA 190 can also release rays, including removing ray assignments from the ray shader core space.

[0209] In some implementations, the parallel tester 710 is configured to perform Figure 21 Element 2124. In some implementations, the ray traversal control circuitry in the RIA is configured to perform... Figure 21 Elements 2112, 2118, 2120, 2122, 2126, 2144, 2146, and 2134. In some implementations, the ray stack manager circuitry is configured to execute... Figure 21 Elements 2128, 2132, and 2130. In some implementations, other graphics circuitry, such as shader circuitry, is configured to perform... Figure 21 The elements are 2110, 2114, 2116 and 2142.

[0210] Shader core space

[0211] As described above, the shader memory space (also referred to herein as shader core space) can be accessed by multiple thread groups executing on the same shader core, which facilitates data sharing between the RIA 190 and different types of SIMD groups (e.g., clique-A and clique-T). In some embodiments, the graphics processor uses the shader memory space for other operations. In general, the disclosed shader memory sharing can advantageously facilitate sharing between coprocessors and shaders, as well as between thread groups, without the latency associated with coherent points at higher memory spaces, such as device or system memory spaces. In some embodiments, the graphics device implements the following memory spaces: thread space (a private space for a given thread, although some SIMD arrangement instructions may allow limited access to data of other threads in the SIMD group), thread group space (a private space for a given thread group), shader memory space (accessible by multiple thread groups executing on the same shader core, and possibly accessible by one or more coprocessors of the shader core, but not by thread groups executing on other shader cores), and device space accessible by multiple shader cores and potentially other circuitry (e.g., CPU) on the computing device.

[0212] Using shader memory space instead of device memory for certain types of data can advantageously provide lower latency for that data, allow for higher bandwidth implementations, reduce resource consistency costs, or any combination thereof.

[0213] Figure 22AThis is a block diagram illustrating an exemplary cache memory hierarchy accessible to the shader core according to some embodiments. In the illustrated embodiment, shader core 2210 and other circuitry 2230 have access to all or a portion of the cache / memory hierarchy 2220. The hierarchy 2220 may include low-level circuitry such as register files, various caches (e.g., L0 (which may be closely associated with one or more ALUs, L1, L2, etc. caches for instructions and / or data) and memory circuitry (e.g., random access memory, disk-based drives, solid-state storage devices, etc.). Consistency of different memory spaces can be implemented at different levels of the hierarchy. In some embodiments, the device implements a unified memory architecture in which all storage is backed up by the memory hierarchy.

[0214] Other circuitry 2230 may include other shader cores, other graphics units, other processors such as a CPU, other circuitry of a system-on-a-chip (SoC), etc. It should be noted that in some implementations, circuitry 2230 and shader core 2210 may, for example, utilize a private low-level cache to internally implement part of a hierarchical structure 2220.

[0215] In some implementations, shader core 2210 is one of a plurality of shader cores included in a graphics processor. Shader core 2210 may include one or more L1 caches not shared with other shader cores. Shader core 2210 may include a plurality of arithmetic logic units (ALUs) configured to execute instructions for SIMD groups in parallel. Shader core 2210 may be the smallest scaling unit of the GPU, such as the smallest unit capable of executing its own shader program. The GPU may include as few individual shader cores as possible or as many shader cores as possible to suit larger-scale applications. For computational work, shader core 2210 may receive computational workgroups and assign work items from the workgroups to internal processing pipelines.

[0216] Figure 22B This is a block diagram illustrating an exemplary cache memory hierarchy accessible to multiple shader cores and their coprocessors according to some embodiments. In the illustrated example, multiple shader cores 2210A-2210N and their coprocessors 2240A-2240N have access to the hierarchy 2220. RIA 190 is one example of coprocessor 2240. A texture processing unit (TPU) is another example. A given shader core 2210 may have multiple coprocessors, and all or part of the coprocessors may have access to at least a portion of the hierarchy 2220.

[0217] In some implementations, the hierarchical structure 2220 includes coherent points of shader memory space that can be accessed by shader core 2210 and its coprocessors, but not by other shader cores or their coprocessors. Although various implementations are discussed in thread group granularity herein, the granularity at which core 2210, coprocessor 2240, or both access the shader memory space can vary (e.g., SIMD groups, threads, or thread groups can use the shader memory space to buffer data).

[0218] Figure 23 This is an illustration of exemplary thread groups, shader cores, and device memory space according to some embodiments. In the illustrated embodiment, device memory space 2330 is shared by multiple shader cores 2210. In contrast, in the illustrated embodiment, shader core space 2320 is accessible by thread groups executing on coprocessor 2240A and shader core 2210A, but not by thread groups executing on other shader cores such as shader core 2210N (but note that shader core 2210N may implement its own shader core space, not explicitly shown). In the illustrated embodiment, thread group (TG) memory spaces 2310A-2310M are private memory spaces accessible by a single thread group executing on shader core 2210A. In some embodiments, shader core 2210A also implements thread memory space (not shown) allocated to a single thread.

[0219] Figure 24 This is a block diagram illustrating exemplary cache organization and coherence points for different memory spaces according to some embodiments. In the illustrated embodiment, shader core 2210 includes L1 cache 2410, register file 2420, shader pipeline 2450, and control circuitry 2440. In this example, shader core 2210 is also configured to access shared L2 cache 2430.

[0220] In the illustrated example, register file 2420 serves as a coherence point for the thread group memory space, and L1 cache 2410 serves as a coherence point for the shader core space. A coherence point is the level at which all entities sharing the memory space (e.g., thread groups and coprocessors for shader memory space) will see the same cached data. Implementing shader memory space at the L1 level reduces memory latency required for shared data (e.g., between thread groups) by avoiding access to higher levels of the memory hierarchy (e.g., L2 cache 2430).

[0221] In a unified memory implementation that does not include a separate register file, the L1 cache can serve as a coherence point for thread groups, thread-private spaces, and shader core spaces. More generally, the L1 cache can be a coherence point for all memory spaces inaccessible to circuitry outside the shader core 2210. In some implementations, thread-private data may be stored in one or more L0 caches (and L1 cache 2410, as needed). In the illustrated example, the L2 cache serves as a coherence point for the device memory space. In other implementations, for example, if the L2 cache is inconsistent, a higher-level cache such as the L3 cache may serve as a coherence point for the device memory space.

[0222] In some implementations, the shader pipeline 2450 is configured to execute instructions from a SIMD group, for example, using a shared program counter for threads within the SIMD group. These pipelines may include multiple pipeline stages configured to perform operations over multiple clock cycles.

[0223] In some implementations, control circuitry 2440 is configured to facilitate the correct execution of memory access instructions targeting different memory spaces. For example, control circuitry may include circuitry for appropriately executing instructions such as load, store, allocate, atomicate, and barrier operations for accessing shader memory spaces. For instance, load and store operations for accessing shader memory spaces do not store or retrieve data from other spaces. From the perspective of other thread groups with access to the space, atomication operations on the shader memory space allow thread groups to perform memory access operations atomically. For example, if the L1 cache is a coherent point in the shader memory space, a thread group can fetch and update one or more L1 cache lines to automatically perform a set of operations. Barrier or fence operations on the shader memory space ensure that all operations in the accessible space before the barrier are completed before operations after the barrier.

[0224] The shader core space can be used for various buffered operations other than (or in place of) the aforementioned ray intersection operation. For example, thread divergence is a common reason for underutilization in SIMD processors, for some graphics workloads. For instance, SIMD processors typically use predictive execution to handle branch instructions. In predictive execution, two paths following the branch are executed, but during its execution, threads that are predicted not to take the current path are shut down. Therefore, if some threads in the same SIMD group are predicted to be shut down while others are predicted to be on, the SIMD pipeline hardware may be underutilized.

[0225] One way to address this type of underutilization is to move threads that have taken different paths to different kernels. However, this could involve writing the resulting data to device memory before booting the new kernel, which can significantly impact performance. In some implementations, the threads in the SIMD group are broken down (and may reformat after the diverging paths have been executed), and the new SIMD group executes within the same kernel on different paths. For example, consider the following pseudocode:

[0226]

[0227]

[0228] In the code example above, if P<0 is unpredictable, the shader may suffer from a divergence problem, where some threads in the same SIMD group execute code block B (while other threads are predicted to be off) and other threads in the SIMD group execute code block C. In some implementations, this code is split into three different shaders within the same kernel:

[0229]

[0230]

[0231] In this example, if the processTriangle shader is executed by SIMD group A, then a dynamically formed SIMD group B can execute the subdivideTriangle path, while another dynamically formed SIMD group C can execute the rasterizeTriangle path. Note that SIMD group B can include threads from multiple different SIMD groups executing the processTriangle shader (as can SIMD group C).

[0232] In some implementations, for example, this fine-grained local scheduling can use shader memory space to store intermediate data instead of sending data to a coherent point in device memory. For instance, in the example above, SIMD group A can store data in a buffer in the shader core space, and SIMD groups B and C can read intermediate results from that buffer. Because SIMD groups B and C are in different thread groups (e.g., because they execute different shaders), the shader core space provides a convenient coherent point for sharing data.

[0233] Figure 25 This is a flowchart illustrating an exemplary method of using shader memory space according to some implementation schemes. Figure 25The methods shown can be used in conjunction with any of the computer circuits, systems, devices, components, or parts disclosed herein. In various embodiments, some of the method elements shown may be executed concurrently in a different order than that shown, or may be omitted. Additional method elements may also be executed as needed.

[0234] At 2510, in the illustrated embodiment, the first graphics shader core and the second graphics shader core execute instructions from multiple thread groups. In the illustrated embodiment, this includes the first graphics shader core executing both: a first thread group having multiple single instruction multiple data (SIMD) groups configured to execute first shader programs, and a second thread group having multiple SIMD groups configured to execute different second shader programs. It should be noted that in some embodiments, different thread groups executing the same shader program may also access the shader memory space. More generally, in some embodiments, the shader memory space is accessible to any thread from any SIMD group of any thread group running on the same shader core.

[0235] At 2520, in the illustrated embodiment, the control circuitry provides access to data stored in the memory circuitry based on the shader memory space, which is accessible by a thread group (including a first thread group and a second thread group) executed by a first graphics shader core, but not by a thread group executed by a second graphics shader core.

[0236] In some implementations, a first cache (e.g., L1 cache 2410) in a first graphics shader core is a coherent point in the shader memory space, and a second high-level cache (e.g., L2 cache 2430) in the device is a coherent point in the device memory space.

[0237] In some implementations, the control circuitry also provides access to data stored in the memory circuitry based on additional memory spaces with different shared granularities, including: a thread group memory space for a first thread group, accessible by the first thread group but not by any other thread group; a thread memory space accessible by a single thread; and a device memory space accessible by a thread group executed by both the first graphics shader core and the second graphics shader core.

[0238] In some implementations, the shader memory space may also be accessed by one or more coprocessors for the first graphics shader core. For example, one or more coprocessors include a RIA 190. In some implementations, the RIA 190 is configured to: based on instructions from a first thread group (e.g., clique-A), traverse a spatially organized data structure to determine one or more primitives against which test rays intersect, and initiate a second thread group (e.g., clique-T) to test the one or more primitives against the rays, wherein both the first and second thread groups operate with respect to ray information stored in the shader memory space.

[0239] In some implementations, the first graphics shader core is configured to execute load, store, and atomize instructions targeting the shader memory space.

[0240] In some implementations, the first graphics shader core is configured to execute a first SIMD group of a first thread group to use shader memory space to store intermediate graphics work at the thread granularity for further processing by threads of a dynamically formed SIMD group. The dynamically formed SIMD group may include a set of threads determined to have the same conditional results for conditional control transfer instructions.

[0241] Exemplary device

[0242] Now for reference Figure 26 The diagram illustrates a block diagram of an exemplary embodiment of device 2600. In some embodiments, the components of device 2600 may be included within a system-on-a-chip. In some embodiments, device 2600 may be included in a mobile device that may be battery-powered. Therefore, the power consumption of device 2600 may be an important design consideration. In the illustrated embodiment, device 2600 includes a structure 2610, a computing complex 2620, an input / output (I / O) bridge 2650, a cache / memory controller 2645, a graphics unit 150, and a display unit 2665. In some embodiments, in addition to and / or replacing the components shown, device 2600 may include other components (not shown), such as video processor encoders and decoders, image processing or recognition elements, computer vision elements, etc.

[0243] Structure 2610 may include various interconnects, buses, MUXs, controllers, etc., and may be configured to facilitate communication between various components of device 2600. In some embodiments, portions of structure 2610 may be configured to implement various different communication protocols. In other embodiments, structure 2610 may implement a single communication protocol, and components coupled to structure 2610 may internally switch from a single communication protocol to other communication protocols.

[0244] In the illustrated implementation, computing complex 2620 includes bus interface unit (BIU) 2625, cache 2630, and cores 2635 and 2640. In various implementations, computing complex 2620 may include a variety of numbers of processors, processor cores, and / or caches. For example, computing complex 2620 may include one, two, or four processor cores, or any other suitable number. In one implementation, cache 2630 is a set of associative L2 caches. In some implementations, cores 2635 and / or 2640 may include internal instruction and / or data caches. In some implementations, coherence units (not shown) in architecture 2610, cache 2630, or elsewhere in device 2600 may be configured to maintain coherence between the various caches of device 2600. BIU 2625 may be configured to manage communication between computing complex 2620 and other elements of device 2600. Processor cores such as the 2635 and 2640 can be configured to execute instructions of a specific instruction set architecture (ISA) that may include operating system instructions and user application instructions.

[0245] The cache / memory controller 2645 can be configured to manage data transfer between the structure 2610 and one or more caches and / or memories. For example, the cache / memory controller 2645 can be coupled to an L3 cache, which in turn can be coupled to system memory. In other embodiments, the cache / memory controller 2645 can be directly coupled to memory. In some embodiments, the cache / memory controller 2645 may include one or more internal caches.

[0246] As used herein, the term "coupled to" can indicate one or more connections between elements, and coupling can include intermediate elements. For example, in Figure 26 In this context, the graphics unit 150 can be described as being "coupled" to memory via structure 2610 and cache / memory controller 2645. In contrast, in... Figure 26 In the exemplary implementation, the graphics unit 150 is "directly coupled" to the structure 2610 because there are no intermediate elements.

[0247] The graphics unit 150 may include one or more processors and / or one or more graphics processing units (GPUs). For example, the graphics unit 150 may receive graphics-oriented instructions, such as... Metal or Instructions. The graphics unit 150 may execute dedicated GPU instructions or perform other operations based on received graphics-oriented instructions. The graphics unit 150 may typically be configured to process large blocks of data in parallel and may construct an image in a frame buffer for output to a display. The graphics unit 150 may include transformation, lighting, triangle, and / or rendering engines in one or more graphics processing pipelines. The graphics unit 150 may output pixel information for displaying the image. In various embodiments, the programmable shader 160 may include highly parallel execution cores configured to execute graphics programs, which may include pixel tasks, vertex tasks, and computation tasks (which may be graphics-dependent or may not be graphics-dependent).

[0248] In some embodiments, the graphics unit 150 includes the circuitry discussed herein. In other embodiments, for example, the disclosed circuitry may be implemented in other types of processors, such as CPUs.

[0249] Display unit 2665 can be configured to read data from a frame buffer and provide a stream of pixel values ​​for display. In some embodiments, display unit 2665 can be configured as a display pipeline. Additionally, display unit 2665 can be configured to blend multiple frames to produce an output frame. Furthermore, display unit 2665 may include one or more interfaces for coupling to a user display (e.g., a touchscreen or an external display). Or embedded display port (eDP)).

[0250] I / O bridge 2650 may include various components configured to implement functions such as Universal Serial Bus (USB) communication, security, audio, and / or low-power always-on functionality. I / O bridge 2650 may also include interfaces such as pulse width modulation (PWM), general purpose input / output (GPIO), serial peripheral interface (SPI), and / or internal integrated circuit (I2C). Various types of peripheral devices and equipment can be coupled to device 2600 via I / O bridge 2650.

[0251] In some embodiments, device 2600 includes network interface circuitry (not explicitly shown) that can be connected to structure 2610 or I / O bridge 2650. The network interface circuitry can be configured to communicate via various networks, which can be wired networks, wireless networks, or both. For example, the network interface circuitry can be configured to communicate via a wired local area network (LAN), a wireless LAN (e.g., via WiFi), or a wide area network (e.g., the Internet or a virtual private network). In some embodiments, the network interface circuitry is configured to communicate via one or more cellular networks using one or more radio access technologies. In some embodiments, the network interface circuitry is configured to communicate using device-to-device communication (e.g., Bluetooth or WiFi Direct). In various embodiments, the network interface circuitry can provide device 2600 with connectivity to various types of other devices and networks.

[0252] Exemplary Applications

[0253] Now go to Figure 27 This illustrates various types of systems that may include any of the circuits, devices, or systems described above. Systems or devices 2700 that may utilize one or more of the techniques described herein, in combination with or otherwise, can be used in a wide range of fields. For example, system or device 2700 may be used as part of the hardware of a system such as a desktop computer 2710, a laptop computer 2720, a tablet computer 2730, a cellular or mobile phone 2740, or a television 2750 (or a set-top box coupled to a television).

[0254] Similarly, the disclosed components can be used in wearable devices 2760, such as smartwatches or health monitoring devices. In many embodiments, a smartwatch can perform a variety of different functions—for example, access to email, cellular services, calendars, health monitoring, etc. Wearable devices can also be designed to perform only health monitoring functions, such as monitoring a user's vital signs, performing epidemiological functions such as contact tracing, providing communication to emergency medical services, etc. Other types of devices are also envisioned, including devices worn around the neck, implantable devices, and glasses or helmets designed to provide computer-generated reality experiences, such as those based on augmented reality and / or virtual reality.

[0255] System or device 2700 can also be used in a variety of other environments. For example, system or device 2700 can be used in the context of a server computer system (such as a dedicated server) or on shared hardware implementing cloud-based services 2770. Furthermore, system or device 2700 can be implemented in a wide range of dedicated everyday devices, including common household devices 2780 such as refrigerators, thermostats, security cameras, etc. The interconnection of such devices is often referred to as the “Internet of Things” (IoT). Components can also be implemented in various modes of transportation. For example, system or device 2700 can be used in control systems, guidance systems, entertainment systems, etc., of various types of vehicles 2790.

[0256] Figure 27 The applications shown are merely illustrative and are not intended to limit the potential future applications of the disclosed systems or devices. Other illustrative applications include, but are not limited to, portable gaming devices, music players, data storage devices, and unmanned aerial vehicles.

[0257] Exemplary computer-readable media

[0258] Various exemplary circuits have been described in detail above in this disclosure. It is intended that this disclosure cover not only embodiments including such circuit systems, but also computer-readable storage media including design information specifying such circuit systems. Therefore, this disclosure is intended to support claims that cover not only means including the disclosed circuit systems, but also storage media specifying circuit systems in a format recognized by a manufacturing system configured to generate hardware (e.g., integrated circuits) including the disclosed circuit systems. Claims regarding such storage media are intended to cover entities that, for example, generate circuit designs but do not themselves manufacture such designs.

[0259] Figure 28 This is a block diagram illustrating an exemplary non-transitory computer-readable storage medium for storing circuit design information according to some embodiments. In the illustrated embodiment, a semiconductor manufacturing system 2820 is configured to process design information 2815 stored on a non-transitory computer-readable medium 2810 and to manufacture an integrated circuit 2830 based on the design information 2815.

[0260] The non-transitory computer-readable storage medium 2810 may include any of a variety of suitable types of memory devices or storage devices. The non-transitory computer-readable storage medium 2810 may be an installation medium, such as a CD-ROM, floppy disk, or magnetic tape device; computer system memory or random access memory such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory such as flash memory, magnetic media, such as a hard disk drive or optical storage device; registers, or other similar types of memory elements, etc. The non-transitory computer-readable storage medium 2810 may include other types of non-transitory memory or combinations thereof. The non-transitory computer-readable storage medium 2810 may include two or more memory media that may reside in different locations, such as different computer systems connected via a network.

[0261] Design information 2815 can be specified using any of a variety of suitable computer languages, including hardware description languages ​​such as, but not limited to, VHDL, Verilog, SystemC, SystemVerilog, RHDL, M, MyHDL, etc. Design information 2815 can be used by semiconductor manufacturing system 2820 to manufacture at least a portion of integrated circuit 2830. The format of design information 2815 can be recognized by at least one semiconductor manufacturing system 2820. In some embodiments, design information 2815 may also include one or more cell libraries specifying the synthesis and / or layout of integrated circuit 2830. In some embodiments, the design information is specified wholly or partially in the form of a netlist specifying cell library elements and their connectivity. Design information 2815 acquired separately may or may not include sufficient information for manufacturing the corresponding integrated circuit. For example, design information 2815 may specify circuit elements to be manufactured but not their physical layout. In this case, design information 2815 may need to be combined with layout information to actually manufacture the specified circuit.

[0262] In various implementations, integrated circuit 2830 may include one or more custom macrocells, such as memory, analog or mixed-signal circuitry, etc. In this case, design information 2815 may include information associated with the included macrocells. Such information may include, but is not limited to, a circuit diagram capture database, mask design data, behavioral models, and device or transistor-level netlists. As used herein, mask design data may be formatted according to a Graphical Data System (GDSII) or any other suitable format.

[0263] The semiconductor manufacturing system 2820 may include any of the 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 the deposited material, modifying the material (e.g., by doping the material or by using ultraviolet treatment to modify the dielectric constant), etc. The semiconductor manufacturing system 2820 may also be configured to perform various tests on the manufactured circuits for proper operation.

[0264] In various embodiments, integrated circuit 2830 is configured to operate according to a circuit design specified by design information 2815, which may include performing any of the functions described herein. For example, integrated circuit 2830 may include Figure 1B , Figure 3A , Figure 6 , Figure 7 , Figure 14A , Figure 19B , Figures 22A-22B , Figure 24 or Figure 26 Any of the various components shown herein. Additionally, integrated circuit 2830 can be configured to perform the various functions described herein in conjunction with other components. Furthermore, the functionality described herein can be performed by multiple interconnected integrated circuits.

[0265] As used herein, a phrase in the form of “design information specifying the design of a circuit configured to…” does not imply that the circuit in question must be manufactured in order to satisfy this element. Rather, the phrase indicates that the design information describes a circuit that, when manufactured, will be configured to perform the indicated action or will include the specified components.

[0266] The following numbered clauses list the various non-restrictive embodiments disclosed herein:

[0267] Set A

[0268] A1. An apparatus, the apparatus comprising:

[0269] A graphics shader circuit configured to execute a ray intersection instruction that indicates the origin and direction information of a set of one or more rays in a graphics scene;

[0270] A beam intersection circuit, wherein the beam intersection circuit is configured as follows:

[0271] In response to the ray intersection command, multiple nodes in an accelerated data structure organized in a spatial form are traversed, wherein the nodes of the data structure indicate coordinates corresponding to boundary regions in the graphics scene;

[0272] During the traversal, a boundary region testing circuit is used to test in parallel whether the rays in the set of rays intersect with multiple different boundary regions indicated by the nodes of the data structure; and

[0273] The device is configured to determine, based on the traversal and testing, information about one or more graphic primitives that intersect with a corresponding ray in the set of one or more rays; and

[0274] The graphics shader circuit is configured to shade one or more specified graphics primitives based on intersecting rays.

[0275] A2. An apparatus according to any of the foregoing clauses in set A, wherein the boundary region test circuit is configured to test multiple rays in parallel for multiple different boundary regions.

[0276] A3. The apparatus according to any of the foregoing clauses in set A, wherein the boundary region test circuit comprises:

[0277] Multiple boundary region testers, configured to determine whether a ray intersects a boundary region and configured to perform the test on multiple boundary regions in parallel; and

[0278] A common node computing circuit, configured to perform one or more operations whose outputs are shared by the boundary region tester.

[0279] A4. The apparatus according to any of the foregoing clauses in set A, wherein the boundary region test circuit further comprises:

[0280] Boundary region data cache;

[0281] Light data cache; and

[0282] The result sorting circuit is configured to sort the intersection results from the plurality of boundary region testers based on the distance to the origin of the measured ray.

[0283] A5. An apparatus according to any of the foregoing clauses in set A, wherein the apparatus is configured to store ray data for a set of one or more rays in a shader memory space accessible by the graphics shader circuitry and the ray intersection circuitry.

[0284] A6. An apparatus according to any of the foregoing clauses in set A, wherein the graphics shader circuitry is configured to generate one or more additional rays based on the shading of one or more specified graphics primitives, and to execute ray intersection instructions for the one or more additional rays.

[0285] A7. The apparatus according to any of the foregoing clauses in set A, wherein the accelerated data structure is a hierarchical structure and the first node is a leaf node of the upper-level accelerated data structure, the first node having child nodes in the lower-level accelerated data structure;

[0286] The lower-level accelerated data structure corresponds to the graphics model instantiated multiple times in the graphics scene; and

[0287] The ray intersection circuit is configured to form a SIMD group to transform the coordinates of one or more rays arriving at the first node to the model space of the instance of the graphical model.

[0288] A8. An apparatus according to any of the foregoing provisions in set A, wherein one or more nodes of the accelerated data structure comprise four or more boundary regions and four or more child nodes.

[0289] A9. Any apparatus described in accordance with any of the foregoing clauses within set A.

[0290] The accelerated data structure described therein includes nodes with boundary regions, for which multiple primitives are indicated as children; and

[0291] The accelerated data structure mentioned therein includes primitives, for which multiple boundary regions are indicated as parents.

[0292] A10. An apparatus according to any of the foregoing clauses in set A, wherein the ray intersection circuit is configured to form a SIMD set to test ray sets against primitives corresponding to leaf nodes of the data structure.

[0293] A11. An apparatus according to any of the foregoing clauses in set A, wherein the ray intersecting circuit is configured to group a portion of the ray set into multiple groups using a grouping circuit based on nodes of the data structure of the next target of the ray, wherein the test is based on the group.

[0294] A12. A device according to any of the foregoing clauses in set A, wherein the device is a computing device, the computing device comprising:

[0295] The graphics processor includes the light intersecting circuit;

[0296] Central processing unit; and

[0297] Network interface circuit.

[0298] A13. A method comprising any combination of operations performed by means of any of the foregoing provisions of set A.

[0299] A14. A non-transitory computer-readable storage medium having design information stored thereon, the design information specifying at least a portion of a design of a hardware integrated circuit in a format recognizable by a semiconductor manufacturing system, the semiconductor manufacturing system being configured to use the design information to manufacture the circuit according to the design, wherein the design information specifying the circuit includes:

[0300] Any combination of the elements described in Clauses A1 to A12.

[0301] ***

[0302] Set B

[0303] B1. An apparatus, the apparatus comprising:

[0304] A beam intersection circuit, wherein the beam intersection circuit is configured as follows:

[0305] Receive one or more ray intersection requests, wherein the one or more ray intersection requests indicate the origin and direction information of multiple rays in a ray set in the graphic scene;

[0306] Traversing multiple nodes of an accelerated data structure organized in space, where each node indicates coordinates corresponding to a boundary region of the graphics scene, to determine whether a ray intersects with the boundary region, includes:

[0307] The grouping circuit groups a portion of the ray set into multiple groups based on nodes of the data structure of the next target of the ray; and

[0308] A boundary region test circuit processes a first group based on the grouping, the first group comprising a subset of the ray set targeting the first node, to determine whether the rays in the first group intersect with one or more boundary regions of the first node.

[0309] B2. The apparatus according to any of the foregoing clauses in set B, wherein the light intersecting circuit is configured to select one or more groups of light during a clock cycle and schedule the light in the light groups to be emitted to the boundary region test circuit.

[0310] B3. The apparatus according to any of the foregoing clauses in set B, wherein the selection is based on the oldest ray in a different group of rays.

[0311] B4. The apparatus according to any of the foregoing clauses in set B, wherein the grouping provides a temporal location for accessing boundary region data cached in one or more data caches.

[0312] B5. An apparatus according to any of the foregoing clauses in set B, wherein the ray intersection circuitry includes independent grouping circuitry for the leaf nodes of the accelerated data structure and the internal nodes of the accelerated data structure.

[0313] B6. Any apparatus described in the foregoing clauses of set B, wherein the first set is specified by the linked list.

[0314] B7. The apparatus according to any of the foregoing clauses in set B, wherein an entry in the ray queue includes a field pointing to the next ray in the linked list for the current group of the corresponding ray.

[0315] B8. The apparatus according to any of the foregoing clauses in set B, wherein the first set comprises rays from multiple different SIMD groups processed by the shader processor.

[0316] B9. An apparatus according to any of the foregoing clauses in set B, wherein the ray intersecting circuit is configured to assign a ray to a new group whenever the ray traverses between levels of the accelerated data structure.

[0317] B10. An apparatus according to any of the foregoing clauses in set B, wherein the ray intersection circuit implements a stack traversal for the rays to perform a depth-first search of the accelerated data structure, and wherein the ray intersection circuit is configured to assign the rays to a new group whenever the top of the stack changes.

[0318] B11. The apparatus according to any of the foregoing clauses in set B, wherein, in order to determine the group of rays, the ray intersecting circuit is configured as follows:

[0319] The set of groups is determined using a key based on the next node pointed to by the ray as input to a hash function; and

[0320] Search the set of groups to determine whether the allocation group in the set matches the key.

[0321] B12. An apparatus according to any of the foregoing clauses in set B, wherein the ray intersecting circuit is configured to assign a new group to rays that do not match any currently assigned group.

[0322] B13. The apparatus according to any of the foregoing clauses in set B, wherein the boundary region test circuit includes a parallel test circuit configured to test light rays in parallel for multiple boundary regions of a node.

[0323] B14. A method comprising:

[0324] Any combination of operations performed by a circuit pursuant to any of the foregoing clauses within set B.

[0325] B15. A non-transitory computer-readable storage medium having design information stored thereon, the design information specifying at least a portion of a design of a hardware integrated circuit in a format recognizable by a semiconductor manufacturing system, the semiconductor manufacturing system being configured to use the design information to manufacture the circuit according to the design, wherein the design information specifying the circuit includes:

[0326] Any combination of the elements described in Articles B1 to B13.

[0327] ***

[0328] Set C

[0329] C1. An apparatus, the apparatus comprising:

[0330] One or more graphics processors, the one or more graphics processors being configured to:

[0331] Access data for multiple graphics primitives in the graphics scene to be rendered;

[0332] Generate a data structure organized in a spatial form, wherein some nodes of the data structure indicate graphical primitives, and some nodes indicate the coordinates of boundary regions in the graphical scene, wherein:

[0333] The spatially organized data structure includes nodes with boundary regions, for which multiple primitives are indicated as children; and

[0334] The spatially organized data structure includes primitives, for which multiple boundary regions are designated as parents; and

[0335] The data structure, organized in a spatial form, is traversed to determine whether rays in the graphical scene intersect with primitives; and

[0336] Based on the determination, the intersecting primitives are colored.

[0337] C2. An apparatus according to any of the foregoing provisions in set C, wherein the one or more graphics processors are configured to represent a first boundary region by quantizing information indicating a first boundary region in a spatially organized data structure using fewer bits than the original representation.

[0338] C3. An apparatus according to any of the foregoing provisions in set C, wherein the one or more graphics processors are configured to perform the quantization such that the quantized representation indicates a region greater than or equal to the first boundary region, thereby preventing false negative intersection results of the first boundary region.

[0339] C4. An apparatus according to any of the foregoing clauses in set C, wherein for a first node indicating one or more primitives, the spatially organized data structure includes one or more fields indicating the following:

[0340] The offset of the one or more basic elements; and

[0341] The number of primitives of the first node located at the offset.

[0342] C5. An apparatus according to any of the foregoing clauses in set C, wherein the spatially organized data structure comprises a node having at least four child nodes.

[0343] C6. An apparatus according to any of the foregoing clauses in set C, wherein the spatially organized data structure encodes the storage location of a node, and all child nodes of the node are located consecutively at that location.

[0344] C7. An apparatus according to any of the foregoing provisions in set C, wherein a driver for the one or more graphics processors is configured to insert debug data into a memory space between children of one or more of the nodes.

[0345] C8. An apparatus according to any of the foregoing clauses in set C, wherein the spatially organized data structure specifies primitive information in leaf nodes and boundary region information in internal nodes.

[0346] C9. An apparatus according to any of the foregoing clauses in set C, wherein the first leaf node and the second leaf node in the spatially organized data structure have different data sizes, wherein the respective parent nodes of the first leaf node and the second leaf node encode the different data sizes.

[0347] C10. The apparatus according to any of the foregoing provisions in set C further includes:

[0348] Network interface circuit; and

[0349] One or more central processing units.

[0350] C11. A method comprising:

[0351] Any combination of operations performed by a circuit according to any of the foregoing clauses within set C.

[0352] C12. A non-transitory computer-readable storage medium having design information stored thereon, the design information specifying at least a portion of a design of a hardware integrated circuit in a format recognizable by a semiconductor manufacturing system, the semiconductor manufacturing system being configured to use the design information to manufacture the circuit according to the design, wherein the design information specifying the circuit includes:

[0353] Any combination of the elements described in Clauses C1 to C10.

[0354] ***

[0355] Set D

[0356] D1. An apparatus, the apparatus comprising:

[0357] A shader circuit configured to execute ray intersection instructions for a first SIMD group, wherein the instructions indicate coordinate information of a set of rays in a graphical scene;

[0358] A beam intersection circuit, wherein the beam intersection circuit is configured as follows:

[0359] In response to the ray intersection command, a plurality of nodes in a spatially organized accelerated data structure are traversed, wherein the nodes of the data structure indicate coordinates corresponding to boundary regions in the graphics scene, and the traversal determines whether a ray intersects with the boundary region; and

[0360] In response to the arrival of the first node indicating the transformation, a second SIMD group is formed to perform on the shader circuit to transform the coordinates of one or more rays in the ray set.

[0361] D2. An apparatus according to any of the foregoing clauses in set D, wherein the accelerated data structure is a hierarchical structure and the first node is a leaf node of a higher-level accelerated data structure, the first node having child nodes in a lower-level accelerated data structure.

[0362] D3. The apparatus according to any of the foregoing clauses in set D, wherein the transformation positions the one or more rays in model space for instances of a graphical model that are instantiated multiple times in the graphical scene.

[0363] D4. An apparatus according to any of the foregoing clauses in set D, wherein the child nodes of the first node also have another parent node in the higher-level accelerated data structure, wherein the other parent node indicates different transformations when traversing the child nodes, wherein the different transformations are associated with model spaces for different instances of the graphical model.

[0364] D5. A device according to any of the foregoing clauses in set D, wherein the device is configured to store the original coordinates of the one or more rays and to recover to the original coordinates in response to traversing back through the accelerated data structure via the first node.

[0365] D6. An apparatus according to any of the foregoing clauses in set D, wherein the first SIMD group and the second SIMD group access ray data of the one or more rays in the shader memory space.

[0366] D7. An apparatus according to any of the foregoing provisions in set D, wherein the first SIMD set includes an instruction to allocate memory space for a set of rays in the shader memory space prior to executing the ray intersection instruction.

[0367] D8. The apparatus according to any of the foregoing provisions in set D, wherein the second SIMD group includes one or more rays from another SIMD group that execute ray intersection commands.

[0368] D9. The apparatus according to any of the foregoing clauses in set D, wherein the accelerated data structure is a boundary volume hierarchical structure.

[0369] D10. A device according to any of the foregoing clauses in set D, wherein the device is a computing device, the computing device comprising:

[0370] The graphics unit includes the ray intersection circuit and the shader circuit;

[0371] One or more central processing units; and

[0372] Network interface circuit.

[0373] D11. A method comprising:

[0374] Any combination of operations performed by a circuit according to any of the foregoing clauses within set D.

[0375] D12. A non-transitory computer-readable storage medium having design information stored thereon, the design information specifying at least a portion of a design of a hardware integrated circuit in a format recognizable by a semiconductor manufacturing system, the semiconductor manufacturing system being configured to use the design information to manufacture the circuit according to the design, wherein the design information specifying the circuit includes:

[0376] Any combination of the elements described in Articles D1 to D10.

[0377] ***

[0378] Set E

[0379] E1. An apparatus, the apparatus comprising:

[0380] Shader circuitry configured to execute ray intersection instructions for a first SIMD group, wherein the instructions indicate coordinate information of a first ray set in the graphics scene; and

[0381] A ray intersection circuit is configured to traverse multiple nodes in a spatially organized accelerated data structure in response to the ray intersection command, wherein the nodes include multiple nodes indicating the coordinates of boundary regions and multiple nodes indicating primitives in the graphics scene.

[0382] The apparatus is configured to form a second SIMD group in response to a node indicating one or more primitives arriving at the accelerated data structure. The second SIMD group operates on a second ray set that partially overlaps only with the first ray set. The second SIMD group includes one or more instructions for determining whether a ray in the second ray set intersects with the one or more primitives.

[0383] The shader circuitry is configured to shade one or more primitives indicated as intersecting based on the execution results of the second SIMD group.

[0384] E2. An apparatus according to any of the foregoing provisions in set E, wherein the shader circuitry is configured to indicate to the ray intersection circuitry whether to continue traversing of the one or more rays based on the intersection result of performing the second SIMD group.

[0385] E3. An apparatus according to any of the foregoing clauses in set E, wherein the first SIMD group and the second SIMD group operate on a first data structure storing information for a first ray of the one or more rays, wherein the first data structure is stored in a shader memory space that is also accessible to the ray intersection circuit.

[0386] E4. An apparatus according to any of the foregoing clauses in set E, wherein the second SIMD group is configured to access thread data of the second SIMD group identified by the ray intersection circuit from a buffer in the shader memory space.

[0387] E5. The apparatus according to any of the foregoing provisions in set E, wherein the second SIMD group comprises different threads configured to test a first ray against a plurality of different primitives.

[0388] E6. An apparatus according to any of the foregoing provisions in set E, wherein the second SIMD group includes a SIMD reduction instruction that performs an operation based on input values ​​from a plurality of threads operating with respect to the first ray.

[0389] E7. The apparatus according to any of the foregoing provisions in set E further includes a boundary region testing circuit configured to test in parallel during the traversal whether the ray intersects with a plurality of different ones in the boundary region indicated by the nodes of the accelerated data structure.

[0390] E8. An apparatus according to any of the foregoing provisions in set E, wherein the shader circuitry is configured to suspend the execution of the first SIMD group and resume the execution of the first SIMD group to shade the one or more primitives after receiving an intersection result from the second SIMD group.

[0391] E9. A device according to any of the foregoing clauses in set E, wherein the device is a computing device, the computing device comprising:

[0392] The graphics unit includes the shader circuit and the ray intersection circuit;

[0393] Central processing unit; and

[0394] Network interface circuit.

[0395] E10. A method comprising:

[0396] Any combination of operations performed by a circuit pursuant to any of the foregoing clauses within set E.

[0397] E11. A non-transitory computer-readable storage medium having design information stored thereon, the design information specifying at least a portion of a design of a hardware integrated circuit in a format recognizable by a semiconductor manufacturing system, the semiconductor manufacturing system being configured to use the design information to manufacture the circuit according to the design, wherein the design information specifying the circuit includes:

[0398] Any combination of the elements described in Articles E1 through E9.

[0399] ***

[0400] set F

[0401] F1. An apparatus, the apparatus comprising:

[0402] A first graphics shader core and a second graphics shader core are configured to execute instructions for multiple thread groups, wherein the first graphics shader core is configured to execute:

[0403] A first thread group, the first thread group having multiple single instruction multiple data (SIMD) groups configured to execute a first shader program; and

[0404] The second thread group has multiple SIMD groups configured to execute different second shader programs;

[0405] Memory circuits; and

[0406] A control circuit, wherein the control circuit is configured to provide access to data stored in the memory circuit according to a shader memory space, the shader memory space being accessible by a thread group (including the first thread group and the second thread group) executed by the first graphics shader core, but not accessible by a thread group executed by the second graphics shader core.

[0407] F2. An apparatus according to any of the foregoing provisions in set F, wherein the first cache in the first graphics shader core is a coherent point in the shader memory space, and the second high-level cache in the apparatus is a coherent point in the device memory space.

[0408] F3. An apparatus according to any of the foregoing clauses in set F, wherein the control circuitry is further configured to provide access to data stored in the memory circuitry according to the memory space described below:

[0409] The thread group memory space is used for the first thread group, and the thread group memory space can be accessed by the first thread group but cannot be accessed by any other thread group;

[0410] Thread memory space, which can be accessed by a single thread; and

[0411] Device memory space, which can be accessed by a thread group executed by both the first graphics shader core and the second graphics shader core.

[0412] F4. The apparatus according to any of the foregoing clauses in set F, wherein the shader memory space may also be accessed by one or more coprocessors for the first graphics shader core.

[0413] F5. The apparatus described in any of the foregoing clauses of set F, wherein the one or more coprocessors include a light-intersecting circuit.

[0414] F6. The apparatus according to any of the foregoing clauses in set F, wherein the ray-intersecting circuit is configured as follows:

[0415] Based on the instructions of the first thread group, traverse the spatially organized data structure to determine one or more primitives for which to test ray intersections; and

[0416] Start the second thread group to test the one or more primitives for the light;

[0417] The first thread group and the second thread group operate on the light information stored in the shader memory space.

[0418] F7. An apparatus according to any of the foregoing clauses in set F, wherein the first graphics shader core is configured to execute load, store, and atomize instructions targeting the shader memory space.

[0419] F8. An apparatus according to any of the foregoing provisions in set F, wherein the first graphics shader core is configured to execute a first SIMD group of the first thread group to use the shader memory space to store thread-granular intermediate graphics work for further processing by threads of a dynamically formed SIMD group.

[0420] F9. An apparatus according to any of the foregoing clauses in set F, wherein the dynamically formed SIMD group comprises a set of threads determined to have the same conditional result for conditional control transmission instructions.

[0421] F10. A method comprising:

[0422] Any combination of operations performed by a circuit according to any of the foregoing clauses within set F.

[0423] F11. A non-transitory computer-readable storage medium having design information stored thereon, the design information specifying at least a portion of a design of a hardware integrated circuit in a format recognizable by a semiconductor manufacturing system, the semiconductor manufacturing system being configured to use the design information to manufacture the circuit according to the design, wherein the design information specifying the circuit includes:

[0424] Any combination of the elements described in Clauses F1 through F9.

[0425] ***

[0426] This disclosure includes references to “implementation” or groups of “implementation” (e.g., “some implementations” or “various implementations”). An implementation is a different specific implementation or instance of the disclosed concepts. References to “implementation,” “an implementation,” “a particular implementation,” etc., do not necessarily refer to the same implementation. A large number of possible implementations are contemplated, including those specifically disclosed, as well as modifications or alternatives that fall within the substance or scope of this disclosure.

[0427] This disclosure may discuss potential advantages that may arise from the disclosed embodiments. Not all specific implementations of all 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 this disclosure. In fact, there are many reasons why an implementation falling 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 circuitry outside the scope of this disclosure, in conjunction with an embodiment of the disclosed embodiments, which negates or diminishes one or more of the disclosed advantages. Furthermore, suboptimal design execution of a particular implementation (e.g., the implementing technique or tool) may also negate or diminish the disclosed advantages. Even assuming an implementation of the technique, the realization of advantages may still depend on other factors, such as the environmental circumstances in which the implementation is deployed. For example, the inputs provided to a particular implementation may prevent one or more problems addressed in this disclosure from occurring in a particular context, and as a result, the benefits of its solution may not be realized. Given the existence of possible factors outside this disclosure, any potential advantages described herein should not be construed as a limitation of the claims that must be satisfied in order to prove infringement. Rather, the identification of such potential advantages is intended to illustrate one or more types of improvements available to a designer who benefits from this disclosure. Describing such advantages permanently (e.g., stating that a particular advantage "may occur") is not intended to convey a question about whether such advantages can actually be realized, but rather to recognize that the realization of such advantages often depends on the technological reality of additional factors.

[0428] 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 this disclosure, even where only a single example is described with respect to a particular feature. The disclosed embodiments are intended to be exemplary and not restrictive, without any statement to the contrary in this disclosure. Therefore, this application is intended to allow for claims covering the disclosed embodiments, as well as such alternatives, modifications, and equivalents, which will be apparent to those skilled in the art upon seeing the effective effects of this disclosure.

[0429] For example, features in this application can be combined in any suitable manner. Therefore, new claims may be made for any such combination of features during the proceedings of this patent application (or a patent application claiming priority thereto). Specifically, referring to the appended claims, features of dependent claims may be combined with features of other dependent claims, including claims dependent on other independent claims, where appropriate. Similarly, features from the respective independent claims may be combined where appropriate.

[0430] Therefore, while the appended dependent claims may be drafted such that each dependent claim is subordinate to a single other claim, additional dependent relationships are also contemplated. Any combination of dependent features conforming to this disclosure is contemplated, and such combinations may be protected by the claims in this patent application or another patent application. In short, the combinations are not limited to those specifically listed in the appended claims.

[0431] Where appropriate, it is also anticipated that claims drafted in one format or statutory type (e.g., apparatus) are intended to support corresponding claims in another format or statutory type (e.g., method).

[0432] ***

[0433] Because this disclosure is a legal document, various terms and phrases are subject to administrative and judicial interpretation. It is hereby announced that the following paragraphs, as well as the definitions provided throughout this disclosure, will be used to determine how the claims drafted based on this disclosure should be interpreted.

[0434] Unless the context clearly specifies otherwise, references to the singular form of an item (i.e., nouns or noun phrases preceded by "an," "a," or "the") are intended to mean "one or more." Therefore, references to "item" in a claim do not exclude additional instances of that item without context. "A plurality of" items refers to a collection of two or more items.

[0435] This article uses the term “may” in the sense of permission (i.e., having the potential to be, being able to), rather than in the sense of mandatory (i.e., must).

[0436] The terms “include” and “including” and their forms are open-ended and mean “including but not limited to”.

[0437] When the term “or” is used in this disclosure in relation to a list of options, it will generally be understood to be used in an inclusive sense unless the context otherwise provides. Thus, the expression “x or y” is equivalent to “x or y, or both,” and therefore covers 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.

[0438] 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 a single element 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” therefore refers to at least one element in the set [w, x, y, z], thus covering all possible combinations of that list of elements. This phrase should not be interpreted as requiring the existence 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.

[0439] In this disclosure, various “labels” may precede nouns or noun phrases. Unless the context otherwise provides, different labels used for features (e.g., “first circuit,” “second circuit,” “specific circuit,” “given circuit,” etc.) refer to different instances of the feature. Furthermore, 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.

[0440] The phrase "based on" is used to describe one or more factors that influence the determination. This term does not exclude the possibility that additional factors may influence the determination. That is, the determination may be based solely on the specified factors or on the 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 the possibility that the determination of A may also be based on another factor such as C. This phrase is also intended to cover implementations where A is determined solely based on B. As used herein, the phrase "based on" is synonymous with the phrase "at least partially based on."

[0441] The phrases “responding to” and “responding” describe one or more factors that trigger an effect. This phrase does not exclude the possibility that additional factors may influence or otherwise trigger the effect, whether these factors are used in conjunction with or independently of the specified factor. That is, the effect may respond solely to these factors, or it may respond to the specified factor along with other unspecified factors. Consider the phrase “responding to B to execute A.” This phrase specifies that B is a factor that triggers the execution of A or triggers a specific result of A. This phrase does not exclude that the execution of A may also respond to certain other factors, such as C. This 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 implementation schemes where A is executed solely in response to B. As used herein, the phrase “responding” is synonymous with the phrase “at least partially responding.” Similarly, the phrase “responding to” is synonymous with the phrase “at least partially responding to.”

[0442] ***

[0443] Within this disclosure, different entities (which may be referred to differently as “units,” “circuits,” other components, etc.) may be described or claimed to be “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 the structure is arranged to perform one or more tasks during operation. A structure may be said 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 perform that task, such as a device, circuit, system with processor units, and memory storing executable program instructions. This phrase is not used herein to refer to intangible things.

[0444] 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.

[0445] The term "configured as" is not intended to mean "configurable as". For example, an unprogrammed FPGA is not considered "configured as" to perform a specific function. However, the unprogrammed FPGA may be "configurable as" to perform that function. After proper programming, the FPGA can then be considered "configured as" to perform a specific function.

[0446] For the purposes of this U.S. patent application, the statement in the claims that the structure is “configured” to perform one or more tasks is expressly intended for the claim elements. NoReferencing 35 U.S.SC § 112(f). If an applicant wishes to invoke part 112(f) in the course of filing a U.S. patent application based on this disclosure, it will use the phrase “means for [performing functions]” to formulate the elements of the claims.

[0447] Different “circuits” may be described in this disclosure. These circuits or “circuits” constitute hardware that 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. Circuits may be custom-designed or taken from standard libraries. In various embodiments, circuits may, as appropriate, include digital components, analog components, or a combination of both. Certain types of circuits may generally be referred to as “cells” (e.g., decoding units, arithmetic logic units (ALUs), functional units, memory management units (MMUs), etc.). Such cells also refer to circuits or circuitry.

[0448] Therefore, the circuits / units / components and other elements disclosed in the accompanying 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 function of that circuit. For example, a particular “decoding unit” can be described as having the function of executing “the opcode of a processing instruction and routing that instruction to one or more of a plurality of functional units,” meaning that the decoding unit is “configured” to perform that function. To those skilled in the art of computers, this functional specification is sufficient to suggest a set of possible structures for the circuit.

[0449] In various implementations, as discussed in the preceding paragraphs, the arrangement of circuits, cells, and other elements defined by the functions or operations they are configured to perform, relative to each other, and the manner in which such circuits / cells / components interact, forms a microarchitecture definition of hardware that is ultimately manufactured in an integrated circuit or programmed into an FPGA to form a physical implementation of the microarchitecture definition. Therefore, a microarchitecture definition is considered by those skilled in the art to be a structure from which many physical implementations are derived, all of which fall within the broader structure described by the microarchitecture definition. That is, those skilled in the art, with the microarchitecture definition provided according to this disclosure, can implement this structure without excessive experimentation and using the application of a person of ordinary skill by encoding the description of the circuits / cells / components in a hardware description language (HDL) such as Verilog or VHDL. The HDL description is often expressed in a way that can be revealed as functional. However, for those skilled in the art, the HDL description is a way of translating the structure of a circuit, cell, or component into the details of the next level of implementation. Such HDL descriptions can take the following forms: behavioral code (which is typically non-synthesizable), Register Transfer Language (RTL) code (which is typically synthesizable compared to behavioral code), or structural code (e.g., a netlist specifying logic gates and their connectivity). HDL descriptions can be sequentially synthesized against a library of cells designed for a given integrated circuit manufacturing technology and can be modified for timing, power, and other reasons to obtain the final design database that is transferred to the factory to generate masks and ultimately produce integrated circuits. Some hardware circuitry or portions thereof can also be custom-designed in a schematic editor and captured into the integrated circuit design along with the synthesized circuitry. The integrated circuit may include transistors and other circuit elements (e.g., passive components such as capacitors, resistors, inductors, etc.), as well as interconnects between transistors and circuit elements. Some implementations may implement multiple integrated circuits coupled together to implement the hardware circuitry, and / or discrete components may be used in some implementations. Alternatively, the HDL design can be synthesized into a programmable logic array such as a Field Programmable Gate Array (FPGA) and implemented in the FPGA. This decoupling between the design of a set of circuits and their subsequent low-level implementations often results in a situation where the circuit or logic designer never specifies a particular set of structures for the low-level implementation that goes beyond a description of what the circuit is configured to do, because that process is performed at different stages of the circuit implementation process.

[0450] The fact that a circuit of the same specifications can be implemented using many different low-level combinations of circuit elements results in a large number of equivalent circuit structures. As noted, these low-level circuit implementations can vary depending on the manufacturing technology, the foundry chosen to manufacture the integrated circuit, the cell library provided for a particular project, and so on. In many cases, the choice of different design tools or methods to produce these different implementations can be arbitrary.

[0451] Furthermore, for a given implementation, a single concrete implementation of the circuit's specific functional specifications typically involves a large number of devices (e.g., millions of transistors). Therefore, the shearing volume of this information makes it impractical to provide a complete description of the low-level structure used to implement a single implementation, let alone a large number of equivalent possible implementations. To this end, this disclosure describes the structure of a circuit using functional abbreviations commonly used in industry.

Claims

1. An apparatus for primitive testing associated with ray intersection ergodicity, comprising: A shader circuit configured to execute a ray intersection instruction for a first single instruction multiple data (SIMD) group, wherein the instruction indicates coordinate information of a first set of rays in a graphical scene; A ray intersection circuit, configured to execute the ray intersection command in hardware, wherein executing the ray intersection command by the ray intersection circuit includes performing the following operations: Traversing multiple nodes in a spatially organized accelerated data structure, wherein the nodes include nodes indicating the coordinates of boundary regions and nodes indicating primitives in the graphical scene, wherein the ray intersection circuit includes multiple node tester circuits configured to perform arithmetic operations for intersecting rays with boundary regions corresponding to nodes; and In response to the traversal of the ray intersection circuit reaching a leaf node indicating one or more primitives of the accelerated data structure, a second SIMD group is invoked for processing by the shader circuitry. This second SIMD group operates on a second ray set that only partially overlaps with the first ray set. The second SIMD group includes one or more additional instructions to determine whether rays in the second ray set intersect with the one or more primitives. The shader circuitry is configured to shade one or more primitives that are indicated to intersect based on the execution results of the second SIMD group.

2. The apparatus according to claim 1, wherein, The shader circuit is configured to indicate to the ray intersection circuit whether to continue traversing the rays based on the intersection result of executing the second SIMD group.

3. The apparatus according to claim 1, wherein, The first SIMD group and the second SIMD group operate on a first data structure that stores information for the first ray, wherein the first data structure is stored in a shader memory space that can also be accessed by the ray intersection circuit.

4. The apparatus according to claim 3, wherein, The second SIMD group is configured to access thread data from a buffer in the shader storage space identified by the ray intersection circuitry used for the second SIMD group.

5. The apparatus according to claim 1, wherein, The second SIMD group includes different threads configured to test the first ray for multiple different primitives.

6. The apparatus according to claim 5, wherein, The second SIMD group includes SIMD reduction instructions that perform operations based on input values ​​from multiple threads operating on the first ray.

7. The apparatus of claim 1, further comprising a boundary region testing circuit configured to test in parallel during the traversal whether a ray intersects with a plurality of different boundary regions in the boundary regions indicated by nodes of the accelerated data structure.

8. The apparatus according to claim 1, wherein, The shader circuit is configured to pause the execution of the first SIMD group and resume the execution of the first SIMD group to shade the one or more primitives after receiving the intersection result from the second SIMD group.

9. The apparatus according to claim 1, wherein, The device is a computing device, and the computing device includes: The graphics unit includes the shader circuit and the ray intersection circuit; Central processing unit; and Network interface circuit.

10. A method for primitive testing associated with ray intersection ergodicity, comprising: A ray intersection instruction for a first single instruction multiple data (SIMD) group is executed by the shader circuitry, wherein the instruction indicates coordinate information of a first set of rays in the graphics scene, and executing the ray intersection instruction includes: A ray intersection circuit, which implements the ray intersection command in hardware, traverses multiple nodes in a spatially organized accelerated data structure, wherein the nodes include multiple nodes indicating the coordinates of a boundary region and multiple nodes indicating primitives in the graphics scene, wherein the traversal includes performing an intersection test between the boundary region and rays in the first ray set using multiple node tester circuits of the ray intersection circuit; and In response to the traversal reaching a leaf node indicating one or more primitives of the accelerated data structure, the ray intersection circuitry invokes the formation of a second SIMD group for processing by the shader circuitry. The second SIMD group operates on a second ray set that only partially overlaps with the first ray set. The second SIMD group executes one or more additional instructions to determine whether rays in the second ray set intersect with the one or more primitives. One or more primitives are shaded as intersecting by the shader circuitry based on the execution results of the second SIMD group.

11. The method of claim 10, further comprising: The shader circuit indicates to the ray intersection circuit whether to continue traversing the ray based on the intersection result of executing the second SIMD group.

12. The method according to claim 10, wherein, The first SIMD group and the second SIMD group operate on a first data structure that stores information for the first ray, wherein the first data structure is stored in a shader memory space that can also be accessed by the ray intersection circuit.

13. The method of claim 10, further comprising: During the traversal, it is tested in parallel whether the light rays intersect with multiple different boundary regions in the boundary region indicated by the nodes of the accelerated data structure.

14. The method of claim 10, wherein, The shader circuit suspends the execution of the first SIMD group and resumes the execution of the first SIMD group to shade the one or more primitives after receiving the intersection result from the second SIMD group.

15. A non-transitory computer-readable storage medium having stored thereon design information specifying at least a portion of a design of a hardware integrated circuit in a format recognizable by a semiconductor manufacturing system, the semiconductor manufacturing system being configured to use the design information to manufacture the circuit according to the design, wherein... The design information specifies that the circuit includes: A shader circuit configured to execute a ray intersection instruction for a first single instruction multiple data (SIMD) group, wherein the instruction indicates coordinate information of a first set of rays in a graphical scene; A ray intersection circuit, configured to execute the ray intersection command in hardware, wherein executing the ray intersection command by the ray intersection circuit includes performing the following operations: Traversing multiple nodes in a spatially organized accelerated data structure, wherein the nodes include nodes indicating the coordinates of boundary regions and nodes indicating primitives in the graphical scene, wherein the ray intersection circuit includes multiple node tester circuits configured to perform arithmetic operations for intersecting rays with boundary regions corresponding to nodes; and In response to the traversal of the ray intersection circuit reaching a leaf node indicating one or more primitives of the accelerated data structure, a second SIMD group is invoked for processing by the shader circuit, wherein the second SIMD group operates on a second ray set that only partially overlaps with the first ray set, wherein the second SIMD group includes one or more additional instructions to determine whether rays in the second ray set intersect with the one or more primitives; and The shader circuitry is configured to shade one or more primitives that are indicated to intersect based on the execution results of the second SIMD group.

16. The non-transitory computer-readable storage medium according to claim 15, wherein, The shader circuit is configured to indicate to the ray intersection circuit whether to continue traversing the rays based on the intersection result of executing the second SIMD group.

17. The non-transitory computer-readable storage medium according to claim 15, wherein, The first SIMD group and the second SIMD group operate on a first data structure that stores information for the first ray, wherein the first data structure is stored in a shader memory space that can also be accessed by the ray intersection circuit.

18. The non-transitory computer-readable storage medium according to claim 17, wherein, The shader storage space includes: A storage area for the buffer, the storage area being used to store thread data for dynamically formed SIMD groups; A storage area for optical data; and This area is used for storing ray stack data.

19. The non-transitory computer-readable storage medium according to claim 15, wherein, The ray intersection circuit includes a boundary region testing circuit configured to test in parallel during the traversal whether a ray intersects with a plurality of different boundary regions in the boundary regions indicated by the nodes of the accelerated data structure.

20. The non-transitory computer-readable storage medium according to claim 15, wherein, The shader circuit is configured to pause the execution of the first SIMD group and resume the execution of the first SIMD group to shade the one or more primitives after receiving the intersection result from the second SIMD group.

Images