Apparatus and method for detecting intersections between rays and graphics primitives, and non-transitory computer readable storage medium

Abstract

The disclosed technology relates to ray intersection processing for ray tracing. In some embodiments, the ray intersection circuitry traverses a spatial organization acceleration data structure and includes a boundary region circuitry configured to test in parallel whether a ray intersects with multiple different boundary regions indicated by a node of the data structure. A shader circuitry can execute a ray intersection instruction invoked by the ray intersection circuitry, and the traversal can produce an intersection result. The shader circuitry can color the intersecting primitives based on these intersection results. Compared to conventional techniques, the disclosed technology, which shares processing between the intersection circuitry and the shader processor, can improve performance, reduce power consumption, or both.

Description

Apparatus and method for detecting intersections between rays and graphic primitives, and non-transitory computer-readable storage medium This disclosure is generally related to ray tracing in a graphics processor, and more particularly, to a circuit system configured to detect intersections between rays and graphic primitives. In computer graphics, ray tracing is a rendering technique used to generate an image by tracing a light path as a pixel in an image plane and simulating its interaction with virtual objects. Ray tracing can allow three-dimensional visibility resolution between any two points in a scene, which is also the source of most of its computational costs. A general ray tracer samples the light path that starts at the camera and propagates through the scene in the opposite direction of light propagation (not from the light source) (this is sometimes called "backward ray tracing"). Starting at the camera has the advantage of only tracing rays visible to the camera. This system can model a rasterizer where the ray only stops at the first surface and invokes a shader (similar to a fragment shader) to compute a color. It can also model more common secondary effects, such as the exchange of illumination between scene elements (such as diffuse inter-reflection and transmission). The shader that evaluates the surface reflectivity properties can invoke further intersection queries (e.g., generate new rays) to capture the illumination incoming from other surfaces. This recursive process has many formulations but is commonly referred to as path tracing. Graphics processors implementing ray tracing generally provide more realistic scene and lighting effects compared to traditional rasterization systems. However, ray tracing is generally computationally expensive. Improving ray tracing techniques can improve realism in graphics scenes, improve performance (e.g., allow tracing more rays per frame, tracing more complex scenes, or both), reduce power consumption (which can be particularly important in battery-powered devices), etc. This disclosure presents various ray tracing techniques, and specifically ray intersection techniques. FIGS. 1A to 2 generally provide an overview of a graphics program and ray tracing. FIGS. 3A to 6 provide an introduction to example embodiments of a ray intersection accelerator circuit system. Figures 7 through 21 provide additional details regarding embodiments of a ray intersection circuit system and interactions with other graphics circuit systems. Specifically, FIG. 7 shows a parallel node test circuit system, FIG. 8 shows a memory space for sharing ray data between a shader and the intersection circuit system, FIGS. 9 through 11 show example data structures and memory spaces, FIGS. 12 through 13 show an example overall data flow, FIGS. 14A through 14B show example techniques for dynamically forming SIMD groups for primitive testing, FIGS. 15 through 16 provide a many-to-many mapping between boundary regions and primitives, FIGS. 17 through 18 provide example techniques for dynamically forming SIMD groups (e.g., for ray transform) during traversal, FIGS. 19 through 20 provide example ray grouping techniques for node testing, and FIG. 21 provides an overall flowchart for a ray intersection operation. FIGS. 21 through 25 provide details regarding the extent of a shader core memory space. FIG. 26 shows an example computing device that may include a graphics processor, FIG. 27 shows an example application, and FIG. 28 shows an example computer-readable medium storing circuit design information. Graphics Processing Overview Referring to FIG. 1A, shown is a flowchart depicting an example processing flow 100 for processing graphics data. In some embodiments, the transform and lighting procedure 110 may involve processing lighting information for vertices received from an application based on defined light source positions, reflectivity, etc.; assembling vertices into polygons (e.g., triangles); and / or transforming the polygons into the correct size and orientation based on their positions in three-dimensional space. The clip procedure 115 may involve discarding polygons or vertices that fall outside a viewport. The rasterization procedure 120 may involve, for example, defining fragments within each polygon based on the texture coordinates of the vertices of the polygon and assigning initial color values to each fragment. Fragments may specify attributes for the pixels they overlap, but the actual pixel attributes may be determined based on combining multiple fragments (e.g., in a frame buffer) and / or ignoring one or more fragments (e.g., if they are covered by other objects). The shading procedure 130 may involve changing pixel components based on lighting, shading, texture mapping, transparency, etc.. The shaded pixels may be assembled in a frame buffer 135. Modern GPUs generally include programmable shaders that allow application developers to customize the shading and other processing procedures. Thus, in various embodiments, the example elements of FIG. 1A are executed in various orders, executed in parallel, or omitted. Additional processing procedures may also be implemented. Referring now to FIG. 1B, there is shown a simplified block diagram depicting a graphics unit 150 according to some embodiments. In the illustrated embodiment, 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 write unit 170, and a memory interface 180. In some embodiments, the graphics unit 150 is configured to process both vertex and fragment data using the programmable shader 160, which can be configured to process graphics data using multiple execution pipelines or instances. In the illustrated embodiment, the vertex pipe 185 may include various fixed-function hardware configured to process vertex data. The vertex pipe 185 may be configured to communicate with the programmable shader 160 to coordinate vertex processing. In the illustrated embodiment, the vertex pipe 185 is configured to send the processed data to the fragment pipe 175 and / or the programmable shader 160 for further processing. In the illustrated embodiment, the fragment pipe 175 may include various fixed-function hardware configured to process pixel data. The fragment pipe 175 may be configured to communicate with the programmable shader 160 to coordinate fragment processing. The fragment pipe 175 may be configured to rasterize polygons from the vertex pipe 185 and / or the programmable shader 160 to generate fragment data. The vertex pipe 185 and / or the fragment pipe 175 may be coupled to the memory interface 180 (coupling not shown) to access graphics data. In the illustrated embodiment, the programmable shader 160 is configured to receive vertex data from the vertex pipe 185 and fragment data from the fragment pipe 175 and / or the TPU 165. The programmable shader 160 may be configured to perform vertex processing tasks on the vertex data, which may include various transformations and / or adjustments of the vertex data. In the illustrated embodiment, for example, the programmable shader 160 is also configured to perform fragment processing tasks (such as texturing and shading) on the pixel data. The programmable shader 160 may include multiple sets of multiple execution pipelines for processing data in parallel. In the illustrated embodiment, the TPU 165 is configured to schedule fragment processing tasks from the programmable shader 160. In some embodiments, the TPU 165 is configured to prefetch texture data and assign initial colors to fragments for further processing by the programmable shader 160 (e.g., via the memory interface 180). For example, the TPU 165 may be configured to provide fragment components in either normalized integer format or floating-point format. In some embodiments, the TPU 165 is configured to provide a group of four fragments in a 2x2 format (a "fragment quad") to be processed by a group of four execution pipelines in the programmable shader 160. In some embodiments, an image write unit (IWU) 170 is configured to store processed tiles of an image and may perform operations before a rendered image is transmitted for display or transmitted to memory for storage. In some embodiments, a graphics unit 150 is configured to perform tile-based deferred rendering (TBDR). In tile-based rendering, different portions of screen space (e.g., squares or rectangles of pixels) can be processed separately. A memory interface 180 can facilitate communication with one or more of various memory hierarchies in various embodiments. In the illustrated example, the graphics unit 150 includes a ray intersection accelerator (RIA) 190, which may include hardware configured to perform various ray intersection operations, as detailed below. Ray Tracing Overview Ray tracing techniques generally sample the optical path that starts at the camera and propagates into the scene (rather than from a light source) in the opposite direction of light propagation (this is sometimes referred to as "backward ray tracing"). A ray can be defined using an origin (O), a direction (D), and a parameter interval (T) that defines the active portion of the ray. Thus, a ray can be considered a line segment. A graphics processor can perform various queries for a given ray. For example, a "closest hit" query can locate the closest intersection geometry along the ray and within the parameter interval (this can be the most common type of query). An "any hit" query can locate any intersection geometry along the ray and within the parameter interval. This type of query can be used for shadow rays, for example, to determine whether a point in the scene has visibility to the light or is blocked. Once the intersection geometry has been determined, the geometry can be shaded based on the intersections, and then more rays can be generated for intersection testing, for example, from reflective surfaces. Ray intersection calculations are often facilitated by an acceleration data structure (ADS). To efficiently perform ray intersection queries, a spatial data structure can reduce the number of ray-surface intersection tests, thereby accelerating the query process. A common type of ADS is a bounding volume hierarchy (BVH) in which surface primitives are enclosed in a hierarchy of geometric proxy volumes (e.g., boxes), and the geometric proxy volumes are cheaper to test for intersection. These volumes can be referred to as bounding regions. By traversing the data structure and performing proxy intersection tests along the way, the graphics processor locates a set of conservative candidate intersection primitives for a given ray. A common form of BVH uses 3D axis-aligned bounding boxes (AABBs). Once constructed, an AABB BVH can be queried for all rays and is a viewpoint-independent structure. In some embodiments, these structures are constructed once for each distinct mesh in the scene, in local object space, or in the model space of the object, and rays are transformed from world space to local space before traversing the BVH. This can allow for geometric instancing (similar to rasterization instancing) of a single mesh with many rigid transformations and material properties. Animated geometry generally requires reconstruction of the data structure (sometimes with a less expensive update operation known as "refit"). For non-real-time usage scenarios where millions or billions of rays are traced for a single scene in a single frame, the cost of the ADS construction is fully amortized to the point of being "free". However, in real-time scenarios, there is generally a difficult trade-off between build cost and traversal cost, where the more efficient structures are generally more expensive to build. In some embodiments discussed in detail below, the intersection circuitry is configured to traverse a BVH ADS that uses 3D axis-aligned boxes for its bounding volumes. The ADS can have a maximum branching factor (e.g., 2, 4, 8, 16, etc.) and a flexible user-defined payload (e.g., the contents at the leaves of the tree), and it does not assume triangle geometry. FIG. 2 is a diagram illustrating an example ray tracing process using ADS according to some embodiments. The ADS construction component 215 receives the geometric data 210 for a graphical scene and generates the ADS 220. The ADS construction component 215 can build the ADS from scratch or update a previous ADS, for example, based on the position change of an animated object. The camera shading component 225 (which may also be referred to as a source shader) generates rays from the viewpoint (which may be referred to as primary rays, camera rays, or eye rays). These rays are processed by the ADS traversal component 230. The traversal includes operations by the boundary region (e.g., box) test component 235 and the primitive test component 240, and provides the intersection result to the result shading component 245 (which may be referred to as a hit shader). The shading can generate additional new rays for ADS traversal. The shading can generate fragment data for building a frame buffer at the component 250. In various disclosed embodiments, the intersection circuitry (e.g., a ray intersection coprocessor or dedicated circuitry included in a graphics processor) is configured to perform the ADS traversal 230 and the boundary region test 235. In some embodiments, the ray intersection circuitry generates work for the shader processors (e.g., for coordinate transformation or primitive test) during traversal. The shader processors can execute SIMD groups to perform various operations discussed below. Because there are various types of SIMD groups discussed in this document, the following notations will be used: "Group A" refers to a traditional SIMD group that executes a graphics program (and can execute a ray intersection instruction); "Group S" refers to the SIMD group formed by the ray intersection circuitry for coordinate transformation; and "Group T" refers to the SIMD group formed by the ray intersection circuitry for primitive test, as discussed in detail below. Example Ray Intersection Circuitry FIG. 3A is a block diagram illustrating an example graphics processor including shader processor circuitry and intersection circuitry according to some embodiments. In the illustrated embodiment, the system includes a programmable shader 160 (which can execute a graphics program) and a ray intersection accelerator (RIA) 190 (which is an example of dedicated intersection circuitry). In the illustrated example, the programmable shader 160 receives and executes an intersection ray instruction included in a graphics program. For example, the intersection ray instruction can be a single-instruction multiple-data (SIMD) instruction and can specify multiple rays. In response, the programmable shader 160 sends an intersection ray command to the RIA 190. The command can include a pointer to a data structure for the processed ray(s). In the illustrated example, the RIA 190 is configured to generate intersection results based on traversal of a spatial organization data structure (e.g., BVH) for the scene. The RIA 190 includes a boundary region test circuitry that can be configured to test a ray against a plurality of boundary regions (e.g., boxes) in parallel. In some embodiments, the intersection results indicate a set of primitives to be tested for intersection. For example, the RIA 190 can initiate one or more SIMD groups to perform primitive tests on the programmable shader 160, as discussed below with reference to FIGS. 14A-14B. In other embodiments, the RIA 190 can perform primitive tests and the intersection results can directly indicate the intersected primitives. The term "SIMD group" is intended to be interpreted in the sense well understood by those skilled in the art, and includes a set of threads for which the processing hardware processes the same instruction in parallel using different input data for different threads. Various types of computer processors can include pipeline sets configured to execute SIMD instructions. For example, graphics processors often include programmable shader cores that are configured to execute instructions for a set of related threads in SIMD fashion. 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 that can be broken down into several SIMD groups based on the parallel processing capabilities of the computer. In some embodiments, each thread is assigned to a hardware pipeline that fetches the operands for that thread and performs those specific operations in parallel with other pipelines for the set of threads. Note that a processor can have a large number of pipelines such that multiple separate SIMD groups can also execute in parallel. In some embodiments, each thread has a private operand storage, e.g., in a register file. Thus, reading a particular register from the register file can provide the register version for each thread in the SIMD group. Note that in other embodiments, a single thread can be used to perform the various disclosed techniques as performed using SIMD groups. Thus, the SIMD examples discussed herein are not intended to limit the scope of the disclosure. In various embodiments, SIMD techniques can improve performance relative to non-SIMD techniques, however, particularly given that a graphics processor generally includes a large amount of parallel hardware. FIG. 3B is a flowchart depicting an example method for detecting ray intersections using a ray intersection circuit system in accordance with some embodiments. The method shown in FIG. 3B may be used in conjunction with any of the computer circuit systems, systems, devices, components, assemblies, or others disclosed herein. In various embodiments, some of the method elements shown may be performed simultaneously, performed in a different order than shown, or may be omitted. Additional method elements may also be performed as needed. At 350, in the illustrated embodiment, a graphics shader circuit system (e.g., programmable shader 160) executes a ray intersection instruction that indicates origin and direction information for a set of one or more rays in a graphics scene. At 360, in the illustrated embodiment, a ray intersection circuit system (e.g., RIA 190) traverses a plurality of nodes in a spatial organization acceleration data structure in response to the ray intersection instruction, where the nodes of the data structure indicate coordinates corresponding to boundary regions in the graphics scene. At 370, in the illustrated embodiment, during the traversal, a boundary region test circuit system 310 tests in parallel whether one of the rays in the set of rays intersects any of the boundary regions indicated by a node of the data structure. At 380, in the illustrated embodiment, the device determines information specifying one or more graphics primitives intersected by respective rays of the set of one or more rays. At 390, in the illustrated embodiment, the graphics shader circuit system colors the specified one or more graphics primitives based on the intersecting rays. The following discussion of various embodiments of the method of FIG. 3B provides a high-level overview of various ray intersection techniques for the more detailed discussion that follows. In some embodiments, the boundary region test circuit system includes a plurality of boundary region testers configured to determine whether a ray intersects a boundary region and configured to perform parallel tests for a plurality of boundary regions. The boundary region test circuit system may also include common computation circuit system configured to perform one or more operations, the output of the one or more operations being shared by the boundary region testers. In some embodiments, the boundary region test circuit system further includes: a boundary region data cache; a ray data cache; and result sorting circuit system configured to sort intersection results from the plurality of boundary region testers based on the distance from an origin of a tested ray. In some embodiments, the boundary region test circuit system is configured to test a plurality of rays in parallel against the plurality of different boundary regions. In these embodiments, the boundary region test circuit system may test N rays against M boundary regions at the same time. In some embodiments, the device 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 a ray shader core space) accessible by 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 the specified one or more graphics primitives; and execute a ray intersection instruction for the one or more additional rays. In some embodiments, the acceleration data structure is a hierarchical structure, and a first node is a leaf node of an upper acceleration data structure, the leaf node having a child node in a lower acceleration data structure. (An example of such a hierarchical structure is discussed in more detail below with respect to FIG. 4.) The lower acceleration data structure may correspond to a graphics model that is instantiated multiple times in the graphics scene. The ray intersection circuitry may be configured to form a SIMD group (which may be referred to as a warp S) to transform the coordinates of one or more rays arriving at the first node into a model space of an instance of the graphics model. In some embodiments, the ADS has a relatively high branching factor, e.g., such that one or more nodes of the acceleration data structure include four or more bounding regions and four or more child nodes. In some embodiments, even larger branching factors may be supported, such as eight, ten, twelve, sixteen, etc. In some embodiments, the ADS supports an instance many-to-many mapping between bounding regions and primitives, e.g., such that the acceleration data structure includes nodes having at least one bounding region, and multiple primitives are indicated as children for the at least one bounding region, and the acceleration data structure includes at least one primitive, and multiple bounding regions are indicated as parents for the at least one primitive. In some embodiments, the ray intersection circuitry is configured to form a SIMD group (a warp T) to test a set of rays against a primitive corresponding to a leaf node of the data structure. In some embodiments, the ray intersection circuitry is configured to use grouping circuitry to group portions of the set of rays into multiple groups based on the node of the data structure that is their next target, where the testing is based on the groups. This can improve the temporal locality of accessing node data. Overview of Example Tree Structures and Depth-First Traversal FIG. 4 is a block diagram illustrating a simplified example ADS tree structure according to some embodiments. In the illustrated example, the tree includes nodes 0 to 5 and leaves L0 to L8. Each node may include two or more boundary regions each pointing to a child node or to one or more primitives. Conceptually, each node may store the bounds for its children, but not for itself (which may mean based on its parent node). In some embodiments, each leaf represents a primitive, such as a triangle, included in one of the boundary regions of the parent node. Detailed example data structures for nodes and leaves are discussed below with reference to FIGS. 9-10. In the illustrated example, each node has at most two child nodes, but in various embodiments, a larger branching factor may be implemented. In some embodiments, the "node test" for a node includes a bounds test for the multiple boundary regions corresponding to the child nodes. An internal node is a node whose children are all nodes (such as nodes 0 and 2 in FIG. 4). A leaf node is a node whose children are all leaves (such as nodes 1, 3, and 5 in FIG. 4). A mixed node has a mixture of leaf and node children, such as node 4 in FIG. 4. Breadth-first, depth-first techniques, or a combination of both may be used to traverse the tree-based ADS structure to, for example, determine one or more primitives against which to test the intersection of a ray. FIG. 5 is a diagram illustrating an exemplary depth-first traversal of a BVH tree using a ray stack according to some embodiments. In the illustrated example, the nodes shown with dashed lines are not intersected by the tested ray, and the solid triangles represent the intersected primitives. Consider the following example traversal corresponding to the situation of FIG. 5. First, the ray is tested against the root node 0 corresponding to a root boundary region of the scene extent. Each time there is a hit, the children of the node are tested. In this example, both nodes 1 and 2 are hit, so the traversal continues to the children of node 2, and node 1 is pushed onto the ray stack for the tested node. Both boxes 5 and 6 are hit, and node 6 is pushed onto the stack. When testing the children of node 5, node 7 is hit, but node 8 is not hit, so nothing is pushed onto the stack, and the traversal continues to the children of node 7. For node 11, both its boundary regions with the leaf children of node 7 are hit, so node 11 is pushed onto the stack, and the leaf is tested for primitive intersection. The ray stack of FIG. 5 shows the stack state at this point during the instance traversal, where nodes 11, 6, and 1 are on the stack. At this point, a leaf has been reached, and the delayed part of the tree, which can be called backtracking, should be traversed next. The intersection circuitry takes the stack and tests the leaf of node 11 for primitive intersection. Then, the intersection circuitry takes the stack and tests the children of node 6, both of which are misses. Nodes 12 and 13 are not reached during the traversal because their parent node 9 is not a hit. Then, the intersection circuitry takes node 1, and both of its children 3 and 4 are misses. Note that there are multiple reasons why a parent node can be a hit, but none of its children are hits. First, due to the nature of ADS, the parent boundary region combines a larger volume than the children, so a ray that intersects the parent boundary region may not intersect the child regions. Another reason is that a ray can be shortened based on the detected intersection with a primitive. For example, after hitting the primitive children of node 7, the length of the active part of the array can be clipped so that it does not pass through the intersection. In some cases, this can cause nodes 3 and 4 to be misses. When the stack is empty and there are no further paths to explore, the traversal can end and the intersection circuitry can return the result. Note that the various disclosed techniques can be applied to other data structures (e.g., non-tree acceleration or non-BVH data structures). The disclosed data structure diagrams are included for illustrative purposes but are not intended to limit the scope of the disclosure. Similarly, various node structures can be implemented using one or more different node types. Instance RIA Connectivity and Region Testing Circuitry FIG. 6 is a block diagram illustrating an example connectivity of a ray intersection circuitry with other graphics circuitry according to some embodiments. In the illustrated embodiment, a graphics processor includes an instruction fetch and scheduling circuitry 610, a shader pipeline 660 (e.g., which can be included in the programmable shader 160), an L0 storage circuitry 615, a routing network 620, an L1 memory 630, a higher-level cache / memory circuitry 640, an RIA 190, and a texture processing unit 165. The L0 register can be configured to store the operands processed by the shader pipeline 660. The L1 register 630 can be configured to store graphics data at a higher level, which is also available for the texture processing unit 165 and the RIA 190. The routing network 620 can facilitate the movement of operands between lanes in the shader pipeline (e.g., between threads within a SIMD group), between different storage levels, and between the L1 register and different units (such as the RIA 190 and the texture processing unit 165). For example, the higher-level cache / memory circuitry 640 can include one or more L2 caches or system memory. Various register or cache elements can implement appropriate addressing or cache organization schemes. Example data structures that can be stored in one or more of the storage elements of FIG. 6 are discussed below with reference to FIGS. 8 through 11. In some embodiments, a graphics program extracted by the circuitry 610 can include a ray intersection instruction. Based on this instruction, a shader pipeline 660 can send a ray intersection command to the RIA 190, which can access the associated ray and geometry data via the L1 register 630. The RIA 190 can also use communication through the routing network 620 to dynamically form SIMD groups for the shader pipeline 660. Note that the circuitry organization disclosed in FIG. 6 is included for illustrative purposes and is not intended to limit the scope of this disclosure. In other embodiments, any of various organizations of dedicated circuitry for ray intersection and programmable shader circuitry can be implemented. FIG. 7 is a block diagram illustrating a detailed example parallel boundary region test circuitry according to some embodiments. In the illustrated example, the parallel tester circuitry 710 receives ray data and boundary region data for multiple boundary regions and outputs results indicating whether a ray intersects the boundary regions. The parallel tester 710 includes a boundary region data cache 715, a ray data cache 720, common computing circuitry 725, boundary region testers 730A through 703N, and a result sorting circuitry 735. In some embodiments, 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 embodiments having M programmable shader instances, the RIA 190 can include multiple parallel testers 710 for each programmable shader, e.g., 2, 4, 8, etc. In these embodiments, each node tester can test up to M nodes per clock per programmable shader core. In some embodiments (e.g., in the depth-first traversal discussed herein), a given ray is tested against at most one node at a time. In some embodiments, the boundary region data cache 715 and the ray data cache 720 are configured to store, respectively, node and ray data for the current test and for reuse in subsequent tests. These caches may be able to maintain a throughput of one node test per clock per tester. For a test to occur, both ray and boundary region information may be required, so cache entries may be locked for reading until both pieces of information are available. FIG. 9, discussed in detail below, provides a detailed example encoding for boundary region data. In some embodiments, grouped rays that target the same next node can improve cache performance and reduce bandwidth to higher-level caches, as discussed in detail below with reference to FIGS. 19A through 19C. In some embodiments, the common computation circuitry 725 is configured to perform computations common to all boundary regions being tested. This may include determining bounds represented in a compressed quantization format. As another example, this may include common ray computations such as determining the reciprocal of a ray and a test point of a ray. In some embodiments, the common computations are performed with a higher floating-point precision for boundary region testing. In some embodiments, the boundary region tester 730 is configured to test whether a ray intersects a representation of a boundary region (however, note that false positives may be included in embodiments with quantization). For rectangular boundary regions, these testers may perform a slab test (e.g., finding the distance of each ray to the six sides of each block and comparing the values to determine if the ray has a hit in the block). 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 embodiments, the boundary region tester 730 uses lower-precision floating-point arithmetic and a selected rounding mode such that the computed intersection results for the three planes facing the ray are rounded down (toward the ray), and the computed intersection results for the three opposite planes away from the ray are rounded up (away from the ray) to ensure that the boundary region test is conservative and does not produce false negatives. In some embodiments, the result sorting circuitry 735 is configured to sort the hit results (e.g., based on their distance from the origin of the ray) and output the results for use in further traversals. Thus, based on this sorting, non-leaf children can be pushed onto a stack. In some embodiments, any leaf children can be grouped into a single stack item. In some embodiments, the sorting can affect the traversal of the ADS, e.g., during a depth-first search, children nodes corresponding to closer hits may be traversed first. In some embodiments, the parallel tester circuitry 710 is configured to store the value of a parameter interval (T) parameter at which a ray intersects a boundary region (and can store this value with higher precision than planar testing). This value may be referred to as T-local and can be stored in a stack item and retrieved to be used as the numerical ray origin for the child boundary region planar test. In some embodiments, multiple rays can be tested in parallel against the same node, a single ray can be tested in parallel against multiple nodes, or both. For example, the RIA 190 can include multiple parallel testers 710 to process all or a portion of the ray groups in parallel. In some embodiments, each boundary region tester 730 can be configured to test multiple rays in parallel against a boundary region. Example Data Structures and Overall Data Flow FIG. 8 illustrates an example organization of a ray shader core space (SCS) for storing ray data according to some embodiments. The ray SCS is a private memory space that can be dynamically allocated and allows sharing of data between different groups. Further, the ray SCS can allow sharing of data between different SIMD groups from the same data master and kick slot (e.g., between group A, group S, group T, etc.). At the end of the discussion of FIG. 8, a more detailed explanation of the concepts of a data master and a graphics kick is discussed below. The graphics processor may also include other memory spaces, such as thread private address space, thread group address space, and device address space. For example, the SCS can be allocated at the start of a graphics kick. The shader core space can advantageously allow sharing between different types of SIMD groups (e.g., group A type and group T or group S type), allow a smaller number of bits for addressing ray data (as compared to using a larger memory space for addressing), allow dynamic allocation of pages for data, or any combination thereof. For example, the techniques for dynamic private memory discussed in U.S. Patent Application No. 16 / 804,128, filed on February 28, 2020, can be used to dynamically allocate pages for the ray shader core space. In the illustrated embodiment, the shader core space includes regions for ray core data 820, ray stack data 830, ray extension data 840, and a token buffer 810. In some embodiments, the SCS may also include a context switch buffer (not shown) to handle context storage. A shader can allocate space in the SCS using an explicit instruction (e.g., an allocate ray instruction) and free the space with another explicit instruction (e.g., a free ray instruction after ray processing is complete). In some embodiments, the token buffer 810 provides scratch space for communication between the RIA 190 and the SIMD groups launched on the shader by the RIA 190. In some embodiments, these SIMD groups receive a ray identifier as part of their input data to access, for example, ray data allocated in the SCS prior to an intersection ray command. When forming a SIMD group (e.g., a group of Ts for primitive testing or a group of Ss for transformation), the RIA 190 can fill 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 embodiments, the token buffer stores pointers to information pending for primitive testing or coordinate transformation. For example, this can include a pointer to a leaf address for intersection testing, along with a thread count (which can be packed into the same group of Ts) sharing the same ray ID and the corresponding thread identifier. As another example, this can include a pointer to a ray for coordinate transformation. In some embodiments, the ray stack data 830 contains stack items for the rays during traversal, as discussed above with reference to FIG. 5. Each ray can have a dedicated space for its stack, but the stacks for all rays can be interleaved, which can reduce the footprint and can reduce the overall number of pages for the stack SCS. For example, the maximum size of the stack SCS can be determined based on one or more of the following: the size of the total number of rays, the number of levels in the ADS, and the branching factor of the ADS. The ray core data 820 can indicate the origin, direction, and active part of each ray and can be indexed using a ray identifier. This area can also be other data, such as an ε and axes for watertight ray traversal. The ray extension data 840 can include additional data that is less frequently accessed, such as intersection results, ray differentials, performance counters, etc., by, for example, a software shader. Separate ray core data 820 and extension data 840 can improve cache utilization. Frames that can execute multiple "kicks" to render graphics data. In some embodiments, a kick is a work unit from a single context, which may include multiple threads to be executed (and may potentially include other types of graphics work not executed by a shader). A kick may not provide any guarantees regarding memory synchronization among the threads (except as specified by the threads themselves), parallelism among the threads, or the order of kicks among the threads. In some embodiments, a kick may be identified as dependent on the result of another kick, which may allow memory synchronization without the need for hardware memory coherency support. Generally, before sending work to the pipeline for processing, the graphics firmware or hardware configuration registers each kick. Often, once a kick has started, it does not access a memory hierarchy above a certain level until the kick is complete (at which point the result may be written to a higher level in the hierarchy). The information for a given kick may include the state information required to complete the corresponding graphics operation, the location of the (multiple) shader programs to be executed, buffer information, the location of texture data, available address space, etc. For example, the graphics firmware or hardware may schedule a kick and detect an interruption when a kick is complete. In some embodiments, portions of the graphics unit 150 are configured to process a single kick at a time. This set of resources may be referred to as a "kick slot". Thus, in some embodiments, any data required for a given kick is read from memory shared among multiple processing elements at the start of the kick, and the result is written back to the shared memory at the end of the kick. Thus, other hardware does not see the kick result until the kick is complete, at which point the result is available in the shared memory and can be accessed by other kicks (including kicks from other data masters). A kick may include a set of one or more render commands, which may include commands for drawing procedural geometry, commands for setting shading sampling methods, commands for drawing meshes, commands for fetching textures, commands for performing generation operations, etc. During the rendering of a frame, a kick may be executed at one of various stages. Examples of rendering stages include but are not limited to camera rendering, light rendering, projection, texturing, fragment shading, etc. Kicks may be scheduled for, for example, arithmetic work, vertex work, or pixel work. Figure 9 is a diagram illustrating an example node data structure according to some embodiments. In the illustrated example, the node data structure includes bounds 0 through N for multiple bounding regions associated with the children of the node, metadata for each bounding region, an opcode, index information, origin information, child base information, status information, and shader index information. In some embodiments, the bounds 0 to N define a bounding region corresponding to at most N-1 child nodes. In some embodiments, these are aligned bounding boxes defined by their upper and lower corners along quantization axes (e.g., having six values per box in the X, Y, Z coordinate space). In some embodiments, these values are represented as fixed-point offsets and scale factors relative to a common origin (specified by the origin X, Y, Z fields) (e.g., scale factors that are powers of two specified by the exponent X, Y, Z fields). For example, the origin values can be represented as signed floating-point values. This allows all child nodes to be encoded relative to the parent bounds, which can avoid the progressive loss of precision as the boxes become smaller in deeper parts of the tree. The parent container (origin and exponent) can be referred to as the quantization frame of the node. The information indicating each bounding 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 status fields. For example, the status field can include one bit per child, which indicates whether the child is an internal node or a leaf node. As another example, the status field can separately encode the number of internal nodes and the number of leaf nodes. The metadata fields can indicate whether the child is invalid. The child base field can indicate the child base address of a node relative to the base address of the BVH tree, after which the children of the node can be stored. For leaf children, the metadata fields can indicate the number of leaves within a given bound and indicate an offset to the child position relative to the overall node's child base address where the number of leaves is stored. For non-leaf children, the metadata fields can similarly specify an offset relative to the child base address (in some embodiments, for hybrid nodes, the child nodes are stored first at that offset position, followed by the leaves). As discussed below with reference to FIG. 15, each bound can refer to one or more leaves, and each leaf can be referred to by one or more bounds. The opcode field can define information and performance hints regarding the node and its children. For example, in embodiments with variable-sized leaves, information about the leaf stride can define the stride between consecutive leaves. Another field in the opcode can indicate whether the children are associated with a transformation, e.g., such that a cluster of S's should be formed to transform rays when traversing to a child (techniques for this case are discussed below with reference to FIGS. 17-18). In some embodiments, the bounding coordinates are quantized to six, seven, or eight bits per coordinate, for example, which results in a 36-, 42-, or 48-bit bounding field to represent the six coordinates that define the rectangular boundary region. In some embodiments, the quantization technique that produces the quantized coordinate values (from an initial value that may use a larger number of bits) ensures that there may be false positive intersection results, but not false negative ones. For example, quantization may be performed in such a way that the quantized square representation is greater than or equal to the non-quantized square representation. For example, the quantization arithmetic may be configured to round for each corner in different directions (if rounding is performed, in the direction corresponding to the extended square). This can advantageously reduce the amount of data used per node without affecting accuracy and increases testing only marginally during traversal. FIG. 10 is a diagram illustrating an example configurable-size leaf data structure according to some embodiments. In the illustrated embodiment, each leaf includes a header and a payload (which has a plurality of available payload sizes A through N). As discussed above, the leaf stride for a leaf of a given node can be defined by the header data of that node. The header may include information to initiate a SIMD group for intersection testing for the primitive or to perform coordinate transformation for the primitive. The payload may include varying information for different types of primitives (e.g., default triangles, alpha-mapped triangles, moving triangles, etc.). Examples of payload information include, but are not limited to: a primitive identifier, a geometry identifier, one or more vectors, etc. In some embodiments, all child leaves of a given bounding have the same size. In other embodiments, the leaf sizes of a given bounding may be encoded separately. FIG. 11 is a diagram illustrating an example memory layout of an ADS tree structure with variable-size leaf nodes according to some embodiments. The left side of FIG. 11 shows a tree with a root node R, nodes A through D, and variable-size leaf nodes 0 through 9. The right side of FIG. 11 shows an example layout of these tree elements in memory. As shown, each node includes information indicating the offset in memory to any node children, followed by any leaf children. For example, for node A, the offset points to the location in memory where the information for node D is stored, followed by leaf nodes 5 and 6. In some embodiments, the disclosed encoding implements an undefined memory region following the leaf block (as indicated by the ellipsis in FIG. 11), which the graphics driver may use for various purposes. For example, the driver may insert debug information, extended primitive information, performance counters, etc. into these portions of the tree structure. In some embodiments, the processor is configured to split leaf data into multiple parts. For example, a leaf may be associated with a geometric primitive, and some data for that geometric primitive is always accessed for intersection testing, while some content is rarely needed for intersection testing (e.g., uv coordinates for alpha texture queries). These different types of data may be stored in the core and extension parts of a leaf data structure. In some embodiments, the extension part is stored in an undefined memory region following the leaf block, as discussed above. Note that the various node, leaf, and tree data structures described herein are included for illustrative purposes and are not intended to limit the scope of the disclosure. In other embodiments, various different structures and organizations may be implemented. FIG. 12 is a diagram illustrating an example data flow between an intersection circuit system, a node test circuit system, a memory region, and SIMD groups executed by a shader circuit system according to some embodiments. As shown in FIG. 12, in some embodiments, a graphics processor includes a ray intersection accelerator 190, a node tester 1210 (e.g., the parallel tester 710 of FIG. 7), and a shader circuit system such as a programmable shader 160 (not explicitly shown), which are configured to execute different types of SIMD groups: group A 1220 and group T / group S 1230. Further, the graphics processor implements a shader core space 1240 and a device memory space 1250 (where ADS is stored). FIG. 13 is a flowchart illustrating an example method associated with the data flow of FIG. 12 according to some embodiments. At 1310, in the illustrated embodiment, a group A executing on a shader allocates ray resources (e.g., by sending a request to the RIA 190 in response to executing an allocate ray instruction in the shader program executed by group A). At 1315, in the illustrated embodiment, the RIA 190 returns one or more ray IDs in one or more general-purpose registers (note that this ray allocation may be performed, for example, for multiple rays processed by group A). At 1320, in the illustrated embodiment, group A writes ray data for one or more allocated rays into the ray shader core space based on the provided ray ID(s). At 1325, in the illustrated embodiment, group A issues an intersect ray command with the ray ID (potentially along with other ray IDs) to the RIA 190 (e.g., based on executing an intersect ray instruction). This may start the ADS traversal process. After this point, rays from a given group A may ultimately take different paths through the ADS and may be processed separately until all rays of group A have completed their traversal. At 1330, in the illustrated embodiment, the RIA 190 locates the next ADS node of the ray and issues a test of the node to the node tester 1210. If this is the first test of the ray, the RIA 190 selects the root node. At 1335, in the illustrated embodiment, the node tester 1210 reads the node data and ray data from the shader core space and performs the node test. It then returns miss / hit information for the children of the node to the RIA 190. At 1340, in the illustrated embodiment, based on the test results, the RIA 190 traverses to the next node until it reaches a leaf node. If the next node is an internal node, the process continues back to 1330. If a leaf node is reached, the process continues to 1345. If the traversal is complete, the process continues to 1355. At 1345, in the illustrated embodiment, a leaf node has been reached and the RIA 190 generates a cluster T and sends a token buffer ID and information for cluster T. At 1350, in the illustrated embodiment, cluster T reads thread data (e.g., ray ID and primitive ID) from the shader core space using the token ID, reads primitive data from the device memory, and reads ray data from the shader core space using the ray ID. Cluster T also performs a primitive test, updates the ray data based on the primitive test (e.g., if there is a hit), and then notifies the RIA 190 whether to continue traversing (e.g., when a hit is detected, end the traversal for the closest hit query). Note that operations similar to those described with reference to elements 1345 and 1350 for cluster T can also be performed for cluster S. At 1340, when an S node is reached, the RIA 190 can generate a cluster S, read data from the device memory, read ray data, perform a transform on the ray on a shader (e.g., a leaf payload can be used to specify its parameters), and appropriately update a portion of the ray data. Cluster S can then notify the RIA 190 to continue traversing. At 1355, in the illustrated embodiment, the traversal is complete and the RIA 190 forms a cluster A that reads ray data with intersection results from the ray shader core space and issues a ray resource command (the subsequent ray ID can be used for another ray). The processor can decrement a fence counter, e.g., such that cluster A can wait until all its rays have completed traversing before continuing. Cluster A can then perform fragment shading based on the intersection results, which in some cases can in turn generate additional rays. Dynamically form SIMD groups FIG. 14A is a block diagram illustrating an example technique for dynamically forming SIMD groups for primitive testing according to some embodiments. In the illustrated embodiment, programmable shader 160 sends an intersect ray command to ray intersection accelerator (RIA) 190. The intersect ray command can be for a group A SIMD group for processing multiple rays, for example. RIA 190 traverses the acceleration data structure to produce intersection results for the rays (which can be from various group As and can take different paths through the data structure). In the illustrated example, once a leaf node is reached, RIA 190 does not actually perform a primitive test, but instead dynamically forms a primitive test SIMD group 1405 to be executed by programmable shader 160 (e.g., for a group of rays against the same primitive test). Programmable shader 160 executes these primitive test SIMD groups (of group T), and can provide primitive test results to RIA 190 (not explicitly shown). RIA 190 can aggregate the test results for a given group A, and when the results are ready, provide the results back to programmable shader 160, or RIA 190 can provide the results when they are done, and group T can aggregate these results (e.g., using a fence instruction). Note that the primitive test results can also indicate to RIA 190 whether it should continue traversing for a given ray, e.g., based on whether there is a hit and the requested intersection type. For a closest hit query, traversal ends when there is a hit. In some embodiments, the processor is configured to group multiple leaves that share the same shader into the same group T so that they can be tested together. This can advantageously reduce the average latency of primitive testing. In some embodiments, the processor designates one thread for each ray as a main thread, which responds to operations that are not parallelized between performing multiple leaf tests (e.g., determining a winner and updating the operations for that ray, such as finding the minimum of all distances and potentially performing a tiebreaker operation for a closest hit operation). Thus, a group can receive data indicating the ray ID of the ray being tested by the group, the primitive address of the primitive being tested, and information indicating "thread segments" that are the threads operating on the same ray (e.g., the count and thread ID information of these thread segments). For example, consider the following information for three rays and ten different primitives being tested: In this example, ray 2 is tested against a count value for five threads in the thread section for ray 2 and primitives 5 through 9 for different thread IDs (TIDs) 0 through 4 for the five threads within this thread section. Similarly, ray 1 is tested against primitives 3 and 4 for two threads in the thread section. As discussed above with reference to FIG. 8, the RAI 190 can store this information in the token buffer 810 for a group of Ts. In some embodiments, the group T executes a SIMD range of reduction instructions to perform non-parallel operations involving transforms. In these embodiments, the SIMD reduction instructions can access data from multiple threads in a SIMD group to produce an output. For example, this can replace a loop in one of the main threads that iterates through the threads to find the minimum distance among the threads within a thread section for a hit. Using SIMD reduction instructions instead of a loop can advantageously improve throughput. In these embodiments, the information for the group T can include a segment mask (SM) that represents the boundary between segments. In this example, a logical "1" in the segment mask indicates that this is the first thread in a new thread section. The SIMD reduction instructions can use this information to operate within each thread section without using input data from other thread sections. U.S. Patent Application No. 16 / 597,625, filed Oct. 9, 2019, is incorporated herein by reference and explains various example SIMD reduction operations and lane connection networks. These operations generally employ result registers and input registers and find the result based on different instances of the input registers corresponding to different threads in the SIMD group. In some embodiments, the SIMD reduction instructions employ an additional argument that indicates the segment mask. This can allow the execution pipeline to avoid carrying reduction results across thread sections and provide separate reduction results for each thread section. Thus, the shader circuitry can include control circuitry configured to limit the SIMD reduction operations to a thread section based on the segment mask. In some embodiments, all threads in a thread section receive the same result from the SIMD reduction operation (e.g., indicating the primitive with the closest hit). The SIMD reduction operation can support various arithmetic operations such as minimum, maximum, addition, etc. Thus, in some embodiments, different threads of a warp of T operate on different rays. Further, different threads of a warp of T may operate on different primitives for the same ray or for different rays. Further, a warp of T may execute a SIMD reduction instruction that performs an operation based on input values from multiple threads operating on the same ray and may produce the same result for each of the multiple threads in a thread section. FIG. 14B is a flowchart depicting an example method for dynamically forming a SIMD group for primitive testing in accordance with some embodiments. The method shown in FIG. 14B may be used in conjunction with any of the computer circuitry, systems, devices, components, assemblies, or others disclosed herein. In various embodiments, some of the method elements shown may be executed concurrently, executed in a different order than shown, or may be omitted. Additional method elements may also be executed as needed. At 1410, in the illustrated embodiment, the shader circuitry executes a ray intersection instruction for a first SIMD group, where the instruction indicates coordinate information for a first set of rays in a graphics scene. At 1420, in the illustrated embodiment, the ray intersection circuitry traverses multiple nodes in a spatially organized acceleration data structure in response to the ray intersection instruction, where the nodes include multiple nodes indicating boundary region coordinates in the graphics scene and multiple nodes indicating primitives. At 1430, in the illustrated embodiment, the device forms a second SIMD group in response to reaching a node of the acceleration data structure indicating one or more primitives, the second SIMD group operating on a second set of rays that only partially overlap the first set of rays, where the second SIMD group executes one or more instructions to determine whether the rays in the second set of rays intersect the one or more primitives. In some embodiments, the RIA 190 forms a second SIMD group, and the shader circuitry executes the second SIMD group. The first SIMD group and the second SIMD group are operable on a first data structure that stores information for a first ray of the one or more rays, where the first data structure is stored in a shader memory space that is also accessible by the ray intersection circuitry. For example, the first data structure may include ray core data 820, ray extension data 840, or both. In some embodiments, the second SIMD group accesses thread data from a buffer (e.g., a token buffer 810) in the shader memory space identified by the ray intersection circuitry for 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, the primitive coordinate data for the one or more primitives and the coordinates of the boundary regions are stored in a device memory space (e.g., as part of the ADS stored in device memory 1250). In some embodiments, the shader circuitry pauses execution of the first SIMD group (e.g., right after the intersecting ray instruction, or later in the program), and after receiving an intersection result from the second SIMD group (and possibly other groups T), continues execution of the first SIMD group to shade the one or more primitives. At 1440, in the illustrated embodiment, the shader circuitry shades one or more primitives indicated as intersections based on the result of executing the second SIMD group. Shading may be performed by continuing execution of the first SIMD group. In various embodiments, the techniques of FIGS. 14A and 14B can advantageously provide the performance and power consumption benefits of dedicated boundary region test circuitry while using a shader processor to perform more complex operations such as primitive tests. Many-to-many mapping between boundary regions and primitives FIG. 15 is a diagram illustrating an example many-to-many mapping between boundary regions and primitives according to some embodiments. In the illustrated example, the upper portion of FIG. 15 shows a two-dimensional view of four primitives and eight boundary regions, and the lower portion of FIG. 15 shows four leaf nodes corresponding to the four primitives and an example ADS node with eight boundary regions. Primitives P0 to P3 are triangular primitives. For example, boundary regions 0 to 7 may be boundary boxes. In various embodiments, although primitive vertices are specified in three dimensions or more in the boundary regions, the simplified example of FIG. 15 is shown in two dimensions to facilitate explanation. As shown, in some embodiments, a graphics processor generates and uses an acceleration data structure that supports a many-to-many mapping between boundary regions and primitives. For example, boundary regions 0 through 3 are all parents of primitive P0, so a primitive can have multiple parent boundary regions. Further, for example, boundary region 3 has multiple primitive children. Where traditional ADS generation techniques may have created a leaf node for primitive P0 at a higher level (e.g., as a child of a node that is an ancestor of boundary regions 0 through 3 and has a larger boundary region), the disclosed techniques can wait to create a leaf for the primitive at a lower level such that it is a child of multiple smaller boundary regions. In various embodiments, this many-to-many mapping structure (combining a relatively high branching factor) allows the boundary regions to provide a tight fit around the primitive. In various embodiments, this can reduce negative primitive test results. Since node testing is relatively less expensive than primitive testing in terms of processing resources, this reduction in primitive testing can improve performance, reduce power consumption, or both. For example, for a given scene, when fewer negative primitive tests are issued, fewer clusters T are formed. FIG. 16 is a flowchart depicting an example method for generating a spatially organized data structure with a many-to-many mapping according to some embodiments. The method shown in FIG. 16 can be used in conjunction with any of the computer circuitry, systems, devices, components, assemblies, or others disclosed herein. In various embodiments, some of the method elements shown can be executed simultaneously, executed in a different order than shown, or omitted. Additional method elements can also be executed as needed. At 1610, in the illustrated embodiment, a graphics processor accesses data for a plurality of graphics primitives in a graphics scene to be rendered. At 1620, in the illustrated embodiment, the graphics processor generates a spatially organized data structure, where the nodes of the data structure indicate the graphics primitives or coordinates of boundary regions in the graphics scene. In the illustrated embodiment, the spatially organized data structure includes a node having a boundary region, and a plurality of primitives for the boundary region are indicated as children. Further, the spatially organized data structure includes a primitive, and a plurality of boundary regions for the primitive are indicated as parents. In some embodiments, the graphics processor quantizes information indicating a first boundary region in the spatially organized data structure to represent the first boundary region using fewer bits than an original representation number. This quantization can reduce the overall storage requirements of the ADS. In some embodiments, performing the quantization causes the quantized representation to indicate 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 embodiments, the spatially organized data structure encodes a position of a node (e.g., an offset from the root position of the ADS), and all child nodes of the node are continuously located at that position. In some embodiments, the spatially organized data structure specifies primitive information in leaf nodes and boundary region information in internal nodes. In some embodiments, the spatially organized data structure includes one or more fields for a first node indicating one or more primitives, the one or more fields indicating: an offset at which the one or more primitives are located; and the number of primitives for the first node located at the offset. In some embodiments, the data structure has a relatively high branching factor. For example, the spatially organized data structure can include a node having at least four child nodes. In some embodiments, the data structure supports leaf nodes of variable size. Thus, a first leaf node and a second leaf node in the spatially organized data structure can have different data sizes, and the respective parent nodes of the first leaf node and the second leaf node can encode the different data sizes. In 1630, in the illustrated embodiment, the graphics processor traverses the spatially organized data structure to determine whether a ray in the graphics scene intersects a primitive and colors the intersecting primitives based on the determination. As discussed above, the processor can form a clique T for primitive testing and continue to execute clique A for coloring based on the intersection results. Dynamically form SIMD groups for ray coordinate transformation during traversal FIG. 17 is a diagram illustrating an example of dynamic formation of SIMD groups for ray transformation when traversing an acceleration data structure according to some embodiments. In the illustrated example, the ADS includes ten nodes 0 to 9. Two nodes (nodes 5 and 6, which can be referred to as S nodes) have boundaries where they have the same child node (node 7, which can be the root of a lower-level ADS, as discussed in detail below). These nodes can have a field that indicates that a transformation should be performed when traversing to the child node. For example, in the illustrated example, the opcode field discussed above with reference to FIG. 9 can indicate the transformation to be performed for this field for nodes 5 and 6 (indicated as a "(T)" value in FIG. 17). The RIA 190 can form a cluster S to transform the coordinates of one or more rays traversed (e.g., hits in the corresponding boundary region). The programmable shader 160 can execute one or more instructions specifying mathematical operations for the cluster S to perform the transformation. In some embodiments, the cluster S operates on the ray data in the shader core space 1240 such that when the transformation is complete, the RIA 190 can continue traversing based on the transformed ray data. At some point during traversal, the RIA 190 can transform the rays back to their original coordinates (e.g., by forming another cluster S or reverting to the stored original coordinates) for further traversal. The above ray coordinate transformation can be used in various scenarios. As an example, geometric instancing is a technique that allows rendering multiple copies of the same model in the same scene. Consider, for example, a model of a house that can be instanced multiple times in a scene to create a row of houses on a street. For each instance, a transformation matrix can be defined to transform the model from model space to world space. The ray tracer can use different techniques to support instancing. As an example, the system can transform the model for each instance and build an ADS that includes the world space geometry for all such instances. As another example, the system can build a single sub - part (e.g., a tree) of the acceleration data structure for the geometry being instanced in model space and perform the transformation to world space during traversal of the ADS, as shown in FIG. 17. The latter technique can provide a relatively small ADS due to the lack of replication of the instanced model in the ADS. In some embodiments, for each instance of the model space tree (e.g., nodes 7 to 9 in FIG. 17, which can provide a BVH tree for multiple instances of the model), a copy of the root boundary region is transformed to world space, and a hierarchy is built in which the root boundary region of the model serves as a leaf with multiple parents in the ADS. The upper - level hierarchy contains all the boundary regions of all instances of the model space tree and can be referred to as a top - level ADS. The model space BVH tree that is included once in the ADS and is being instanced can be referred to as a lower - level ADS. The system can perform the transformation when traversing from the top - level ADS to the lower - level ADS. The incident ray or the boundary region itself can be transformed. In some embodiments, as described above, the ray is transformed because this may be less computationally expensive. For example, for an affine transformation, only the origin and direction of the ray can be transformed (and not the direction). In some embodiments, for backtracking during traversal, an inverse transformation (e.g., using an inverse transformation matrix) can be performed. In other embodiments, the processor can record the original ray coordinates (e.g., origin and direction), avoiding the need to perform a reduction transformation. For example, this can reduce errors due to floating - point operations. In some embodiments, an ADS may include more than two hierarchical levels, where a transformation relative to the current level is performed each time the traversal continues to the next lower level. The processor may maintain a transformation stack that stores the coordinate information before the transformation for traversing back to a previous level. The ADS may indicate that the transformation should be performed at various granularities. As an example, a node may include a single field that indicates that a transformation should be performed when traversing to any of its child nodes. As another example, a node may separately encode whether a transformation should be performed when transitioning to a different child node. In the example illustrated in FIG. 17, a model may have been generated with three meshes corresponding to nodes 7 through 9, respectively. In the illustrated example, this model has been instantiated twice, and in the top-level ADS (corresponding to nodes 0 through 6), one node (nodes 5 and 6) per instance is marked as requiring a transformation. These nodes (nodes 5 and 6) are effectively the leaves of the top-level hierarchy. Although the disclosed techniques utilize SIMD groups executed by a shader pipeline, in other embodiments, dedicated RIA circuitry may be configured to perform the transformation for S nodes. FIG. 18 is a flowchart illustrating an example method for dynamically forming SIMD groups for ray coordinate transformation according to some embodiments. The method shown in FIG. 18 may be used in conjunction with any of the computer circuitry, systems, devices, components, assemblies, or others disclosed herein. In various embodiments, some of the method elements shown may be performed simultaneously, performed in a different order than shown, or may be omitted. Additional method elements may also be performed as needed. In 1810, in the illustrated embodiment, shader circuitry (e.g., programmable shader 160) performs a ray intersection instruction for a first SIMD group, where the instruction indicates the coordinate information of a set of rays in a graphics scene. In 1820, in the illustrated embodiment, ray intersection circuitry (e.g., RIA 190) traverses a plurality of nodes in a spatial organization acceleration data structure in response to the ray intersection instruction, where the nodes of the data structure indicate the coordinates corresponding to boundary regions in the graphics scene, and the traversal determines whether the ray intersects the boundary regions. In some embodiments, the acceleration data structure is a hierarchical structure, and the first node is a leaf node of an upper acceleration data structure, and the leaf node has a child node in a lower acceleration data structure. In some embodiments, the transformation positions one or more rays in a model space that is used for an instance of a graphical model that is instantiated multiple times in the graphical scene. Thus, in some embodiments, a child node of the first node (e.g., a root node for the model space) also has another parent node in the upper acceleration data structure, where the other parent node indicates a different transformation when traversing to the child node, and the different transformation is associated with a model space of a different instance of the graphical model. In some embodiments, the acceleration data structure is a bounding volume hierarchy. In 1830, in the illustrated embodiment, the device forms a second SIMD group (e.g., a group of S's) in response to reaching a first node indicating a transformation to be executed on the shader circuitry to transform the coordinates of one or more of the rays in the set of rays. In some embodiments, the ray intersection circuitry stores the original coordinates of the one or more rays; and in response to traversing back through the acceleration data structure through the first node, reverts to the original coordinates. In some embodiments, the first SIMD group and the second SIMD group access ray data for the one or more rays in a shader memory space. The first SIMD group includes an instruction for allocating memory space for the set of rays in the shader memory space before executing the ray intersection instruction. In some embodiments, the second SIMD group includes one or more rays from another SIMD group that executed a ray intersection instruction. Generally, rays from a group of A's can be split when taking different paths through the traversal, such that group S or group T can operate on rays from multiple different groups of A's. Example ray grouping during traversal FIG. 19A is a diagram illustrating an example of different rays whose current targets are different nodes in the ADS during their traversal. In the illustrated example, the targets of rays A, C, and E are node 1, the targets of rays B and D are node 2, the targets of rays X and Y are node 3, and the target of ray Z is node 4. In some embodiments, the graphics processor is configured to group rays to increase the number of rays tested against a node at a given time. This may also be referred to as binning or coherency gathering. The disclosed grouping techniques, discussed in detail below, can reduce bandwidth consumption, for example, at the L1 data cache that stores node data. In some embodiments, the graphics processor assigns each ray to a group before allowing the ray to be tested. The group can be a list of rays that share the same key. For boundary region testing, the key can be the address of the node that is the next target of the ray in the traversal. As other examples, the key can be the address of a parent node or a grandparent node. For leaf testing, the key can be the leaf header virtual address. The key can also include other context information of the data master and launch slot associated with the ray. The information for each group indicates the list of rays in the group. In some embodiments, dedicated circuitry is configured to store the list of rays for each bin. In these embodiments, various numbers of items can be used for grouping in various implementations, for example, 64, 128, 256, or 512 groups, each having 4, 8, 16, 32, or 64 items. In some embodiments, each time the top of the traversal stack changes for a given ray, the RIA searches the assigned group for a match for the corresponding key. The RIA can include grouping control circuitry 1910 configured to assign rays to groups, as shown in FIG. 19B. Similar to cache lines in a set-associate cache, the grouping control circuitry 1910 can search the groups, for example, by hashing the key to determine a set of groups and search for any assigned group in the set of groups for a key match. In these embodiments, the grouping control circuitry 1910 can include a content-addressable memory structure. If a match is found, the RIA 190 is configured to append the ray to the matching group. If no match is found but an unassigned group is available, the RIA 190 can create a new group and assign the ray to the new group. If no match is found and all groups are currently assigned, the grouping can pause until a group becomes available. Similar techniques can be used to group leaf nodes associated with primitives, for example, using separate dedicated circuitry to store the list of rays whose target is the same leaf node (or the same type of leaf, e.g., for shading coherence). In some embodiments, different numbers of groups, different numbers of items per group, or both can be implemented for leaf nodes and internal nodes. In some embodiments, the RIA 190 also tracks the age of the oldest ray within each group. For example, the RIA 190 can maintain an age field for each group in a control register. The age field can be quantized. Each cycle, the RIA can select up to N groups with the oldest rays and issue the rays from the selected groups that are scheduled to be issued for node or primitive testing. In some embodiments, the RIA 190 may not consider a group for scheduling until it includes a threshold number of rays. In other embodiments, various different techniques can be implemented for selecting between available groups. In some embodiments, the matching group determined by the grouping control circuitry 1910 is an index in a dedicated circuitry configured to store a list of rays for each assigned group. In other embodiments, attributes of a data structure can be used to indicate the matching group, e.g., one or more pointers to items in a list, as discussed below with reference to FIG. 19C. FIG. 19C is a diagram illustrating an example singly-linked list implementation 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 that indicates the next target node (e.g., in the example of FIG. 19A, where 0x2C is the node identifier that identifies node 1); and a next ray field that indicates the position of the next ray in the list. In some embodiments, this technique can allow groups to grow indefinitely without pausing. In some embodiments, the RIA supports at most 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 a tail pointer maintained by the grouping control circuitry 1910 can be updated. When a group is scheduled for testing, the RIA can use pointer chasing to iteratively traverse the list and find all the rays in the group. Although a singly-linked list is discussed for illustrative purposes, any of various other data structures can be implemented for ray grouping. Note that although a singly-linked list is shown for illustrative purposes, other data structures are contemplated. The disclosed grouping techniques can advantageously improve the temporal locality of boundary region data fetching. This can reduce cache thrashing and bandwidth to one or more data caches. FIG. 20 is a flowchart illustrating an example method for grouping rays during traversal of an ADS according to some embodiments. The method shown in FIG. 20 can be used in conjunction with any of the computer circuitry, systems, devices, components, assemblies, or others disclosed herein. In various embodiments, some of the method elements shown can be executed concurrently, executed in a different order than shown, or omitted. Additional method elements can also be executed as needed. In 2010, in the illustrated embodiment, a ray intersection circuit system (e.g., RIA 190) receives one or more ray intersection requests that indicate origin and direction information for a plurality of rays in a set of rays in a graphical scene. In 2020, in the illustrated embodiment, the ray intersection circuit system traverses a plurality of nodes in a spatial organization acceleration data structure whose nodes indicate coordinates corresponding to a boundary region of the graphical scene to determine whether a ray intersects the boundary region. In the illustrated embodiment, the traversal in 2020 includes steps 2030 and 2040. In 2030, in the illustrated embodiment, the ray intersection circuit system (e.g., using the grouping control circuit system 1910) groups portions of the set of rays into a plurality of groups based on the nodes of the data structure of their next targets. In some embodiments, the ray intersection circuit system includes separate grouping circuit systems for leaf nodes of the acceleration data structure and internal nodes of the acceleration data structure. In some embodiments, each time a ray traverses between levels of the acceleration data structure, the ray intersection circuit system assigns the ray to a new group. For example, the ray intersection circuit system can implement a traversal stack for the ray for a depth-first search of the ADS, and each time the top of the traversal stack changes, the ray intersection circuit system can assign the ray to a new group. In some embodiments, to determine a group for a ray, the ray intersection circuit system uses a key based on the next node targeted by the ray as an input to a hash function to determine a set of groups, and searches the set of groups to determine whether the assigned group in the set matches the key. The ray intersection circuit system can assign a new group to a ray that does not match any currently assigned group. In 2040, in the illustrated embodiment, the ray intersection circuit (e.g., using the parallel tester 710) processes a first group including a subset of the set of rays targeted at a first node based on the grouping to determine whether the rays in the first group intersect one or more boundary regions of the first node. In some embodiments, the processing is based on selecting one or more ray groups during a clock cycle for scheduling for issuing the boundary region test circuit system. In these embodiments, these groups can be emptied before continuing to process other groups, providing temporal locality for accessing boundary region data cached in one or more data caches. The selection of the (multiple) groups can be based on the oldest ray in the assigned ray group, which can provide fairness and avoid starvation. The first group can be specified by a linked list. In some embodiments, an item in a ray queue includes a field that points to the next ray in the linked list for the current group of the corresponding ray. In some embodiments, for example, due to rays from a given SIMD group that take different paths through the ADS and combine with rays from other groups, the first group includes rays from multiple different SIMD groups processed by a shader processor. The ray intersection circuitry can include parallel test circuitry configured to test a ray against multiple boundary regions of a node in parallel. Multiple instances of the parallel test circuitry can be configured to process multiple rays in parallel. Detailed Overall Intersection Traversal Example FIG. 21 is a flowchart illustrating an example method for processing rays according to some embodiments. The method shown in FIG. 21 can be used in combination with any of the computer circuitry, systems, devices, components, assemblies, or others disclosed herein. In various embodiments, some of the method elements shown can be executed simultaneously, executed in a different order than shown, or omitted. Additional method elements can also be executed as needed. In 2110, in the illustrated example, Group A, executed by a shader processor, assigns a ray. In 2112, RIA 190 allocates ray shader core space for the ray and returns a ray ID. In 2114, Group A writes data for the ray into the shader core space. In 2116, Group A issues an intersect ray instruction. In 2118, RIA 190 begins traversing an ADS for the ray, e.g., starting at the BVH root node. In 2120, RIA assigns the ray to a group (e.g., using a grouping circuitry) and waits for the group to clear (e.g., due to being one of the N oldest rays among the active groups, or according to some other suitable arbitration scheme within the group). In 2122, once the group is issued, RIA 190 determines the node type. If the node that is the target of the group is an interior node, the flow proceeds to 2124. If the node is a leaf node, the flow proceeds to 2140. In 2124, in the illustrated example, the parallel tester 710 performs a node test and returns hit information for the boundary regions of the node. If there is a hit in 2126, the flow proceeds to 2128, and RIA 190 pushes any unexplored nodes onto the ray stack, and the flow returns to 2120 (e.g., traversing to the next node in the ADS). If there is no hit in 2126, the flow proceeds to 2130. At 2130, if the stack is not empty, then at 2120, the RIA 190 removes a node from the stack and proceeds to 2120 (e.g., traverses to the next node in the ADS). If the stack is empty, then the RIA 190 ends the traversal at 2134. At 2140, in the illustrated example (for leaf nodes), the RIA 190 generates a token ID (a pointer to a buffer in the shader core space) for communication between the RIA 190 and the cluster T or cluster 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. Then, the shader schedules cluster T (for primitive testing) or cluster S (for ray coordinate transformation) and executes the cluster that updates the ray data at 2142. Once the cluster has ended, at 2144, the RIA 190 wakes up the ray to continue the traversal. If the ray is to be terminated (e.g., due to detecting an intersection for a closest hit query), then the flow proceeds to 2134 and the traversal ends. Otherwise (e.g., for an any hit query), then the flow proceeds to 2130, and if the stack is not empty, then the traversal continues. After the traversal has ended, cluster A can read the result data from the ray shader core space. The RIA 190 can also release the ray, including deallocating the ray from the ray shader core space. In some embodiments, the parallel tester 710 is configured to execute the component 2124 of FIG. 21. In some embodiments, the ray traversal control circuitry in the RIA is configured to execute the steps 2112, 2118, 2120, 2122, 2126, 2144, 2146, and 2134 of FIG. 21. In some embodiments, the ray stack manager circuitry is configured to execute the steps 2128, 2132, and 2130 of FIG. 21. In some embodiments, other graphics circuitry (such as shader circuitry) is configured to execute the steps 2110, 2114, 2116, and 2142 of FIG. 21. Shader Core Space As discussed above, a 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 can facilitate sharing of data between the RIA 190 and different types of SIMD groups (e.g., warp A and warp T). In some embodiments, the graphics processor uses the shader memory space for other operations. Generally, the disclosed shader memory sharing can advantageously facilitate sharing between co-processors and shaders and sharing between thread groups without the latency associated with cache coherence points in a higher-level memory space (such as a device or system memory space). In some embodiments, a graphics device implements the following memory spaces: a thread space (a private space for a given thread, although some SIMD permutation instructions may allow limited access to data for other threads in the SIMD group); a thread group space (a private space for a given thread group); a shader memory space (which can be accessed by multiple thread groups executing on the same shader core and possibly by one or more co-processors for the shader core, but not by thread groups executing on other shader cores); and a device space (which can be accessed by multiple shader cores and possibly by other circuitry on a computing device (e.g., a CPU)). Using the shader memory space (instead of the device memory) for certain types of data can advantageously provide lower latency for that data, allow for higher bandwidth implementations, reduce resource costs for coherence, or any combination thereof. FIG. 22A is a block diagram illustrating an example flash memory hierarchy accessible by a shader core according to some embodiments. In the illustrated embodiment, shader core 2210 and other circuitry 2230 can access all or a portion of cache / memory hierarchy 2220. Hierarchy 2220 can include lower-level circuitry (such as a register file), various caches (e.g., L0 (which can be tightly associated with one or more ALUs) for instructions and / or data, L1, L2, etc. caches), and memory circuitry (e.g., random access memory, disk drives, solid state storage, etc.). Coherence for different memory spaces can be enforced at different levels of the hierarchy. In some embodiments, the device implements a unified memory architecture where all storage is supported by the memory hierarchy. Other circuitry 2230 can include other shader cores, other graphics units, other processors (such as a CPU), other circuitry of a system-on-chip (SoC), etc. Note that in some embodiments, other circuitry 2230 and shader core 2210 can implement a portion of hierarchy 2220 internally, e.g., with private lower-level caches. In some embodiments, 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 that are not shared with other shader cores. Shader core 2210 may include several arithmetic logic units (ALUs) configured to execute instructions for a SIMD group in parallel. Shader core 2210 may be the smallest unit of scale of the GPU, e.g., the smallest unit capable of executing its own shader program. The GPU may include as few as a single shader core or as many shader cores as needed in a larger scale application. For arithmetic work, shader core 2210 may receive an arithmetic work group and assign work items from the work group to an internal processing pipeline. FIG. 22B is a block diagram showing an example flash memory hierarchy accessible by a plurality of shader cores and their coprocessors according to some embodiments. In the illustrated example, a plurality of shader cores 2210A to 2210N and their coprocessors 2240A to 2240N may access hierarchy 2220. RIA 190 is an example of coprocessors 2240A to 2240N. A texture processing unit (TPU) is another example. A given shader core 2210 may have multiple coprocessors, and all or a portion of these coprocessors may access at least a portion of hierarchy 2220. In some embodiments, hierarchy 2220 includes a coherence point for a shader memory space that is accessible by a shader core 2210 and its (multiple) coprocessors but not accessible by other shader cores and their coprocessors. Although various embodiments are discussed herein in terms of thread group granularity, the granularity at which core 2210, coprocessor 2240, or both access the shader memory space may vary (e.g., SIMD groups, threads, or thread groups may use the shader memory space to buffer data). FIG. 23 is a diagram illustrating an exemplary thread group, shader core, 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 can be accessed by co-processor 2240A and the thread group executed by shader core 2210A, but cannot be accessed by the thread groups executed by other shader cores (such as shader core 2210N) (however, note that shader core 2210N can implement its own shader core space, not explicitly shown). In the illustrated embodiment, thread group (TG) memory spaces 2310A to 2310M are private memory spaces that can be accessed by the thread group executed by shader core 2210A. In some embodiments, shader core 2210A also implements a thread memory space (not shown) assigned to a single thread. FIG. 24 is a block diagram illustrating an exemplary cache organization and coherence points for different memory spaces according to some embodiments. In the illustrated embodiment, shader core 2210 includes an L1 cache 2410, a register file 2420, a shader pipeline 2450, and control circuitry 2440. In this example, shader core 2210 is also configured to access a shared L2 cache 2430. In the illustrated example, register file 2420 serves as the coherence point for a thread group memory space, and L1 cache 2410 serves as the shader core space coherence point. The coherence point is the level at which all entities of a shared memory space (e.g., a thread group and a co-processor for a shader memory space) will see the same cached data. Implementing the shader memory space at the L1 level can reduce (e.g., among thread groups) the memory latency required for shared data by avoiding accessing higher levels of the memory hierarchy (e.g., to L2 cache 2430). In a unified memory embodiment that does not include a separate register file, the L1 cache can serve as the coherence point for the thread group space, the thread private space, and the shader core space. More generally, the L1 cache can be the coherence point for all memory spaces that are not accessible by circuitry external to shader core 2210. In some embodiments, thread private data can be stored in one or more L0 caches (and L1 cache 2410 if needed). In the illustrated example, L2 cache serves as the coherence point for the device memory space. In other embodiments, if the L2 cache is non-uniform, a higher-level cache (such as an L3 cache) can serve as the coherence point for the device memory space. In some embodiments, the shader pipeline 2450 is configured to execute instructions for a SIMD group, for example, using a shared program counter for threads in the SIMD group. These pipelines may include multiple pipeline stages configured to perform operations over multiple clock cycles. In some embodiments, the control circuitry 2440 is configured to facilitate the correct execution of memory access instructions targeted at different memory spaces. For example, the control circuitry may include circuitry to appropriately execute load, store, allocate, atomic, barrier, etc. instructions that access the shader memory space. For example, loads and stores to the shader memory space do not store or retrieve data from other spaces. From the perspective of other thread groups that can access the shader memory space, atomic operations on that space allow a thread group to perform memory access operations in an atomic manner. For example, if the L1 cache is the coherency point for the shader memory space, a thread group may acquire and update one or more L1 cache lines to perform a set of operations in an atomic manner. Barrier or fence operations for the shader memory space cause all operations before the barrier / fence in the code that can access the space to complete before the operations after the barrier. In addition to (or instead of) the ray intersection operations described above, the shader core space can also be used for various buffer operations. For example, thread divergence is a common cause of underutilization in SIMD processors for certain graphics workloads. For example, SIMD processors often use speculative execution to handle branch instructions. In speculative execution, both paths after the branch are executed, but threads that do not take the current path are predicted to be turned off during their execution. Thus, if some threads in the same SIMD group are predicted to be turned off while others are predicted to be turned on, the SIMD pipeline hardware may be underutilized. One way to address such underutilization is to move threads taking different paths to different cores. However, this can involve writing the resulting data out to device memory before starting a new core, which can substantially impact performance. In some embodiments, the threads of a SIMD group are split (and potentially recombined after executing divergent paths), and new SIMD groups are executed for different paths within the same core. For example, consider the following pseudocode: kernel void divergentTriangleShader (....) { / / Code block A t = loadTriangleData(); p = processTriangle(t); if (p < 0) { / / Code block B subdivide(t);} else { / / Code block C softwareRasterize(t, visibilityBuffer);}} In the above code example, if p < 0 is unpredictable, the shader can suffer from divergence issues where some threads in the same SIMD group execute code block B (while other threads are predicted off), and other threads in that SIMD group execute code block C. In some embodiments, this code is split into three different shaders within the same core: kernel void processTriangle () { t = loadTriangleData(); p = processTriangle(t); / / Thread subset queues work for other cores at thread granularity, / / to be formed into local simd groups for immediate execution on local shader cores if (p < 0) dispatchWorkitem(t, subdivideTriangleShader); else dispatchWorkitem(t, rasterizeTriangleShader);} kernel void subdivideTriangle () { t = loadTriangleData(); subdivide(t);} kernel void rasterizeTriangle () { softwareRasterize(t, visibilityBuffer);} In this example, if the processTriangle shader is executed by SIMD group A, one 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). In some embodiments, this fine-grained local scheduling can use shader memory space to store intermediate data, rather than sending data up to a coherence point for device memory, for example. For instance, in the above example, SIMD group A can store data in a buffer in the shader core space, and SIMD groups B and C can read the intermediate results from this buffer. Since SIMD groups B and C are in different thread groups (e.g., because they execute different shaders), the shader core space provides a convenient coherence point for shared data. FIG. 25 is a flowchart illustrating an example method for using shader memory space according to some embodiments. The method shown in FIG. 25 can be used in conjunction with any of the computer circuitry, systems, devices, components, assemblies, or others disclosed herein. In various embodiments, some of the method elements shown can be executed simultaneously, executed in a different order than shown, or omitted. Additional method elements can also be executed as needed. At 2510, in the illustrated embodiment, a first graphics shader core and a second graphics shader core execute instructions for 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 a first shader program; and a second thread group having multiple SIMD groups configured to execute a different second shader program. Note that in some embodiments, different thread groups executing the same shader program can also access the shader memory space. More generally, in some embodiments, the shader memory space can be accessed by any thread of any SIMD group of any thread group running on the same shader core. At 2520, in the illustrated embodiment, control circuitry provides access to data stored in the memory circuitry according to a shader memory space that can be accessed by the thread groups including the first thread group and the second thread group executed by the first graphics shader core, but not by the thread groups executed by the second graphics shader core. In some embodiments, a first cache (e.g., L1 cache 2410) in the first graphics shader core is a coherence point for the shader memory space, and a second higher-level cache (e.g., L2 cache 2430) in the device is a coherence point for the device memory space. In some embodiments, the control circuitry also provides access to data stored in the memory circuitry according to additional memory spaces having different sharing granularities, including: for one thread group memory space of the first thread group, which is accessible by the first thread group but not by any other thread group; a thread memory space, which is accessible by a single thread; and a device memory space, which is accessible by thread groups executed by both the first graphics shader core and the second graphics shader core. In some embodiments, one or more coprocessors for the first graphics shader core can also access the shader memory space. For example, the one or more coprocessors include RIA 190. In some embodiments, RIA 190 is configured to: based on an instruction of the first thread group (e.g., group A), traverse a spatially organized data structure to determine one or more primitives, a ray to be intersected with the one or more primitives; and initiate the second thread group (e.g., group T) to test the one or more primitives against the ray, where both the first thread group and the second thread group operate on ray information stored in the shader memory space. In some embodiments, the first graphics shader core is configured to execute load, store, and non-cuttable execution instructions targeted at the shader memory space. In some embodiments, the first graphics shader core is configured to execute a first SIMD group in the first thread group to use the shader memory space to store intermediate graphics work at thread granularity for further processing by threads of a dynamically formed SIMD group. The dynamically formed SIMD group can include a set of threads that are determined to have the same conditional result for a conditional control transfer instruction. Example Device Referring now to FIG. 26, shown is a block diagram depicting an example embodiment of a device 2600. In some embodiments, the components of device 2600 can be included within a system-on-chip. In some embodiments, device 2600 can be included in a mobile device that can be battery-powered. Thus, the power consumption of device 2600 can be an important design consideration. In the illustrated embodiment, device 2600 includes a fabric 2610, a compute 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, device 2600 can include other components (not shown) in addition to and / or instead of the illustrated components (such as video processor encoders and decoders, image processing or recognition elements, computer vision elements, etc.). The mesh architecture 2610 may include various interconnects, buses, MUXs, controllers, etc., and may be configured to facilitate communication between various components of the device 2600. In some embodiments, portions of the mesh architecture 2610 may be configured to implement various different communication protocols. In other embodiments, the mesh architecture 2610 may implement a single communication protocol, and components coupled to the mesh architecture 2610 may internally convert from the single communication protocol to other communication protocols. In the illustrated embodiment, the computing complex 2620 includes a bus interface unit (BIU) 2625, a cache 2630, and cores 2635 and 2640. In various embodiments, the computing complex 2620 may include various numbers of processors, processor cores, and / or caches. For example, the computing complex 2620 may include 1, 2, or 4 processor cores or any other suitable number. In one embodiment, the cache 2630 is a set-associative L2 cache. In some embodiments, the cores 2635 and / or 2640 may include internal instruction and / or data caches. In some embodiments, a coherence unit (not shown) in the mesh architecture 2610, in the cache 2630, or elsewhere in the device 2600 may be configured to maintain coherence between the various caches of the device 2600. The BIU 2625 may be configured to manage communication between the computing complex 2620 and other components of the device 2600. Processor cores, such as cores 2635 and 2640, may be configured to execute instructions of a particular instruction set architecture (ISA), which may include operating system instructions and user application instructions. The cache / memory controller 2645 may be configured to manage data transfer between the mesh architecture 2610 and one or more caches and / or memories. For example, the cache / memory controller 2645 may be coupled to an L3 cache, which in turn may be coupled to a system memory. In other embodiments, the cache / memory controller 2645 may be directly coupled to a memory. In some embodiments, the cache / memory controller 2645 may include one or more internal caches. As used herein, the term "coupled to" may indicate one or more connections between components, and a coupling may include intermediate components. For example, in FIG. 26, the graphics unit 150 may be described as "coupled to" a memory through the mesh architecture 2610 and the cache / memory controller 2645. Conversely, in the embodiment illustrated in FIG. 26, the graphics unit 150 is "directly coupled" to the mesh architecture 2610 because there are no intermediate components. 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 OPENGL®, Metal, or DIRECT3D® instructions. The graphics unit 150 may execute specialized GPU instructions or perform other operations based on the received graphics-oriented instructions. The graphics unit 150 may generally be configured to process large data blocks in parallel and may construct an image in a frame buffer for output to a display. The graphics unit 150 may include transform, lighting, triangle, and / or rendering engines in one or more graphics processing pipelines. The graphics unit 150 may output pixel information for displaying an 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 arithmetic tasks (which may or may not be graphics-related). 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 a CPU. The display unit 2665 may be configured to read data from a frame buffer and provide a stream of pixel values for display. In some embodiments, the display unit 2665 may be configured as a display pipeline. Additionally, the display unit 2665 may be configured to blend multiple frames to produce an output frame. Further, the display unit 2665 may include one or more interfaces (such as MIPI® or embedded display port (eDP)) for coupling to a user display (such as a touch screen or an external display). For example, the I / O bridge 2650 may include various components configured to implement: universal serial bus (USB) communication, security, audio, and / or low-power always-on functionality. For example, the bridge 2650 may also include interfaces such as pulse-width modulation (PWM), general-purpose input / output (GPIO), serial peripheral interface (SPI), and / or inter-integrated circuit (I2C). Various types of peripheral devices and apparatuses may be coupled to the device 2600 via the I / O bridge 2650. In some embodiments, device 2600 includes network interface circuitry (not explicitly shown) that can be connected to mesh fabric 2610 or I / O bridge 2650. The network interface circuitry can be configured to communicate via various networks, which can be wired, wireless, or both. For example, the network interface circuitry can be configured to communicate via a wired local area network, a wireless local area network (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 connectivity to device 2600 to various types of other devices and networks. Example Applications Turning now to FIG. 27, various types of systems can include any of the circuits, devices, or systems discussed above. Systems or devices 2700 that can incorporate or otherwise utilize one or more of the techniques described herein can be used in a wide range of fields. For example, systems or devices 2700 can be utilized as part of system hardware, such as a desktop computer 2710, a laptop computer 2720, a tablet computer 2730, a cellular or mobile phone 2740, a television 2750 (or a set-top box coupled to the television). Similarly, the disclosed elements can be used in wearable devices 2760, such as smart watches or health monitoring devices. In many embodiments, a smart watch can implement various different functions, e.g., accessing email, cellular services, calendars, health monitoring, etc. Wearable devices can also be designed independently to perform 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 contemplated, including devices worn around the neck, devices implantable in the human body, glasses or helmets designed to provide a computer-generated reality experience, such as based on augmented and / or virtual reality, etc. The system or device 2700 can also be used in various other contexts. For example, the 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. Further, the system or device 2700 can be implemented in a wide range of dedicated everyday devices, including devices 2780 commonly found in the home, such as refrigerators, thermostats, security cameras, etc. The interconnection of such devices is often referred to as the "Internet of Things" (IoT). The components can also be implemented in various modes of transportation. For example, the system or device 2700 can be used in control systems, guidance systems, entertainment systems, etc. of various types of vehicles 2790. The applications depicted in FIG. 27 are merely illustrative and are not intended to limit the potential future applications of the disclosed system or device. Other example applications include (but are not limited to): portable gaming devices, music players, data storage devices, drones, etc. Example computer-readable media This disclosure has described various example circuits in detail above. This disclosure not only intends to cover embodiments including such circuit systems, but also intends to cover a computer-readable storage medium including design information specifying such circuit systems. Thus, the patent claims supported by this disclosure not only cover a device including the disclosed circuit system, but also cover a storage medium specifying a circuit system in a format recognized by a manufacturing system configured to produce hardware (e.g., an integrated circuit) including the disclosed circuit system. The patent claims for such a storage medium are intended to cover, for example, an entity that produces a circuit design but does not itself manufacture the design. FIG. 28 is a block diagram illustrating an example non-transitory computer-readable storage medium storing circuit design information according to some embodiments. In the illustrated embodiment, the semiconductor manufacturing system 2820 is configured to process design information 2815 stored on the non-transitory computer-readable medium 2810 and manufacture an integrated circuit 2830 based on the design information 2815. The non-transitory computer-readable storage medium 2810 may include any of various 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, a floppy disk, or a magnetic tape device); a computer system memory or random access memory (such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.); a non-volatile memory (such as flash, magnetic media (such as a hard disk), or optical storage); a register or other similar type of memory element, etc. The non-transitory computer-readable storage medium 2810 may also 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 at different locations (such as in different computer systems connected via a network). The design information 2815 may be specified using any of various suitable computer languages (including hardware description languages), such as, but not limited to: VHDL, Verilog, SystemC, SystemVerilog, RHDL, M, MyHDL, etc. The semiconductor manufacturing system 2820 may use the design information 2815 to manufacture at least a portion of the integrated circuit 2830. The format of the design information 2815 may be recognized by at least one semiconductor manufacturing system 2820. In some embodiments, the design information 2815 may also include one or more component libraries that specify the synthesis and / or layout of the integrated circuit 2830. In some embodiments, the design information is specified, in whole or in part, in the form of a wiring对照表 that specifies the component library components and their connections. The design information 2815, taken alone, may or may not include sufficient information to manufacture a corresponding integrated circuit. For example, the design information 2815 may specify the circuit components to be manufactured but not their physical layout. In this case, the design information 2815 may need to be combined with layout information to actually manufacture the specified circuit system. In various embodiments, the integrated circuit 2830 may include one or more custom macro circuit components, such as, memories, analog or mixed-signal circuits, and the like. In such a case, the design information 2815 may include information related to the included macro components. Such information may, without limitation, include a circuit diagram extraction database, mask design data, behavioral models, and device or transistor-level wiring对照表. As used herein, the mask design data may be formatted according to the Graphic Data System (GDSII) or any other suitable format. The semiconductor manufacturing system 2820 can include any of a variety of suitable components configured to manufacture integrated circuits. For example, this can include components for depositing semiconductor materials (e.g., on a wafer that may include a mask), removing materials, changing the shape of the deposited materials, modifying materials (e.g., by doping the materials or using ultraviolet treatment to modify the dielectric constant), etc. The semiconductor manufacturing system 2820 can also be configured to perform various tests of the manufactured circuits for proper operation. In various embodiments, the integrated circuit 2830 is configured to operate according to a circuit design specified by the design information 2815, which can include any of the functions described herein. For example, the integrated circuit 2830 can include any of the various components shown in FIGS. 1B, 3A, 6, 7, 14A, 19B, 22A - 22B, 24, or 26. Further, the integrated circuit 2830 can be configured to perform the various functions described herein in combination with other components. Further, the functions described herein can be performed by multiple connected integrated circuits. As used herein, a phrase of the form "design information specifying a design of a circuit configured to..." does not mean that the circuit in question must be manufactured to meet that element. Instead, this phrase indicates that a circuit described by the design information, once manufactured, will be configured to perform the indicated actions or will include the specified components. The following numbered clauses set forth various non - limiting embodiments disclosed herein: A Group A1. An apparatus comprising: A graphics shader circuit system configured to execute a ray intersection instruction indicating origin and direction information for a set of one or more rays in a graphics scene; A ray intersection circuit system configured to: Traverse a plurality of nodes in a spatial organization acceleration data structure in response to the ray intersection instruction, wherein the nodes of the data structure indicate coordinates corresponding to boundary regions in the graphics scene; During the traversal, use a boundary region test circuit system to concurrently test whether one of the set of rays intersects a plurality of different boundary regions indicated by a node of the data structure; and Wherein the apparatus is configured to determine information of one or more graphics primitives specified to be intersected by respective rays of the set of one or more rays based on the traversal and testing; and Wherein the graphics shader circuit system is configured to color the one or more specified graphics primitives based on the intersecting rays. A2. The apparatus as in any of the preceding items in Group A, wherein the boundary region test circuit system is configured to concurrently test a plurality of rays against the plurality of different boundary regions. A3. The apparatus as in any of the preceding items in Group A, wherein the boundary region test circuit system includes: A plurality of boundary region testers configured to determine whether a ray intersects a boundary region and configured to perform concurrent testing for a plurality of boundary regions; and A common node calculation circuit system configured to perform one or more operations, the output of the one or more operations being shared by the boundary region testers. A4. The apparatus as in any of the preceding items in Group A, wherein the boundary region test circuit system further includes: A boundary region data cache; A ray data cache; and A result sorting circuit system configured to sort intersection results from the plurality of boundary region testers based on a distance from an origin of a tested ray. A5. The apparatus as in any of the preceding items in Group A, wherein the apparatus is configured to store ray data for the set of one or more rays in a shader memory space accessible to the graphics shader circuit system and the ray intersection circuit system. A6. The apparatus as in any of the preceding items in Group A, wherein the graphics shader circuit system is configured to: Generate one or more additional rays based on the coloring of the one or more specified graphics primitives; and Execute a ray intersection instruction for the one or more additional rays. A7. The apparatus as in any of the preceding items in Group A, wherein the acceleration data structure is a hierarchical structure, and a first node is a leaf node of an upper-level acceleration data structure, the leaf node having a child node in a lower-level acceleration data structure; Wherein the lower-level acceleration data structure corresponds to a graphics model that is instantiated multiple times in the graphics scene; and Wherein the ray intersection circuit system is configured to form a SIMD group to transform coordinates of one or more rays reaching the first node into a model space of an instance of the graphics model.A8. The apparatus of any of the foregoing items in Group A, wherein one or more nodes of the acceleration data structure include four or more boundary regions and four or more child nodes. A9. The apparatus of any of the foregoing items in Group A, wherein the acceleration data structure includes a node having a boundary region, and a plurality of primitives for the boundary region are designated as children; and wherein the acceleration data structure includes a primitive, and a plurality of boundary regions for the primitive are designated as parents. A10. The apparatus of any of the foregoing items in Group A, wherein the ray intersection circuitry is configured to form a SIMD group to test a set of rays against a primitive corresponding to a leaf node of the data structure. A11. The apparatus of any of the foregoing items in Group A, wherein the ray intersection circuitry is configured to use a grouping circuitry to group portions of the set of rays into groups based on the nodes of the data structure for their next targets, wherein the testing is based on the groups. A12. The apparatus of any of the foregoing items in Group A, wherein the apparatus is a computing device, which includes: a graphics processor, which includes the ray intersection circuitry; a central processing unit; and network interface circuitry. A13. A method, which includes any combination of operations performed by the apparatus of any of the foregoing items in Group A. A14. A non-transitory computer-readable storage medium having design information stored thereon, the design information specifying a design of at least a portion of a hardware integrated circuit in a format recognized by a semiconductor manufacturing system configured to produce the circuit according to the design using the design information, wherein the design information specifies that the circuit includes any combination of the elements described in items A1 to A12. *** B Group B1. An apparatus comprising: a ray intersection circuitry configured to: receive one or more ray intersection requests indicating origin and direction information for a plurality of rays in a set of rays in a graphics scene; traverse a plurality of nodes in a spatial organization acceleration data structure whose node indicates coordinates corresponding to a boundary region of the graphics scene to determine whether a ray intersects the boundary region, including: grouping portions of the set of rays into a plurality of groups by a grouping circuitry based on the nodes of the data structure for their next targets; and processing, by the boundary region testing circuitry, a first group including a subset of the set of rays targeted at a first node to determine whether the rays in the first group intersect one or more boundary regions of the first node. B2. The apparatus as in any of the preceding items in Group B, wherein the ray intersection circuitry is configured to select one or more ray groups during a clock cycle and schedule the rays in the ray groups for issuance to the boundary region testing circuitry. B3. The apparatus as in any of the preceding items in Group B, wherein the selection is based on the oldest ray in different ray groups. B4. The apparatus as in any of the preceding items in Group B, wherein the grouping provides temporal locality for accessing boundary region data cached in one or more data caches. B5. The apparatus as in any of the preceding items in Group B, wherein the ray intersection circuitry includes separate grouping circuitry for leaf nodes of the acceleration data structure and internal nodes of the acceleration data structure. B6. The apparatus as in any of the preceding items in Group B, wherein the first group is specified by a linked list. B7. The apparatus as in any of the preceding items in Group B, wherein an entry in a ray queue includes a field that points to the next ray in the linked list for the current group for the corresponding ray. B8. The apparatus as in any of the preceding items in Group B, wherein the first group includes rays from a plurality of different SIMD groups processed by a shader processor. B9. The apparatus as in any of the preceding items in Group B, wherein the ray intersection circuitry is configured to assign a ray to a new group each time the ray traverses between levels of the acceleration data structure. B10. The apparatus as in any of the preceding items in Group B, wherein the ray intersection circuitry implements a traversal stack for a ray for a depth-first search of the acceleration data structure, and wherein the ray intersection circuitry is configured to assign the ray to a new group each time the top of the traversal stack changes. B11. The apparatus as in any of the preceding items in Group B, wherein to determine a group for a ray, the ray intersection circuitry is configured to: use a key based on the next node targeted by the ray as an input to a hash function to determine a set of groups; and search the set of groups to determine whether an assigned group in the set matches the key.B12. The apparatus of any of the foregoing items in Group B, wherein the ray intersection circuit system is configured to assign a new group to a ray that does not match any currently assigned group. B13. The apparatus of any of the foregoing items in Group B, wherein the boundary region test circuit system includes a parallel test circuit system configured to test a ray in parallel against multiple boundary regions of a node. B14. A method comprising: any combination of operations performed by a circuit system of any of the foregoing items in Group B. B15. A non-transitory computer-readable storage medium having design information stored thereon, the design information specifying a design of at least a portion of a hardware integrated circuit in a format recognized by a semiconductor manufacturing system configured to produce the circuit from the design information according to the design, wherein the design information specifies that the circuit includes: any combination of the elements described in Items B1 to B13. ***. C Group C1. An apparatus comprising: one or more graphics processors configured to: access data for a plurality of graphic primitives in a graphic scene to be rendered; generate a spatial organization data structure, wherein some nodes of the data structure indicate graphic primitives and some nodes indicate coordinates of boundary regions in the graphic scene, wherein: the spatial organization data structure includes a node having a boundary region, and a plurality of primitives for the boundary region are indicated as children; and the spatial organization data structure includes a primitive, and a plurality of boundary regions for the primitive are indicated as parents; and traverse the spatial organization data structure to determine whether a ray in the graphic scene intersects a primitive; and color the intersecting primitives based on the determination. C2. The apparatus according to any of the preceding items in Group C, wherein the one or more graphics processors are configured to quantify information indicating a first boundary region in the spatial organization data structure to represent the first boundary region using fewer bits than an original representation number. C3. The apparatus according to any of the preceding items in Group C, wherein the one or more graphics processors are configured to perform quantization such that the quantized representation indicates a region greater than or equal to the first boundary region, thereby preventing false negative intersection results for the first boundary region. C4. The apparatus according to any of the preceding items in Group C, wherein the spatial organization data structure includes one or more fields for a first node indicating one or more primitives, the one or more fields indicating: an offset at which the one or more primitives are located; and the number of primitives for the first node located at the offset. C5. The apparatus according to any of the preceding items in Group C, wherein the spatial organization data structure includes a node having at least four child nodes. C6. The apparatus according to any of the preceding items in Group C, wherein the spatial organization data structure encodes a memory location for a node, and all child nodes of the node are continuously located at the memory location. C7. The apparatus according to any of the preceding items in Group C, wherein a driver for the one or more graphics processors is configured to insert debug data into a memory space between one or more of the nodes and their children. C8. The apparatus according to any of the preceding items in Group C, wherein the spatial organization data structure specifies primitive information in leaf nodes and boundary region information in internal nodes. C9. The apparatus according to any of the preceding items in Group C, wherein a first leaf node and a second leaf node in the spatial organization data structure have different data sizes, and respective parent nodes of the first leaf node and the second leaf node encode the different data sizes. C10. The apparatus according to any of the preceding items in Group C, further comprising: network interface circuitry; and one or more central processing units. C11. A method comprising: any combination of operations performed by a circuit system according to any of the preceding items in Group C.C12. A non-transitory computer-readable storage medium having design information stored thereon, the design information specifying a design of at least a portion of a hardware integrated circuit in a format recognizable by a semiconductor manufacturing system configured to use the design information to produce the circuit according to the design, wherein the design information specifies that the circuit includes: any combination of the components described in clauses C1 to C10. ***. D Group D1. An apparatus, comprising: a shader circuit system configured to execute a ray intersection instruction for a first SIMD group, wherein the instruction indicates coordinate information of a set of rays in a graphics scene; a ray intersection circuit system configured to: traverse a plurality of nodes in a spatially organized acceleration data structure in response to the ray intersection instruction, wherein the nodes of the data structure indicate coordinates corresponding to boundary regions in the graphics scene, and the traversal determines whether the ray intersects the boundary regions; and form a second SIMD group in response to reaching a first node indicating a transformation to be executed on the shader circuit system to transform the coordinates of one or more rays in the set of rays. D2. The apparatus according to any of the preceding items in Group D, wherein the acceleration data structure is a hierarchical structure, and the first node is a leaf node of an upper-level acceleration data structure, and the leaf node has a child node in a lower-level acceleration data structure. D3. The apparatus according to any of the preceding items in Group D, wherein the transformation positions one or more rays in a model space for an instance of a graphics model that is instantiated multiple times in the graphics scene. D4. The apparatus according to any of the preceding items in Group D, wherein a child node of the first node also has another parent node in the upper-level acceleration data structure, and when traversing to the child node, the other parent node indicates a different transformation, and the different transformation is associated with a model space of a different instance of the graphics model. D5. The apparatus according to any of the preceding items in Group D, wherein the apparatus is configured to: store the original coordinates of the one or more rays; and restore to the original coordinates in response to traversing back through the first node throughout the acceleration data structure. D6. The apparatus according to any of the preceding items in Group D, wherein the first SIMD group and the second SIMD group access ray data for the one or more rays in a shader memory space. D7. The apparatus according to any of the preceding items in Group D, wherein the first SIMD group includes an instruction for allocating memory space for the set of rays in the shader memory space before executing the ray intersection instruction. D8. The apparatus according to any of the preceding items in Group D, wherein the second SIMD group includes one or more rays from another SIMD group that executed a ray intersection instruction. D9. The apparatus according to any of the preceding items in Group D, wherein the acceleration data structure is a bounding volume hierarchy. D10. The apparatus according to any of the preceding items in Group D, wherein the apparatus is a computing device, comprising: a graphics unit including the ray intersection circuit system and the shader circuit system; one or more central processing units; and network interface circuit system. D11. A method, comprising: any combination of operations performed by a circuit system according to any of the preceding items in Group D.D12. A non-transitory computer-readable storage medium having design information stored thereon, the design information specifying a design of at least a portion of a hardware integrated circuit in a format recognizable by a semiconductor manufacturing system configured to use the design information to produce the circuit according to the design, wherein the design information specifies that the circuit includes: any combination of the elements described in items D1 to D10. ***. E Group E1. An apparatus, comprising: a shader circuitry configured to execute a ray intersection instruction for a first SIMD group, wherein the instruction indicates coordinate information of a first set of rays in a graphics scene; and a ray intersection circuitry configured to traverse a plurality of nodes in a spatially organized acceleration data structure in response to the ray intersection instruction, wherein the nodes include a plurality of nodes indicating boundary region coordinates in the graphics scene and a plurality of nodes indicating primitives; wherein the apparatus is configured to form a second SIMD group in response to reaching a node of the acceleration data structure indicating one or more primitives, the second SIMD group operating on a second set of rays that only partially overlaps with the first set of rays, wherein the second SIMD group includes one or more instructions to determine whether rays in the second set of rays intersect the one or more primitives; and wherein the shader circuitry is configured to color one or more primitives indicated as intersecting based on the result of executing the second SIMD group. E2. The apparatus according to any one of the preceding items in Group E, wherein the shader circuitry is configured to indicate whether the ray intersection circuitry continues to traverse one of the one or more rays based on the intersection result of executing the second SIMD group. E3. The apparatus according to any one of the preceding items in Group E, wherein the first SIMD group and the second SIMD group operate on a first data structure that stores information for a first ray of the one or more rays, wherein the first data structure is stored in a shader memory space that can also be accessed by the ray intersection circuitry. E4. The apparatus according to any one of the preceding items in Group E, wherein the second SIMD group is configured to access thread execution data from a buffer in the shader memory space identified by the ray intersection circuitry for the second SIMD group. E5. The apparatus according to any one of the preceding items in Group E, wherein the second SIMD group includes different threads configured to test a first ray against a plurality of different primitives. E6. The apparatus according to any one of the preceding items in Group E, wherein the second SIMD group includes a SIMD reduction instruction that performs an operation based on input values from threads operating on the first ray. E7. The apparatus according to any one of the preceding items in Group E, further comprising a boundary region test circuitry configured to test in parallel during the traversal whether a ray intersects a plurality of different ones of the boundary regions indicated by a node of the acceleration data structure. E8. The apparatus according to any one of the preceding items in Group E, wherein the shader circuitry is configured to: pause execution of the first SIMD group; and after receiving the intersection result from the second SIMD group, continue execution of the first SIMD group to color the one or more primitives.E9. An apparatus as in any of the preceding items in Group E, wherein the apparatus is a computing device, comprising: a graphics unit including the shader circuitry and the ray intersection circuitry; a central processing unit; and network interface circuitry. E10. A method, comprising: any combination of operations performed by a circuitry as in a preceding item in Group E. E11. A non-transitory computer-readable storage medium having design information stored thereon, the design information specifying a design of at least a portion of a hardware integrated circuit in a format recognized by a semiconductor manufacturing system configured to use the design information to produce the circuit according to the design, wherein the design information specifies that the circuit includes: any combination of the elements described in Items E1 to E9. ***. F Group F1. An apparatus, comprising: a first graphics shader core and a second graphics shader core, configured to execute instructions for a plurality of thread groups, wherein the first graphics shader core is configured to execute: a first thread group having a plurality of single instruction multiple data (SIMD) groups, configured to execute a first shader program; and a second thread group having a plurality of SIMD groups, configured to execute a different second shader program; a memory circuitry; and a control circuitry, wherein the control circuitry is configured to provide access to data stored in the memory circuitry according to a shader memory space, the shader memory space being accessible by the thread groups including the first thread group and the second thread group executed by the first graphics shader core, but not accessible by the thread groups executed by the second graphics shader core. F2. The apparatus according to any one of the preceding items in Group F, wherein a first cache in the first graphics shader core is for a coherence point of the shader memory space, and a second higher-level cache in the apparatus is for a coherence point of the device memory space. F3. The apparatus according to any one of the preceding items in Group F, wherein the control circuitry is further configured to provide access to data stored in the memory circuitry according to the following memory spaces: a thread group memory space for the first thread group, the first thread group being able to access the thread memory space, but any other thread group not being able to access the thread memory space; a thread memory space accessible by a single thread; and a device memory space accessible by the thread groups executed by both the first graphics shader core and the second graphics shader core. F4. The apparatus according to any one of the preceding items in Group F, wherein one or more coprocessors for the first graphics shader core can also access the shader memory space. F5. The apparatus according to any one of the preceding items in Group F, wherein the one or more coprocessors include ray intersection circuitry. F6. The apparatus according to any one of the preceding items in Group F, wherein the ray intersection circuitry is configured to: traverse a spatial data structure based on an instruction of the first thread group to determine one or more primitives to be compared for intersecting a ray for an intersection test; and initiate the second thread group to test the one or more primitives against the ray; wherein both the first thread group and the second thread group operate on ray information stored in the shader memory space. F7. The apparatus according to any one of the preceding items in Group F, wherein the first graphics shader core is configured to execute load, store, and non-cuttable execution instructions targeted at the shader memory space.F8. The apparatus of any of the preceding clauses in Group F, wherein the first graphics shader core is configured to execute a first SIMD group in the first thread group to use the shader memory space to store intermediate graphics work in thread granularity for further processing by threads of a dynamically formed SIMD group. F9. The apparatus of any of the preceding clauses in Group F, wherein the dynamically formed SIMD group may include a set of threads that are determined to have the same conditional result for a conditional control transfer instruction. F10. A method, comprising: any combination of operations performed by a circuit system of any of the preceding clauses in Group F. F11. A non-transitory computer-readable storage medium having design information stored thereon, the design information specifying a design of at least a portion of a hardware integrated circuit in a format recognized by a semiconductor manufacturing system configured to produce the circuit according to the design, wherein the design information specifies that the circuit includes: any combination of the elements described in Clauses F1 to F9. ***。 This disclosure includes references to "an embodiment" or groups of "embodiments" (e.g., "some embodiments" or "various embodiments"). Embodiments are different implementations or instances of the disclosed concepts. References to "an embodiment", "one embodiment", "a particular embodiment", and the like do not necessarily refer to the same embodiment. A large number of feasible embodiments are contemplated, including those specifically disclosed, as well as modifications or alternatives that fall within the spirit or scope of this disclosure. This disclosure may discuss potential advantages that may result from the disclosed embodiments. Not all implementations of these embodiments will necessarily exhibit any or all of the potential advantages. Whether the advantages realized for a particular implementation depend on many factors, some of which are outside the scope of this disclosure. In fact, there may be many reasons why implementations 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 combination with one of the disclosed embodiments) that invalidates or weakens one or more of the disclosed advantages. Additionally, suboptimal design implementation of a particular implementation (e.g., implementation technology or tool) may also invalidate or weaken the disclosed advantages. Even assuming a skilled implementation, the realization of advantages may still depend on other factors, such as the environmental circumstances in which the implementation is deployed. For example, the input applied to a particular implementation may prevent one or more of the problems solved in this disclosure from occurring in a particular instance, and as a result, the benefits of its solution may not be realized. Given the existence of possible factors outside this disclosure, it is expressly intended that any potential advantages described herein are not to be construed as requirements for claim limitations to prove infringement. Rather, the identification of such potential advantages is intended to illustrate the types of (multiple) improvements available to designers who benefit from this disclosure. The such advantages described permissively (e.g., stating that a particular advantage "may result in") are not intended to convey doubt as to whether such advantages can actually be achieved, but rather to recognize that the technical reality of achieving such advantages often depends on additional factors. Unless otherwise stated, the embodiments are non-limiting. That is, the disclosed embodiments are not intended to limit the scope of the claims based on the draft of this disclosure, even if only a single instance regarding a particular feature is described. The disclosed embodiments are intended to be illustrative rather than restrictive, and there is no statement to the contrary in this disclosure. Accordingly, this application is intended to allow the claims to cover the disclosed embodiments and such alternatives, modifications, and equivalents that would be obvious to one of ordinary skill in the art who benefits from this disclosure. For example, the features in this application can be combined in any suitable manner. Accordingly, new claims can be formulated for any such combination of features during the examination of this application (or the application claiming its priority). Specifically, referring to the appended claims, features from independent claims can be combined with features from other independent claims, if appropriate, including claims that depend on other dependent claims. Similarly, if appropriate, features from individual dependent claims can be combined. Accordingly, although the appended dependent claims may be drafted such that each depends on a single other claim, additional dependencies are also contemplated. Any combination of the features of the dependent claims consistent with this disclosure is contemplated and can be claimed in this application or another application. In short, the combinations are not limited to those specifically recited in the appended claims. If appropriate, it is also contemplated 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). *** Since this disclosure is a legal document, various terms and phrases may be subject to administrative and judicial interpretation. The following paragraphs and the definitions provided throughout the disclosure are hereby incorporated to determine how to interpret the claims drafted based on this disclosure. Unless the context clearly dictates otherwise, the singular form of an item (i.e., a noun or noun phrase preceded by "a / an" or "the") is intended to mean "one or more." Thus, the mention of "an item" in a claim does not exclude additional instances of that item in the absence of an accompanying context. A "plurality" of items refers to a collection of two or more items. As used herein, the term "may" is used in a permissive sense (i.e., having the possibility of, being able to), and not in a mandatory sense (i.e., must). The terms "comprising" and "including" and their forms are open-ended and mean "including, but not limited to." When the term "or" is used in this disclosure with respect to a list of options, it will generally be understood to be used in an inclusive sense unless the context provides otherwise. Thus, the statement "x or y" is equivalent to "x or y, or both," and thus: 1) covers x, but not y; 2) covers y, but not x; and 3) covers both x and y. On the other hand, a phrase such as "either x or y, but not both" clearly indicates that "or" is used in an exclusive sense. The phrases “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 any number of elements from one to the total number of elements in the set. For example, given the set [w, x, y, z], these phrases cover any single element of 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. Thus, the phrase “at least one of … w, x, y, and z” refers to at least one element of the set [w, x, y, z], thereby covering all possible combinations in this list of elements. This phrase is not to be construed as requiring 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. In this disclosure, various “designations” may be placed before a noun or noun phrase. Unless the context otherwise provides, different designations for a feature (e.g., “first circuit,” “second circuit,” “specific circuit,” “given circuit,” etc.) refer to different instances of the feature. Additionally, unless otherwise specified, the designations “first,” “second,” and “third” when applied to a feature do not imply any type of order (e.g., spatial, temporal, logical, etc.). The phrase "based on" is used to describe one or more factors that affect a determination. This phrase does not exclude the possibility that there may be additional factors that affect the determination. That is, a determination can be based solely on specific factors, or based on those specific factors as well as other unspecified factors. Consider the phrase "determine A based on B". This phrase indicates that B is a factor used to determine A, or that B affects the determination of A. This phrase does not exclude the possibility that A can also be determined based on some other factor such as C. This phrase is also intended to encompass an embodiment in which A is determined solely based on B. As used herein, the phrase "based on" is synonymous with the phrase "based at least in part on". The phrase "in response to / response to" describes one or more factors that trigger an effect. This phrase does not exclude the possibility that additional factors may affect or otherwise trigger the effect, either in combination with the specific factors or independently of the specific factors. That is, an effect can be solely in response to those factors, or can be in response to the identified factors as well as other unspecified factors. Consider the phrase "perform A in response to B". This phrase specifies that B is the factor that triggers the performance of A or the specific result of A. This phrase does not exclude the possibility that A can also be performed in response to some other factor such as C. This phrase also does not exclude the possibility that A can be performed in response to B and C in combination. This phrase is also intended to encompass an embodiment in which A is performed solely in response to B. As used herein, the phrase "responsive to" is synonymous with the phrase "responsive at least in part to". Similarly, the phrase "in response to" is synonymous with the phrase "at least in part in response to". *** In this disclosure, different entities (which may be variously referred to as "units", "circuits", other components, etc.) may be described or claimed as "configured" to perform one or more tasks or operations. This notation (an "entity" is configured to "perform one or more tasks") is used herein to refer to a structure (i.e., the physical thing of the entity). Specifically, this notation is used to indicate that the structure is arranged to perform the one or more tasks during operation. Even if a structure is not currently being operated, the structure may still be said to be "configured to" perform a certain task. Thus, an entity that is described or recited as "configured to" perform a certain task refers to a physical thing, such as a device, a circuit, a system having a processing unit, a memory storing program instructions executable to implement the task, etc. This phrase is not used herein to refer to something intangible. 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 recited. The phrase "configured to" is not intended to mean "configurable to". For example, an unprogrammed FPGA will not be considered "configured to" perform a particular function. However, this unprogrammed FPGA may be "configurable to" perform the function. After appropriate programming, then, the FPGA may be claimed as "configured to" perform the specific function. For the purposes of a U.S. patent application based on this disclosure, describing a structure as "configured to" perform one or more tasks in a claim is specifically intended not to invoke 35 U.S.C. § 112(f) to construe the claim element. If the applicant intends to invoke section 112(f) during the examination of a U.S. patent application based on this disclosure, the claim element will be stated using the phrase "means for 'performing a function'". In the present disclosure, different "circuits" may be described. These circuits or "circuitries" constitute hardware including various types of circuit elements, such as combinational logic, time-controlled storage devices (e.g., flip-flops, registers, latches, etc.), finite state machines, memories (e.g., random access memories, embedded dynamic random access memories), programmable logic arrays, and the like. The circuitry may be custom designed or taken from a standard library. In various embodiments, the circuitry may include digital components, analog components, or a combination of both as needed. Certain types of circuits are often referred to as "units" (e.g., decode units, arithmetic logic units (ALUs), functional units, memory management units (MMUs), etc.). Such units also refer to circuits or circuitries. Accordingly, the circuits / units / components disclosed and other elements depicted in the drawings and disclosed herein include hardware elements such as those described in the foregoing paragraphs. In many instances, the internal configuration of the hardware elements within a particular circuit may be specified by describing the function of that circuit. For example, a particular "decode unit" may be described as performing the function of "processing an opcode of an instruction and routing that instruction to one or more of a plurality of functional units", which means that the decode unit is "configured to" perform this function. The description of this function is sufficient for those of ordinary skill in the art of computer technology to imply a set of viable structures for the circuit. In various embodiments, as discussed in the foregoing paragraphs, circuits, units, and other elements defined by the functions or operations implemented thereby, the configuration and such circuits / units / components define a micro-hierarchy of hardware relative to each other and in the manner in which they interact, the hardware ultimately fabricated in an integrated circuit or programmed into an FPGA to form a physical implementation of the micro-hierarchy definition. Thus, the micro-hierarchy definition is recognized by those of ordinary skill in the art as a structure from which many physical implementations can be derived, all of which fall within the broad structure described by the micro-hierarchy definition. That is, a person of ordinary skill in the art provided with the micro-hierarchy definition according to the present disclosure can implement the structure by encoding a description of the circuit / unit / component in a hardware description language (HDL) (such as Verilog or VHDL) without undue experimentation and in the application of ordinary skill. The HDL description is often expressed in a functionally presentable manner. However, for those of ordinary skill in the art, this HDL description is a way of transforming the structure of a circuit, unit, or component into the details of the next level of implementation. Such an HDL description can take the form of behavioral code (which is generally not synthesizable), register transfer language (RTL) code (which is generally synthesizable, as opposed to behavioral code), or structural code (e.g., a wiring对照表 specifying logic gates and their connectivity). Subsequently, the HDL description can be synthesized according to a library of components designed for a given integrated circuit manufacturing technology and modified for timing, power, and other reasons to produce a final design database, which is transmitted to a fabrication plant to fabricate masks and finally produce an integrated circuit. Some hardware circuits or portions thereof can also be custom-designed in a schematic editor and transferred to integrated circuit design along with the synthesized circuit system. An integrated circuit can include transistors and other circuit elements (e.g., passive elements such as capacitors, resistors, inductors, etc.) and interconnects between the transistors and circuit elements. Some embodiments can implement multiple integrated circuits, the multiple integrated circuits being coupled together to implement the hardware circuit, and / or in some embodiments discrete components can be used. 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. The decoupling between the design of this circuit group and the subsequent lower-level implementation of these circuits typically results in a situation where the circuit or logic designer never specifies a particular set of structures beyond the description of what the circuit is configured to do when this process is performed at a different stage of the circuit implementation process. In fact, many different underlying combinations of circuit components can be used to implement a circuit of the same specification, resulting in a large number of equivalent structures for that circuit. As mentioned, these underlying circuit implementations can vary according to changes in manufacturing technology, the foundry selected to manufacture the integrated circuit, the component library provided for a particular project, etc. In many cases, the selection by different design tools or methodologies to produce these different implementations can be arbitrary. In addition, for a single implementation of a particular functional specification of a circuit, it is common, for a given embodiment, to include a large number of devices (e.g., millions of transistors). Accordingly, the vast amount of this information makes it impractical to provide a complete statement of the underlying structure for implementing a single embodiment, let alone a vast array of equivalent viable implementations. For this reason, the present disclosure describes circuit structures using functional shorthand commonly employed in the industry. 0 - 9: Node 100: Processing flow 110: Transformation and lighting procedure 115: Editing procedure 120: Rasterization procedure 130: Shading procedure 135: Frame buffer 150: Graphics unit 160: Programmable shader 165: Texture processing unit (TPU) 170: Image write unit (IWU) 175: Fragment pipe 180: Memory interface 185: Vertex pipe 190: Ray intersection accelerator (RIA) 210: Geometric data of the graphics scene 215: Accelerated data structure (ADS) construction component 220: Accelerated data structure (ADS) 225: Camera shading component 230: ADS traversal component / ADS traversal 235: Boundary region test component 240: Primitive test component / Boundary region test 245: Result shading component 250: Component 310: Boundary region test circuit system 350: Step 360: Step 370: Step 380: Step 390: Step 610: Instruction fetch and scheduling circuit system / Circuit system 615: L0 storage circuit system 620: Routing network 630: L1 memory 640: Higher-level cache / Memory circuit system 660: Shader pipeline 710: Parallel tester / Parallel tester circuit system 715: Boundary region data cache 720: Ray data cache 725: Common computing circuit system 730: Boundary region tester 730A - 703N: Boundary region tester 735: Result sorting circuit system 810: Token buffer 820: Ray core data 830: Ray stack data 840: Ray extension data / Extension data 1210: Node tester 1220: Group A 1230: Group T / S 1240: Shader core space 1250: Device memory 1310: Step 1315: Step 1320: Step 1325: Step 1330: Step 1335: Step 1340: Step 1345: Step 1350: Step 1355: Step 1405: Step 1410: Step 1420: Step 1430: Step 1440: Step 1520: ADS node 1610: Step 1620: Step 1630: Step 1810: Step 1820: Step 1830: Step 1910: Group control circuit system 2010: Step 2020: Step 2030: Step 2040: Step 2110: Step 2112: Step 2114: Step 2116: Step 2118: Step 2120: Step 2122: Step 2124: Step 2126: Step 2128: Step 2130: Step 2132: Step 2134: Step 2140: Step 2142: Step 2144: Step 2146: Step 2210: Shader core / Core2210A - 2210N: Shader Core 2220: Cache / Memory Hierarchy / Hierarchy 2230: Other Circuit Systems 2240: Coprocessor 2240A - 2240N: Coprocessor 2310A - 2310M: Memory Space 2320: Shader Core Space 2330: Device Memory Space 2410: L1 Cache 2420: Register File 2430: L2 Cache 2440: Control Circuit Systems 2450: Shader Pipeline 2510: Step 2520: Step 2600: Device 2610: Mesh Structure 2620: Arithmetic Complex 2625: Bus Interface Unit (BIU) 2630: Cache 2635: Core 2640: Core 2645: Cache / Memory Controller 2650: Input / Output (I / O) Bridge 2665: Display Unit 2700: System or Device 2710: Desktop Computer 2720: Laptop Computer 2730: Tablet Computer 2740: Cellular or Mobile Phone 2750: Television 2760: Wearable Device 2770: Cloud - Based Service 2780: Device 2790: Vehicle 2810: Non - Transitory Computer - Readable Medium 2815: Design Information 2820: Semiconductor Manufacturing System 2830: Integrated Circuit A - D: Nodes L0 - L8: Leaves P0 - P3: Primitives R: Root Node [Fig. 1A] is a diagram illustrating an overview of an example graphics processing operation according to some embodiments. [Fig. 1B] is a block diagram illustrating an example graphics unit according to some embodiments. [Fig. 2] is a diagram illustrating an example ray tracing procedure using ADS according to some embodiments. [Fig. 3A] is a block diagram illustrating an example graphics processor including a shader processor circuit system and an intersection circuit system according to some embodiments. [Fig. 3B] is a flowchart illustrating an example method for detecting ray intersection using a ray intersection circuit system according to some embodiments. [Fig. 4] is a block diagram illustrating an example ADS tree structure according to some embodiments. [Fig. 5] is a diagram illustrating an example depth-first traversal of a BVH tree using a ray stack according to some embodiments. [Fig. 6] is a block diagram illustrating an example connectivity between a ray intersection circuit system and other graphics circuit systems according to some embodiments. [Fig. 7] is a block diagram illustrating a detailed example parallel boundary region test circuit system according to some embodiments. [Fig. 8] is a diagram illustrating an example organization of a ray shader core space (SCS) for storing ray data according to some embodiments. [Fig. 9] is a diagram illustrating an example node data structure according to some embodiments. [Fig. 10] is a diagram illustrating an example leaf data structure with a configurable size according to some embodiments. [Fig. 11] is a diagram illustrating an example memory layout of an ADS tree structure with variable-size leaf nodes according to some embodiments. [Fig. 12] is a diagram illustrating an example data flow between an intersection circuit system, a node test circuit system, a memory region, and SIMD groups executed by a shader circuit system according to some embodiments. [Fig. 13] is a flowchart illustrating an example method associated with the data flow of Fig. 12 according to some embodiments. [Fig. 14A] is a block diagram illustrating an example technique for dynamically forming SIMD groups for primitive testing according to some embodiments. [Fig. 14B] is a flowchart illustrating an example method for dynamically forming SIMD groups for primitive testing according to some embodiments. [Fig. 15] is a diagram illustrating an example many-to-many mapping between a boundary region and primitives according to some embodiments. [Fig. 16] is a flowchart illustrating an example method for generating a spatial organization data structure with a many-to-many mapping according to some embodiments. [Fig. 17] is a diagram illustrating an example dynamic formation of SIMD groups for ray transformation when traversing an acceleration data structure according to some embodiments. [Fig. 18] is a flowchart illustrating an example method for dynamically forming SIMD groups for ray coordinate transformation according to some embodiments. [Fig. 19A] is a diagram illustrating an example situation of different rays with current targets at different nodes in an ADS during their traversal according to some embodiments.[FIG. 19B] is a block diagram illustrating an example grouped control circuit system according to some embodiments. [FIG. 19C] is a diagram illustrating an example unidirectional link list implementation for grouped rays according to some embodiments. [FIG. 20] is a flowchart illustrating an example method for grouping rays during traversing an ADS according to some embodiments. [FIG. 21] is a flowchart illustrating an example method for processing rays according to some embodiments. [FIG. 22A] is a block diagram illustrating an example flash memory hierarchy accessible by a shader core according to some embodiments. [FIG. 22B] is a block diagram showing an example flash memory hierarchy accessible by multiple shader cores and their coprocessors according to some embodiments. [FIG. 23] is a diagram illustrating an example threadgroup, shader core, and device memory space according to some embodiments. [FIG. 24] is a block diagram illustrating an example cache organization and coherence points for different memory spaces according to some embodiments. [FIG. 25] is a flowchart illustrating an example method for using a shader memory space according to some embodiments. [FIG. 26] is a block diagram illustrating an example arithmetic device according to some embodiments. [FIG. 27] is a diagram illustrating an example application of a system or device according to some embodiments. [FIG. 28] is a block diagram illustrating an example computer-readable medium storing circuit design information according to some embodiments. 0-7: Nodes 1520: ADS Node P0-P3: Primitives

Claims

1. An apparatus for detecting intersections between rays and graphic primitives, comprising: a ray intersection circuit system configured to: receive a ray intersection request indicating origin and direction information for a ray in a graphic scene; traverse a plurality of nodes in a spatial organization accelerated data structure, wherein a given node of the plurality of nodes indicates coordinates corresponding to a boundary region of the graphic scene; in response to detecting an intersection of the ray with a first boundary region, store a local parameter value of the ray, the local parameter value indicating a point where the ray intersects with the first boundary region; and retrieve the stored local parameter value, and use the retrieved local parameter value as an origin value of the ray for one or more intersection tests between the ray and one or more sub-boundary regions of the first boundary region.

2. The device as requested in item 1, wherein: The space organization accelerates the data structure to store quantized boundary region data of the first boundary region, which encodes the coordinates of the first boundary region; and the ray intersection circuit system is configured to store the local parameter values ​​with a higher precision per coordinate value than the quantized boundary region information.

3. The device of claim 1, wherein, in order to store the local parameter value, the ray intersection circuit system is configured to push the local parameter value onto a traverse stack for a depth-first traverse.

4. The apparatus of claim 1, wherein the ray intersection circuit system includes a boundary region test circuit system configured to test the intersection of the ray with multiple boundary regions in parallel, and to store different local parameter values ​​of the ray for different intersecting boundary regions.

5. The device as requested in item 1, wherein the device is configured to: during the traverse, in response to an execution individual node arriving at the space organization accelerated data structure, change the coordinates of the ray.

6. The apparatus of claim 1, wherein the ray intersection circuitry is configured to provide one or more intersection results to a shader processor based on the traversal of the spatial organization accelerating data structure.

7. The apparatus of claim 1, wherein the intersecting circuit system is further configured to group the set of rays into a group based on a set of rays with the same first node as the target of the space organization acceleration data structure, and to test in parallel the intersection of the group with a boundary region corresponding to the first node.

8. The device as requested in item 1, wherein: The spatial organization data acceleration structure includes a node with a boundary region, and multiple primitives for the boundary region are indicated as children; and the spatial organization data acceleration structure includes a primitive, and multiple nodes for the primitive corresponding to different boundary regions are indicated as parents.

9. The device as requested in item 1, wherein the spatial organization acceleration data structure is a bounding volume hierarchy (BVH).

10. The apparatus of claim 1, wherein the ray intersection circuit system includes a boundary region test circuit system configured to simultaneously test, during the traverse, whether multiple rays in a set of rays intersect with multiple different boundary regions indicated by a node of the spatial organization acceleration data structure.

11. The device as claimed in claim 10, wherein the boundary area test circuit system includes: A common-node computing circuit system configured to perform one or more operations, the output of which is shared by such parallel tests.

12. The apparatus of claim 1, wherein the ray-intersection circuitry is further configured to access a shader memory space shared with a shader core, the shader core being configured to execute a shader program including commands for the ray-intersection circuitry.

13. The device as claimed in claim 1, wherein the device is a computing device, comprising: A graphics processor that includes the ray-intersecting circuit system; One central processing unit; And network interface circuit system.

14. A method for detecting intersections between a ray and a graphical primitive, comprising: receiving a ray intersection request via a ray intersection circuit system, the ray intersection request indicating origin and direction information for a ray in a graphical scene; traversing a plurality of nodes of a spatial organization acceleration data structure via the ray intersection circuit system, wherein a given node of the plurality of nodes indicates coordinates corresponding to a boundary region of the graphical scene; in response to detecting an intersection of the ray with a first boundary region, storing a local parameter value of the ray, the local parameter value indicating a point where the ray intersects the first boundary region; and retrieving the stored local parameter value via the ray intersection circuit system, and using the retrieved local parameter value as an origin value of the ray for one or more intersection tests between the ray and one or more sub-boundary regions of the first boundary region.

15. As in request item 14, wherein: The spatial organization accelerates the data structure to store quantized boundary region data of the first boundary region, which encodes the coordinates of the first boundary region; and the storage of the local parameter values ​​uses a higher precision per coordinate value than the quantized boundary region data.

16. The method of request 14, wherein the storage includes pushing the local parameter value onto a cross stack.

17. The method of claim 14 further comprises: testing the intersection of the ray with multiple boundary regions in parallel using the ray intersection circuit system, and storing different local parameter values ​​of the ray for different intersecting boundary regions.

18. The method of claim 14, further comprising: during the traverse, in response to reaching an execution individual node of the space organization's accelerated data structure, transforming the coordinates of the ray.

19. The method of claim 14, further comprising: providing one or more intersection results to a shader processor based on the traversal of the spatial organization accelerating data structure.

20. A non-transitory computer-readable storage medium for detecting the intersection between a ray and a graphic primitive, having design information stored thereon, the design information specifying a design of at least a portion of a hard volume circuit in a format identified by a semiconductor manufacturing system configured to produce the circuit using the design information according to the design, wherein the design information specifies that the circuit includes: A ray intersection circuit system configured to: receive a ray intersection request indicating the origin and direction information of a ray in a graphical scene; traverse multiple nodes of a spatial organization acceleration data structure, wherein a given node of the multiple nodes indicates coordinates corresponding to a boundary region of the graphical scene; in response to detecting that the ray intersects with a first boundary region, store a local parameter value of the ray indicating a point where the ray intersects with the first boundary region; and retrieve the stored local parameter value, and use the retrieved local parameter value as an origin value of the ray for one or more intersection tests between the ray and one or more sub-boundary regions of the first boundary region.

Images