JP5740704B2 - Parallelized cross-test and shading architecture for ray-trace rendering - Google Patents

Description

(Cross-reference of related applications)
The present application is based on the priority of US Patent Application No. 12,408,478 filed on March 20, 2009, and the name of the invention filed on March 21, 2008, “Coupling Ray Storage and Computer”. "For Memory-Efficient Ray Intersection Test Scaling", US Provisional Application No. 61 / 038,731, and the title of the invention filed on September 10, 2008 is "Architectures for Parallelized Interception Intersection Test" Claiming priority according to US Provisional Application No. 61 / 095,890, “Shading for Ray-Tracing Rendering” This reference is hereby incorporated by reference for all purposes.

  The present invention relates to rendering two-dimensional representations from three-dimensional scenes, and more particularly, ray tracing for accelerated rendering of photo-realistic two-dimensional representations of scenes. ) Regarding the use of.

  The rendering of photorealistic images by ray tracing is well known in computer graphics art. Raytracing is known to produce photorealistic images, including realistic shadows and lighting effects, because it can model the physical behavior of light interacting with scene elements. . However, ray tracing is also known to be computationally intensive and currently takes considerable time to render complex scenes using ray tracing, even in the context of art graphics workstations. .

  Raytracing usually starts with a camera and, through a number of potential interactions with the scene object, either terminates at the light source, or tracks the rays until they exit the scene without intersecting the light source, Obtaining a scene description composed of geometric primitives like triangles that describe the surface of the structure in the scene, and how light interacts with the primitives in the scene Modeling what to do.

  For example, a scene can include a car on a street with buildings on both sides. A car in such a scene can be defined by a large number of triangles (eg, 1 million triangles) that approximate a continuous surface. A camera position for observing the scene is defined. Rays emitted from the camera are often referred to as primary rays; for example, rays emitted from one object to another to allow reflection are often secondary. Called Ray. An image plane with a selected resolution (eg, 1024 × 768 for SVGA displays) is placed at a selected position between the camera and the scene.

  The simplest ray tracing algorithm involves firing one or more rays from the camera through each pixel of the image into the scene. Each ray is then tested against each primitive that makes up the scene to identify the primitive that the ray intersects, and then the effect that the primitive has on the ray, eg, reflecting and / or refracting the ray Whether it is determined. Such reflection and / or refraction causes the ray to propagate in different directions and / or split the ray into multiple secondary rays that can take different paths. All of these secondary rays are then tested against scene primitives to determine the intersecting primitives, and this process is performed by secondary (and tertiary, and so on) rays, for example, Continue recursively until terminated by leaving or reaching the light source. While all of these ray / primitive intersections are determined, a tree is created that maps the intersections. After the ray ends, the contribution of the light source is traced back through the tree to determine the effect of the light source on the scene pixels. As will be readily appreciated, the complex computation of testing (for example) 1024 x 768 rays for intersections with millions of triangles is computationally intensive, and the number of such rays is It does not include all of the additional rays that result from material interactions with intersecting rays. )

  Raytracing scene rendering is referred to as a “thorny parallel problem” because the color information stored for each pixel of the image being generated can be stored independently of the other pixels in the image. . Thus, there may be some filtering, interpolation or other pixel processing before outputting the final image, but the color information of the pixels of the image can be determined in parallel. It is therefore easy to segment the ray tracing task of an image for a given set of processing resources by dividing the pixels to be rendered among the processing resources and performing the rendering of these pixels in parallel. .

  In some cases, the processing resource may be a computing platform that supports multithreading, while in other cases it may involve a cluster of computers linked via a LAN, or a cluster of computer cores. For these types of systems, a given processing resource, such as a thread, can be instantiated to process a ray or group of rays allocated by the intersection test and the end of shading. In other words, using the property that pixels can be rendered independently of each other, rays known to contribute to different pixels can be divided between threads or processing resources to be cross-tested, Thereafter, the results of such shading calculations can be written to the screen buffer for processing or display, and these intersections can be shaded.

  Several algorithmic approaches that address this type of problem have been proposed. One such approach is described by Matt Pharr, et al. Is disclosed in “Rendering Complex Scenes with Memory-Coherent Ray Tracing”, Proceedings of SigGraph (1997) (referred to herein as “Document Pharr”). The document Pharr discloses dividing the scene to be ray-traced into geometric voxels, assuming that each geometric voxel is a cube containing scene primitives (eg, triangles). The document Pharr is a scheduling voxel where each element of the scheduling grid can overlap some part of the geometric voxel (ie, the scheduling voxel is sized differently from the geometric voxel cube) It is further disclosed to superimpose the scheduling grid (as is also a cube with a volume in the scene that is possible). Each scheduling voxel has a ray that is currently inside, that is, the associated ray queue that contains the rays contained within that scheduling voxel, and information about which geometric voxel overlaps that scheduling voxel. Have.

  The document Pharr discloses that when scheduling voxels are processed, the rays in the associated queue are tested for intersection with primitives in the geometric voxels contained by the scheduling voxel. If an intersection between a ray and a primitive is found, a shading calculation is performed, which can increase the number of rays added to the ray queue. If no intersection is found in that scheduling voxel, the ray proceeds to the next non-empty scheduling voxel and is accommodated in the ray queue of that scheduling voxel.

  The document Pharr explains that the advantage of this approach is that if the scene geometry in each scheduling voxel can fit in the cache, the cache will not cause much trashing during ray intersection testing with the scene geometry. It is disclosed that it is useful to fit the geometry in a cache provided in a typical general purpose processor.

  Further, the document Pharr discloses that when a primitive is fetched into a geometry cache, further work can be performed on the primitive by queuing a ray for testing into a scheduling voxel. In situations where multiple scheduling voxels can be processed next, the scheduling algorithm can select a scheduling voxel that will minimize the amount of geometry to be loaded into the geometry cache.

  The document Pharr suggests that the proposed regular scheduling grid may not work well if a particular scene has a non-uniform complexity, that is, if the density of primitives is high in some parts of the scene. Admits. The document Pharr assumes that an adaptive data structure such as an octree can be used instead of a regular scheduling grid. An octree is divided into 8 sub-volumes at each level of the hierarchy, and the 8 smaller volumes can be divided into 8 smaller sub-volumes, and so on. Spatial partitioning is introduced into the three-dimensional scene by causing partitioning along the principal axes (ie, x, y, and z axes). In each subvolume, a split / non-split flag is set that determines whether the subvolume will be further split. Such subvolumes are indicated for splitting until the number of primitives in the subvolume is sufficiently low for testing. Thus, for octrees, the amount of splitting can be controlled depending on the number of primitives present in a particular part of the scene. Thus, the octree allows for varying degrees of partitioning of the volume to be rendered.

  A similar approach is disclosed in US Pat. No. 6,556,200 to Pfister (“Literature Pfister”). The document Pfister also discloses partitioning the scene into a plurality of scheduling blocks. Ray queues are provided for each block, and the rays in each queue are spatiotemporally ordered using a dependency graph. Rays are tracked in each scheduling block according to the order defined in the dependency graph. The literature Pfister refers to the literature Pharr paper, and the literature Pfister devises two or more (for example, not only triangles) single-type graphical primitives and devise more complex scheduling algorithms for scheduling blocks It supplements that it requests. The document Pfister further considers intermediate subportions of scene geometry at multiple cache levels in the memory hierarchy.

  Yet another approach is referred to as packet tracing, and a general reference for such packet tracing is Ingo Wald, Phillips Slullek, Carsten Benthin, et al. "Interactive Rendering through Coherent Ray Tracing", Proceedings of EUROGRAPHICS 2001, pp 153-164, 20 (3), Manchester, United Kingdom (Sep. 2001). In this reference, packet tracing involves tracking packets of rays that have similar starting points and directions through the grid. Rays originate from a substantially common grid location and travel in a substantially similar direction so that most rays pass through the common grid location. Thus, packet tracing needs to identify rays that travel in similar directions from similar starting points. Another variation on such packet tracing determines which voxels a frustum ray intersects and helps reduce the number of computations for a given ray packet (i.e., all rays are tested for intersection). Use frustum rays to demarcate the edges of the packets of the rays so that only those rays at the outer edge of the packet are tested). Packet tracing still requires identifying rays that originate from similar locations and travel in similar directions. Such rays can become increasingly difficult to identify when the rays are reflected, refracted, and / or generated during ray tracing.

  Yet another approach exists in the field of accelerating ray tracing, and one approach attempts improved cache utilization through more active management of ray states. Navrati et al. "Dynamic Ray Scheduling for Improved System Performance", 2007 by IEEE Symposium on Interactive Ray Tracing, (Sep. It describes that it has a weakness of “ray explosion” that makes it inappropriate for main memory. To address this, the document Navratil proposes to avoid "ray state explosions" by placing restrictions designed to "actively manage" ray and geometry states during ray tracing. To do. One proposal is to trace the generation of rays separately, so the literature Navratil traces the primary ray first, then finishes the primary ray, then traces the secondary ray, and so on. Similarly, it is disclosed to continue.

  The above background shows the diversity of ideas and approaches that continue to prevail in the field of accelerating rendering based on ray tracing. Similarly, these references indicate that further progress remains in the field of ray tracing. However, the description of any of these references and techniques is not an endorsement or suggestion that any reference or subject matter in the reference is prior art to any subject matter disclosed herein. Absent. On the contrary, these references are written to help show the differences in the approach to rendering using ray tracing. Furthermore, the handling of any of these references is necessarily omitted for clarity and is not exhaustive.

  In one aspect, the method uses multiple computing resources to ray trace a 2D representation of a 3D scene. The method includes using a first subset of computing resources to cross test a geometric shape having one or more primitives and geometry acceleration elements in a ray traveling through a three-dimensional scene. . Each computing resource in the first subset operates to communicate with a respective localized memory resource that stores a respective subset of rays traveling through the scene. The method includes communicating an indication of an intersection between a ray and a primitive from a first subset of computing resources to a second subset of computing resources; and an identified intersection between the ray and the primitive; Using a second subset of computing resources to execute the associated shading routine, and the output from the shading routine has a new ray to be cross-tested. Membership in the subset is time-dependent during rendering of either a scene or a series of scenes, or is determined statistically during system configuration or during a reconstruction point.

  The method further comprises the steps of distributing data defining the new ray among the localized memory resources and communicating the grouping of ray identifiers along with the shape data to the computing resources of the first subset. Each ray identifier has data other than ray definition data related to the ray. The transmission of the ray identifier activates the specified ray intersection test with the shape specified by the shape data. The tests were shown for each computing resource with respect to intersecting based on the retrieved ray definition data and retrieving data defining the identified rays stored in each computing resource's localized memory Testing the shape and outputting the detected intersection indicator for communication.

  Another aspect includes a system that uses ray tracing to render a 2D representation of a 3D scene composed of primitives. The system has multiple cross-test resources that can access each cache memory, each cache memory storing a subset of the master definition of ray definition data, and each ray definition data is a test of that ray. Is kept in cache memory until

  The system further includes control logic that operates to control testing of each ray by a respective test resource that assigns an identifier to each ray and has access to the definition data of each ray in the cache memory of the respective test resource. Test control is achieved by providing a ray identifier to each test cell that stores the data of the ray to be tested. The system has an output queue that identifies the ray that has completed the intersection test and each intersected primitive. The control logic allocates a new ray resulting from the shading calculation and replaces the ray that has completed the cross test in the cache memory.

  In one aspect, the replacement is done by reusing the ray identifier for which the control logic has ended as a new ray identifier, that the ray identifier relates to a memory location that stores the respective data defining that ray, and One or more of replacing the data stored in the memory location of the finished ray with the data defining the new ray can be performed.

  Yet another aspect includes a system that uses ray tracing to render a 2D representation of a 3D scene composed of primitives. This system has a memory for storing primitives constituting a three-dimensional scene, and a plurality of intersection test resources. Each intersection test resource operates to test at least one ray traveling through the scene with at least one primitive and output an indication of the detected intersection. The system further includes a plurality of shader resources that operate to execute a shading routine associated with the primitive from the indication of the ray / primitive intersection where each shader resource was detected. The system further includes a first communication link that outputs the detected intersection indicator to the shader resource, and a second communication link that transmits a new ray resulting from the execution of the shading routine to the intersection test resource. Rays can be sent to the cross test resource and the cross tests are terminated in a different order than the relative order in which the new rays were sent. Both communication links can be achieved as queues such as FIFO queues.

  Yet another aspect is that the system is composed of primitives in a system having a distributed memory between the main memory and the computing resource, the main memory having a plurality of computing resources connected in a hierarchical memory structure having a higher latency than the distributed memory. Including ray tracing methods. This method distributes the data defining the rays to be cross-tested in a scene among the distributed memories, such that the subset of rays are stored in different ones of the distributed memories, And the group members are stored in a plurality of distributed memories, along with one or more geometric shapes. The method fetches data defining one or more geometric shapes from main memory, and identifies the geometric shape and group ray identifiers for each distributed data storing the ray data in the group. Providing to at least one computing resource associated with the memory. The method tests the intersection of this ray with a computing resource associated with at least one of the distributed memories storing data for each ray of the group and collects the intersection test results resulting from the computing resource. And further.

  Yet another aspect includes a system that cross-tests primitives and rays that make up a three-dimensional scene. The system has a plurality of intersection test resources that operate to test each ray for intersection with a geometric shape. Each one of the rays is specified by reference information provided for each intersection test resource, which in turn provides an indication of the intersection between the ray and the geometry at the first output or the second output. It operates to output to either of these.

  One output is for primitive intersections and the other output is for geometry acceleration element intersections. For example, a first output can provide input to a plurality of shading resources, can be for an indication of an intersection between a ray and a primitive, and a second output can be a ray collection manager. And receive an indication of the intersection between the ray and the geometry acceleration element.

  Yet another aspect is the step of storing in a main memory resource the primitives that make up the 3D representation and the geometry acceleration elements that delimit the selection of the primitives, and the layers to be cross-tested in the scene. And a ray tracing method having a step of defining a respective identifier of the ray. The method includes storing, in a system having a plurality of separately programmable processing resources, a portion of ray start and direction data in localized memory resources each associated with one of the processing resources. . The method further comprises performing ray scheduling for the cross test by providing to the processing resource an identifier of the ray scheduled for testing and an indication of the geometric shape. Each processing resource determines whether the localized memory resource stores ray definition data for any specified ray, and if so, with respect to intersection with the indicated geometry Test these rays.

  Yet another aspect is machine-readable for a system that controls multiple processing resources to achieve a cross-test of geometry and rays used to render a two-dimensional representation of a three-dimensional scene. Computer readable media / media with instructions. The instruction accesses a packet of ray identifiers determined to intersect a first geometry acceleration element that delimits a first selection of primitives; and by the first geometry acceleration element Determining other geometry acceleration elements that bound a portion of the bounded primitive portion. The method includes instantiating a plurality of packets, each packet containing a ray identifier, and a respective indication of a different geometry acceleration element among other geometry acceleration elements, and a plurality of packets. Providing to each one of a plurality of computing resources each configured for cross-testing less than all the rays identified in each packet. The method includes receiving an indication of intersection detected from a plurality of computing resources, and determining a geometry acceleration element until a number of next geometry acceleration elements greater than the threshold number of received indications are identified. In response, the method further comprises the step of tracking the received indicator and repeating the access using the next packet.

  Yet another aspect is to define several of the computing resources configured to cross-test the shape with the ray and several of the rays that are connected to each of the computing resources and travel through the scene. Each of the caches storing data to be transmitted and a channel for sending messages between the plurality of computing resources, each computing resource having a plurality of data in the message received by the computing resource. To determine whether this computing resource cache has any of a plurality of rays stored in this computing resource and to associate the stored ray Ray-tracing sys configured to test with Including the arm.

  Yet another aspect includes a system that cross-tests primitives and rays that make up a three-dimensional scene. The system has a plurality of intersection test resources that operate to test each ray for intersection with a geometric shape. Each ray is specified by reference information provided to each cross test resource. Each intersection test resource is further configured to output an indication of the intersection between the ray and the primitive to either the first output or the second output. The system maintains a plurality of shading resources that operate to execute the shading code for the detected intersection, and a reference to the ray, and the ray reference information to indicate the ray to be tested. It further has a ray collection manager that operates to provide resources. The first output provides input to the plurality of shading resources and receives an indication of the intersection between the ray and the primitive, and the second output provides input to the ray collection manager and the ray and geometry Receive an indication of the intersection with the acceleration element.

  Yet another aspect is a processor coupled to a local cache configured to store data defining a plurality of rays to be tested for intersection with a specified geometric shape, and provided by the processor. And the data received in the input queue can be interpreted by the processor as including a plurality of ray identifiers to be tested for intersection with a specified geometric shape, Retrieve definition data for only the identified ray in the input queue where the data stored in the processor's local cache is present, cross test such ray with the identified geometry, and detect the detected intersection A 2D table of 3D scenes based on parallel ray tracing, configured to output an index of The includes a computing arrangement used to render.

  Yet another aspect is bounded by accessing a packet of ray identifiers that have been determined to intersect a geometry acceleration element that delimits the selection of the primitive, and by the intersected geometry acceleration element. A computer readable medium comprising machine readable instructions for performing a ray tracing method having determining other geometry acceleration elements that delimit a portion of the primitive. The method includes instantiating a plurality of packets, each packet containing a ray identifier, and a respective indication of a different geometry acceleration element among other geometry acceleration elements, and a plurality of packets. Providing to each one of a plurality of computing resources each configured for cross-testing of all the rays identified in each packet. The method further includes receiving an indication of intersection detected from the plurality of computing resources and tracking the received indication as a function of the geometry acceleration factor.

  Yet another aspect includes a method of ray tracing that includes determining ray definition data defining a plurality of rays to be tested for intersection with primitives comprising a three-dimensional scene. The method includes the steps of distributing a subset of ray definition data among respective local memories of a plurality of computing resources configured to cross-test geometric shapes and rays, and within a management module, computing resources Determining a collection of rays from a plurality of rays to be cross tested by. A collection is defined by a plurality of ray identifiers, each containing data other than ray definition data, and is associated with a boundary shape that delimits a portion of the primitive. The method further includes causing the computing resource to test the ray of the determined collection by communicating a ray identifier for the determined collection between the computing resources, wherein the definition data is for the computing resource. Each computing resource responds to it by cross-testing the identified ray stored in its local memory.

  In any aspect, the plurality of rays stored in the local cache can be disjoint subsets of the second plurality of rays, and some of the plurality of ray identifiers are stored in the local cache. , And some of the second plurality of rays are not stored in the local cache.

The functional aspects described can be implemented as modules, such as modules of computer-executable code that configures the appropriate hardware resources to be operable to generate inputs and outputs as described. .
For a fuller understanding of the aspects and examples disclosed herein, reference is made to the accompanying drawings in the following description.

FIG. 1 illustrates a first embodiment of a system for rendering a scene using ray tracing. FIG. 2 illustrates some additional aspects of FIG. FIG. 3 illustrates another implementation of the intersection test portion of the ray tracing rendering system. FIG. 4 illustrates an example of cross-test computing resources used in the systems of FIGS. FIG. 5 illustrates a further example of a cross test system architecture used in ray tracing. FIG. 6 illustrates aspects of another embodiment of a cross test architecture. FIG. 7 illustrates a system architecture that implements aspects of the disclosure according to FIGS. 1-6 including cross-test resources and shading resources concatenated by queues. FIG. 8a illustrates an aspect of providing ray identifiers that can be used in controlling ray tracing in the systems according to FIGS. FIG. 8b illustrates an aspect of providing a ray identifier that can be used in controlling ray tracing in the system according to FIGS. FIG. 9a illustrates an example of using a ray ID to identify ray data in memory that can be provided to any of the cross test resources of FIGS. FIG. 9b illustrates an example of using a ray ID to identify ray data in memory that can be provided to any of the cross test resources of FIGS. FIG. 10 illustrates aspects of cross-test control and shape distribution among multiple cross-test resources that can be implemented in the systems of FIGS. FIG. 11 illustrates a multiprocessor architecture that can be implemented when the system aspects of FIGS. 1-10 use a ray tracing architecture. FIG. 12 illustrates the organization of multiple computing resources using inter-resource communications and localized ray data storage that can accomplish the implementation of the disclosure according to FIGS. FIG. 13 illustrates an example of multiple threads or cores operating as part of the computing resource of FIG. FIG. 14a illustrates various queuing implementations useful for the systems and architectures according to FIGS. FIG. 14b illustrates various queuing implementations useful for the system and architecture according to FIGS. FIG. 14c illustrates various queuing implementations useful for the system and architecture according to FIGS. FIG. 15 is used to illustrate various ways in which ray data can be distributed between an L2 cache shared by multiple computing resources and a private L1 cache. FIG. 16 illustrates an example of data in a packet that can exist in a queue through these disclosures. FIG. 17 shows disclosure relating to how a particular computing resource uses locally available ray data during a cross test and writes back the results of this test to process the ray ID from the packet. Do. FIG. 18A illustrates aspects of an exemplary SIMD architecture processing packet of ray ID information. FIG. 18B illustrates an exemplary SIMD architecture processing packet aspect of ray ID information. FIG. 19 illustrates the concept of distributing ray identifiers, testing rays, and fusing test results into additional packets for further testing. FIG. 20 illustrates the method steps that are generally applicable to the system according to the above diagram in the context of the data structure. FIG. 21 illustrates a further method aspect according to the present disclosure.

  The following description is presented to enable any person skilled in the art to make and use various aspects of the present invention. Descriptions of specific techniques, implementations, and applications are provided only as examples. Various modifications to the examples described herein will be apparent to those skilled in the art, and the general principles described herein may be used in other examples and without departing from the scope of the invention. Applicable for use. This description first introduces aspects related to the embodiment of a three-dimensional (3-D) scene (FIG. 1) that can be extracted using geometry acceleration data, as in the embodiment of FIG. To proceed. Such a three-dimensional scene can be rendered as a two-dimensional representation using the system and method according to the illustrated and described embodiment.

  As introduced in the background section, the 3D scene should be converted into a 2D representation for display. Such a conversion requires selecting the camera position at which the scene is observed. The camera position often indicates the position of a scene observer (eg, a person playing a game, a person watching a movie, etc.). The two-dimensional representation is usually in a planar position between the camera and the scene so that the two-dimensional representation includes an array of pixels at the desired resolution. The color vector for each pixel is determined through rendering. During ray tracing, the ray can first be released from the camera position so that it intersects the plane of the two-dimensional representation at the desired point, followed by a three-dimensional scene. The location where a ray intersects the two-dimensional representation is kept in the data structure associated with that ray.

  The camera position does not necessarily have to be a single point defined in space; instead, the camera position is released from the number of points that the ray is considered to be within the range of the camera position. , May diffuse. Each ray intersects the two-dimensional representation within a range of pixels, sometimes called samples. In some implementations, a more accurate location of where the ray intersects the pixel is recorded, allowing more accurate interpolation and blending of colors.

  For the sake of clarity, certain types of object data, eg primitives (eg the coordinates of the three vertices of a triangle) are simply described as the object itself, rather than referencing the object data. There is often. For example, when “fetching a primitive” is to be understood, the data representing the primitive is fetched, not the physical realization of the primitive. However, particularly with respect to rays, this disclosure distinguishes between ray identifiers and the data that defines the rays themselves, and when the term “ray” is used, unless the context reveals otherwise, the ray ID and It is considered to be a generic term for both the data defining a ray.

  A realistic and fine representation of the contour of an object in a 3D scene is usually done by providing a number of small geometric primitives that approximate the surface of the object (ie, a wire frame model). ). Thus, more complex objects need to be represented using more primitives and smaller primitives than simpler objects. Provides the advantage of higher resolution, but in particular, a complex scene can have a large number of objects, so it intersects between a ray and a large number of primitives (as described above and shown in more detail below) Running the test is computationally intensive. Without adding any external systematization to the scene for intersection testing, each ray should be tested for intersection with each primitive, resulting in a very slow intersection test. Thus, a method that reduces the number of ray / primitive intersection tests required per ray is useful for accelerating ray intersection testing in a scene. One way to reduce the number of such cross tests is to provide an excess bounding surface that extracts a certain number of primitive surfaces. Rays can first be cross-tested against the bounding plane to identify a smaller subset of primitives that cross-test with each ray. Such a bounding surface shape can be provided in various shapes. In this disclosure, such a collection of bounding surface elements is referred to as geometry acceleration data (hereinafter referred to as GAD).

  A more extensive treatment of GAD organization, elements, and applications can be found in US patent application Ser. No. 11 / 856,612, filed Sep. 17, 2007 and incorporated herein by reference. Thus, a simpler handling of GAD is described here for context and further details regarding these issues can be obtained from the above referenced applications.

  As introduced, GAD elements generally indicate that a geometric surface and a ray do not intersect indicates that the ray does not intersect any primitive bounded by that shape, In a three-dimensional space, it contains geometric shapes that surround each collection of primitives. GAD elements can include spheres, axially aligned bounding boxes, kd-trees, octrees, and other types of bounding volume hierarchies, so implementations according to the present disclosure can be implemented by kd-tree cutting plane methods, or A bounding scheme such as another method of finding the bounding surface that bounds one or more scene primitives and identifying the extent of the bounding surface can be used. In summary, the GAD element is preferably in a shape that can be easily tested for intersection with a ray, since it primarily helps to extract primitives to more quickly identify intersections between rays and primitives. is there.

  GAD elements can be related to each other. The interrelationship of GAD elements can be a graph that includes nodes that represent GAD elements and edges that represent interrelationships between two GAD elements herein. When a pair of elements are connected by an edge, the edge may indicate that one of the nodes has a relative granularity different from the other, ie, of the nodes connected by that edge Can be connected by edges that delimit more or fewer primitives than the other node. In some cases, the graph can be hierarchical so that it is oriented to the graph, the graph can be traversed from parent node to child node order, and the remaining bounded primitives Narrows along the way. In some cases, the graph may be such that when a given GAD element delimits another GAD element, that given GAD element does not directly delimit the primitive (ie, a uniform GAD structure). It is possible to have uniform GAD elements (so that primitives are bounded directly by leaf node GAD elements and non-leaf nodes directly bound other GAD elements rather than primitives).

  A graph of GAD elements can be constructed with the goal of maintaining a certain uniformity in a certain number of elements and / or primitives bounded by each GAD element. A given scene can be subdivided until such a goal is achieved.

  In the following description, it is assumed that there is a mechanism for determining which other GAD elements should be tested next in response based on the ray determined to cross a given GAD element. In the hierarchical graph embodiment, therefore, the next element to be tested is generally a child node of the tested node.

  One usage of GAD implemented in a certain number of embodiments is that when a ray is found to intersect a given GAD element, this ray will also intersect this element as well. Is collected along with other rays that have been determined. When a certain number of rays are collected, the stream of GAD elements connected to this element is fetched from main memory and streamed through testers where each tester has a different collected ray. Thus, each tester keeps each tester's ray fixed in local high-speed memory, while the geometry is fetched from slow memory and allowed to be rewritten when needed. More generally, this description describes how a computing resource processes a ray to detect the intersection of such a ray with a geometry (GAD elements and primitives), and finally which ray A series of examples are provided for methods that can be organized to identify hits on primitives.

  Other aspects in which these embodiments can be implemented are: (1) a queue is provided for output from the cross test to the shading; (2) the ray data is localized to some extent in computational resources; Those geometric shapes are fetched from slower memory when it is decided to test certain rays with the geometry, and (3) the computation that the intersection test performs the intersection test Driven by identifying a ray to a resource (using a ray identifier), each compute resource has data corresponding to the identified ray (s) from the localized memory (s) of each compute resource Or fetching.

  The following description presents examples of systems and portions of systems that render a two-dimensional representation of a three-dimensional scene using ray tracing. The two main functional components of such a system are (1) tracing the rays that identify the intersection, and (2) shading the identified intersection.

  FIG. 1 illustrates aspects of a system used in ray tracing a scene composed of primitives. In general, any function or role of any of the functional units in FIG. 1 and other figures may be implemented in multiple hardware units, software components, software subroutines, and executed on different computers. There is even a thing. In some cases, such implementations are described more specifically because they can affect system functionality and performance.

  FIG. 1 shows a geometry unit 101, an intersection processing unit 102, a sample processing resource 110, a frame buffer 111, a geometry shape including GAD elements and primitives (primitive and GAD storage 103), a sample 106, a ray shading A memory resource 139 that is operable, configured, or storing data 107 and texture data 108 is illustrated. The geometry unit 101 inputs a description of the scene to be rendered and outputs an acceleration structure that includes primitives and GAD elements that define the boundaries of the primitives. The intersection process 102 shades the identified intersection between the ray and the primitive and uses inputs such as texture, shading code, and other sample information obtained from the illustrated data source. The output of the intersection process 102 includes new rays (described below) and color information that are used in generating a two-dimensional representation of the scene being rendered. All of these functional components can be implemented with one or more host processing resources designated generally by dashed line 185.

  As described above, during shading of the identified ray / primitive intersection, the intersection process 102 can generate a new ray to be intersection tested. The driver 188 interfaces with the intersection process 102 to receive these new rays, and between the intersection process resource 102 and the localized intersection test area 140 that includes the ray data store 105 and the intersection test unit 109. Manage communications. Intersection test area 140 tests rays for intersections, has read access to primitives and GAD storage 103 via interface 112, and cross-processes 102 the intersection indicator identified via results interface 121. Output to. While local ray data storage 105 is preferably implemented with relatively fast memory, which can be relatively small in size, primitive and acceleration structure storage is the main dynamic memory of host 185. It is implemented with a relatively large and slow main memory 139 that can be.

  One aspect of the ray-tracing high resolution scene includes a vast amount of ray data and shape data. For example, rendering a full HD resolution film at 30 frames per second requires determining more than 60 million pixels (1920 × 1080> 2M, 30 times per second) per second. In addition, a large number of rays may be required to determine each pixel color. Thus, hundreds of millions of rays may be processed every second, and if every ray requires several bytes of storage, ray tracing for a full HD scene requires more than a few gigabytes of ray data per second. Is possible. In addition, a large number of ray data should be stored in memory at any given time. There is almost always a trade-off between access speed and memory size to the extent that large, cost-effective memories are relatively slow. Furthermore, large scale memories are constructed such that the memory is not used efficiently unless a sufficiently large block of data is accessible and usable. Thus, one challenge is to be able to consistently identify sufficiently large groups of rays for efficient access from memory. However, there is processing overhead and sometimes very high processing overhead in identifying such rays, as can be seen by approaches like ray detection and group testing with similar start points and directions. Is possible. In one aspect, the following exemplary architecture uses multiple computing resources, fast and expensive memory, and slow and large memory to increase ray intersection testing and shading throughput for scene rendering. Disclose how to organize and use.

  FIG. 1 illustrates the intersection shading identified by the flow of data including ray definition data stored in high-speed memory localized to computational resources 109 that test the rays for intersection with GAD elements and primitives. Figure 2 illustrates the separation of the cross test from. The output of the intersection test 109 includes an indication of the identified ray that intersects the identified primitive. Intersection process 102 can receive these indicators, perform shading according to these intersections, and can instantiate new rays that are ultimately stored in high-speed ray data memory 105 for testing. Such separation is in various implementations using one or more fixed function hardware and a general purpose computer programmed with software according to this description, along with communication means selected according to the processing resources used. It can be done. However, one repetitive aspect in these implementations is that the shape data tested for intersection with the ray is transient in the intersection test region 140 when compared to the ray definition data. In other words, where applicable, high-speed memory is primarily allocated to ray data, while shapes are streamed through a tester, but little computational resources are used to optimize the caching of such shape data. . The various figures below illustrate more specific examples of such separation, data flow, ray data storage, and association with cross-test resources.

  FIG. 1 further illustrates that the output of the frame buffer 111 can ultimately be used to drive the display 197. However, this is just an example of the output that can result from cross-testing and shading operations, sometimes referred to as rendering for convenience. For example, the output is further written to a computer readable medium containing a rendering product, such as a series of rendered images, for later display or distribution on a tangible computer readable medium. Or transmitted over a network that includes computing resources interconnected by communication links. In some cases, the rendered 3D scene is a real world 3D scene, such as in the case of an immersive virtual reality conference or rendering an image that includes a perspective view of a 3D CAD model. Can be expressed. In such cases, the method of rendering affects the data representing the physical object or otherwise transforms the data. In other cases, the three-dimensional scene may have several objects representing physical objects and other non-physical objects. In yet another 3D scene, the entire scene may be fictitious, as in a video game or the like. Ultimately, but in general, these methods are variations of objects in memory, displays, and / or computer readable media.

  Furthermore, since 1979, rendering using ray tracing has been performed, and various approaches have been developed for other functions required to perform cross testing and rendering using ray tracing. Thus, the specific architectures and methods described herein do not exercise the occupancy rights of the basic principles of ray tracing used in rendering 3D scenes into 2D representations.

  FIG. 2 illustrates that the intersection test unit 109 in the intersection test area 140 includes one or more individual test resources (also known as test cells) that can test the geometry against the ray. Region 140 includes test cells 205a-205n that each receive ray data from ray data storage device 105 and receive geometric shape data from memory 139. Each test cell 205a-205n produces a result that may include an indication of whether a given ray has crossed a given primitive for communication to the intersection process 102 via the result interface 121. On the other hand, the result of the GAD element and ray cross test is provided to logic 203. Logic 203 maintains a collection of reference information 210 to the ray that relates the ray to the GAD element that was determined to be intersecting.

  In general, system components are designed to support the time to an unknown end of a given specific ray test. The intersection test unit 109 has read access to the geometry memory and has a queue of reference information to the ray as input. As the output of the intersection test, each ray is associated with the portion of the geometry that each ray first intersected (referred to as a primitive in this disclosure for convenience). Other pieces of geometry (ie, primitives) can be considered irrelevant.

  As described above, region 140 includes a ray reference information buffer and associated management logic 203 that maintains a list 210 of ray collections to be tested in test cells 205a-205n. The buffer management logic 203 can be implemented in fixed function processing resources or hardware configured using instructions obtained from a computer readable medium. Such instructions can be organized into modules according to functions and tasks assigned to logic 203 herein. One skilled in the art can also provide further implementations of logic 203 based on these disclosures.

  Logic 203 can assign rays and geometry to test cells and can handle communication with other units in the design. In one aspect, each ray collection in list 210 includes only a plurality of ray identifiers to be tested for intersection with one or more geometric shapes, and logic 203 maintains such ray collections. . In a more specific embodiment, a plurality of ray identifiers are determined to intersect with a GAD element identified in the collection, and a next GAD element to be tested for intersection with a plurality of rays is a GAD element. Related to that crossed GAD element in the graph. Elements associated with a given collection are fetched from memory 139 when cross testing with these elements is initiated.

  In other words, the logic 203 can hold reference information representing rays that intersect a small portion of the geometry data corresponding to each child node in the temporary ray reference information buffer, and further processing such rays. Allows postponement of. In the hierarchically-arranged GAD embodiment, such deferrals may occur until a later point in time when the cumulative number of rays intersecting a small portion of the child node's geometry is found to be suitable for further processing. Processing for a small portion of the geometry acceleration data below the node can be postponed.

  Logic 203 can further communicate with memory 139 to set up memory transactions that provide test geometry to test cells 205a-205n. The logic 203 further communicates with the ray data storage device 105 to determine the ray in which the data is stored. In some implementations, the logic 203 obtains or receives rays from the shading process executing in the memory 139 or the intersection processing unit 102, and these are stored and used during intersection tests when space is available. Are provided to the memory 105.

  Thus, the logic 203 can maintain a temporary ray reference information buffer that includes the relevance of the ray identifier to the GAD shape identifier. In an implementation, an identifier for a GAD element can be hashed to identify a location in a buffer that stores a predetermined collection associated with that GAD element. Relevance is collectively referred to herein as collections when describing the storage or collection of such data in memory, and in some places in the present application, generally, the movement of collection data during testing, The term “packet” is used to mean returning a result from a test. Such returned results can be merged into a collection stored in the memory associated with the GAD shape, as described below.

  In summary, FIG. 2 continues to illustrate that ray definition data is stored in the high speed memory 105 and that shape data to be tested for such ray intersections comes from the memory 139. The above disclosure allows multiple next shapes to be tested to be fetched from memory 139 at the same time and tested sequentially for intersection with a group of rays known to intersect the “parent” GAD element. Further clarify that it is preferable.

  FIG. 3 now includes a block diagram of an embodiment of an implementation by an intersection test unit (ITU) 350 of a region 140 (FIG. 1) that can be used in a rendering system that ray-traces a two-dimensional representation of a three-dimensional scene. The ITU 350 includes a plurality of test cells 310a to 310n and 340a to 340n. The GAD element is illustrated as being provided from the GAD data store 103b, and the primitive data is provided from the primitive data store 103a.

  Test cells 310a-310n receive GAD elements and ray data to be tested with these GAD elements (ie, these test cells test the GAD elements). Test cells 340a-340n receive primitive data and ray data to be tested with these primitives (ie, these test cells test the primitives). Thus, ITU 350 can test a collection of rays for intersection with primitives and can test a collection of separate rays for intersection with GAD elements.

  The ITU 350 further includes a collection management logic 203a and a collection buffer 203b. The collection buffer 203b and the ray data 105 can be stored in a memory 340 that can receive ray data from the memory 139 (for example). The collection buffer 203b maintains ray reference information associated with the GAD element. Collection management 203a maintains these collections based on intersection information from test cells. Collection management 203a may also initiate fetching of primitives and GAD elements from memory 139 to test ray collection.

  The ITU 350 returns an indication of the identified intersection that can be temporarily stored in the output buffer 375 for final provision to the intersection process 102 via the results interface 121. The indicator information is sufficient to identify the ray and the primitive that is determined to intersect the ray within a predetermined accuracy.

  The ITU 350 can be viewed as a function or utility that can be called through a control process or driver (eg, driver 188) that gives the ITU 350 a ray and the geometry that the ray will be tested for crossing. . For example, ITU 350 may be provided with information via driver 188, i.e., through a process that interfaces ITU 350 with other rendering processes such as shading and initial ray generation functions. From an ITU 350 perspective, ITU 350 uses rays, GADs, and primitives (or more generally scene geometry) where region 140 is provided or obtained based on other information provided. Cross-testing can be performed, so there is no need to be aware of the origin of the information provided.

  As described above, the ITU 350 controls how, when, and what data is provided to the ITU 350 so that the ITU 350 is not passive and is needed, for example, for cross testing Depending on the, ray or geometry data or acceleration data can be fetched. For example, the ITU 350 can be provided with a number of rays for intersection testing, along with sufficient information to identify the scene where the rays are to be tested. For example, the ITU 350 can be provided with more than 10,000 rays for a crossover test at a given time, and when these ray tests are finished, as described below (generated by the crossover process 102). New rays) can be provided to keep the number of rays being processed in the ITU 350 at approximately the initial number. The ITU 350 then controls the temporary storage of rays (in the logic 203a (see FIG. 3)) during processing (in the ray collection buffer 203b (see FIG. 3)) and during processing. Fetching of primitive and GAD elements can be initiated as needed.

  As described above, while the data defining the ray is maintained in the ray data 105, the ray identifier is maintained in the buffer 203b and organized with respect to the GAD element, so that the GAD element and primitive are Compared to Ray, it is temporary in ITU 350. Each of the buffer 203b and the ray data 105 can be physically implemented in various ways, such as one or more banks of the SRAM cache, and can be maintained in the memory 340.

  As described above, the logic 203a tracks the state of ray collection stored in the memory 340 and determines which collection is ready for processing. As shown in FIG. 3, logic 203a is communicatively coupled to memory 340 and can initiate distribution of rays to each of the connected test cells for testing. In situations where a GAD element is not a combination of a GAD element and a primitive, but only a GAD element or a primitive-only boundary, the logic 203a associates a GAD element with a specific collection that defines the boundary of the primitive or other GAD element. Depending on whether or not the test cell 340a to 340n or the test cells 310a to 310n can be assigned a ray.

  In embodiments where a unique GAD element can delimit both other GAD elements and primitives, ITU 350 will have a data path that, along with the ray, provides both GAD elements and primitives to each test cell. Thus, the logic 203a prepares a collection test ray among the test resources. In such an embodiment, because of the typical difference in shape between GAD elements and primitives (eg, sphere-to-triangle), the test logic is switched or the intersection optimized for the shape being tested An indicator for loading a test algorithm can be provided from logic 203a.

  The logic 203a can cause the provision of information to the test cells 310a-310n and the test cells 340a-340n directly or indirectly. In an indirect situation, logic 203a can provide information to each test cell such that each test cell begins fetching test ray data from memory 340. The logic 203a is illustrated separately from the memory 340 for the sake of simplicity, but the management functions performed by the logic 203a are primarily related to the data stored in the memory 340, so the logic 203a is not included in the memory 340. Can be incorporated into the circuit.

  The ability to enhance parallelization of access to memory 340 by cross-test resources is an advantage of some aspects described herein. Therefore, it is advantageous to increase the number of access ports to memory 340, preferably to at least one per test cell. An exemplary organization associated with such parallelization is further described below.

  Further, the ITU 350 can operate asynchronously with respect to units that provide input data to the ITU or receive output from the ITU. Here, “asynchronous” includes the ITU receiving additional rays and initiating additional ray crossing tests while the crossing test continues for previously received rays. be able to. In addition, “asynchronous” may include that a ray may not finish the cross test in the order in which the ITU 350 received the ray. Asynchronous means that the intersection test resource in ITU 350 does not take into account the position of the ray in the 3D scene or the scheduling grid superimposed on the scene, or for the assignment or scheduling of the intersection test, or the parent ray. And test-only rays that have intergenerational relationships, such as child rays generated from a small number of parent rays, or can be used to test only special generation rays, such as camera rays or secondary rays .

  The ITU 350 further includes an output buffer 375 that receives the indication of the identified intersection of the primitive and the ray that intersected the primitive. In an embodiment, the indicator includes identifying information for the primitive paired with sufficient information to identify the ray that intersected the primitive. Ray identification information may include reference information such as an index identifying a particular ray in a list of rays maintained in resources available to the host processor. For example, the list can be maintained by a driver 188 running on the host processor, and the list can be maintained in memory 139. Preferably, memory 139 can include definition data for all rays in memory 340. However, ray specific information can include information such as ray start and direction sufficient to reconstruct the ray. In the normal case, fewer bits will be required to pass the reference information, which is advantageous.

  FIG. 4 illustrates an example of a test cell 310 a that includes a working memory 410 and test logic 420. The working memory 410 can be several registers that contain enough information to test the line segment for intersection with the surface, or it can be more complex in other implementations. For example, the working memory 410 can store instructions that configure the test logic 420 to test a particular shape received for an intersection, and based on the received data what shape was received. Can be detected. The working memory 410 can further cache detected hits, each test cell being configured to test a series of rays against the geometry, or vice versa, and therefore cached. Hits can be output as a group. The working memory can also receive shape data received from the storage device 103b.

  Test logic 420 may perform a cross test with available or selectable resolutions and return a binary value indicating whether a cross was detected. Binary values can be stored in working memory for reading, caching, or output for latching during a read cycle, such as a read cycle in memory 340 for GAD element testing.

  FIG. 5 illustrates an embodiment of a cross test unit 500 with more emphasis on details with an exemplary memory organization. In the ITU 500, test cells 510a to 510n and 540a to 540n appear, and correspond to 310a to 310n and 540a to 540n in this embodiment. This does not imply any requirement on the number of test cells. Thus, in ITU 500, both primitives and GAD elements can be tested in parallel. However, if it is determined that more test cells of one type or another type are needed, any test cell can be reconfigured as needed (reassigned in the case of hardware, software Will be reprogrammed). As transistor density continues to increase, more such cells can be accommodated in a hardware implementation (or as a resource available to run software). As described, some of the test cells test rays against a common shape (ie, primitive or GAD element) and can be treated as an operational group. Test cells 540a-540n can return a binary value indicating intersection with a primitive at a specified accuracy level (e.g., 16 bits) and can be useful for larger primitives on ray intersected primitives. It is also possible to return a more accurate indicator of the location.

  In ITU 500, memory 540 includes a plurality of independent computing banks 510-515 each having two ports (ports 531 and 532 of identified bank 515). One port is accessed via GAD test logic 505 and the other is accessed via primitive test logic 530. Each of GAD test logic 505 and primitive test logic 530 manages the flow of data between the respective working buffers 560-565 and 570-575, and tests from GAD storage 103a and primitive storage 103b, respectively. Operates to get the GAD element for.

  Banks 510-515 are primarily intended to operate to allow non-competing access to ray data by GAD test logic 505 and primitive test logic 530 so that each test cell 510a- 510n and test cells 540a-540n may be provided with rays from separate banks 510-515. Such non-contention access is to be understood from these disclosures, but can be implemented, for example, by separate cache banks, and similarly, the cross bar architecture is a different physical part of the memory by port. Enable access to. If testing of a ray stored in a bank with one or more test cells is allowed, a conflict occurs when two rays to be tested are in the same bank, in such a case, Access can be handled sequentially by test logic 505 and 530. In some cases, working buffers 560-565 and 570-575 are loaded for subsequent processing while other processing is complete. The ITU 500 can be further organized into regions. For example, since region 578 includes GAD tester 510a and memory bank 510, it constitutes a test region for GAD elements, and region 579 includes testers 510a and 540a (one for each of GAD and primitive), and Access to the memory bank 510 that stores the ray data to be used in tests related to the test cells in regions 578 and 579, thus forming a test region for both GAD elements and primitives.

  By testing rays in a consistent arrangement, it is possible to reduce tracking of which rays are assigned to which test cells. For example, each collection can have 32 rays and there can be 32 test cells 310a-310n (510a-510n). For example, by consistently providing the fourth ray in the collection to test cell 310d, test cell 310d need not maintain information about the provided ray, but only need to return an intersection indicator. It is. As will be apparent, other implementations can be provided that maintain consistency, including passing a ray identifier packet between test cells and allowing the test cell to write the intersection result into the packet.

  Ray collection storage is implemented as an n-way interleaved cache for ray collection so that a given ray collection can be stored in one of n locations of ray collection buffer 203b or 520. Can be done. The ray collection buffer 203b or 520 can thus maintain a list of ray collections stored in each of the n locations of the buffer. Implementation of the ray collection buffer 203b or 520 can include using the identifying characteristics of the GAD element associated with the ray collection, for example, the GAD element used in rendering the scene. A unique identifier string can be used. The alphanumeric character string may be a number, hash, or the like. For example, the hash can reference one of the n locations of the ray collection buffers 203b and 520.

  In other implementations, elements of the GAD can be scheduled for storage in predetermined locations in the ray collection buffers 203b and 520, for example, the segments of alphanumeric strings used can be stored in such buffers. Map to the location (s). Primitive / ray intersection output 580 represents an output that identifies a potential primitive / ray intersection, and output 580 can be serial or parallel. For example, if there are 32 primitive test cells 540a-540n, the output 580 may include 32 bits that specify the presence or absence of each ray intersection for the last tested primitive. Of course, the output may come directly from the test cell in other implementations, eg, packet implementation. The outputs can be serial and can be stored serially in the packet by the test cell.

  Ray data is received into memory 340 (520) from a light source such as a shader. Collection management logic (eg, 203a in FIGS. 2 and 3) operates to initially assign a ray to a collection when each collection is associated with a GAD element. For example, a GAD element can be the root node of a graph, and all received rays are initially assigned to one or more collections associated with the root node. The receipt of a ray can also be done, for example, in a group sized to be a complete collection from the input queue, with each collection treated as a collection identified in the ray collection buffer 203b, for example. Is possible.

  With the understanding that a certain number of collections can be tested in parallel, with an emphasis on processing one collection, retrieving the collection ray associated with the test node from memory 340 can be, for example, a collection A bank that provides ray data on a plurality of output ports for reception by a test cell (eg, test cells 560-565) from memory 340, or as stored in FIG. 5, in accordance with the embodiment of FIG. Initiated by collection management logic 203a by providing such ray addresses (ray identifiers) from 510-515 that allow such ray retrieval.

  For testing a GAD element bounded by a selected node for testing (ie, the GAD element associated with the selected node bounds another GAD element), the ray for the ray of the collection under test The data distribution ends and a bounded GAD element fetch is also performed (such a fetch does not necessarily have to be done next to the ray distribution). Because of such fetching, the logic 203a can input addressing information to the GAD storage device 103b (or regardless of what memory management means is provided), and the GAD storage device The designated GAD element (s) is output to the test cells 310a to 310n. If multiple GAD elements are delimited as usual, the elements are streamed serially to the test cell, eg, using a serialization buffer, to allow block reading of multiple GAD elements. Be placed.

  In test cells (eg, 310a-310n), collection rays can be tested for intersection with GAD elements provided in series (eg, different rays in each test cell). If a ray is determined to intersect, it is determined whether a collection exists for the intersected GAD elements, and if so, the ray is added to that collection that allows room, otherwise a collection is created, Ray is added. If there is no room in the existing collection, a new collection is created.

  In some implementations, there is a 1: 1 correspondence between the maximum number of rays in the collection versus the number of test cells 310a-310n so that all rays in the collection can be tested in parallel against a given GAD element. This implementation can include an architecture where the throughput is such that it can be obtained using a 1: 1 ray-to-test cell correspondence, but the entire ray of a given collection is parallel. Sequential transmission of packets (e.g., information representing a collection as described above) between different test cells so that different test cells can test rays from different packets even though they are considered testable Can be delivered.

  The rays are then tested for intersection with the primitive provided to the test cell (ie, in this example, each test cell has a different ray and tests that ray and the common primitive). After the test, each test cell informs the detected intersection.

  Each ray in the collection is tested in that test cell for intersection with the GAD element provided to the test cell (eg, in the multiple back embodiments of FIG. 5 (regions 578 and 579 shown)). Rays are considered localized to the GAD element test area and / or the primitive test area, for example, so that the bank provides ray data to various one or more testers).

  Because the output from testing a ray for an intersection with a GAD element is different from testing the same ray for a primitive intersection (ie, an intersection with a GAD element results in a collection into the collection for that GAD element, Since an intersection with a primitive results in the determination of the closest intersection with that primitive and the output of such an intersection), it is assumed that a particular ray exists in two collections that are accidentally tested in parallel However, contention to writeback for collection data or output intersections should not normally occur. If further parallelization is performed, for example, by testing multiple collections of rays for primitive intersections in multiple instantiations of test cells 340a-340n, such tests such as storage of multiple intersections. Features can also be implemented, such as forcing an orderly end, locking bits, etc. And in the embodiment of FIG. 5, if data for a given ray can be provided from a single bank to one tester type (ie, if a given ray is located in one memory bank), Multiple GAD testers avoid the problem of write-back contention, for example, because they do not test the same ray at the same time.

  In summary, the method comprises: receiving a ray; assigning a ray to the collection; selecting a collection that is ready for testing if the readiness is algorithmically determinable; Assigning the rays in the collection to the appropriate test cell and streaming the appropriate geometry in the test cell for intersection testing. The output depends on whether the geometry is a scene primitive or a GAD element. For a ray tested against a GAD element, the GAD element is identified based on the graph connection between the collection under test and the associated node, and the ray is added to the collection associated with the GAD element under test. . The collection is reviewed for readiness and selected when ready for testing. For ray intersections with primitives, the closest intersection is tracked using rays. Since a ray is tested when associated with a ready collection, an implicit cross test for a particular ray is determined that the collection with which the particular ray is associated is ready for testing. Postponed until Rays can be collected simultaneously into multiple collections that allow such rays to be tested against different parts of the scene geometry (ie, the rays may not be tested in traversal order).

  As described above, the ITU stores in memory information representative of rays previously received from ray inputs. For these rays, the ITU maintains the association of each ray with one or more of the multiple collections. The ITU further maintains a collection fullness measure for multiple collections stored in memory. These indicators can be each flag designating a full collection or a number representing a certain number of rays associated with a given collection. Further details of implementation and other examples and variations related to the implementation of the test algorithm are described in the above referenced referenced related applications, where the information presented literally is not their exclusive treatment It is made clear.

  As is apparent from the disclosure so far, a ray is loaded (or accessed in memory) from memory based on information provided in the collection of rays. Thus, such loading can include determining a respective memory location where data representing each ray is stored. Such data can be included in the ray collection, for example, ray collection can be a memory location where ray data for those rays is stored in the collection, or to a storage location. A list of other reference information can be included. For example, ray collection can include reference information to locations in memory, eg, memory 340, or banks of memory (eg, bank 510), or in other implementations these reference information can be absolute It can be a value, an offset from the base, or another suitable way to reference such data. However, in some implementations, ray collection data and ray data can be maintained, for example, as a content association database. The separation need not be so explicit or obvious, the relationship between the collection and the ray, and the relationship between the collection and the elements of the GAD are maintained and associated with the collection for testing Used to identify the ray and the GAD elements that are also associated with the collection.

  Similarly, it is clear that ray data is “quiesced” within a test cell because either primitives or GAD elements are cycled through the test cycle. Other implementations are possible, as described in the related application, but the main focus of these disclosures is localized or otherwise prepare the ray to be stationary with respect to the cell In the meantime, the geometry is fetched and tested.

  Such an embodiment is proposed in connection with FIG. In particular, another implementation of the cross test logic includes a fetch control unit 620 (similar to the test logic 203 of FIG. 2), an instruction cache 630, an instruction decoder 645, and data, coupled to a memory interface 625. A processor 605 including a cache 650 may be included. The data cache 650 inputs data to the test cells 610a to 610n. Instruction decoder 645 further provides inputs to test cells 610a-610n. Instruction generator 665 provides instruction input to instruction decoder 645. The test cell outputs an indication of the detected intersection to the write-back unit 660, which can then store the data in the data cache 650. The output from write back unit 66 is also used as an input to instruction generator 665 when generating instructions. The instructions used in such a processor 605 may be a single data, multi-instruction series, where the intersection between the plane (eg, primitives and GAD elements) on which the instructions to be processed in the test cell are defined and the ray. Considered a test.

  In an embodiment, an “instruction” may include data defining a geometric shape, such as a primitive or GAD element, and a plurality of data elements may be provided with a geometric shape provided as an “instruction”. Reference information for a separate ray to test against can be included. Thus, the combination of geometry and multiple ray reference information is considered to be a packet of separate information that can be distributed across multiple illustrated test cells. In some cases, packet distribution can proceed sequentially, so that multiple packets “collide” between multiple test cells.

  Such a test cell can exist in the context of a full-function processor with a large instruction set, and each packet then contains sufficient other information to identify the purpose of the packet be able to. For example, a certain number of bits may be included to distinguish a packet created for cross-testing from a packet that exists for other purposes for other operations to be performed. Similarly, various cross test instructions can be provided for purposes including different primitive shapes and different GAD element shapes, and, optionally, different test algorithms.

  In an exemplary embodiment, each intersection test packet first intersects a geometry element with reference information to the geometry element or data for the geometry element, which is either reference information to a GAD element or primitive. It is possible to accommodate reference information (ie, the aforementioned “packets”) to a certain number of rays to be tested for.

  Decoder 645 can interpret the instruction to determine reference information to the geometry element and initiate fetching of the element via fetch 620 (control for a memory interface such as memory interface 625). In some implementations, the decoder 645 can provide for a certain number of instructions to begin fetching the geometry elements needed in the future. Geometry elements can be provided to decoder 645 by fetch 620, which provides the geometry elements to test cells 610a-610n.

  The decoder 645 further provides ray reference information from the instruction as a function address to the data cache 650, which provides each of the test cells 610a-610n with sufficient respective data for each ray cross test. Data associated with rays that are not needed for cross testing need not be provided. Thus, the data cache 650 can serve as a localized ray data storage facility for one or more computing resources that operate as a cross-cell test.

  The geometry elements are tested for intersection with their respective rays in each test cell 610a-610n, and an indication of the intersection is output from each test cell 610a-610n for reception by writeback 660. Depending on the nature of the geometric element being tested, write back 660 performs one of two different functions. If test cells 610a-610n are testing a primitive for intersection, writeback 660 outputs an indication of each ray that intersected the primitive being tested. Writeback provides the output of test cells 610a-610n to instruction unit 665 when test cells 610a-610n are testing elements of GAD.

  The instruction unit 665 operates to assemble future instructions that will be commanded to the test cell during further cross-tests. The instruction unit 665 operates using the inputs from the test cells 610a-610n that specify a ray crossing a predetermined element of the GAD, the instruction cache 630, and the input from the GAD input 670 as follows. Using the inputs from test cells 610a-610n, instruction unit 665 determines GAD elements connected to the specified GAD elements among the inputs from test cells 610a-610n based on the GAD inputs. (Ie, the instruction unit 665 determines the next element to be tested based on the indicated intersection for a given GAD element).

  Instruction unit 665 determines whether an instruction stored in instruction cache 630 already exists for each element of the GAD identified as connected to the crossed element and whether the instruction allows further ray reference information ( That is, are all data slots of the instruction filled?). Instruction unit 665 adds the same number of rays identified as intersecting in the test cell input to the instruction and creates enough other instructions to receive the remaining ray reference information. The instruction unit 665 does this for each element of the GAD identified as being connected to the element identified in the test cell input. Thus, after processing test cell inputs (intersection indicators), rays identified as intersecting the same GAD element each specify a ray test for the GAD element connected to that same GAD element. Added to the order. The instruction thus created can be stored in the instruction cache 630.

  Instructions can be organized in instruction cache 630 based on the organization of elements of GAD received from GAD input 670. Instruction unit 665 receives an indication of which ray hits which element, both of logic 203a and instruction unit 665, and groups such rays for future testing, thus providing a function similar to logic 203a. Run. The system of FIG. 6 is intended to be more versatile because the ray packets to be tested can be some type of packet that accomplishes different functions.

  For example, the GAD input 670 can provide a GAD graph, where the nodes of the graph represent elements of the GAD, and pairs of nodes are connected by edges. The edge identifies which nodes are connected to which other nodes, and the instruction unit 665 determines which instructions are already in the cache for a given element of the GAD and where new rays are added. To identify, the instruction cache 630 is searched by following the edges connecting the nodes. If multiple instructions exist for a given GAD element, the multiple instructions can be linked in a list or otherwise ordered or associated with each other. Other methods such as hashing of GAD element IDs to identify potential locations in the instruction cache 630 where related instructions may be found can be implemented as well.

  The instruction is being tested so that in response to an issued and decoded instruction (as opposed to storing an instruction for each connected node), the instruction causes a fetch of the GAD connected node. Further reference can be made to the GAD nodes. Each such connected element can be streamed into test cells 610a-610n for testing with a respective ray maintained in each test cell (i.e. GAD elements are provided to each test cell, and each test cell remains stationary in the test cell as it tests each ray in turn with each GAD element).

  Thus, a processor implemented in accordance with these embodiments obtains or otherwise creates an instruction to collect the specified ray for intersection with the first node for intersection testing for connected nodes. Will provide functionality to do. Similar to the embodiments described above, if the GAD provided to the processor 605 is hierarchical, the GAD graph may be traversed in a hierarchical order.

  Exemplary connections and sources of GAD are typical, and other arrangements are possible. For example, the memory 615 may be the source of GAD elements, but preferably, if the given processing architecture permits, it is not the geometry data, but the ray (ie, the data defining the ray and found). Other data such as the current nearest neighbor intersection) continue to be stored in high speed memory. Similarly, in the above example, the next node to be tested (ie, the next acceleration element or primitive) is determined based on the test results, and the packet is instantiated for each geometry. . Other implementations that are apparent from the above disclosure can include instantiating a packet for each “child” node as soon as it decides to start testing a child of a given node, at a later point in time. Create child instructions / collections.

  FIG. 7 further illustrates aspects of a ray tracing system (eg, system 700) that can use cues to separate the operation of intersection testing and ray shading that includes the generation of new rays such as camera rays. System 700 allows for ray submission for intersection testing and completion of intersection testing, and produces outputs for shading in a different order, similar to the systems of FIGS. Similarly, the intersection test resource can proceed with ray intersection tests without stagnation due to the previously identified intersection shading resolution.

  FIG. 7 illustrates a plurality of intersection test resources (ITR) 705a-705n each coupled to ray data stores 766a-766n that store data defining the rays to be tested for intersections in the intersection test resource. Each group of ITRs and ray data stores (eg, ray data 766 and ITR 705a) are similar to localized groupings of test resources and ray data stores, eg, previous groupings, eg, groupings 578 and 579 of FIG. The illustrated grouping 704 can be considered.

  The ray data storage devices 766a-766n can be memory such as a private L1 cache, a shared or mapped portion of L2, and so on. In the embodiment described above, the high speed memory is preferably dedicated to storing ray data that is local to a particular processing resource rather than geometric data. Localized storage of ray data is simplified by the cross-test algorithm used here, increasing the time period during which rays can be stored in localized high-speed memory, and this small memory thrashing. Reduce the amount. Thus, this ray storage can be considered quasi-static because the data for a given ray is usually stored in the same local memory until it completes the intersection test in the scene.

  Data defining a ray is loaded via output 743 from test control 703 (similar to logic 203b, etc. in the above diagram). The test control 703 receives input including the identifier of the ray that has completed the cross test in the ITRs 70a to 705n via the ray end queue 730.

  Queue 730 stores ray identifiers (some exemplary ray IDs 1, 18, 10 and 480 are shown). Queue 730 obtains inputs from ITRs 705a-705n that are tested to identify the closest intersection that intersected and represent a ray that ends the test in the scene. Thus, the queue 730 represents GAD element information, or a primitive intersection that appears to be the nearest neighbor (helpful if the ITRs 705a-705n can test both types of shapes) from the ITRs 705a-705n. Data can be entered from decision point 751, which can determine whether to do.

  Decision point 751 thus represents the two types of crossing control functions described above. In one intersection control function, the GAD / Ray intersection is maintained / managed near the intersection tester, while on the other hand, only the nearest detected primitive / ray intersection is output for shading. In some of the above architectures, if a separate test cell is used for each, the decision point can only track when a primitive intersection that appears to be the nearest neighbor is found.

  From decision point 751, the GAD result is provided from ray control 703 and enters multiplexer 752, which also receives a ray ID input from queue 725 that stores the ray ID received from input 742. The ray control 703 inputs the input 742 together with the ray identifier corresponding to the ray information provided to the ray data 766a to 766n from the test control 703 via the output 743. Therefore, data defining the ray specified in the queue 725 by (Ray identifier (Ray ID)) is provided to the ray data 766a to 766n via the output 743 and stored in these memories. Examples of how ray IDs are formed are described below.

  Both queues 730 and 725 illustrate a series of ray identifiers (Ray IDs). However, as described below, rays are generally tested in parallel against a given geometric shape. Thus, in such a case, the queue 725 will preferably store a ray ID for a ray ID packet, so that the queue 730 has a certain number of rays with each entry associated with a predetermined shape. A series of entries having IDs can be represented.

  As a specific example, the algorithm driving this architecture generally waits until it is determined that a certain number of rays should be tested against a given shape, so that a large number of rays test at about the same time. It is generally considered to finish and start the test. Advantageously, these end rays can be completely independent of each other with respect to the method or time instantiated initially or with respect to which path these end rays used to traverse the acceleration hierarchy. Conversely, queue 725 can be considered to contain a new ray group or packet to be tested against the scene's default GAD element, eg, the root node in the hierarchy of GAD elements.

  Such a new ray comes from a light source that includes a camera shader 735 and other shaders 710a-710n. The camera shader 735 is identified separately because it generates the primary ray to be tested in the scene. The shaders 710a-710n are suitable for the specified intersection between rays and primitives, for example, running on computing resources in the form of threads and / or on the core of one or more processors. Represents the execution of an instruction or other logic that specifies a response. Typically, such a response is determined at least in part by shading the code associated with the primitive and can reveal various other effects and considerations.

  Shaders 710a-710n receive crossed ray and primitive identifiers via distribution points 772 that receive such ray data from output 745 of test control 703 (see FIG. 8a). Since the distribution point 772 can be used to provide such ray data to computational resources with the availability to execute code for a given primitive, such availability determination means can be used to measure load, It can be used to control such distribution including flags set by computational resources, FIFO separation using fullness index, or round robin or pseudo-random distribution schemes.

  The outputs of these shaders 710a to 710n can include other rays called secondary rays for convenience (the output from the camera 735 also includes rays). In this example, such a ray now includes at least the starting point and direction that define the ray, but at this point, it is preferable that the ray ID provided by the test control 703 should be associated at this point. Absent.

  As can be identified, the test control 703 can monitor the ray status in the cross-test resource, and a new ray in the ray data 766a-766n as described in more detail in connection with FIGS. Allows you to replace a finished ray. The distribution of ray IDs to ITRs 705a-705n is performed by distributor 780, which is described in detail with respect to FIG. Such distribution is mainly controlled by storing the data defining the ray specified by the predetermined identifier in the memory of the ray data 766a to 766n. Similarly, the distributor 780 controls when a ray ID is acquired from the queue 725 based on considerations such as collection ready, as will be further described below with respect to FIG.

  Referring now to FIG. 8a, it includes a bank of memory associated with each of the ray data 766a-766n, each bank having a slot occupied by ray data, and addressable by a memory address. A portion of test control 703 is shown. FIG. 8 a illustrates that output 744 from ray end queue 730 includes ray identifiers 1, 18, 106 and 480, each identifier being allocated space in memory 803. Such spaces are allowed to be overwritten / filled in response to receipt of these ray identifiers from output 744. The output 745 to the distribution point 722 includes ray data used during shading. The output 745 can further include other data. In practice, memory 803 may be implemented with memory that is also used by other processes, such as processes that execute shaders 710a-710n. In such cases, output 745 can represent the retrieval of such data from memory 803 by computational resources (or can be implemented by retrieval).

  Various communication links, such as links 741, 742, 743, 744, 745, 750, 790, are identified in FIG. 7, and any of these links can be implemented according to the overall architectural implementation, shared memory It can include regions, physical links, virtual channels established on expansion buses, shared register space, and the like.

  FIG. 8b shows that data for new data comes from output 741 (eg, from a shading operation such as camera shader 735). Such ray data includes at least a ray start point and direction information. Test control 703 then assigns these new rays to locations for various ray data 766a-766n in memory 803. The identifier associated with each ray start point and direction depends on the location where each is stored. Thus, input 742 (input for queue 725) receives a ray identifier determined based thereon. Similarly, output 743 includes both ray identifiers and start point and direction information associated with them and stored in memory 803. Ray IDs can be used to index memory to identify related data, but as long as the identification of ray data in ITRs 705a-705n and memory 803 can be performed using ray identification data, Since type identifiers can also be used, the ray ID assignments illustrated in FIGS. 8a and 8b are convenient.

  FIG. 9a illustrates an example of such an alternative where the content associative memory 910 maintains a key 905 that is associated with different ray data.

  FIG. 9 b illustrates that within each ray data 766 a-766 n, a slot is provided for receiving ray data from the test control 703 via the interface 743. These slots can be further subdivided into multiple banks, or can be interleaved, and / or other cache organization mechanisms that allow easier retrieval of data from the cache Is possible. Rays here need to be distributed for storage, and such distribution is based on the least significant bit of the ray ID, or the hash of the ray ID, or the number of banks where the distribution takes place We can proceed with modulo division by, using round robin queuing, or other distributed mechanisms that can be used to distribute ray data to memory. Within a predetermined portion, ray data can be sorted based on ray IDs.

  In summary, FIGS. 7-9b show identifiers based on the memory locations where the rays to be tested are collected by control logic and preferably the ray definition data is stored in respective caches linked to different cross test resources. 1 illustrates an architecture to which is assigned. Primitive intersection test results come from these test resources when the test is finished, and the test control logic then reassigns the memory locations of these finished rays to new rays that need to be tested. Is possible. The finished ray can be shared by any of a number of different cross processing / shading resources that can generate additional rays to be tested. Rays typically cycle through intersection test resources throughout the acceleration structure traversal and until the nearest primitive intersection is identified (or until it is determined that the ray does not intersect anything other than the scene background). Be made.

  Referring to FIG. 10, a further architectural aspect of the rendering system is illustrated. One aspect in FIG. 10 is that ray data can be stored in respective cache memories coupled to processors configured for cross testing. Another aspect is how the distributor 780 can interface with the ITRs 705a-705n. A further aspect shown is a method in which shape data for testing can be provided to the intersection tester.

  Distributor 780 receives ray identifiers from multiplexer 752 (FIG. 7) via communication link 790 (implemented as hardware, inter-process or inter-thread communication, etc.). Each of these ray IDs is sent to a collection management 1075 where the association between the ray ID and each GAD element bounding object to be tested next is maintained. Ray IDs are further distributed between queues 1021, 1022, and 1023 by decisions 1013, 1014 and 1015, where ray IDs wait for decisions from collection management and storage 1075 to test their collections. Is possible. For example, collection 1045 is determined to be ready for testing, and ray IDs are sent to respective ITRs 705a-705n where caches 1065a-1065n contain data for each such ray ID. The Collection management 1075 may also have an interface to a memory that stores GAD element data and / or primitive data to initiate retrieval of the geometric shapes required for testing.

  These shapes reach the queue 1040 from the storage device 103 (FIG. 1) via the link 112 (for example). These shapes are identified based on their association with GAD elements associated with a given collection. For example, in the case of hierarchical GAD, these shapes can be children of the parent GAD element. Each ITR can test each ray sequentially against the shape from the queue 1040. Thus, the highest throughput is achieved when the rays of a given collection are evenly distributed among the caches 1065a-1065n, and the collection management 1075 is the easiest to collect based on the results of testing the given ray collection. Can be updated. When multiple rays in a given collection are in one cache, other cross testers can either stall or test the rays from the next collection. The maximum number of out-of-order tests is accepted before collection test synchronization is required again.

  Output is generated at outputs 750a-750n (which can be a component of link 750 (FIG. 7)) and provided to decision point 751 (FIG. 7). As described above, this architecture provides an ITR that tests any shape (ie, either primitives or GAD elements). In addition, decision point 751 coupled with collection management 1075 indicates that the result of the GAD cross test includes a decision that a given ray hits a given GAD element, and the identified ray corresponds to that GAD element. To be added to the collection. Thus, another implementation can include providing GAD test results directly to collection management 1075. More generally, the above example illustrates the flow of potential information and other flows are apparent therefrom.

  Another aspect to note is that one or more ray IDs of a given ray collection can be stored in any of the queues 1021, 1022, 1023 (indicated by collection 1047). In such a case, the ITR for that queue can test both rays and outputs the result of the second test (or multiple subsequent tests) when it becomes available. Decision point 751 can wait for all the results of the collection to be assembled, or propagated as long as “scattering” results are available.

  In summary, FIG. 10 allows a packet of ray identifiers associated with one or more shapes to be distributed into queues for multiple test resources, each queue storing a subset of ray data. The system organization is illustrated. Each test resource fetches the ray data specified by each ray identifier for the shape loaded into the test resource. Preferably, the shapes can be streamed sequentially among all test resources in parallel. A shape can be specified as a series of children starting from an address in main memory. Thus, FIG. 10 illustrates a system organization whose shape is typically tested in parallel against multiple rays.

  However, other embodiments sequentially test shapes in a series of different cross test resources, and the shape data and ray identifier packets travel between the cross test resources. Progressing multiple packets increases test throughput. Examples according to this approach are described below.

  FIG. 11 illustrates a first embodiment of a computer architecture in which a ring bus arrangement of multiple computing resources 1104-1108 can be implemented. Each computational resource contains ray data to be cross-tested with the geometry provided to that computing resource from shape data store 1115 in memory 340 for the computational resource used for the cross-test. The private L1 caches 1125a to 1125n can be accessed. Communication between computing resources 1104-1108 can be performed by a bus 1106, which can include multiple point-to-point or other architectures available for such interprocessor communication. .

  When computing resources share certain memory structures such as L2 caches 1130 and 1135, communication between these computing resources, eg computing resources 1107 and 1106 sharing L2 cache 1130, is They can communicate with each other via a cache. Additionally, a copy of the data for the ray being tested in the system can be maintained in the ray data 1110 due to the distribution of the subset of data among the ray data 1101a-1110n, ( It can also be stored in these L2 caches (as described below). The shape data 1115 can exist in the memory 340, or can temporarily exist in one or more of the L2 1130, 1135, and in any of the caches 1125a-1125n. However, ray data stored in such a cache is protected from being overwritten by such shape data, and the amount of space allocated for such a shape is generally used next in a test. Packets currently identified as being ready for testing so that it is sufficient to block latency to shape data 1115 without trying to keep shape data around when there is no indication of when Is limited to the size that can be used for. In other words, because of ray data, it is preferable to avoid the use of typical cache management algorithms, such as maximum unused replacement.

  FIG. 11 further illustrates that the application and / or driver 1120 can be executed on the computational resource 1104 in addition to the cross test. Similarly, ray process 1121 can be executed on computing resource 1108 and packet data 1116 can be stored in cache 1125 a for use by packet process 1121. Other packet data can be stored in the L2 1129, but it is preferable to store the packet data in the memory considered to be the highest speed, similarly to the ray data. The packet process performs most of the same functions that collection and other management logic performed in the above-mentioned drawings, i.e. records which ray intersects which GAD element and, for example, intersected GAD By having enough rays ready to be tested against the children of the element, for example, select a GAD element that is ready for testing.

  In this example, the packet process 1121 is centralized so that multiple ray identifiers and reference information to the shape (s) or data of the shape to be tested for intersections with the identified ray (s). Any one of them is issued to issue a packet. Each computing resource 1104-1107 that performs the intersection test receives the packet. For example, sequentially in multiple point-to-point links (further described below) or almost simultaneously in a shared bus type medium (which can be similar to the architecture of FIG. 10). Each computational resource 1104-1107 determines whether the respective localized ray data 1110 a-1110 n stores data relating to the ray specified in the packet, and if so, retrieves the data relating to that ray and tests And output the result.

  Since the result of the GAD element crossing is tracked by the packet process 1121, a communication mechanism that returns such a result to the packet process 1121 is acceptable. Such a mechanism can be selected based on the overall architecture of the system. Some exemplary approaches are described below and can include a separate indicator for each intersection found, or allow each test resource to inject the intersection result into a circulating packet.

  FIG. 12 illustrates a further embodiment of the organization of computing resources 1205-1208 with associated caches 1281-1284 storing ray data 1266a-1266n and packet data 1216a-1216n, respectively. Each computing resource 1205-1208 is connected to at least one other computing resource by queues 1251-1254. Ray process 1210 provides input to computing resource 1205 via queue 1250. Ray process 1210 communicates with application / driver 1202. Output 1255 from computing resource 1208 communicates with ray process 1210. Another output 1256 communicates with the computational resource 1205. Primitive and GAD storage 103 provides read access to its shape data for computational resources 1205-1208.

  Ray process 1210 receives or creates a ray for testing and forms a packet containing the ray identifier and ray data for the identified ray. The packet is transmitted to each of the computing resources 1205-1208 via the queues 1250-1254. Each computational resource 1205-1208 requires a portion of a ray in a given packet, in some embodiments one ray, and stores that portion of the ray in the computational resource ray data 1266a-1266n. . Other embodiments may include sending packets destined for specific computational resources 1205-1208, where ray process 1210 stores which ray data is stored in which localized ray data 1266a-1266n. Will be determined.

  After a ray is loaded into a localized storage device, the ray is then identified by a packet that contains only the ray ID, with no starting point and direction data. Such a packet further contains either reference information or shape data to the shape to be tested for the ray identified in the packet. In some embodiments, the data forming such packets is distributed among the localized memories 1281-1284 of computing resources 1205-1208. Thus, each of the computational resources 1205-1208 is for the ray being tested in the system at a given time so that information about which ray should be tested next for which shape is distributed. A portion of the packet data is maintained. Thus, each computational resource 1205-1208 can issue a ray ID and shape information packet to start testing a collection ready for testing.

  Each packet goes around the queue and computational resources and is then sent back to the originating computational resource along with the results of the cross test put into the packet. In one implementation, each computational resource 1205-1208 fetches shape data for the packet issued by each computational resource. For example, the computational resource 1205 has packets ready for testing (eg, a collection of rays for a given GAD element), and the computational resource then has such an association (eg, GAD It is possible to fetch the shapes to be tested by the children of the element, create a packet with data for each shape, and send each packet out of the queue 1251.

  In turn, the computational resource 1205 receives each packet sent by this computational resource after the packet has moved through the other computational resources. When received, each packet is the result of testing the shape in that packet for intersection with the specified ray stored / stored in the other computational resources 1206-1208 (reference information or Definition data). The computational resource 1205 can test any identified ray that the computational resource has locally in the ray data 1266a either before or after the other computational resources perform their respective tests. is there. Thus, ray definition data can be distributed among a plurality of high-speed memories linked to cross test resources, and test results can be collected in a distributed manner.

  Implementing the architecture according to FIG. 12 can take into account various characteristics of the physical system being used. For example, a queue is represented as sending a packet in one direction. However, benefits can be realized by sending packets in both directions (bidirectional queue or multiple queues). Similarly, FIG. 12 shows that packet data is distributed among computing resources, more distributed memory access to more L2 caches, and potentially other memory to larger memories such as main memory 103. Figure 2 illustrates enabling port access.

  When packets are centralized, a packet sent in one direction with data reference information can have, for example, data fetched by computational resource 1205, and a packet sent in the other direction with data reference information May have data fetched by the computational resource 1208. This situation can be generalized to provide entry points in such a ring bus architecture (one-way or two-way).

  As will be apparent from the disclosure, the queue interconnects the cross-test resources with one or more queues for introducing a new ray for cross-test into a system that includes multiple cross-test resources. And queues. In some cases, a queue that introduces a new ray can accommodate ray definition data (eg, a queue that waits to store data in a cache connected to a cross-test resource). Such queues can be implemented as a list in main memory that stores ray definition data. The queue that interconnects the cross-test resources that carry packets preferably contains only ray identifiers and no ray definition data.

  FIG. 13 shows that the computational resource can be implemented using the core of the chip so that the computational resource 1205 is one core and the computational resource 1206 is another core, and the queue 1251 is an inter-core communication. FIG. 2 illustrates a portion of a potential implementation of the system 1200. Also illustrated is an intermediate L2 cache 1305 that can store ray data along with shape data. As described with respect to the previous figure, the L2 cache 1305 can store several portions of scene geometry and acceleration data, and as long as such data is stored, the slashing of the ray data There is no increase (i.e., ray data is preferably preferred in cache storage).

  FIGS. 14a-14c illustrate various relationships that can each be queued by various implementations of the exemplary system. In general, communication between computing resources is not required to be serial or 1: 1. For example, FIG. 14a illustrates that one input 1404 can be entered into both queues 1405 and 1406 that are dedicated to one calculation 1407 and 1408, respectively. For example, if calculations 1407 and 1408 are performed on a single physical chip, input 1404 can be a chip level input and each queue 1405, 1406 can be used for a specific core. It is.

  FIG. 14b shows that a single input can input data into multiple cores, each of the multiple cores can input data into calculations 1407, 1408, and each of the calculations can similarly send data to the opposite queue 1406, 1405. It is illustrated that transmission can be made to each. FIG. 14 c illustrates that queue 1411 can receive input 1410 and can provide output to both calculations 1407 and 1408. Thus, FIGS. 14a-14c illustrate that various queuing strategies can be implemented to convey packets in accordance with these aspects.

  FIG. 15 illustrates that there are multiple levels of cache hierarchy (eg, various combinations of level 1 caches 1502 and 1503, level 2 cache 1504, and ray data may be provided). For example, ray data 1507 can include disjoint subsets of ray data 1505 and 1506 and ray data that does not exist in either 1505 or 1506. Ray data 1505 and 1506 can change dynamically; for example, if one queue enters data into one or more computational resources (FIG. 14c), the ray data can be any ray data. The dynamic allocation of rays stored in ray data 1507 to 1505 or 1506 can be reflected.

  FIG. 16 illustrates in greater detail an exemplary implementation of the queue 1251 and the data that the queue can store. Packets 1601a to 1601n are shown, each packet having a respective ray identifier 1605a to 1605p, 1606a to 1606p, and 1607a to 1607p, and corresponding hit information fields 1610a to 1610p, 1611a to 1611p, and 1612a to 1612p. . Packet 1601a contains data 1615a for shape 1, packet 1601b contains data 1615b for shape 2, and packet 1601n contains data 1615n for shape n. As can be seen, the queue 1251 is data input by the computational resource 1205 and read by the computational resource 1206. Of course, various other queuing strategies, some of which are illustrated in FIGS.

  Queuing does not mean a first-in / first-out requirement for a ray tested on any given computational resource, as that term is used herein. In general, the rays identified in a given packet are approximately evenly distributed among localized ray stores for different computational resources, so that a given packet is between some number of computational resources. Should find a ray of that packet distributed across the network, so that parallelism is achieved for each packet. If a certain number of packets for one packet are to be tested in one computational resource, a bubble can be formed that does not have a ray that another computational resource intersects for that packet. Such a bubble can be filled by other calculations including other cross tests of other packets. In some embodiments, each computational resource can maintain the state of multiple threads and switch threads with a predetermined packet stall condition. As long as critical data for each cross-test between packets can be maintained in the register, a net throughput advantage should be realized.

  To summarize in part the operational aspects of the exemplary system, each computational resource acts in response to receiving a packet. When a packet arrives from an input queue for a particular computational resource, the computational resource looks up the ray identifier in that packet and which rays identified in that packet are in their memory for those rays. Determine whether the data is stored. In other words, a packet does not have a priori knowledge of which computational resources contain ray data for the ray specified in the packet or have fast access to ray data. It can be formed using an identifier. In addition, each computational resource does not responsively attempt to obtain ray data for all the rays identified in the packet, and the computational resource is identified in the packet in its local high speed memory. It only determines whether it has ray data for any of the rays that were made, and only tests that ray (s) for intersection with the identified shape (s).

  FIG. 17 is intended to describe an aspect of how a packet can be processed in an exemplary computing resource. FIG. 17 illustrates the packet 1601a entering the computational resource 1206. FIG. The computing resource 1605a uses the ray identification information from the packet 1601a to inquire about the ray data (for example, ray 1605a has ray ID 31 and collates with ray ID 31 in ray data storage device 1266b). The starting point and direction associated with ray ID 31 are retrieved via 1290. Similarly, if shape data is specified in a packet, it is acquired 1715 from memory resource 1291 where shape data is currently stored. If shape data is provided in the packet, the shape data is used directly. Next, ray 31 is tested 1720 for intersection with shape 1 (or the shape defined by the retrieved data).

  If the tested shape is a GAD element (1725), the effect of such an intersection test is to determine a small subset of scene primitives that may still have the potential to intersect the tested ray. Thus, the positive hit result is written back 1726 to the packet in location 1610a for the ray identifier, ie, the identifier of ray 31. In some implementations, packet emission can track which ray IDs are emitted in which order in the packet, so only the results need to be written back, and the implicit order is the same as radiation. is there. Thus, after passing through the tester, packets exiting the resource can process the test results.

  Conversely, if the tested shape is a primitive (1733), the nearest neighbor intersection decision (1731) can be implemented to determine if this detected primitive is closer than the previous primitive. . If so, the intersected primitives and optionally the intersection distance can be stored with the packet or otherwise output. Since a given ray can be associated with multiple packets (ie, multiple GAD elements at the same time), the count can be maintained 1733 over the period each time a ray is associated with a GAD element, so the count is still It is decremented each time so that it can be determined when it is not present in other packets that need testing, allowing the memory dedicated to that ray to be freed up for the introduction of another ray.

  In summary, the data associated with each ray in the ray's local high-speed storage preferably includes the nearest detected primitive intersection identifier, the primitive reference information and the parameterized distance to that intersection, and Can be included. Other data associated with each ray includes a count of GAD element ray collections in which the ray exists. After each collection is tested, the count is decremented, and when another collection is created, the count is incremented. When the count is zero, then the primitive identified as the nearest intersection is the primitive that is determined to have intersected the ray.

  FIG. 18 relates to an exemplary single instruction multiple data (SIMD) architecture that allows a packet to identify the start of a geometric strip for testing. In an embodiment, nodes in the GAD element graph are connected by edges to one or more other nodes, each node representing an element of geometry acceleration data, such as a sphere or an axial alignment bounding box. In some embodiments, the graph is hierarchical, so when testing a given node, it is known that the children of a given node will delimit the selection of primitives that are also bounded by the parent node. It has been. The GAD element ultimately delimits the selection of primitives.

  In the implementation, the character string of the acceleration element that is a child of the predetermined element can be specified by the memory address of the first element in the character string. Thus, the architecture can provide a predetermined data stride length at the beginning of the next element. A flag can be provided to specify the end of the string of a given element that is a child of a given node. Similarly, a strip of primitives can be identified by a starting memory address using a known stride length to define the next primitive. More specifically, for a triangle strip, two consecutive vertices can each define a plurality of triangles.

  FIG. 18 is used to illustrate aspects of a SIMD architecture similar to the SIMD architecture illustrated in connection with FIG. In the present embodiment, a plurality of ray identifiers 1605a to 1605n, a space for selectively storing received intersection test results 1610a to 1610n, shape definition data of a shape to be tested (for example, a triangle primitive), a shape identifier, Alternatively, a packet 1601a storing shape data including an identifier 1815a for starting a strip is received.

  This exemplary architecture may be appropriate when a smaller number of more powerful separate processing resources with a larger cache are used for cross-testing. Here, each of the separate processing resources generally has approximately the same number of rays in the processing resource's local storage as can be tested by the SIMD instruction (as opposed to FIG. An embodiment is shown in which each cache preferably has one ray per collection). For example, if 4 rays can be tested at the same time in the SIMD execution unit, for each packet sent in sequence, about 4 rays are statistically stored in the local storage for that SIMD unit. It is preferable to possess. For example, if four separate processing resources are provided and each processing resource has a SIMD unit capable of testing four rays, a packet can have about 16 rays referenced. It is. Alternatively, a separate packet is provided for each processing resource comprising a SIMD unit, so for example, a packet can carry four referenced rays and there are four times as many SIMD units. .

  In one embodiment, the first computational resource 1205 that receives the packet 1601a can use the identifier 1815a to obtain data for the strip of shapes. Next, each ray referenced in packet 1601a stored in ray data 1266a is tested in computing units 1818a-1818d. In the shape strip embodiment, shape strip 1816 is removed and includes shapes 1-4. Each shape can be streamed through each computation unit 1818a-1818d, testing each shape for intersection with a ray loaded into that computation unit. For each strip shape, the computational resource can create a packet (packet 1820 shown), each storing the results of testing a ray against one of the shapes.

  Alternatively, separate bits can be provided in the result section of each ray to accept the cross result, and one packet can be passed. In order to avoid re-fetching from slow memory, this approach can be used if multiple computational resources can share L2, or fetching by the first computational resource will similarly transfer shape data to other computational resources. If caused, it is expected to be most appropriate. For example, a DMA transaction can have multiple targets, each of which is a different computational resource that requires a predetermined shaped stream to be tested, and an appropriate memory transaction transaction for some implementations. It is an example of a model. The main consideration is to reduce fetching the same data from the main memory 103 more than once.

  As described above, each intersection test resource determines which ray identifier stores ray data in its ray data store. For any such ray, the ray start point and direction are retrieved. To date, embodiments have assumed that the test resource can test a given identified ray with one or more identified shape sequences. However, if the processing resources can test multiple shapes for intersection with a given ray without substantial extra latency, or if multiple rays can be tested with one shape, or both May be a combination of In FIG. 18, the SIMD architecture is shown, and within one computing resource configured for intersection testing, each of the four SIMD units tests a different ray with respect to the intersection with the shape provided sequentially to this SIMD unit. Is possible. A sequence of shapes can be fetched based on the shape strip reference information used as an index into the scene data store 340 to initiate an initial retrieval of the sequence of shapes, one by one or Four shapes are tested in the calculation unit 123.

  Preferably, rays are collected in the collection based on the detected intersection between the collected rays and elements of the acceleration data. Thus, in this embodiment, different rays are tested in each SIMD unit against four different shapes, and the computing resource that houses the SIMD unit reformats the result into a packet of rays each referring to the shape. Can be

  Other architectures that use SIMD units can instead fetch multiple rays collected in a collection. As described above, such a ray will then be cross-tested against a shape related to the shape associated with the collection. For example, there can be 16 or 32 shapes connected to the collected control shapes. The first subset of these shapes can be loaded into different SIMD units and the collected rays can be streamed within each SIMD unit (ie, the same Ray passes through each SIMD unit at the same time). The result packet can be formed independently by each SIMD unit and the next shape is loaded into the SIMD unit. The ray can then be recycled in the SIMD unit. This process can continue until all relevant shapes have been tested against the collected rays.

  FIG. 18b illustrates the time-based course of the calculation unit 1818a for such an embodiment. At time 1, shape 1 and ray 1 are tested. Shapes are numbered from 1 to q, and rays from the collection are numbered from 1 to n. At time n, shape 1 and ray n are tested. At the start of the next cycle (time point q-1 * n + 1), the last shape starts testing in the calculation unit 1818a.

  FIG. 19 illustrates how aspects of how packets 1905 can be distributed among computing resources for cross-testing and computing resources 1910 that maintain memory for the rays in the packet 1905 associated with the identified shape. Figure 5 illustrates the test results in which each is finally fused. FIG. 19 illustrates an exemplary system state during processing. In particular, each computational resource 1910-1914 receives ray identification information for a ray stored in memory accessible by the computational resource, tests its identified shape for intersection, and identifies identified hit 1915, Results 1915 to 1919 including 1917 and 1919 are output. Since either a hit or a miss can be the default behavior, for example, a miss can not be specified by a positive value, or the default value in a packet can be set to miss It is. After testing, the computational resource 1910 collects at least hit information, where the computational resource 1910 manages all packet information in the test system or a subset of all this packet information including this unique shape. It is possible that

  The exemplary organization in memory 1966 represents a logical organization of shape reference information mapped to a certain number of ray IDs, ie, ray A, ray B, etc. Further illustrated is that some slots in the row associated with reference number 1 (ie, reference information to the shape under test) are empty. Therefore, when the calculation resource 1910 receives the hit result, the calculation resource first inputs data into the remaining empty slot of the predetermined reference number 1, and then the ray n is the reference number 1 in the memory 1966. Starting a new packet for it is illustrated in 1966. This time, since the packet for reference number 1 is full, it can be determined that this packet is ready to be tested. In some embodiments, a child GAF element of the shape referenced by reference number 1 is fetched and a packet is formed using all of the rays associated with reference number 1 in each packet. For example, since there can be 32 children with reference number 1, 32 packets can be formed, and packets 1922-1924 are shown. In some embodiments, computing resource 1910 may fetch data defining child shapes and store the data in packets 1922-1924. Alternatively, reference information can be provided that allows other computing resources to fetch such data.

  In some cases, computing resource 1910 can further store a ray identified within the created packet, so that the ray can be tested first before sending the packet. In such a case, the computing resource 1910 can store the shape data that has already been fetched in the transmitted packet. As described in connection with FIG. 12, implementations can send such packets to one or more other computational resources, eg, bi-directional queuing, or communication in any direction Can be.

  FIG. 20 is intended to illustrate some examples of how the method according to the above aspect can be implemented. The packet is released 2005 with the shape information, ray ID, and the location where the hit information can be written back, and the hit information is now zeroed or otherwise “don't care” Can be done. The first test is performed 2006 on the ID of ray 1 and is found to hit, so 1 is written to the packet, the packet is communicated for the second test 2007, and ray 3 is the second time. Is found to be localized for the test, and a zero is found, so 0 is written (or maintained) and the hit information from test 2006 is carried forward in the packet ( That is, the rays in the packet can be tested out of order). A third test is performed on ray 2 and found to hit. This example shows that rays in a packet can be tested regardless of the order in which they appear in the packet, and the order of testing determines which tester has the ray data for a given ray ID. Depends on the best access possible. The test continues until all ray IDs have been tested (2009). The packets can then be merged, i.e. only hit information needs to be maintained. Such a fusion can be performed on the computational resource that released the packet. New hit results can be combined with hit results from existing packets (see FIG. 19). Thereafter, a determination 2025 is made whether the collection of rays in the packet is ready to be tested (eg, based on full status). If not ready, a different packet can be processed 2040. If ready, the child shape of the shape associated with the packet can be fetched 2030, the parent node 2041 is the shape, and the child of that node is identified, for example, by 2042. A new packet can then be generated 2035 for each ray identifier and child shape from the packet associated with the parent.

  21 and 22 serve to summarize the method aspects described above in a system in a situation that can be used to implement the method aspects described above. In particular, FIG. 21 shows that method 2100 uses primitive definition and GAD elements to be stored in main memory (2105) and ray definition data (eg, start and direction information) to define a ray for intersection testing. Including a step (2110). Each ray is identified using an identifier (2115). The subset of ray definition data is stored in a localized memory associated with each processing resource of the plurality of such resources. Rays are scheduled for testing by distributing (2125) these ray identifiers and shape data among the processing resources. Rays are tested 2130 in processing resources where definition data for these rays is stored locally. In some situations, each ray can have definition data in only one local memory.

  An indication of the intersection between the ray and the primitive is communicated from the first subset of computing resources to the second subset (2135). The second subset shades the intersection (2140). Shading is distributed 2145 between the memory in which the definition data is localized, and can preferably result in new rays replacing the definition data of the finished ray. These rays are then tested as described above. A subset of computational resources can be implemented by instantiating or otherwise allocating computational resources, including instantiating threads that run on multithreaded processors or cores. The allocation can vary over time and it is not necessary to be a static allocation between cross-testing resources and shading resources. For example, a core executing a cross-test thread can fill the memory space with some number of indications of ray crossings with primitives and finish a series of cross-tests, after which the core It is possible to switch to shading.

  Some of the embodiments described above are primarily described in terms of testing GAD elements for intersection, and the results of such tests are related to the grouping of smaller primitives (relationships between ray IDs and specific GAD elements). ) Grouping of rays. Finally, it is disclosed that the GAD element identified by the test delimits the primitive to be tested against the ray identified as being part of the group associated with that GAD element. For packets with primitives, the result of the intersection test is that the ray with other data, usually defining the ray, considered by tracking at least the nearest such intersection detected for a given ray. / Primitive intersection identification information (for convenience).

  Next, after a given ray is tested against the entire scene, the nearest detected intersection for each ray, if any, starts the application or driver or shading process with the ray ID. Thus, such a result can be sent back to another process that can use it. Ray identifiers can be returned via a queuing strategy, such as a queuing strategy according to various embodiments herein (i.e., which computing resource has a shading code for a particular intersection). It is not necessary to specify whether it is running, and the specific intersection test resource does not detect the intersection tested by a given shading resource). In some intersection tests, barycentric coordinates are calculated for the intersection test, and these coordinates are made available for shading as needed. This is an example of other data that can be transmitted from the intersection tester to the shader.

  In general, any of the functions, features, and other logic described herein can be implemented using various computing resources. Computing resources can be threads, cores, processors, fixed function processing elements, and the like. Similarly, other functions, such as collection or packet management, can be localized to one computing resource or can be distributed among multiple computing resources, threads, or It can be provided or implemented as a task (eg, multiple threads distributed among multiple physical computational resources). The task basically involves identifying an ongoing packet that holds cross test results for a shape having a collection managed by that computing resource.

  Similarly, the computing resource being used for the intersection test may host other processes, such as a shading process used to shade the detected intersection. For example, a processor that performs a cross test can also execute a shading thread. For example, in a ring bus implementation, if the queue for one processing resource does not currently have a packet for intersection testing, the data processing resource instead starts a thread that shades the previously identified intersection. It is possible. The main difference is that there is no general relationship between or having a cross test thread on a given processor, which further drives the shading thread for ray crossing detected by that thread. . Instead, queued ray / primitive intersections provide input to the shading thread, so the mapping between intersection test resources and shading resources can be in any direction, so different hard It is possible for a wear unit or software unit to cross test and shade the same ray.

  Similarly, various queues and other interfaces that mediate communication between different functions (eg, between cross test resources, and between cross test and shading) are physical resources available to implement memory. Can be implemented in one or more memories according to any of a variety of buffering strategies that can be selected based on considerations related to. The queue can be controlled by the originating resource or the terminating resource. In other words, the called party can listen to the data on the shared bus and take the data it needs, or the data can be received by memory mapping, direct communication, etc. Can be addressed.

  As a further example, if the core can support multithreading, one thread can be dedicated to shading and another thread can be dedicated to cross processing. However, care must be taken to avoid cache non-coherence resulting from fetching textures and other shading information at the expense of maintaining ray data, while still prioritizing cache allocation for cross-test resources. It is.

  The advantage of this architecture is thought to be that the caching requirements for shape data are relaxed, thus reducing cache coherence considerations for that type of data. In fact, in some implementations, little effort should be spent on keeping certain shape data available or predicting when shape data will be used again. Instead, when a given packet of ray IDs is ready for testing, shape data for these packet (s) can be obtained from the fastest memory, then the shape data is stored, In general, existing workloads that process other packets block the latency incurred during such fetching. After testing these shapes for intersection, shape data can be allowed to be overwritten.

  Any of the queues identified herein are known in shared memory resources, in SRAM, as a linked list, as a circular buffer, in sequential or striped memory locations in memory, or in queue technology. Can be implemented in other functional forms. The queue is not a requirement, but is operable to maintain packet ordering so that the first packet arrives first. In some implementations, each computational resource is given the ability to inspect a predetermined number of packets in each computational resource queue to determine whether it is advantageous to process the packets out of order. Can be done. Such an implementation is more complex than an ordered system, but can be provided as needed.

  Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform or otherwise configure a particular function or group of functions. Computer-executable instructions may be, for example, binary, intermediate format instructions such as assembly language, or source code. Although some subject matter is described in language specific to an example of structural features and / or method steps, claimed subject matter is not necessarily limited to those described features or acts. Should be understood. On the contrary, the described features and steps are disclosed as examples of components of a system and method within the scope of the appended claims.

  Thus, various embodiments of computing hardware and / or software programming and embodiments of how such hardware / software can communicate with each other have been described. These embodiments of such a communication interface with hardware or hardware configured using software provide a means to achieve their respective functions. For example, the means of cross-testing according to some embodiments herein includes (1) localized storage of ray definition data, each provided with ray identifier (s) and shape data. Can include any of a plurality of independently operable computing resources operable to test these ray (s) for intersection with a shape.

  For example, a means for managing a collection of rays may include tracking a group of ray identifiers and associating the group with an element of acceleration data, a computing resource configured using programming, or an FPGA or ASIC, or Including or forming a packet comprising ray identifiers and either reference information or shape data to a shape determined by a shape associated with a group of ray identifiers. Is possible.

  For example, the function described above may terminate the intersection test and communicate the identifier of the ray that intersected the primitive via a queue for processing in a computing resource configured to shade these intersections. Including. Means for performing this function may include a hardware queue or a shared memory space organized as a queue or list, such as a memory configured as a ring buffer or linked list. Thus, this means may include programming and / or logic that causes the ray identifier and primitive identifier to be obtained from the next slot in the queue or a designated slot, or a location in memory. . The controller can manage the queue or memory to maintain the next read position and the next write position for sending and receiving ray and primitive identifiers. Such queuing means can further be used to interface the cross-test resources together when the cross-test resources communicate a ray identifier and a packet of shape data to each other. Such queuing means can further be used to receive a ray identifier for a new ray waiting for the start of an intersection test. Thus, each such more specific queuing function can be implemented by these means or equivalents.

  For example, the functions described above include shaded intersections specified between rays and primitives. This functionality can be implemented by means including computing hardware configured with programming associated with the intersected primitives. Programming, to determine primitive is required what other information to determine the effect on the light hits the primitive, texture computing hardware, such as procedural geometry deformation Get data. Programming can cause new ray radiation to be further cross-tested (eg, shadow rays, refraction rays, reflection rays). Since programming causes such ray emission, it is possible to interface with an application programming interface. Rays as defined by the shading program can include start and direction definition information, and the controller can determine the ray identifiers of such defined rays. Fixed function hardware can be used to implement some of these functions. However, it is preferred to allow programmable shading using computing resources that can be configured according to code associated with the intersected primitives and / or other code as required or required.

  For example, another feature described above may be a distributed cache that maintains a master list of rays that are being tested for intersections and / or waiting for intersection tests, and a subset of these master rays associated with the means of intersection tests. Distributed among the memory. Such functions include a processor or group of processors that can use an integrated or separate memory controller to interface with memory that stores data under the control of programming that implements these functions. It can be implemented using means. Such programming can be associated with the cross test function or otherwise incorporated at least partially in the driver that controls the cross test function.

  The functions and method aspects described above and / or in the claims may be implemented on a special purpose or general purpose computer including computer hardware, as described in detail below. Such hardware, firmware, and software can also be embodied on a video card or other external or internal computer system peripheral. Various functions can be provided in a customized FPGA or ASIC, or other reconfigurable processor, but some functions can be provided in a management or host processor. Such processing functions include personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, game consoles, network PCs, minicomputers, mainframe computers, mobile phones It may be used in telephones, PDAs, pagers, etc.

  In addition, communication links and other data flows represented in diagrams such as links 112, 121 and 118 in FIG. 1 and similar links in other diagrams can vary in various ways depending on the implementation of the specified function. Can be implemented. For example, if the intersection test unit 109 includes multiple threads running on one or more CPUs, the link 118 may be configured with such CPU (s) and appropriate to allow access to the ray data storage device 105. Physical memory access resources of various memory controllers, hardware / firmware / software. As a further example, if cross test area 140 is on a graphics card connected to host 140 by a PCI express bus, links 121 and 112 are implemented using the PCI express bus.

  Cross testing as described herein generally exists in the context of large systems and system components. For example, the processing can be distributed over a network such as a local or wide area network, otherwise it can be implemented using peer-to-peer technology or the like. The division of tasks can be determined based on the desired performance of the product or system, the desired price, or some combination thereof. In embodiments in which any of the above units is implemented at least in part by software, the computer-executable instructions indicating the unit function are, for example, a magnetic disk, an optical disk, a flash memory, a USB device, or a NAS or SAS device. It can be stored in a computer-readable medium such as a network-type storage device. Other suitable information such as data for processing can also be stored on such media.

  Similarly, in some cases, terminology will be used herein because it is believed that the gist will be reasonably conveyed by one of ordinary skill in the art, such terminology may be used in the disclosed examples and It should not be considered to implicitly limit the scope of implementation encompassed by other aspects. For example, a ray is sometimes referred to as having a starting point and direction, each one of these separate items being a point in three-dimensional space to understand aspects of the present disclosure, In addition, it can be considered that each direction vector in the three-dimensional space is expressed. However, any of a variety of other ways to represent a ray can be provided and remain within the scope of this disclosure. For example, the ray direction can be expressed in polar coordinates. It is also understood that data provided in one format can be converted or mapped to another format while maintaining the significance of the data information originally represented. Will be.

  Similarly, a number of embodiments are illustrated and described in the preceding disclosure, each embodiment stored in a system, method and computer-readable medium embodied in the claims. Fig. 3 illustrates various aspects of computer-executable instructions. Naturally, not all embodiments may illustrate every aspect, and examples do not illustrate the exclusive components of such aspects. Instead, the aspects illustrated and described in connection with one drawing or example can be used, or can be combined with the aspects illustrated and described with respect to other figures. is there. Accordingly, those skilled in the art from this disclosure will not be construed as limiting the disclosure above with respect to the components of the claimed embodiments, but rather the scope of the claims is the breadth and scope of the embodiments of the invention herein. You will understand defining.

Claims (12)

A method performed by an apparatus for cross-testing rays in a scene,
By one or more processors
Tracing a ray of a first ray group to a plurality of points in a hierarchical acceleration structure, wherein each of the points of the hierarchical acceleration structure includes a primitive of a scene being raytraced; Showing the boundaries of the group in a three-dimensional space ;
Tracing a ray of a second ray group to at least some of the plurality of points in the hierarchical acceleration structure;
Combining the ray of the first group and the ray of the second group into a third ray group, respectively, based on the commonality of the points of the hierarchical acceleration structure in which rays are traced;
Test one or more of the third ray groups simultaneously for intersections with nodes that are children of respective points in the acceleration structure associated with each of the third ray groups being tested. Continuing to trace ray groups from at least some of the third ray groups further into the hierarchical acceleration structure.
A method implemented by an apparatus. A method performed by an apparatus for cross-testing rays in a scene,
By one or more processors
Tracing a ray of a first ray group to a plurality of points in a hierarchical acceleration structure, wherein each of the points of the hierarchical acceleration structure includes a primitive of a scene being raytraced; Showing the boundaries of the group in a three-dimensional space ;
Tracing a ray of a second ray group to at least some of the plurality of points in the hierarchical acceleration structure;
Combining the first group of rays and the second group of rays into a third ray group, respectively, based on the commonality of points of the hierarchical acceleration structure in which the rays are traced;
The third ray group is tested by simultaneously testing rays from one of the third ray groups for intersections with a plurality of nodes that are children of points in the acceleration structure associated with each of the third ray groups. Tracing ray groups from at least some of the ray groups further into the hierarchical acceleration structure;
Tracing a ray of a first ray group to a plurality of points in a hierarchical acceleration structure, wherein each of the points of the hierarchical acceleration structure includes a primitive of a scene being raytraced; Showing the boundaries of the group in a three-dimensional space ;
Tracing a ray of a second ray group to at least some of the plurality of points in the hierarchical acceleration structure;
By simultaneously testing a ray for intersection from the one or more points of the plurality of points with the plurality of nodes being one or more children of the plurality of points in the acceleration structure Tracing a ray group from at least some of the plurality of points in the hierarchical acceleration structure to the hierarchical acceleration structure;
A method implemented by an apparatus comprising: Selecting a ray group from the third ray group for further movement in the hierarchical acceleration structure;
The step of selecting determines which third group is ready to move further, and the decision is different if none of the collection is ready to move further Including repeating the move and combination for a ray group,
A method performed by the apparatus of claim 1. The tracing is a series of hierarchical acceleration structures that are identified based on each of the points of the acceleration structure associated with the ray group having those rays. Carried out by testing at the same time as the element,
A method performed by the apparatus of claim 1. The points of the hierarchical acceleration structure include a selection from a capacity defined by cutting the plane of the axial alignment bounding box, sphere, and kD tree;
A method performed by the apparatus of claim 1. A device that controls the tracing of rays in a scene,
A processor coupled to a memory and a tester capable of testing a ray for intersection with a shape;
The processor is
Control the storage of data in the memory;
In the memory, data associated with the first collection of rays with a first region of the scene in which the first collection of rays is cross-tested and associated with each portion of the first region and a plurality of second collection of rays Store the data you want to
For the intersection with the first region of the scene, receive the test results for each ray of the first collection of rays and indicate additions for each ray found to intersect the first region of the scene By storing data in the memory, the ray is added to each of the plurality of second collections and intersects with each of the portions of the first region of the scene associated with each of the second collections. Wait for the test,
By receiving the result of the cross test from the tester,
A device characterized by that. The processor is for logically separating memory into a plurality of locations that can be referenced based on identifiers for regions of the scene associated with the plurality of second collections and the rays of the first collection;
The apparatus according to claim 6. The processor identifies an identifier of the ray in each of the first collection and the plurality of second collections based on a hash value of the identifier for the region of the scene associated with such ray collection. For storage in the memory at a respective location for each possible collection;
The apparatus according to claim 7. The processor operates to hash the identifier for the region of the scene to identify candidate locations in the memory where a collection of rays associated with the region of the scene can be stored.
The apparatus according to claim 7. The processor is for scheduling ray-crossing tests of the first collection and the plurality of second collections by selecting a whole collection and a mixture of collections less than the whole;
The apparatus according to claim 6. The processor increases the number of collections less than the total in response to determining that the amount of space consumed in memory to store the collection of rays exceeds a usage criterion;
The apparatus according to claim 10. The processor is for outputting an entire selected collection and a mixture of less than collections to a collection ready list, reads a collection ray identifier from the ready list, and comprises a plurality of testers Further comprising an arbiter for distributing said identifiers of rays between test cells;
The apparatus according to claim 10.