KR20100128337A - Architectures for parallelized intersection testing and shading for ray-tracing rendering - Google Patents

Abstract

In one example, the ray tracing method for the scene includes using a plurality of cross test resources coupled to the plurality of shading resources, which are collectively communicateable via a link / queue. The cue generated from the test for shading contains individual ray / circular intersection identifications, which include ray identifiers. The shading of the test queue includes an identifier of the new beam for testing, and the data defining the beam are stored separately in memory distributed among the cross test resources. The ray definition data may be maintained in distributed memory until the ray completes the crossover test and may be selected for testing multiple times based on the ray identifier. Acceleration shaped structures can be used. Packets of ray identifiers and shape data may cycle between cross test resources, each resource identified in the packet, and the ray of definition data being tested in the memory being tested. The accelerated shape test results allow the collection of light rays based on the crossed shape and the closest detected light / circular intersections are identified by queuing the fanatic identifier for shading.

Description

 ARCHITECTURES FOR PARALLELIZED INTERSECTION TESTING AND SHADING FOR RAY-TRACING RENDERING}

The present invention relates to a method of rendering two-dimensional representations from a three-dimensional scene, and more particularly to a method of using ray tracing to accelerate rendering a photorealistic two-dimensional representation of a scene.

Methods of rendering photorealistic images using ray tracing are known in the computer graphics art. Ray tracing is known to produce photorealistic images (including realistic shadows and lighting effects). This is because ray tracing can model the physical behavior of light's interaction with components in the scene. However, ray tracing is known computationally intensive, and even now, even in art graphics workstations, it takes considerable time to render complex scenes using ray tracing.

Ray tracing usually involves obtaining a scene description consisting of geometric primitives, such as triangles, that depict the surfaces of the structures in the scene, and starting with the camera, numerous possible interactions with scene objects. Actions involve modeling how light interacts with the circles in the scene by tracing the rays until they exit the scene without blocking or intersecting the light source.

For example, a scene may include a car on a street, along with a building located on either side of the street. The car in such a scene can be defined by a large amount of triangles (eg, one million triangles) proximate a continuous surface. The camera position at which the scene is visible is defined. Rays from cameras are often called primary rays, and rays emitted from one object to another, for example to enable reflection, are called secondary rays. An image plane of a selected resolution (eg, 1024x768 for SVGA display) is placed at a selected location between the camera and the scene.

The simplest ray tracing method of tracking algorithms involves casting one or more rays into the scene from each camera through each pixel of the image. Each ray is then tested for each circle that constitutes a scene to identify primitives that the ray intersects, and determines the effect of the circle on the ray that reflects and / or diffracts, for example. . This reflection and / or diffraction causes the light to travel in different directions and splits the light into several secondary rays that take different paths. All of these secondary rays are then tested against scene primitives to determine the circles with which they intersect, and then repeat repeatedly until secondary (and tertiary, etc.) rays are canceled by, for example, out of scene or light source collision. . While all these rays / circles are determined, a tree is created that maps them. After the ray is canceled, the contribution of the light source is traced back through the tree, and the effect on the pixels of the scene is determined. As can be appreciated, the computational complexity of testing 1024x768 rays (for example) against the intersection with millions of triangles is computationally expensive, and these numbers of rays are the materials that use ray intersection. It does not take into account any additional rays generated as a result of the intersection.

Rendering a scene using ray tracing is called an "embarrassingly paralle problem," because the color information accumulated in each pixel of the resulting image can be accumulated independently of the rest of the pixels in the image. . Thus, even though there is constant filtering, interpolation, or other processing for the pixels before outputting the final image, the color information for the image pixels can be determined in parallel. Thus, it is simple to divide the task of ray tracing an image for a specified 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 multiple threading, in other cases involving a computer cluster or computer core cluster connected on a LAN. With respect to this type of system, the designated processing resource (e.g., thread) may be an example for processing allocated rays or groups of rays through the completion of cross testing and shading. In other words, with the property that pixels can be rendered independently of one another, rays known to contribute to different pixels can be split between threads or processing resources to be cross-tested, and then these intersections It is shaded and writes the result of this shading operation to the screen buffer to be processed or displayed.

Some algorithmic approaches have been proposed to solve this kind of problem. One such approach is described by Matt Pharr et al in "Rendering Complex Secene with Memory-Coherent Ray Tracing" (Proceedings of SigGraph (1997), hereinafter referred to as "Pharr"). Pharr describes a method of segmenting a scene to be ray traced into geometric 3D pixels (voxels), where each geometric voxel is a cube surrounding a primitive (eg, triangle). Pharr also describes a method of superimposing a scheduling grid, where each component of the scheduling grid is a scheduling voxel that may overlap with a portion of the geometric voxel (ie, the scheduling voxel is different from the cube of the geometric voxel). Each scheduling voxel has an associated ray queue, which depends on the rays currently present inside the scheduling voxel, i.e. the rays enclosed within the scheduling voxel, and which geometric voxels overlap the scheduling voxel. Contains information about

 Pharr is tested for the intersection with a circle in a geometric voxel where the rays in the associated queue are surrounded by the scheduling voxel when the scheduling voxel is processed. If the intersection between the ray and the circle is found, a shading operation is performed, which results in the ray being added to the ray queue. If no intersection is found in this scheduling voxel, the beam proceeds to the next non-blank scheduling voxel and is placed in the beam queue of the scheduling voxel.

Pharr believes that the goal of this approach is to adapt the scene's geometry to a cache typically provided by a general purpose processor, so that if the lifespan geometry in each scheduling voxel fits into the cache, the cache will be State that you are not subjected to excessive trash (load) during the cross test.

Pharr also describes that by queuing a ray for testing in a scheduling voxel, more work can be performed on the cache when the prototype is fetched into the geometric cache. If the next processing is to a multiple scheduling voxel, the scheduling algorithm may select a scheduling voxel that minimizes the amount of geometry that needs to be loaded into the geometric cache.

Pharr recognizes that the proposed regular scheduling grid does not work well when a particular scene has non-uniform complexity (eg, high density of prototypes in a portion of the scene). Pharr assumes that adaptive data structures such as octrees can be used in place of regular scheduling grids. The octree introduces spatial subdivision within the three-dimensional scene by subdivisioning at each level of the hierarchy along each major axis of the scene (e.g., the x, y, and z axes), thereby octet subdivision. These eight small sub-volumes are produced, which can for example produce eight smaller sub-volumes each. In each sub-volume, a divide / do not divide flag is set to determine whether or not the sub-volume is further divided. These sub-volumes indicate partial partitioning until the number of primitives in the sub-volume is small enough to test. Thus, with respect to the octree, the amount of subdivision can be controlled depending on how many prototypes exist in a particular part of the scene. In this way, the octree can change the degree of subdivision of the volume to be rendered.

A similar approach is described in Pfister US Pat. No. 6,556,200 (hereinafter referred to as 'Pfister'). Pfister describes a method of dividing a scene into a plurality of scheduling blocks. Ray queues are provided in each block, and the rays in each queue are ordered spatially and temporarily using a dependency graph. Rays are tracked through each scheduling block in the order defined in the dependency graph. Pfister consults Pharr's paper, adds the purpose of Pfister to render one or more single graphical prototypes (eg, not limited to triangles), and to devise more complex scheduling algorithms for scheduling blocks. Pfister also considers the sub-parts on the stage of the scene figure at multiple cache levels in the memory hierarchy.

Another approach relates to packet tracing, and a general reference to such packet tracing is described by Ingo Wald, Philip Slusallek Carsten Benthin et al. "Interactive Rendering through Coherent Ray Tracing (Proceedings of EUROGRAPHICS 2001, pp 153-164, 20 (3), Machester, United Kindom (Sep. 2001). ”In these references, packet tracking is similar to tracking packets of rays with similar origins and directions through the grid. Most of these rays travel through the same grid position as they move out of substantially the same grid position, thus identifying rays that move in similar directions from similar origins. Another variant of this packet tracing method is the frustration to distinguish the edges of a ray packet. Using rum truncation, the truncation beam is used to determine the crossed voxels, which helps to reduce the number of operations for a given beam packet (ie, not all beams are tested for crossing, but packets). Only the rays on the outer edge of are tested.) The packet tracing method should still identify the rays traveling from a similar location in a similar direction, as these rays are reflected, diffracted and / or generated during ray tracing. It can be harder and harder to do.

Another approach exists in the field of accelerating ray tracing. In other words, one approach attempts to improve cache usage by more actively managing ray conditions. Navratil et al. "Dynamic Ray Scheduling for improved System Performance" (2007 IEEE Symposium on Interactive Ray Tracing (Sep. 2007)) suggests that Pharr's approach is a "ray state explosion" that makes main memory unsuitable for processor cache traffic. explosion) "(hereinafter referred to as" Navratil "). To address this, Navratil proposes to prevent "ray state explosion" by having the necessary constraints to "actively manage" ray state and figure state during ray tracing. One suggestion is to track the generation of several rays separately, so Navratil first tracks the primary rays, then the secondary rays after the primary rays are finished.

The background above shows a variety of general ideas and approaches in the area that accelerate ray-tracing based rendering. This reference also appears to have additional advantages in the field of ray tracing. However, a discussion of any one of these references or techniques is not an admission or suggestion that any one of these references or their central subject matter is prior art on any subject disclosed herein. Rather, these references are intended to help highlight the differences with an approach to ray tracing rendering. Furthermore, the processing of any of these references should be omitted for clarity and need not be clearly described.

In one aspect, the method utilizes a plurality of computational resources in ray tracing a 2-D representation of a 3-D scene. The method includes using a first subset of computational resources for cross testing a geometric shape comprising one or more circular and geometric acceleration components using ray movement in a 3-D scene. Each computing resource of the first subset may be operable to communicate with an individual localized memory resource that stores an individual subset of rays traveling in the scene. The method sends an identifier between the rays and the circles from the first subset of the computational resources to the second subset of the computational resources and executes a shading routine associated with the identified intersection between the rays and the circles. Using a second set of computational resources, and the output from the shading routine includes a new ray to be cross tested. Membership in a subset can be a time-variable, or is determined statistically during recognition point during system configuration or while rendering a scene or one of a series of scenes.

The method also includes distributing data defining new rays of the localized memory resources and passing the grouping of ray identifiers for the first subset of computational resources using shape data. Each ray identifier includes different ray definition data for this ray. The passage of the ray identifier identifies the cross test of the identification rays having the shape identified by the shape data. This test retrieves the data defining the identified rays stored in its localized memory by each computing resource, tests the identified shape for the intersection based on the retrieved definition data, and detects for communication. Outputting an identification indication of the intersection.

In another aspect, the present invention includes a system for rendering a 2-D representation of a 3-D scene constructed in a circle using ray tracing. The system includes a plurality of cross test resources including access to individual cache memories, each cache memory comprising a subset consisting of a master copy of the ray definition data, and the ray definition data for each ray It stays in cache memory until the test for the beam is complete.

The system also has control logic that operates to control the test for each light ray by an individual test resource having access to definition data for the light rays in a separate cache memory, and to assign an identifier to each light ray. Include. Test control is affected by providing ray identifiers to individual test cells that store data for the ray to be tested. The system includes an output queue to identify the individual prototypes crossed with the beams that completed the cross test. The control logic allocates a new beam obtained as a result of the shading operation to replace the cross-tested beam in cache memory.

In some aspects one or more of the following may be provided. The control logic replaces by reusing the identifier for the completed ray as an identifier for the new ray, and the ray identifier relates to a memory location that stores the individual data defining the ray, and the data defining the new ray is the It replaces the data stored in the memory location.

Another aspect of the invention includes a system for rendering a 2-D representation of a 3-D scene constructed in a circle using ray tracing. The system includes a memory for storing prototypes constituting the 3-D scene and a plurality of cross test resources. Each cross test resource operates to test one or more rays moving within the scene using one or more of the above prototypes, and outputs an identification result of the detected intersection. The system also includes a plurality of shading resources, each of which operates to run a shading routine associated with the circle from the result of the detection of the detected ray / circular intersection. The system also includes a first communication link for outputting an identification result of the intersection detected as the shading resource, and a second communication link for delivering a new light beam generated as a result of the operation of the shading routine to the cross test resource. Here, new rays can be sent to the cross test resources and complete cross tests that differ from the relative order in which they were sent. Communication links may be implemented as a queue, such as a FIFO queue.

Another aspect of the invention includes a method for ray tracing a scene comprised in a circle in a system having a plurality of computational resources coupled to a hierarchical memory structure including distributed memory between main memory and computational resources. Here, the main memory has a greater latency than the distributed memory. The method distributes data defining the rays to be cross-tested in the scene in distributed memory, such that subsets of the rays are stored in different memories of the distributed memory, and cross-tests of groups of rays having one or more geometric shapes. Determining. Here, the members of the ray group are stored in several distributed memories. The method involves fetching one or more shape data from main memory, the geometric shape for the ray group and the one or more computational resources associated with each distributed memory where the identifier stores data for one ray of this ray group. Providing a step. The method also includes testing each ray of the ray group with respect to the intersection using a computational resource associated with one or more of the distributed memories that store data for the ray, and collecting cross-test results from the computational resource. It includes.

Another aspect includes a system for cross testing light rays using prototypes that make up a 3-D scene. The system includes a plurality of cross test resources, each cross test resource being operative to test individual rays with respect to cross using geometric shapes. Each individual light ray is identified by a reference provided to each cross test resource, and the test resource is operative to output an identification indication of the intersection between the light ray and the geometry to the first or second output.

One output relates to the circular intersection and the other output relates to the geometric acceleration element intersection. For example, the first output may provide an input with a plurality of shading resources, and relates to the result of the identification of the intersection between the beam and the circle. On the other hand, the second output provides an input to the ray collection manager and receives a result of the identification of the intersection between the ray and the geometric acceleration element.

Another aspect includes a ray tracing method, which stores geometric acceleration elements that individually limit the selection of a circle within a main memory resource and a circle that constitutes a 3-D representation; Defining and defining an identifier for each ray. The method includes storing a portion of the ray origin and direction data in a localized memory resource individually associated with each processing resource in a system comprising a plurality of individually programmable processing resources. The method also includes implementing ray scheduling for cross testing by providing an identifier for a ray scheduled for testing and a geometric shape identification result for processing resources. Each processing resource determines whether its localized memory resource stores ray definition data for any identified ray and, in such cases, whether to cross test such ray using this identified geometry. .

Another aspect includes computer readable instructions for a system that controls a plurality of processing resources to enable crossover testing of geometric shapes using light rays for use in rendering a 2-D representation of a 3-D scene. Computer-readable media. Such instructions may include accessing an identifier packet for a beam determined to intersect a first geometric acceleration element that limits the first selection of a circle, and other geometric acceleration elements that limit a portion of the circle limited by the first geometric acceleration element. To implement the method comprising the step of determining. The method also instantiates individual identification results for a plurality of packets each including a beam identifier and another of the other geometric acceleration elements, and individually for cross-testing fewer rays than all the rays identified in each packet. Providing a plurality of packets with each of the configured plurality of resources. In addition, the method further includes receiving an identification result of the intersection detected from the plurality of computational resources, and by means of the geometric acceleration element until identifying the next geometric acceleration element that has fewer identification results than the number of received identification results of the threshold. Tracking the received identification and repeating access to the next packet.

Another additional aspect of the invention is a plurality of computational resources configured to cross-test shapes using rays, and a separate cache each associated with the computational resources, where each cache defines some of the plurality of rays traveling in the scene. And a channel for message transfer between a plurality of computational resources. Wherein each computational resource includes a plurality of ray identifiers to interpret data in a message received by the computational resource, determine whether to have one of a plurality of rays stored in the cache, and use any associated shape to store any Configured to test the beam.

Another additional aspect includes a system for cross testing light rays using prototypes that make up a 3-D scene. The system includes a plurality of cross test resources, each operative to test individual rays with respect to geometric shapes and crosses. Individual rays are identified by the reference provided to each cross test resource. Each cross test resource is also configured to output, as a first output or a second output, the identification result of the intersection between the ray and the circle. The system also includes a plurality of shading resources, each of which operates to execute shading code for the detected intersection, and a plurality of cross testing resources for maintaining a reference to the rays and identifying the rays to be tested. It includes a ray collection manager that operates to provide ray references. The first output provides an input with a plurality of shading resources, receives an identification of the intersection between the light beam and the circle, and the second output provides an input to the light beam collection manager and provides the input of the intersection between the light beam and the geometric acceleration element. Receive the identification result.

Another further aspect includes a computational configuration for using ray tracing based rendering in parallel with a 2-D representation of a 3-D scene. This includes a processor coupled to a local cache (the local cache stores data defining a plurality of rays to be tested for intersection with a specified geometric shape); And an input queue provided by this processor. The data received in the input queue can be interpreted by the processor as it includes a plurality of identifiers for the light beams to be tested with respect to their intersection with the identified geometric shapes, where the processor has data stored in the processor's local cache. Extract definition data only for the identified arbitrary rays of the queue, cross-test any identified rays with the identified geometric shapes, and output the identification result of any selected intersection.

Still further aspects include computer readable media. This medium accesses the identifier packet for a ray defined to intersect the geometric acceleration element that limits the selection of the circle, and determines other geometric acceleration elements that limit (bound) the portion of the circle defined by the crossed geometric acceleration element. Computer-readable instructions for implementing a ray tracing method comprising the steps of: In addition, the method instantiates individual identification results of a plurality of packets (each packet comprising a beam identifier) and one of the geometric acceleration elements, and a plurality of packets of the beams identified in each packet. Providing each of the plurality of computing resources individually configured to cross-test. The method also includes receiving an identification result detected from the plurality of computational resources and tracking the received identification result according to the geometric acceleration factor.

Yet another additional aspect includes a ray tracing method. The method includes determining ray definition data defining a plurality of rays to be tested for intersection with the circles constituting the 3-D facade. The method also includes distributing a subset of the ray definition data in separate local memories of the plurality of computational resources, wherein the computational resource cross-tests the rays using geometric shapes and, in the management module, by the computational resources And determine which of the plurality of light rays to be cross-tested to be collected. This collection is defined by a plurality of ray identifiers, each of which includes definition data for the ray and other data and is associated with a defined shape that defines a portion of the circle. The method also includes causing the computing resource to test the collection beam determined by passing the ray identifier for this collection between the compute resources, each computed resource having an identified ray in which definition data is stored in the local memory of the compute resource. Answer individually by cross-testing

In these aspects, the plurality of rays stored in the local cache may be a separate subset of the second plurality of rays, wherein some of the plurality of ray identifiers identify rays stored in the local cache and some of the second plurality of rays. Is not stored in the local cache.

The described functional aspects can be implemented like a module, which is, for example, a module of computer executable code that constitutes suitable hardware resources that operate to generate input and output as described.

For a more complete understanding of the aspects and embodiments described in this specification, reference is made to the accompanying drawings described in the following.
1 shows a first embodiment of a system for rendering a scene using ray tracing.
2 shows a further aspect of the portion of FIG. 1.
3 illustrates another implementation of a cross test portion of a ray tracing renting system.
4 illustrates an example of computational resources for cross testing that may be used in the systems of FIGS. 1-3.
5 illustrates a further embodiment of a cross test system architecture for use in ray tracing.
6 illustrates aspects of another embodiment of an architecture for cross testing.
FIG. 7 shows a system architecture implementing various aspects of the examples of FIGS. 1-6, which include cross test resources and includes shading resources connected by queues.
8A illustrates various aspects of a method of providing an identifier for a ray that may be used to control ray tracing in the system according to FIGS. 1-7.
9A and 9B illustrate embodiments that use ray IDs to identify ray data in memory that may be provided to any of the cross test resources of FIGS. 1-7.
10 illustrates various aspects of cross test control (function) and appearance distributed among a plurality of cross test resources that may be implemented in the system of FIGS. 1-7.
11 illustrates a multiprocessor architecture in which various aspects of the system of FIGS. 1-10 may be implemented when using an architecture for ray tracing.
12 illustrates the organization of a plurality of computational resources using localized ray data storage media and inter-resource communications that may affect the implementations of FIGS. 1-11.
FIG. 13 shows an example of multiple threads or cores operating as part of the computational resource of FIG. 12.
14A-14C illustrate several different queue implementations that may be used in systems and architectures according to FIGS. 1-13.
FIG. 15 is used to illustrate different ways in which ray data can be distributed between an L2 cache shared by a plurality of computational resources and a private L1 cache.
16 shows an example of packets that may exist in a queue, per embodiment of the present invention.
FIG. 17 provides a method for using a locally available ray data in a cross test, where a particular computational resource processes a ray ID from a packet and rewrites these test results.
18A and 18B illustrate embodiments of an exemplary SIMD architecture for processing packets of ray ID information.
19 shows propagation of the ray identifier, testing the ray, and summing the test results into additional packets for further testing.
20 illustrates methodological steps in terms of the content of a data structure, which is generally applicable to a system according to the previous figures.
21 shows further method aspects according to the invention.

Hereinafter, the present invention will be described in detail with the accompanying drawings and examples.

The following description is intended to enable those skilled in the art to make and use the various embodiments of the present invention. Various modifications to the examples described herein will be apparent to those skilled in the art, and the generic principles described herein may be applied to other examples and applications without departing from the scope of the present invention. have. This description begins by introducing a plurality of aspects relating to an example of a three-dimensional (3-D) scene (FIG. 1), which can be compressed using geometric acceleration data, as in the example of FIG. 2. Such three-dimensional facades can be rendered in two-dimensional representations using systems and methods in accordance with the representations and examples described.

As introduced in the art, a three dimensional scene needs to be transformed into a two dimensional representation for display. This conversion requires selecting the camera position from where the scene is visible. Camera position often represents the position of the person viewing the scene (eg gamers, viewers of animated films, etc.). The two-dimensional representation is generally in a planar position between the camera and the scene, so that the two-dimensional scene includes a pixel array of the desired resolution. The color vector for each pixel is determined through rendering. During ray tracing, the ray can intersect the plane of the two-dimensional representation of the desired point starting from the camera position. Then continues to the three-dimensional scene. The position at which the ray intersects the two-dimensional representation is maintained in the data structure associated with the ray.

The camera position does not necessarily need to be a single point defined in space, but instead the camera position is distributed so that light rays can be emitted from a large number of points considered within the camera position. Each ray intersects a two-dimensional representation in the pixel, which may be called a sample. In some embodiments, the more accurate the location at which light rays intersected with the pixel can be recorded, the more accurate color interpolation and blending is possible.

For clarity of explanation, data for a given type of object (eg, coordinates for three vertices of a triangle) is often described simply as the object itself rather than as to the data for the object. For example, when referred to as "circular fetch", it should be understood that the circular data representation is fetched rather than the physical manifestation of the circular. However, in particular with respect to light rays, the present invention distinguishes the identifier for a light ray from the data defining the light beam itself, where the term "ray" is used, unless otherwise indicated. It is broadly understood to be both data and ray IDs that define.

Actual and highly detailed object representation in a three-dimensional scene is achieved by providing a large number of small geometric primitives which are in close proximity to the surface of the object (ie wireframe model). As such, complex objects need to be represented in more circles and smaller circles than simple objects. While providing the advantages of high resolution, performing cross-tests between light rays and a large number of circles (as described above, and as described further below) intensifies associations, particularly in large numbers of complex scenes. This is because it has an object of. Without constant external structuring forced into the scene for the cross test, each ray must be tested for each circle and cross, which results in a very slow cross test. Thus, a method of reducing the number of ray / circle cross tests required per ray helps to accelerate the ray cross test in the scene. One way to reduce the number of such cross tests is to provide an extra bounding surface that compresses a large number of circular surfaces. The light beams may first be cross-tested against the boundary surface to identify a subset of circles smaller than the circle for cross-testing with each light beam. Such boundary surface shapes may be provided in various shapes. In this specification, this collection of boundary surface elements is referred to as Geometry Acceleration Data (GAD).

More extensive treatments for GAD oranization, elements and uses can be found in US patent application Ser. No. 11 / 856,612, filed Sep. 17, 2007, which is incorporated herein by reference. Thus, a simpler treatment of GAD for the content is provided below, and more details on this issue can be obtained from the above referenced application.

As introduced, the GAD element generally includes a geometric shape surrounding a separate collection of circles in three-dimensional space, so that the failure of the ray to intersect the surface of the geometric shape indicates that the ray does not intersect any circle within that shape. . GAD elements may include shapes, axis-aligned bounding boxes, kd-trees, octrees, and other types of boundary volume hierarchies, and thus embodiments in accordance with the present invention employ boundary schemes such as the kd-tree's cut plane. Alternatively, other methods of specifying or specifying a range of boundary surfaces delimiting one or more circular boundaries may be used. In summary, since the GAD element is primarily useful for compressing the circle to more quickly identify the intersection between the ray and the circle, the GAD element is preferably in a shape that can be easily tested for intersection with the ray.

GAD elements may be related to each other. The correlation of a GAD element may be a graph that includes nodes and edges in this specification, where the node represents a GAD element and the edge represents a correlation between two of the GAD elements. In the case where a pair of elements are connected by an edge, the edge indicates that one of the nodes has a different granularity than the other node, which means that one of the nodes connected to that edge is compared to the other node. It can mean that you are delimiting more or less circles. In some cases, the graph may be layered, such that there is a direction for the graph, where the graph narrows the remaining bounded circles in this manner across from the parent node to the child node. In some cases, the graph may include homogeneous GAD elements, such that if the designated GAD element specifies another GAD element, the designated GAD element does not directly define a prototype (ie, in a homogeneous GAD structure). , The prototype is directly determined by the leaf node GAD element, and the non-leaf node directly defines another GAD element, not directly).

The graph for the GAD elements may be configured to maintain uniformity in the numerical aspects of the elements and / or primitives defined by each GAD element. The designated scene may be subdivided until this goal is achieved.

In the following description, the fact is provided that there is a mechanism for determining which GAD element should be tested in response in the next, based on the light rays determined to intersect the designated GAD element. In one example of a hierarchical graph, the next element to be tested is typically the child node of the node being tested.

One method of use for a GAD implemented in many embodiments herein includes that when a ray is found to intersect a specified GAD element, it is collected with another ray determined to intersect that element. If many rays are collected, the stream of GAD elements associated with that element is fetched from main memory and streamed through a tester, each having a different collection ray. Thus, each tester keeps the rays unchanged in the local fast memory while the geometry is fetched from slow memory when redundant writing is needed or allowed. More generally, this description is a series of how computational resources are structured to advance the rays to detect the intersection of these rays with geometric shapes (GAD elements and circles) and consequently identify which rays collide with which circles. Provide an example.

Another aspect of the invention in which this embodiment may be implemented includes one of the following. (1) a cue is provided to provide output from the cross-test to the sadie, (2) when a decision is made to test a particular ray for such a shape, while the geometry is fetched from slow memory, the ray data may Some localization to compute, and (3) cross testing is driven by identifying the rays with a computational resource that performs the cross-test (by using a ray identifier), in which each computational resource is derived from its localized memory. Fetch data corresponding to the identified rays.

The following description shows an example of a system and apparatus for rendering a two-dimensional representation of a three-dimensional scene using ray tracing. Two conceptual functional components of such a system are (1) ray tracing to identify intersections and (2) shading of identified intersections.

1 illustrates various aspects of a system for use in ray tracing a scene consisting of a circle. In general, one of the functions or roles of one of the functional units in FIG. 1 and the other figures may be implemented in multiple hardware units or software, software subroutines, and may run on a computer with each other. In some cases, such implementations are described in more detail as they may affect system functionality and performance.

1 shows a geometric shape comprising a geometric unit 101, a cross processing unit 102, a sample processing resource 110, a frame buffer 111, and a GAD element and a circle (circular and GAD storage 103). , Memory 106 138 configured to store or store samples 106, ray shading data 107, and texture data 108, otherwise operative to store them. The geometric unit 101 inputs an acceleration structure that includes a description of the rendering scene and a GAD element that defines a circular boundary. Intersection processing 102 shades the identified intersections between light rays and circles, and uses inputs such as textures, shading codes, and other sample information obtained from the illustrated data resources. The output of the cross processing 102 includes new light rays (described below) and color information to be used to generate a two-dimensional representation of the scene to be rendered. All of these functional components may be implemented in one or more host processing resources, represented generically by dashed lines 185.

As described above, during shading of the identified light / circular intersections, cross processing 102 may generate a new light to be cross tested. The driver 188 receives new rays and manages communication between the cross processing resource 102 and the localized cross test region 140 including the ray data storage 105 and the cross test unit 109. It may be an interface with cross processing 102 to decompose. The cross test area 104 tests the light beams for the cross, has read access to the circular and GAD storage 103 via the interface 112, and identified through the result interface 121 to the cross processing 102. Outputs the identification result of the intersection. The local light data storage 105 is preferably implemented in a relatively fast memory that can be relatively small in size. Circular and accelerated structure storage, on the other hand, is implemented in relatively large and slow main memory 139, which may be the main dynamic memory of host 185.

One method of ray tracing a high resolution scene is related to the volume of related ray data and shape data. For example, rendering a full HD resolution film at 30 frames per second requires more than 60 million pixels per second (1920 x 1080> 2M, 30 times per second). And, to determine each pixel color, many rays may be needed. Thus, hundreds of millions of rays need to be processed every second, every ray needs several bytes of storage, and ray tracing of a full HD scene involves more than a few gigabytes of ray data per second. Also, at any given time, a large amount of light ray data must be stored in the memory. Almost always there is a trade-off between access speed and memory size, and therefore large cost-efficient memory is relatively slow. Also, large memory sizes cannot be effectively used unless sufficiently large blocks of data are accessed or used. Thus, one challenge is to be able to simultaneously identify groups of rays that are large enough to effectively access data from memory. However, as shown by approaches such as searching and group testing of rays having similar origins and directions, there may be processing excess, sometimes serious excess, when identifying such rays. In one aspect, the following example architecture structures and uses multiple computational resources, faster and more expensive memory, and slower, larger memory to increase the throughput of ray cross testing and shading for scene rendering. Explain how.

Thus, Figure 1 shows the shading of identified intersections by a data flow that includes ray definition data to be stored in a fast memory localized to a GAD element and a computational resource 109 testing the rays for intersection with the prototype. To separate the crossover test from. The output of the crossover test 109 includes the identification of the identified rays intersecting the identified circles. Cross processing 102 may receive these identifications, perform shading based on these identifications, and generate interns of new rays for testing, which ultimately results in fast ray data memory 105. Stored. Such decoupling may be provided in various implementations using one or more of a general purpose computer and fixed function hardware programmed in software in accordance with this description, using communication means selected according to the processing resources used. However, one aspect that occurs in this embodiment is that the shape data tested for intersection with the ray in the intersection test region 140 compared to the ray definition data is transient. In other words, where applicable, high speed memory is also assigned primary to ray data, while shapes are streamed through the tester and there is little computational resource to be used to optimize the caching of such shape data. Various subsequent figures show more specific examples of such decoupling, data flow, ray data storage, and collocation with cross test resources.

1 also shows that the frame buffer 111 can finally be used to drive the display 197. But. This is just one example of the output that is the result of a cross test and shading operation that may be called rendering for convenience. For example, the output may be recorded on computer readable media. This computer readable medium includes a rendering product, such as a sequence of rendered images for transmission onto a network containing computational resources connected by a communication link, or for dissemination on a tangible computer readable medium or for later display. . In some cases, the rendering 3-D scene may be a representation of a live-action 3-D scene, such as in the case of rendering or immersive virtual reality conferencing of an image containing a perspective view of a 3-D CAD model. have. In this case, the rendering method acts on or transforms the data representation of the physical object. In other cases, the 3-D scene may have some objects representing physical objects and other objects that do not exist. In another additional 3-D scene, the integrity of the scene may be fictional, such as in a video game or the like. As a result, however, this method is typically a variation of the article in memory, display and / or computer readable media.

In addition, rendering using ray tracing has been implemented since 1979, and various techniques have been developed for cross-testing and other functions required to implement rendering using ray tracing. Thus, the particular architectures and methods described in this specification do not replace the functional principles of ray tracing for use in rendering 3-D scenes in 2-D representations.

2 shows that the cross test unit 109 of the cross test area 140 includes one or more individual test resources (also known as test cells), which can test the geometry of the light beam. Region 140 includes test cells 205a-205n that receive ray data from ray data storage 105 and geometric data from memory 139, respectively. Each test cell 205a-205n generates a result for communication via the result interface 121 with cross processing 102, which may include an identification of whether the designated ray intersects the designated circle. In contrast, the result of the cross test of the light and GAD elements is provided to logic 203. Logic 203 maintains a collection 210 of references to the light rays that associate these light rays with the GAD elements determined to have crossed light rays.

In general, system components are designed to support unknown, time-completed, designated, specific light tests. The cross test unit 109 has a read access to the geometric memory and as input has a reference queue for the light beam. As the output of the crossover test, each ray is correlated with one geometric figure that first intersects the ray (referred to herein as primitive for convenience). Other geometric figures (ie, circles) may be shown uncorrelated.

As introduced above, region 140 includes management logic 203 associated with the ray reference buffer, which maintains a list 210 of ray collections to be tested in test cells 205a-205n. The buffer management logic 203 may be implemented in hardware consisting of instructions obtained from fixed function processing resources or computer readable media. Such instructions may be structured in modules according to the functions and tasks specific to logic 203 herein. Those skilled in the art to which this invention pertains may provide further implementations for logic 203 based on this description.

Logic 203 may assign light rays and geometric shapes to test cells and handle communication with other units in this design. In one aspect, each ray collection in list 210 includes a plurality of ray identifiers, all of which are to be tested for intersection with one or more geometric shapes, and logic 203 stores such ray collection. In a more specific example, the plurality of ray identifiers are arranged to intersect the identified GAD elements in this collection, and the next GAD element to be tested for intersection with the plurality of rays is associated with the crossed GAD element in the graph of the GAD element. Related elements for a given collection are fetched from memory 139 when a cross-test with these elements begins.

Alternatively, logic 203 may store a reference representing a ray that intersects the sub-portion of geometric data corresponding to an individual child node in the temporary ray reference buffer, which delays the execution of further processing of this ray. Let's do it. In the example of hierarchically aligned GAD, this execution deferral is a sub-sequence of geometric acceleration data below the child node until a subsequent time when the cumulative number of rays intersecting the geometric sub-part of the child node is found to be suitable for further processing. You can postpone the pros of the part.

Logic 203 may communicate with memory 139 to establish a memory transaction that provides a geometry for testing for cells 205a-205n. Logic 203 also communicates with ray data storage 105 and determines which ray will be stored there. In some implementations, logic 203 can be obtained or received from memory 139 or from a shading process executed in cross-processing unit 102, and when space is available, memory 105 for storage. This beam can be provided and used during crossover testing.

Thus, logic 203 may include a temporary ray reference buffer that contains the association data of the ray identifier to the GAD shaped identifier. In one implementation, the identifier for the GAD element may be hashed to identify a location in the buffer to store a designated collection associated with the GAD element. Association data is generally referred to as a collection when referring to the storage or collection of such data, in memory and at some place within the current application, and the term "packet" refers to the collection of collection data during Commonly used to mean movement. The result thus returned is incorporated into a collection stored in memory associated with the GAD shape, as described below.

In summary, FIG. 2 shows that the ray definition data is stored in the first memory 105 while the shape data to be tested with respect to the intersection with the ray is fetched from the memory 139. The above description also shows that it is desirable for a plurality of shapes to be next-tested once to be fetched from memory 139 and then tested for a cross with a group of rays known to intersect the "parent" GAD element.

3 now includes a block diagram of an implementation of an intersection testing unit 350 (ITU) of area 140 (FIG. 1) that can be used in a rendering system for ray tracing a two-dimensional representation of a three-dimensional scene. ITU 350 includes a plurality of test cells 310a-310n and 340a-340n. The GAD element is shown as originating from the GAD data store 103b and the prototype data is shown as originating from the circle data store 103a.

Test cells 310a-310n receive GAD elements and ray data (ie, such test cells test GAD elements) for testing against these elements. Test cells 40a-340n receive the prototype and the ray data (ie, such a test cell tests the prototype) for testing against these prototypes. Thus, ITU 350 may test a collection of rays for intersection with a circle and a separate collection of rays for intersection with a GAD element.

ITU 350 also includes collection management logic 203a and collection buffer 203b. Collection buffer 203b and ray data 105 are stored in memory 340 that can receive ray data from memory 139 (eg,). Collection buffer 203b maintains a ray reference associated with the GAD element. The collection manager 203a manages this collection based on cross information from the test cell. The collection manager 203a may also begin fetching the prototype and GAD elements from the memory 139 to test the ray collection.

ITU 350 returns the identification result of the identified intersection. This may be buffered in the output buffer 375 for final preparation via the result interface 121 to the cross processing 102. The identification information is sufficient to identify, in the light beam and the specified range, the circle in which the light beam is determined to intersect.

ITU 350 may be viewed as a function or utility that may be invoked through a control process or driver (eg, driver 188). This control process or driver provides the ITU 350 with the rays to be tested for intersection with the rays. For example, ITU 350 is supplied with information through driver 188 (ie, a rendering process such as shading and a process of connecting the initial ray generation functional unit with ITU 350). In perspective view of ITU 350, ITU 350 does not need to know the origin of the information provided to it. This is because region 140 may perform cross-tests using prototypes (more generally scene figures) obtained based on light rays, GAD, and other information supplied or supplied to itself.

As described above, the ITU 350 can control how, when, and what data is supplied so that the ITU 350 is not passive, e.g., the ray or geometry required for cross testing. You can fetch data or acceleration data. For example, ITU 350 may be provided with a large number of rays for cross testing, along with enough information to identify the scene within the rays to be tested. For example, more than 10,000 rays may be provided for cross testing at a given time, and upon completion of testing for these rays, new rays (generated by cross processing 102) may be used as described below. Likewise, it may be supplied to maintain the number of rays to be processed at ITU 350 at approximately an initial number. ITU 350 then controls the temporary storage of the light beam during processing (in light collection buffer 203b (see FIG. 3)) (in logic 203a (see FIG. 3)). You can also start fetching the prototypes and elements of the GAD that are needed during this processing.

As described above, the GAD element is temporary at the ITU 350 compared to the ray. This is because the ray identifier 105 is stored in the buffer 203b and is structured with respect to the GAD, whereas the data defining the ray is stored ray data 105. Buffer 203 and ray data 105 may each be stored in memory 340, which may be physically implemented in various ways, such as one or more banks of an SRAM cache.

As described above, logic 203a tracks the state for the ray collection stored in memory 340 and determines the collection ready for processing. As shown in FIG. 3, logic 203a is communicatively coupled to memory 340 and may initiate the transmission of light beams for testing to each of the connected test cells. In a situation where a GAD element specifies only GAD elements or only circles (not a combination thereof), logic 203a tests the ray, depending on whether a particular collection that defines a circle or other GAD element is associated with the GAD element. The cells may be allocated to the cells 340a-340n or the test cells 310a-310n.

In an example where a particular GAD element may define both a GAD element and a circle, the ITU 350 may have a data path for providing both the GAD element and the circle with rays to each test cell, thereby providing logic 203a. ) Can prepare for ray testing of the collection between test resources. In this example, due to the typical differences in shape between the GAD element and the circle (eg, sphere versus triangle), the identification result for selecting the test logic or loading the cross-test algorithm optimized for the shape to be tested is determined by the logic ( 203a).

The logic 203a may provide information about the test cells 340a-340n and the test cells 310a-310n directly or indirectly. In an indirect case, logic 203a provides information to each test cell so that each test cell can begin fetching light ray data to memory 340. Logic 203a is shown separately from memory 340, but for simplicity of explanation, logic 203a may be implemented within circuitry of memory 340. This is because a management function that is extensively performed by logic 203a is associated with data stored in memory 340.

The ability to increase parallelization of access to memory 340 by cross test resources is an advantage of some aspects of the invention described herein. As such, an increase in the number of access ports for the memory 340 (preferably one or more per test cell) is an advantage. Exemplary structuring related to such parallelization is further described below.

In addition, ITU 350 may operate asynchronously with a unit providing input data and receiving output from ITU 350. Here, “asynchronous” may include the ITU receiving and starting an additional ray crossover test while the crossover test continues for a previously received ray. In addition, “asynchronous” includes that the cross-test for the beams need not be completed in the order in which the ITU 350 receives the beams. In addition, asynchronous means that the cross-test resource in ITU 350 is irrespective of the position of the ray in the three-dimensional scene or the scheduling grid superimposed on the scene, or has a generational relationship, such as the ray of light from the parent ray and a small number of ray rays. Regardless of testing the bay or only a particular generation of rays (eg, camera rays or secondary rays), it is possible to assign or assign cross tests.

The ITU 350 also includes an output buffer 375 that receives the identification of the circle and the identified intersection of the light beams intersecting the circle. In one example, the identification results include identification results for the prototype paired with enough information to identify the ray intersected with the prototype. Identification information for a ray may include a reference (eg, an index), which identifies the particular ray in the list of rays. For example, this list may be managed by the driver 188 operating on the host 185, which may be kept in the memory 139. Preferably, if the memory 139 does not contain such information, the memory 139 may include information such as the origin or direction of the light beam (which is sufficient to reconstruct the light beam). Usually a few bits are required to pass the reference, which can be an advantage.

4 illustrates an example of a test cell 310a and may include a working memory 410 and test logic 420. The working memory 410 includes several registers, which contain enough information to test the line segment for intersection with the surface, which may be more complex in other embodiments. For example, the working memory 410 may store instructions for configuring test logic 420 to test a particular shape received with respect to the intersection, and detect which shape was received based on the received data. . The working memory 410 may temporarily store the detected hits, where each test cell is configured to test a series of rays for a geometric shape, or vice versa. The temporarily stored hits may then be output as a group. The working memory also receives shape data input from storage 103b.

The test logic 140 may perform a crossover test at an available or selectable resolution and return a binary value indicating whether the detected crossover is present. This binary value may be stored in the working memory for output for latching during a read cycle, such as a read, caching (temporary) or read cycle in memory 340 for GAD element testing.

5 illustrates various aspects of an implementation of a cross test unit 500, focusing in detail on example memory structuring. In the ITU 500, test cells 510a-510n and 540a-540n are shown, corresponding to test cells 310a-310n and 340a-340n in this example. This does not imply any limitation on the number of test cells. Thus, in ITU 500, the prototype and GAD elements can be tested in parallel. However, if it is determined that an additional test cell in one variant or the like is needed, any test cell may be properly reconfigured (relocated in the case of hardware and reprogrammed in the case of software). As the transistor density increases, the test cells can be accommodated more in hardware implementations (or as a resource capable of executing software). As described above, some of the test cells may be treated as working groups in that they will test the light beams for a common shape (ie, circular or GAD elements). The test cells 540a-540n can return a binary value indicating intersection with the circle at a particular level of precision (e.g., 16 bits), which is useful for larger circles, for points where the rays intersect in the circle. More accurate identification can be returned.

In ITU 500, memory 540 includes a plurality of independent operating banks 510-515, each of which has two ports (port 531 and port 532 of identified bank 515). One port is accessed through the GAD test logic 505 and the other port is accessed through the prototype test logic 530. The GAD and prototype test logic 505 and 530 are each a separate working buffer 650. Manage the data flow between -565 and 570-575 and obtain GAD elements for testing from GAD storage 103a and prototype storage 103b, respectively.

The banks 510-515 mostly operate to provide non-conflict access to the ray data by the GAD and prototype test logic 505 and 530, thereby providing test cells 510a-510n and test cells 540a-540n. ) May each receive light from separate banks 510-515. Such non-conflict access is implemented by, for example, separate cache banks and cross-bar architectures, which allow access by ports to different physical parts of memory, as can be understood herein. Can be. If testing of the rays stored in the bank by one or more test cells is allowed, a collision may occur when two rays to be tested exist in the same bank, in which case access is made by the test logic 505 and 530. Can be processed sequentially. In some cases, job buffers 560-565 and 570-575 may load the next processing cycle while other processing is completed. For example, region 578 includes a test region for the GAD element. This is because this area includes the GAD tester 510a and the memory bank 510. In contrast, region 579 includes testers 510a and 540a, one for each of the GAD and prototype, and stores a memory bank 510 that stores light data to be used in a test relating to the test cells of regions 578 and 579. Because it has access to, it includes a test area for all of the GAD element prototypes.

 By consistently testing the rays, the operation of tracking which rays are assigned to which test cells can be reduced. For example, each collection may have 32 rays, and there may be 32 of the test cells 310a-310n (510a-510n). For example, by consistently providing the fourth light ray in the collection to the test cell 310d, the cell 310d does not need to maintain information about the light rays that were provided to it, and only needs to return the identification result of the intersection. As shown, another implementation may be provided to maintain consistency, which sends a packet of ray identifiers in the test cell, allowing the test cell to write the intersection result in the packet.

Storage for the ray collection may be implemented as an n-way interleaving cache for the ray collection, such that any designated ray collection may be stored in one of the n portions of the ray collection buffer 203b or 520. The ray collection buffer 203b or 520 will keep a list of ray collections stored in each of the n portions of the buffer. For example, a unique identifier string may be used between the GAD elements used to render the scene. An alphanumeric string character set is a number or a hash. For example, the hash may refer to one of n portions of the ray collection buffers 203b and 520.

In other implementations, elements of the GAD may be arranged to be stored in designated portions of the ray collection buffers 203b, 520, for example by mapping segments of alphanumeric strings used in portions of the buffer. Circular / ray intersection output 580 represents an output for identifying potential circular / ray intersection, and output 580 may be in series or in parallel. For example, if there are 32 circular test cells 540a-540n, the output 580 may include 32 bits indicating the presence or absence of the intersection of each ray for the circle just tested. have. Of course, in other implementations, such as, for example, packet implementations, the output may come directly from the test cell. The output may be serial and may be stored serially by test cells in the packet.

Light ray data is received in the memory 340 and 520 from a light source (eg, a shader). Collection management logic (eg, 203a in FIGS. 2 and 3) operates to initially assign rays to a collection, where each collection is associated with an element of the GAD. For example, an element of the GAD may be the root node of the graph, with all received rays initially assigned to one or more collections associated with the root node. Receipt of the rays may also be included in a group sized to be the entire collection (eg from an input queue), each of which may be treated like a collection identified in the rays collection buffer 203b, for example. .

Concentrating on the processing of one collection, multiple collections can be processed in parallel, and retrieval of the rays of the collection associated with the test node from the memory 340 can be achieved by, for example, the address of such rays stored as data within the collection. Ray identifier) from the memory 340 or according to the example of FIG. 5, a bank 510-515 providing ray data on a plurality of output ports for reception of a test cell (eg, test cells 560-565). Is provided by the collection management logic 203a by providing for retrieving such rays.

Regarding the testing of the GAD element defined by the node selected for testing (ie, the GAD element associated with the selected node defines another GAD element), the distribution of the ray data for the ray of the collection under test is terminated, and Fetching of the GAD elements is performed (this subsequent fetching is not necessary for ray dispersion). With respect to this fetching, the logic 203a can input address information into the GAD storage 103b (or by any provided memory management means) and output the address GAD element to the test cells 310a-310n. do. As in this case, where multiple GAD elements are defined, for block reading of the multiple GAD elements, these elements may be arranged to be serially streamed into the test cell (eg using a serial buffer).

In test cells (eg, 310a-310n), the light rays of the collection can be tested for intersection with the GAD elements provided in series (eg, different light rays in each test cell). If it is determined that the rays intersect, it is determined whether a collection exists for the crossed GAD elements, in which case the rays are added to that collection (space allowed), otherwise the collection is created, Rays are added. If there is no space in an existing collection, a new collection can be created.

In some implementations, a 1: 1 correspondence of the maximum number of rays in a collection to a number of test cells 310a-310n is provided such that all rays of the collection can be tested in parallel to a given GAD element, which is one It may include the architecture of. In this architecture, throughput is generally similar to what can be obtained using a 1: 1 correspondence of light to test cells. However, it provides for the serial transfer of packets (eg, information representing a collection as described above) between different test cells, so that even if the entire ray of a given collection appears to have been tested in parallel, rays from different packets Allows you to test

Thereafter, the ray is tested for intersection with the circle provided to the test cell (ie, in this embodiment, each test cell has a different ray and tests the ray with a common circle). After the test, each test cell identifies the detected intersection.

Each ray of the collection is tested in the test cell for intersection with the GAD element provided in the test cell (eg, in the multi-bank example of FIG. 5 (regions 578 and 579 are shown), the ray is an example. For example, it may be considered to be localized in the GAD element test area and / or the circular test area, whereby the bank uses ray data to assist one or more testers of each kind).

Since the output from the ray test on the intersection with the GAD element differs from the test of the same ray on the circular intersection (ie, the intersection with the GAD element becomes a collection into the collection for the GAD element, whereas The intersection of is the determination of the intersection closest to its circle and the output of these intersections), even if a particular ray exists in two collections to be tested in parallel, no collisions occur in rewriting the collection data or outputting the intersection result. It is not common. For example, if additional parallelization is implemented by testing multiple collections of rays for circular intersections during multiple instantiations of test cells 340a-340n, sequential completion of the test, such as storage of multiple intersections, or bit locks. And so on. In the embodiment of FIG. 5, if the data for a given beam of light can be provided in one tester type (e.g., a designated conduit is located in one memory bank) in only one bank, the multiple GAD testers are for example. At the same time, the same rays are not tested, thereby avoiding the problem of rewriting collisions.

In summary, this method receives a ray, assigns it to a collection, selects a test-waiting collection, assigns the ray of the selected collection to the appropriate test cell, and creates a suitable geometric shape for cross-testing through the test cell. Streaming, wherein the radiance may be determined algorithmically. The output depends on whether the geometry is a scene circle or a GAD element. With respect to the rays tested for the GAD element, the GAD element is identified based on a graph connection with the node associated with the collection to be tested, and the optical document is added to the collection associated with the GAD element to be tested. The collection shows the wait state and is selected to test when it waits. Regarding the intersection of the circle and the ray, the nearest intersection is tracked by the ray. Since the ray is tested vs. associated with the ray collection, the cross-test for a particular ray is assumed to be postponed until the associated collection is determined to be waiting for testing. Rays can be collected consistently in multiple collections, which allows these rays to be tested against distinct parts of the scene geometry (ie they do not need to be tested in an in order of traversal).

As previously described, the ITU is stored in memory, and an informational representation of the ray previously received from the ray is input. The ITU uses one or more ray collections of a plurality of collections for these rays to maintain the association of each ray. The ITU also stores the identification of collection fullness for a plurality of collections stored in memory. This identification may be an individual flag representing the entire collection or may be a number representing a plurality of rays associated with the mechanism collection. More specifically, and other implementations and variations related to implementing the test algorithms are provided in the relevant applications referenced above, which show that the information provided herein is not to be taken as their limiting.

As is apparent from the description of these points, the rays are loaded (or accessed) from the memory based on the information provided in the collection of rays. Thus, this loading determines the individual memory locations where data representing each ray is stored. Such data is included in the ray collection, for example one ray collection contains a list of memory locations or other references to storage, where the ray data about the rays in the collection is stored. For example, the ray collection includes references to locations in memory (e.g., memory 340), or banks of memory (e.g., bank 510, or other implementations). The aspect may be represented in a perspective view in which separate ray data and ray collection data are maintained, but in some embodiments, this distinction is a ray collection. There is no need to be very explicit or explicit in that data and ray data can be kept in a content-related database, for example, where associations between collections and rays and between elements in the collection and GAD are maintained and tested. To identify the rays associated with the collection and the GAD elements associated with the collection.

It is also evident that the ray data is “stationa” within the test cell as the circular or GAD element is traversed through the test cell. As described in the related application, other implementations are possible. However, the main focus of this description is that the geometric figure provides a ray to be localized or fixed with the test cell during fetching and testing.

Various aspects of this embodiment are provided with reference to FIG. 6. In particular, another implementation of cross test logic includes a processor 605 that includes test control logic 603 (similar to the test logic of FIG. 2), where the test control logic includes a memory interface 625, an instruction cache. 630, a command decoder 645, and a fetch unit 620 for connecting to the data cache 650. The data cache 650 supplies the test cells 610a-610n. The command decoder 645 also provides an input to the test cells 610a-610n. The command generator 665 provides the command input to the command decoder 645. The test cell outputs the identification result of the intersection detected by the rewriting unit 660, and the rewriting unit may sequentially store data in the data cache 650. The output from the rewrite unit 660 is also used as an input to the command generator 665 when the command is generated. The instructions used in the processor 605 are assumed to have a single instruction, multiple data diversity, in which case the instruction processed in the test cell is a cross test between the defined surface (eg, circular and GAD elements) and the ray.

In one example, the "command" includes data defining a geometric shape, such as a circular or GAD element, and the multiple data elements may include a separate reference to a ray for testing against the geometric shape provided by the "command". have. As such, the combination of geometric shape and multi-beam reference is assumed to be a separate packet of information that can be delivered to several illustrated test cells. In some cases, packet delivery is processed continuously, resulting in multiple packets being " in flight " between a plurality of test cells.

Such test cells may exist in the form of a full-featured processor with a large instruction set, and such packets may each contain other information sufficient to distinguish the purpose of the packet. For example, there may be a number of bits included to distinguish packets formed for cross testing from packets that exist for several different purposes. In addition, various cross test commands may be provided, which are included with respect to different circular shapes and different GAD element shapes, or with respect to different test algorithms.

In a typical example, each cross test packet may initially contain a reference to a geometric element or data about a geometric element (one of which is a GAD element) or a reference to a prototype. And reference to a plurality of rays (ie, "packets" as described above) for testing for intersection with the geometric elements.

Decoder 645 may interpret the instructions to determine a reference for the geometric element and initiate the fetch of the element via fetch 620 (control to a memory interface, such as memory interface 625). In some implementations, the decoder 645 can anticipate a number of instructions for initiating the fetch of geometric elements needed in the future. The geometric elements may be provided to the decoder 645 by the fetch 620, where the decoder 645 provides the geometric elements to the test cells 610a-610n.

Decoder 645 also provides a ray reference from an instruction, such as a functional address for data cache 650, which provides sufficient individual data to cross test each ray into each of test cells 610a-610n. Data associated with the light beam (not required for crossover testing) need not be provided. Thus, the data cache 650 may function as localized ray data for one or more computational resources that behave like cross test cells.

The geometric elements are cross tested with individual light beams in each test cell 610a-610n, and are output from each test cell 610a-610n so that the identification result of the intersection is received by the rewriting unit 660. Depending on the attributes of the geometric elements tested, the rewrite unit 660 performs one of two different functional units. In the case where the test cells 610a-610n tested the circle for the intersection, the rewriting unit 660 outputs the intersection of each ray intersected with the circle to be tested. When the test cells 610a-610n have tested the GAD elements, the rewrite unit provides the output of the test cells 610a-610n to the command unit 665.

The instruction unit 665 is operative to combine virtual instructions that will command the test cell upon further cross testing. The instruction unit 665 operates as follows using inputs from the test cells 610a-610n, the instruction cache 630, and the GAD input 679 that specify the ray intersecting the designated GAD element. Using inputs from the test cells 610a-610n, the instruction unit 665 determines a GAD element connected to the GAD element specified for the input from the test cells 610a-610n based on the GAD input ( That is, the instruction unit 665 determines which GAD element should next be tested based on the intersection identified for the designated GAD element).

The instruction unit 665 is connected with the intersected elements to determine if there is already an instruction stored in the instruction cache for each element of the identified GAD and that the instruction can accept any additional ray reference (i.e. all of the instructions Is the data slot filed?). The instruction unit 665 adds the rays identified as intersecting at the test cell input with the command by the number of rays identified, and generates another ruin enough to receive a natural ray reference. The instruction unit 665 executes this for each element of the identified GAD by being connected with the element identified in the test cell input. Thus, after processing the test cell inputs (cross-identification results), light rays identified as intersecting with the same GAD element are each added to instructions specifying a test of light rays for the elements of the GAD connected to the same GAD element. These generated instructions are stored in the instruction cache 630.

The instructions may be structured in the instruction cache 630 based on the structure of the GAD elements received from the GAD input 670. The instruction unit 665 receives the result of identifying which rays collide with which GAD element and both the logic 203a and the instruction unit 665 group these rays together for later testing. 203a). The system of FIG. 6 becomes a general purpose system in that the ray packet for testing may be one of several types of packets for accommodating different functions.

For example, the GAD input 670 can provide a graph of the GAD, where the nodes of the graph represent elements of the GAD, and the pair of nodes are edge connected. The edge indicates which node is connected with another node, and the instruction unit 665 is configured by the instruction cache 630 by the next edge connecting the nodes to identify whether the command already exists in the cache for the specified GAD element. You can search for. If multiple commands exist for a given GAD element, they can be linked to one list, ordered, or associated with each other. Other methods may be implemented, such as hashing a GAD element ID to identify a potential location in the instruction cache 630 where relevant instructions may be found.

The command may refer to the GAD node under test, thereby causing the command to fetch the connected node of the GAD in response to the issued and decoded instructions (as opposed to storing the command for each connected node). Each of these connection nodes can be streamed through test cells 610a-610n for testing with individual light rays stored in each test cell (ie, light data is provided by a plurality of GAD elements in each test cell). The test cell remains stationary in the test cell, and each test cell in turn tests the beam against each GAD device).

Thus, a processor implemented in accordance with this embodiment provides functionality for generating or obtaining instructions for connecting nodes to collect the identified rays with respect to the intersection with the first node for cross testing. As in the example described above, where the GAD provided to the processor 605 is hierarchical, the graphs of the GADs may be concatenated in a hierarchical order.

Exemplary connections and sources of GAD are illustrated and other arrangements are possible. For example, memory 615 may be the source for the GAD element. However, it is desirable to store the rays (i.e., data defining the rays and data such as the present nearest nearest circular intersection) in a high speed memory rather than geometric data. The processing architecture specified here is allowed. Also, in the above example, the next node to be tested (i.e., the next accelerating element or prototype) was determined based on the test result, and in response, the packet was instantiated per geometric shape. Another implementation that may be apparent from this description may include instantiating a packet for each "child" node when deciding to start testing for a child node of a specified node, where the specified node may be a child command / Create a collection.

FIG. 7 further illustrates various aspects of a ray tracing system (eg, system 700) that may use cues for cross testing and separation operations of ray shading (including generating new rays including camera rays). . System 700 enables the provision of light beams for cross testing and on-off of cross testing, thereby producing outputs for shading in a different order, such as the system of FIGS. 1-6. Likewise, the cross test resource can proceed with cross testing of the beams without limiting the shading resolution of the previously-identified cross.

7 shows a plurality of cross test resources (ITRs) 705a-705n, each resource coupled to a ray data storage 766a-766n, respectively. This storage stores data that defines the ray to be tested for intersection in the resource. Each group of ITRs and ray data storage (eg, ray data 766a and ITR 705a) may be shown as a localized grouping of test resources (eg, the grouping shown at 704). This is similar to previous groupings such as, for example, grouping 578 and 579 in FIG.

Ray data storage 766a-766n may be memory such as a private L1 cache, a shared or mapped portion of the L2 cache, and the like, as in the previous example, where fast memory is localized to a specific processing resource, rather than geometric data. It is desirable to be used to store the generated ray data. Localized storage of ray data is made easier by the cross-test algorithm used here, which increases the length of time that the ray can be stored in more localized, faster memory, and reduces the amount of thrash in small memory. Decreases. As such, this ray storage device may appear to be quasistatic in that the data for a given ray is stored in the same local memory until the crossover test of the scene is complete.

The data defining light beam is loaded via the output 743 from the test control unit 703 (similar to logic 203b, etc. in the previous figure). The test control unit 703 receives an input that includes an identifier for the light beam through which the cross-test at the ITRs 705a-705n is completed via the light completion queue 730.

Queue 730 stores ray identifiers (in some examples Ray IDs 1, 18, 106, 480 are shown). Queue 730 takes input from ITRs 705a-705n, which represents the light beam that completed testing in the tested scene to identify the nearest intersection crossed. As such, the queue 730 can be used if the output specified from the ITRs 705a-705n is information about the GAD element or if the nearest circle (ITR 705a-705n) can test both types of shapes. May be supplied from decision point 751 which may determine whether to represent the intersection of

Decision point 751 represents the two types of cross control functional units described previously. One is that the GAD / ray intersection is closer to the cross tester, and the other is that the nearest detection circular / ray intersection is output for shading. In some earlier architectures, where separate test cells are each used, decision points can be tracked when there is the nearest (possible) circular intersection.

From decision point 751, a GAD result is input to mux 752, the mux receives a ray ID input from cue 725, which stores the ray ID received from input 742, and the input is It is input sequentially from the light beam control unit 703. The ray control unit 703 includes an input 742 having a ray identifier corresponding to ray information to be provided to the ray data 766a-766n via the output 743 from the test control unit 703. Thus, the data defining rays (identified by the ray identifiers (ray IDs)) identified in the queue 725 are output via the output 743 and ray data 766a-766n are provided for storage in such a memory. . An example of how the ray ID is formed is provided below.

Two cues 730 and 725 represent a series of identifiers (ray IDs) for the rays. However, as will be described below, a plurality of light rays are generally tested simultaneously for a given geometric shape. Thus, in this case the queue 725 preferably stores the ray ID for the packet of ray IDs, so the queue 730 may represent a series of entries each having a plurality of ray IDs associated with the specified shape.

As a specific example, the algorithm driving this architecture generally waits until it is determined that a plurality of orphans need to be tested for a given shape, after which such a test is performed and the results are output. Thus, it is common to assume that a plurality of rays will complete the test at the same time and begin testing at about the same time. Effectively, these tested light rays can be completely separated from each other in terms of how and when the rays initially instantiate or by the path through which the rays pass through the acceleration hierarchy. Conversely, queue 725 may be considered to contain a group or packet of new rays to be tested against a fixed GAD element of the scene (eg, the root node of the hierarchy of GAD elements).

These new rays originate from light sources including camera shaders 735 and other shaders 710a-710n. Camera shader 735 is identified separately as it generates the primary rays to be tested in the scene. Shaders 710a-710n represent the execution of instructions or logic that operate on computing resources such as threads and / or cores of one or more processors, and specify appropriate responses to identified intersections between rays and circles. Usually, this response is determined at least in part by the shading code associated with the prototype, and various other effects and considerations can be made.

The shaders 710a-710n receive intersecting light rays and circular identifiers through the scattering points 772 and receive such light data from the output 745 of the test control unit 703 (see FIG. 8A). Dispersion point 772 can be used to provide such ray data with a computational resource having the ability to execute code for a given prototype, so that any means for determining this capability is determined by load measurement, a flag set by the computational resource. It can be used to control this distribution, including saturation indicator and FIFO separation. Or round robin or pseudo random variance scheme may be used.

The outputs of the shaders 710a-710n may include other light rays (called secondary light rays for convenience, and the output from the camera 735 includes light rays). In this example, the ray at this point contains origin or direction data defining the ray. However, it is not necessary to have a softened beam ID that is preferably provided by the test control unit 703.

As can be seen, the test control unit 703 can monitor the ray condition of the cross test resource and, as will be described in more detail with reference to FIGS. 8-9, the ray of completed ray data 766a-766n. Allocate a new ray to replace. Dispersion of the ray IDs into the ITRs 705-705n is performed by the spreader 780, which is described in detail with reference to FIG. This distribution is primarily controlled by the memory of the ray data 766a-766n storing data defining the ray identified by the designated identifier. Also, as described with reference to FIG. 10, based on considerations such as the collection wait state, the spreader 780 controls the point in time at which the ray ID is obtained from the queue 725.

Turning now to FIG. 8A, a portion of the test control unit 703 is shown. This control unit includes memory banks each associated with light beam data 766a-766n, each bank having a slot in which the light beam data is dense and can be addressed by a memory address. 8A shows that the output 744 from the ray complete queue 730 includes ray identifiers 1, 18, 106, and 480, each of which has an allocated space in memory 803. This space is allowed to be overwritten / filled in response to receiving such a ray identifier from output 744. Output 745 to scatter point 722 includes ray data for use in shading. Output 745 may also include other data. Indeed, memory 803 may be implemented in memory that is also used by other processes, such as process execution shaders 710a-710n. In such a case, the output 745 may represent (or may be implemented by) the retrieval of such data from the memory 803 by computational resources.

Various communications links are identified in FIG. 7, such as links 741, 742, 743, 744, 745, 750, 790. One of these links may be implemented according to an overall architecture implementation and may include unique memory regions, physical links, virtual channels installed on an expansion bus, shared register space, and the like.

8B shows data for new light rays coming out of output 741 (eg, from a shading operation such as camera shader 735). Such ray data includes at least ray origin and direction information. The test control unit 703 now assigns this new light ray to a location in the memory 803 that is different from the light ray data 766a-766n. The identifier associated with each ray origin and direction depends on where the identifier was stored. Thus, input 742 (input to queue 725) receives a ray identifier determined according to this basis. The output 743 also includes both origin and direction information associated with them stored in the beam identifier and memory 803. The arrangement of the ray ID shown in Figs. 8A and 8B is convenient in that the ray ID can be used to index a memory for identifying relevant data. However, as a result, as long as the identification result of the ray data in the ITRs 705a-705n and the memory 803 is affected by the use of the ray identification data, other kinds of identifiers for the ray can be used.

9A shows an example where a content associative memory 910 holds a key 905 each associated with different ray data.

9B shows that a slot in each ray data 766a-766n is provided to receive the ray data from the test control update 703 via the interface 743. Such slots may be further subdivided into multiple banks, interleaved, and / or other cache structured mechanisms to facilitate retrieval of data from the cache. Where the ray needs to be distributed for storage, this dispersion is based on the least significant bit of the ray ID, either by hashing the ray ID, or by module partitioning with multiple banks where dispersion will occur. queuing, or otherwise, may be enriched by a distribution mechanism that can be used to distribute the ray data into memory. Within any designated portion, ray data may be stored based on ray Id.

In summary, Figures 7-9B illustrate an architecture in which the beams to be tested are collected by the control logic and the identifiers are assigned, the identifiers being memory where the beam definition data can be stored in individual caches connected to different cross test resources. Preferred based on location. The prototype cross test results come from the test resources as they are completed, and the test logic reallocates memory locations for these completed rays with new rays that need to be tested later. The completed rays may be shared in one of a plurality of different cross processing / saiding resources, which may create additional rays to be tested. In general, light rays traverse the entire accelerated structure through cross test resources until the closest circular intersection is identified (or until the light is determined not to intersect with the scene background).

Returning to FIG. 10, additional architectural aspects for rendering the system are shown. One aspect of FIG. 10 is that ray data may be stored in a separate cache memory coupled to a processor configured for cross testing. Another aspect is how the disperser 780 can interface with the ITRs 705a-705n. A further aspect shown relates to how shape data relating to the test is provided to the tester.

Disperser 780 receives the ray identifier from mux 751 (FIG. 7) via communication link 790 (implemented in hardware, interprocess or interthreaded communication, or the like). This ray ID is sent to the collection management unit 1075, where the association between the ray ID defining the object to be tested next and the individual GAD elements is maintained. The ray ID is also determined by the decision 1013, 1014, 1015 between the queues 1021, 1022, 1023 waiting for the decision result from the collection management and storage unit 1075 to test their collection. Can be dispersed. For example, the collection 1045 is determined to be ready for testing, the beam IDs are sent to individual ITRs 705a-705n, and the cache 1065a-1065n of the ITRs contains data for each of these beam IDs. do. The collection management unit 1075 may also have an interface for storing GAD element data and / or prototype data to begin searching for the geometric shape required for the test.

This shape reaches the queue 1040 from storage 103 (FIG. 1), for example via link 112. These shapes are identified based on their association with the elements of the GAD associated with the specified collection. For example, in the case of hierarchical GAD, this shape may be the child of the parent GAD element. Each ITR may test its rays in series for appearance from cue 1040. Therefore, the highest throughput can be obtained when the rays of the specified collection are equally distributed between the caches 1065a-1065n, and the collection management unit 1075 can most easily update the collection based on the test results of the designated rays collection. Can be. When multiple rays of a given collection exist in one cache, the rest of the cross-test is delayed. Or they can test the rays from the next collection. Before the collection test synchronization is required again, the tests in which the maximum order is reversed can be adjusted.

An output is generated at the output stages 750a-750n (which can be a component of the link 750, FIG. 7), which is provided to decision points 751, FIG. 7. As described above, this architecture is provided by an ITR that tests any shape (eg, a circular or GAD element). In addition, decision point 751 coupled to collection management unit 1075 indicates that the result of the GAD crossover test includes a determination that the specified ray collides with the specified GAD element, which indicates that the collection of identified rays corresponds to the GAD element. To be added to. Thus, another implementation may include providing the GAD test results directly to the collection management unit 1075. More generally, the described examples illustrate the flow of tentative information, and other flows can be appreciated from them.

Another aspect of the invention to be noted is that one or more ray IDs for a given ray collection may be stored in any of the queues 1021, 1022, 1023, shown by the collection 1047. In this case, the ITR for that queue can be tested, as it becomes available, as a result of the ray and secondary test (or many subsequent tests). Decision point 751 may wait for all the results of the collection to be collected, or the "straggler" results may be propagated as needed.

In summary, FIG. 10 illustrates a system structure that allows packets of ray identifiers to be associated with one or more shapes to be distributed in a queue for a plurality of test resources, each of which stores a subset of ray data. Each test resource fetches the ray data identified by each ray identifier for the shape loaded into the test resource. Preferably, this shape can be streamed serially consistently across all test resources. The shape can be identified by a sequence of children starting at one address in main memory. Thus, FIG. 10 illustrates system structuring in which one shape is tested simultaneously for multiple rays.

However, another example provides for the step-by-step shape in a series of different cross test resources, where the shape data and the ray identifier packet move between cross test resources. By putting multiple packets in flight, the throughput of the test is increased. Several examples of this approach are described below.

11 illustrates a first example of a computer architecture in which ring bus placement of a plurality of computing resources 1104-1108 may be implemented. Each computing resource has access to a private L1 cache 1125a-1125n, which is provided to that computing resource from shape data storage 1115 in memory 340 for any computing resource used for cross testing. Includes ray data to be cross-tested using geometric shapes. Communication between computational resources 1104-1108 can be accomplished by bus 1106, which can include a plurality of point-to-point links or any other architecture suitable for such inter-processor communication.

Where computational resources share a particular memory structure (eg, L2 caches 1130 and 1135), communication between computational resources 1107 and 1106 sharing these computational resources (eg, L2 cache 1130) They can communicate with each other through a purposeful cache. In addition, a copy of the data regarding the light beam under test in the system may be stored in the light data 1110, for the distribution of their subset between the light data 1110a-1110n, such light data being L2 (1130). ) And L2 1135, and many of them may be stored in the L2 cache (described below). Shape data 115 may also be present in memory 340 and temporarily present in one or more of L2 1130, 1135 and in either cache 1125a-1125n. However, the ray data stored in these caches is protected from overwriting the shape data, and the amount of space allocated to these shapes is typically used without attempting to maintain shape data, without indication of when it will be used next in the test, It is limited to what can be used for the currently identified ray packet as waiting for a test and sufficient to defend against latency for shape data 115. In other words, for ray data,

11 also preferably avoids using a typical cache management algorithm, such as replacing a least recently used.

11 also illustrates that in addition to the replacement test, the application and / or driver 120 can be executed on the computational resource 1104. In addition, ray process 1121 may be executed on arithmetic resources 1108, and packet data 1116 may be stored in cache 1125a for use by packet process 1121. Other packet data may be stored in L2 1129. However, similar to ray data, it is desirable to store packet data in the fastest available memory. The packet process performs many of the same functions as the collection and other management logic derived from the previous figures. That is, it selects the GAD element that is waiting to be tested by tracking which rays intersect which GAD element and, for example, having enough rays tested for the ruler of the GAD element with sufficient rays crossed.

In this example, because the packet process 1121 is centralized, it operates by issuing a packet that includes a plurality of ray identifiers and a reference to the shape to be tested for intersection with the identified ray or data for the shape. do. Each computing resource 1104-1107 that performs a cross test receives a packet. For example, it is received continuously on a plurality of point-to-point links (described below) or simultaneously on a shared bus type medium (which is similar to the architecture of FIG. 10). Each computing resource 1104-1107 determines whether localized ray data 1110a-1110n stores data for any ray identified in the packet, and in that case retrieves data for that ray. Test it and print the result.

Since the results for GAD element intersections are tracked by the packet process 1121, any communication mechanism that returns this result to the packet process 9121 is suitable. This mechanism can be selected based on the overall architecture of the system. Some exemplary approaches are described below and may include separate identification results for each found intersection. Alternatively, each test resource can use a crossover result to densify cyclic packets.

12 shows a further embodiment of the structure of the computational resources 1205-1208, associated with the caches 1281-1284, each of which stores ray data 1266a-1266n and packet data 1216a-1216n. do. Each computing resource 1205-1208 is connected to one or more other computing resources by the queues 1251-1208. Ray process 1210 provides input to computational resource 1205 via queue 1250. Ray process 1210 is in communication with an application / driver 1202. The output 1255 from the computational resource 1208 is coupled to the ray process 1210. Another output 1256 is coupled to a computational resource 1205. The prototype and GAD storage 103 provides the computational resources 1205-1208 for reading in shape data.

Ray process 1210 receives or generates a ray for testing, and forms a packet that includes ray identifiers and ray data for the identified ray. Packets are delivered to each of the computational resources 1205-1208 through the queues 1250-1254. Each computational resource 1205-1208 acquires a portion of the ray in the designated packet, in some examples only one ray and stores a portion of the ray in ray data 1266a-1266n. Another example includes sending a predetermined packet to a particular computational resource 1205-1208 such that the ray process 1210 determines which ray data is to be stored in which localized ray data 1266a-1266n.

After the rays are loaded into the localized storage, they are then identified by packets containing only the ray ID without origin and direction data. This packet also contains either a reference or data to the shape to be tested for the light beam identified in that packet. In some examples, the data forming these packets is distributed between the localized memory 1281-1284 of the computational resources 1205-1208. Thus, each of the computational resources 1205-1208 is configured at a specified point in time. Keeps a portion of the packet data for the ray under test and distributes information about which ray will be tested next for which shape, so that each computational resource 1205-1208 can test the collection of pending tests. To begin with, it may issue a packet of ray ID and shape information.

Each packet makes a round through the queue and computational resources, and then retransmits it to the originating computational resource according to the results of the cross-test aggregated therein. In one implementation, each computing resource 1205-1208 fetches shape data for the packet to issue. For example, if a computational resource 1205 has a packet waiting to be tested (e.g., a collection of rays for a given GAD element), the arithmetic resource may be shaped to be tested by this association (e.g., the ruler of the GAD element). It can fetch, create a packet with data for each shape, and send each packet from queue 1251.

Next, after the packet has moved through another computational resource, the computational resource 1205 receives each packet it has emitted. When received, each packet contains the results of testing the shape in the packet (reference or definition data) regarding the intersection with the ray identified in the packet stored / stored in the remaining computational resources 1206-1208. Computational resource 1205 may test any identified rays localized to ray data 1266a at any time before or after the remaining compute resources perform their tests. Thus, ray definition data can be distributed among a plurality of fast memories coupled to cross test resources, and test results can be collected in a distributed manner.

The method of implementing the architecture according to FIG. 12 takes into account various characteristics of the physical system in use. For example, a queue is shown that transmits packets in one direction. However, transmitting packets in both directions can also be implemented (i.e. bidirectional queues or multiple queues). 12 also spreads data packets between computational resources, allowing more L2 caches and potentially more distributed forms of memory access to other ports to potentially large memory (eg, main memory 103).

If the packet data is centralized, a packet transmitted in one direction with the data reference may have fetched data, for example, by the computing resource 1205, and a packet transmitted in the other direction with the data reference may have a computational resource ( 1208) may have data fetched. This situation can be generalized to provide any entry point with a ringbus architecture (one-way or two-way).

As demonstrated from the content, the described queue may include one or more queues for inputting new rays for cross testing into a system comprising a plurality of cross test resources, and for interconnecting cross test resources. In some cases, the queue for entering new rays may include ray definition data (eg, a queue waiting to store data in a cache connected to the cross test resource). Such a queue may be implemented in an enumerated manner in main memory that stores ray definition data. It is preferable that the queue interconnecting the cross test resources for sending packets only contain ray identifiers, not ray definition data.

13 illustrates some of the potential implementations of system 1200, where the computational terminology may be implemented in cores of a chip, so that computational resource 1205 is one core and computational resource 1206 is another core. . The queue 1251 here is intercore communication. Also shown is an interpolated L2 cache 1305 that can store ray data as well as shape data.

As described with reference to the previous figures, the L2 cache 1305 stores some of the scene figures and acceleration data, as long as the thrashing of the ray data is increased by storing such data (ie, ray data is cached). Prioritize storage).

14A-14C each illustrate various relationships a queue may have in accordance with various implementations of the exemplary system. In general, communication between computational resources need not be serial or 1: 1. For example, in FIG. 14A, one input 1404 may be input to both queues 1405 and 1406, and these queues may be specialized for one computation unit 1407 and 1408, respectively. For example, where computing units 1407 and 1408 are implemented on a single physical chip, input 1404 may be a chip level input, and each queue 1405 and 1406 may be for a particular core.

FIG. 14B shows that a single input is input to multiple cores, which cores may input to computing units 1407 and 1408, respectively, which individually route data to opposite queues 1406 and 1405. Can transmit 14C shows that queue 1411 receives input 1410 and provides it to both output computing units 1407 and 1408. Thus, FIGS. 14A-14C illustrate that various queuing strategies may implement packet transmissions in accordance with these aspects.

15 illustrates that where multiple levels of cache metrology exist (eg, level 1 caches 1502 and 1503 and level 2 caches 1504, various combinations of ray data may be provided. For example, ray data 1507 may include separate subsets of ray data 1505 and 1506, and similarly no other ray data may be present in one or more of ray data 1505 or 1506. One queue Ray data 1505, 1506 can be dynamically changed, as is the case when the input to one or more computational resources (FIG. 14C), the ray data 1505 or 1506 of the ray stored in ray data 1507. ) To reflect the result of the assignment.

16 illustrates in detail an implementation example of a queue 1251 and data that can be stored. Packets 1601a-1601n are shown, each having collision information fields 1610a-1610p, 1611a-1611p, 1612a-1612p, corresponding to individual ray identifiers 1605a-1605p, 1606a-1606p, 1607a-1607p. . Packet 1601a includes data 1615a for shape 1, packet 1601b includes data 1615b for shape 2, and packet 1601n includes data 1615n for shape n . Of course, various other queuing strategies (some of which are shown in FIGS. 14A-14C) may be implemented.

The term queuing, as used herein, does not add a first in / first out condition for a ray tested on any specified computational resource. On average, the rays identified in any given packet will be evenly distributed among the ray storage localized for different computational resources, resulting in parallelization for each packet. In the case where a plurality of light rays need not be tested for one packet in one computing resource, a bubble may be formed in which no other computing resource has rays to intersect for that packet. These bubbles can be filled by other operations, which involve cross testing of other packets. In some examples, each computational resource may maintain state for multiple threads and switch between threads that are stationary for a given packet. Basic throughput gains should be realized as long as the data for each cross test between packets can be kept in a register.

Partly summarized in terms of operation of the example system, each computing resource operates in response to receipt of a packet. When a packet arrives from an input queue for a particular computational resource, the computational resource examines the ray identifier in that packet and determines whether the identified ray in the packet has data stored for the identified ray in a separate memory. Stated differently, a packet may be formed using a ray identifier without prioritization information on which computational resources include fast access to ray data for the ray identified in the packet. Furthermore, each computational resource does not make a responsive attempt to obtain ray data for all identified rays in the packet. It only determines if it has ray data in the local fast memory for any ray identified in the packet, and performs ray ray tests only for intersection with the identified shape.

17 is intended to illustrate various aspects of how a packet can be processed in an exemplary computing resource. 17 illustrates that a packet 1601 is input to an arithmetic resource 1206. The computational resource 1206 queries the ray data using the ray identification result from the packet 1601a (eg, ray 1605a has ray ID 31 and ray in ray data storage 1266b). Query whether ID 31 is matched). The origin and direction associated with ray ID) 31 is retrieved through 1290. Also, shape data (if identified in the packet) is obtained (1715) from the memory resource 1291 where the current shape data is stored. If shape data is not provided in the packet, the shape data is used directly. The light beam 31 is then tested 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 this crossover test is to determine a subset of scene prototypes that may have the potential to intersect with the tested ray. Thus, the positive hit (collision) result is rewritten (1726) in packet 1610a at a location relative to the ray identifier (i.e. ray identifier 31). In some implementations, the sender of the packet can track what ray ID is transmitted and what order in the packet, and the inferred order is the same order as the transmission, so only the results need to be rewritten. Thus, after passing the tester, the packet transfer (emission) resource can process the test results.

On the other hand, when the tested shape is a circle 1730, the closest circular crossover determination unit 1731 may determine whether the detected crossover is adjacent to any previous one. Then, in the case where the detector is a crossed circle, optionally the intersection distance can be stored or output using the packet. Since a given ray is associated with multiple packets (ie, concurrent with multiple GAD elements), a count may be kept every time the ray is associated with a GAD element (1733), so that the count is any other that the ray needs to be tested. It is possible to determine when a packet no longer exists and cause the memory used for that ray to be free for the input of another ray.

In summary, it is preferred that the data associated with each ray in the local fast storage device include the nearest detected circular intersection identifier, which includes a parameterized distance and circular reference to the intersection. Other data associated with each ray includes the count of the GAD element ray collection in which the ray is present. After each collection is tested, the count is decremented and the count is incremented when another collection is created. When the count is zero, it is determined that the circle identified as the nearest intersection circle will be crossed by that ray.

18 relates to an exemplary single instruction multiple data (SIMD) architecture, which may be used where a packet can identify the beginning of a strip of geometric shape for testing. In one example, nodes in the GAD element graph are edge connected to one or more other nodes, where each node represents an element of geometric acceleration data, such as an axis or sphere, aligned to define a box. In some examples, the graph is hierarchical, and therefore, when testing a designated node, the chair of the designated node is known to define the selection of the circle defined by the parent node. The GAD element finally defines the selection of the prototype.

In an implementation, the string of acceleration elements, which are children of the designated element, may be identified by the memory address of the first element in the string. The architecture then provides a predetermined stride length to the data of the starting point of the next element. A flag may be provided to indicate the end of the specified string of elements that is a child node of the designated node. Similarly, a circular strip can be identified by the starting memory having a known stride length to define the next prototype. More specifically for triangular strips, two vertices of a sequence may each define several triangles.

FIG. 18 is intended to illustrate various aspects of a SIMD architecture similar to the SIMD architecture shown in FIG. 6. In this example, the multi-beam identifiers 1605a-1605n, optionally storage space for receiving cross-test results 1610a-1610n, and shape definition data, identifiers for shapes, or strips of shapes to be tested (e.g., A packet 1601 is received that includes shape data that includes an identifier 1815a for the beginning of a triangle circle).

This example architecture is suitable when a small number of powerful individual processing resources (with large caches) are used for cross testing. Here, it can be expected that each individual processing resource will, on average, have a number of rays of local storage that is approximately equal to the number of rays that can be tested by the SIMD instruction (in contrast, FIG. 10 is in each collection). Shows an example where it is desirable for each cache to have one ray. For example, if four rays can be tested simultaneously in the SIMD execution unit, it is desirable to have four rays statistically in the local storage that the SIMD unit in each packet goes through. For example, if four separate processing resources are provided, each has a SIMD unit capable of testing four rays and one packet may have about 16 referenced rays. Alternatively, a separate packet may be provided to each processing resource having a SIMD unit, such that, for example, the packet may have four rays referenced when there is a 4 x SIMD unit.

In some examples, first computing resource 1205 receiving packet 1601 may use identifier 1815a to obtain data for a strip of shape. Subsequently, each ray referenced in the packet 1601a stored in the ray data 1266a is tested in the computing units 1818a-1818d. In the example of a shape strip, shape strip 1816 is retrieved, which includes shapes 1-4. Each shape can be streamed through each computing unit 1818a-1818d and tested for intersection with the rays loaded in that unit, respectively. For each shape of the strip, the computational resource may organize packets (packet 1820 shown) that each contain the results of testing the light beams for one of the shapes.

Alternatively, a separate bit may be provided in the result section for each ray that received the intersection result, and one packet may be passed. To avoid being fetched back from the slow memory, this approach can be used when multiple computational resources can share L2, or when a patch by a first computational resource sends shape data to another computational resource. It is considered the most suitable. For example, a DMA transaction may include multiple targets. Each target is a different computational resource that needs to receive a testdori shaped stream and is an example of a memory transaction model suitable for some implementations. The principle consideration is to reduce the fetch of the same data from main memory 103 more than once.

As previously described, each cross test resource determines which identifier has ray data stored in its ray data storage. For any ray, the ray origin and direction is retrieved. Above, an example has been provided in which a test resource can test a designated identifying ray using a sequence of one or more identified shapes. Apparently, processing resources can test a plurality of shapes that intersect a specified beam at the same time, or test one shape and a plurality of beams, or a combination of the two, without substantial additional latency. In FIG. 18, a SIMD architecture is shown, which can test different rays intersecting the shape of each of the four SIMD units successively provided within one computational resource configured for cross testing. The sequence of shapes can be fetched based on the shape strip reference used as an index into the scene data storage 340 to begin searching for a series of shapes, each of which is tested in the computation unit 123. And four.

Preferably, the rays are collected into the collection based on the detected intersection between the collected rays and the elements of the acceleration data. Thus, in this example, when different rays are tested in each SIMD unit for different shapes of four, the computational resources containing the SIMD units may reformat the results into packets of rays, each of which is a packet of rays. See shape.

Other architectures using SIMD units may instead provide a fetch for a plurality of collected rays as a collection. As described above, these rays are next cross tested for the shape relative to the shape associated with the collection. For example, there may be 16 or 32 shapes linked to the collection for the shapes. This first subset of shapes can be loaded into different SIMD units, and the collected rays can be streamed through each SIMD unit (ie, the same rays pass through each SIMD at the same time). The resulting packet can be formed independently by each SIMD unit, and the next shape is loaded into the SIMD unit. The light beam can then be recirculated through the SIMD unit. This process continues until all relevant shapes have been tested for the collected rays.

18B shows the time-based progression of computing unit 1818a for this example. At time 1, shape 1 and ray 1 are tested. These shapes are numbered from 1 to q, and light rays from the collection are numbered from 1 to n. At time n, shape 1 and ray n are tested. At the beginning of the next cycle (time q-1 * n + 1), the final shape starts testing in the computation unit 1818a.

FIG. 19 illustrates various aspects of test results and how the packet 1905 is distributed for cross testing between computational resources, where the test results are operations that manage memory for the ray of packets associated with the identified shape 1905. Finally merged within the resource 1910. 19 illustrates an example system state during processing. Specifically, arithmetic resources 1910-1914 each receive ray ID information for a ray stored in a memory accessible to the arithmetic resource, test the identified shape for the intersection, and output a result 1915-1919. . The output result includes the identified conflicts 1915, 1917, 1919. Either hit or non-collision may be the default behavior, so for example, non-collision may not be indicated as a positive or default (fixed) value, or the default value in the packet may be set to non-collision. . After the test, the computational resource 1910 collects at least collision information, where the computational resource 1910 can manage all packet information or a subset thereof, including those for a particular appearance in the test system.

Exemplary structuring of the memory 1966 represents a logical structuring of shape references mapped to a plurality of ray IDs (rays A, B, etc.). It also indicates that some slots in the row related to Ref # 1 (reference to the shape under test) are empty. Thus, when the computational resource 1910 receives a collision result, it first populates the remaining empty slots of the specified Ref # 1 collection, and then at 1966, ray n starts a new packet for Ref # 1 in memory 1966. Is shown. Now, because the packet for Ref # 1 is saturated, this packet can be determined to be waiting for testing. In some examples, a child GAD element of the shape referenced by Ref # 1 is fetched, and a packet is formed using all the rays associated with Ref # 1 in each packet. For example, there are 32 children packets of Ref # 1, and thus 32 packets can be formed using the illustrated packets 1922-1924. In some embodiments, arithmetic resources 1910 may fetch data defining child shapes and store data in packets 1922-1924. Alternatively, references are provided that allow other computational resources to fetch such data.

In some cases, arithmetic resources 1910 may also store the identified rays in the generated packets, thus testing the rays first before sending the packet. In this case, the computation resource 1910 may store shape data already fetched in the transmitted packet. As described with reference to FIG. 12, the examples may allow such a packet to be sent to one or more other computing resources (eg, bidirectional queuing, random-to-random, etc.).

20 is intended to illustrate some examples of how a method in accordance with the described aspects may be implemented. A packet is sent, including shape information, ray ID, and location where collision information is rewritten (2005), and collision information can be zero'ed and "don't care" at this point. The first test is performed on ray 1 ID (2006) and finds a collision, thus one 1 is written to the packet and the packet is passed to the second test (2007), where ray 3 is first. It was found to be localized for 2 tests, and found to be non-collision, so one zero is recorded (or maintained), and collision information from test 2006 is moved in the packet direction (i.e. within the packet). Rays are tested sequentially) A third test (2008) is performed on rays 2 and found to be collisions, this example shows that the rays in a packet can be tested out of the order in which they exist in the packet, and Which tester is responsible for the specified beam ID The test sequence is determined by whether it was best suited to access the ray data, the test continues until all the ray IDs have been tested (2009), then packets are merged, which means that only collision information needs to be maintained. This coalescing can occur in the computational resource that originated the transmitted packet A new collision result can be combined with a collision result from a previously existing packet (see Figure 19). It is determined whether or not this test is waiting (at 2025, based on fullness). Otherwise, another packet may be processed (2040). If in waiting, the shape of the shape associated with this packet is Is fetched 2030, where the parent node 2041 is, for example, the shape and child node of the node identified in step 2042. The new packet is then sent to the packet associated with the parent. For each shape having a beam identifier of the emitter, it may be generated.

21 and 22 help to summarize the method aspects described above in terms of the content of a system that can be used to implement. Specifically, FIG. 21 illustrates a method 2100 in which the method 2100 assigns circular and GAD elements to the main memory, and defines beams for cross testing using beam definition data (e.g., origin and direction information). 2110). Each ray may be identified 2115 using an identifier. A subset of the ray definition data is stored in localized memory associated with individual processing resources of these plurality of resources. Rays are scheduled for testing by distributing identifiers and shape data about these rays between processing resources (2125). The ray is tested 2130 at a processing resource having definition data for the locally stored ray. In some cases, each ray may have definition data in one local memory.

The identification of the intersection between the ray and the circle is passed 2135 from the first subset of computational resources to the second subset. The second subset shades 2140 the intersections. This shading creates a new ray and the definition data for it is distributed between localized memories (2145), preferably crossing the definition data for the completed ray. This beam is then tested as described above. A subset of computational resources may be implemented by instantiation or by computational resource allocation, where the computational resources include instantiation threads running in a multithreaded processor or core. The allocation can change over time, and static allocation between resources for cross testing and shading is not required. For example, a core running a thread of cross-tests may complete a series of cross-tests and fill the memory space with many identifications for ray intersection with the prototype. The core may then switch to shade these intersections.

Some of the examples above have been described primarily in terms of testing GAD elements for intersections. The result of this test is to group the rays for a progressively smaller circular grouping (via a combination of ray IDs using specific GAD elements). Finally, it has been described that the GAD element identified by the test will define a prototype to be tested for the identified rays as it becomes part of the group associated with the GAD element. For packets with a circle, the result of the crossover test is the identification of the ray / circle intersection, which (for convenience) usually tracks the nearest intersection detected for a given ray, using other data defining the ray. It is obtained by doing this.

Subsequently, after the specified ray has been tested for the entire scene, the nearest detected intersection, if any, is used for each ray, using these results to start the shading process or the ray ID to the application or driver. Return to the other process. As in various embodiments of this specification, ray identifiers may be returned via a queuing strategy (i.e. specifying which computational resources to execute the shading code for a particular intersection or tested by a predetermined shading resource. There is no need to specify a particular cross test resource with detected cross sections). In some crossover tests, the center of gravity coordinates are calculated with respect to the crossover test, and these coordinates can be used for shading if necessary. This is an example of other data that may be sent from the cross tester to the shader.

In general, any of the functional units, features, and other logic described herein may be used to implement various computing resources. The computational resource may be a thread, core, processor, fixed function processing element, or the like. In addition, other functional units (eg, collections or packet management units) may be provided or implemented as a process, thread or task that may be distributed among a plurality of computing resources or localized to one computing resource (e.g., a plurality of Multiple threads distributed among physical compute resources). The task primarily involves identifying packets in an in-flight state that contain cross-test results for shapes having collections managed by the compute resource.

Similarly, the computational resources used for cross testing may host other processes, such as the shading process used to shade the detected intersections. For example, a processor executing a cross test can execute a shading thread. For example, in a Ringbus implementation, if the queue for one processing resource does not currently have any packets for cross testing, then the data processing resource replaces the thread for shading the previously identified intersection. You can start The fundamental difference between having a cross test thread on a given processor and operating the shading thread with respect to the ray intersection detected by this thread is that no requirement or general relationship exists. Instead, the queued ray / circular intersection provides ray input to the shading thread, so that the mapping between the cross test resource and the shading resource can be arbitrary versus arbitrary, so that different hardware units or software units Cross testing and shading can be performed on the same orphanage.

Similarly, various interfaces that mediate communication between various queues and different functional units (eg, between cross test resources and between cross test and shading) may be selected according to considerations related to the physical resources suitable for implementing them. It can be implemented in one or more memories according to one of various buffering strategies. Queues may be controlled by source resource or destination resource. In other words, the destination may expect data on the shared bus and obtain the required data, or the data may be addressed to the destination by memory mapping, direct communication, or the like.

As a further example, where the core supports multithreading, a thread may be specific to shading while other threads may be specialized for cross processing. However, instead of keeping ray data (which maintains cache allocation priority for cross-test resources), care must be taken to avoid inconsistencies (confusing) of the cache resulting from fetching textures or other shading information.

Since this architecture has the advantage of reducing cache conditions for shape data, considerations about cache coherency with respect to data types are reduced. In fact, in some implementations, it is possible to continue to use certain shape data, and it is not difficult to predict when the shape data will be used again. Instead, when a specified packet of rays IDs is waiting for testing, shape data about these packets is obtained from and stored in the fastest memory, and the current workload for processing other packets is in this patch operation. It will defend against latency incurred. After testing this shape for intersection, the shape data may be allowed to be overwritten.

Any one of the queues identified herein is implemented in a shared memory resource in the SRAM, such as a linked list, circular buffer, memory serial or string memory location, or in the form of any functional unit known in the art with respect to the queue. Can be. The queue operates to maintain the priority of the packets, so that the first packet is output first. But this is not essential. In some examples, each computing resource is provided with the ability to examine a specified number of packets in a queue to determine whether it is beneficial to process the packets out of order. Such an implementation is more complex than a sequential operating system and can be provided as needed.

Computer-executable instructions include, for example, instructions and data that cause a general purpose computer, special purpose computer, or special purpose processing device to perform a particular function or group of functions. The computer executable instructions may be, for example, binary, intermediate format instructions such as assembly language or source code. Although some main objects have been described in language that specifies embodiments of constructive features and / or method steps, the main objects defined in the appended claims are not necessarily limited to the described features or operations. Rather, the described features and steps are disclosed as examples of components of systems and methods within the scope of the appended claims.

Above, various examples of computing hardware and / or software programs have been described, and likewise, how such hardware / software communicate with each other has been illustrated. Embodiments of software and hardware consisting of such communication interfaces provide a means for achieving the functions belonging to each of them. For example, the means for cross testing according to some embodiments of this specification may include any one of the following: (1) a plurality of independently operating computational resources, each of which is localized in ray definition data; Having a storage area and operative to test the intersection of a shape and a light beam in response to providing an identifier for such light and shape data.

For example, the means for managing the collection of rays tracks a group of ray identifiers and provides information for forming a packet having shape or shape data determined by the shape associated with the group of ray identifiers and the ray identifier, Contains computational resources consisting of programming, FPGAs or ASICs, and parts of them.

For example, the functional unit described above includes completing the crossover test and sending an identifier for the ray intersected with the circle for processing to a computational resource configured to shade this crossover, via a queue. Means for implementing the functions may include hardware queues, or shared memory space structured as queues or lists (e.g., memory consisting of ring buffers or linked lists), and the like. Thus, such means may include programs and / or logic to cause the ray identifier and the circular identifier to be obtained from the next or specific slot or memory location in the queue. The controller may manage the queue or memory to maintain the next read position and the next write position for outputting or inputting the light and circular identifiers. This queuing means can also be used to interface cross test resources together when such resources deliver packets of ray identifier shape data to each other. This queuing means may also be used to receive a ray identifier for a new ray waiting for the start of the crossover test. Thus, more detailed queuing functionality can be implemented by such means or equivalent.

For example, the functionality described above includes shading the identified intersection between the ray and the circle. Such functionality may be implemented by means including computational hardware configured using programming associated with crossed primitives. Programming allows the computing hardware to acquire data such as textures, procedural geometric changes, etc., to determine what information is needed to determine the effect of light on the impacted prototype. Programming can cause additional intersections to be generated to generate new rays (eg shadows, diffractions, half-beams). Programming may interface with an application program interface to generate these rays. The rays defined by the shading program include origin and direction definition information, and the controller can determine the ray identifier for the rays thus defined. Fixed functional hardware can be used to implement some of this functionality. However, it is desirable to allow programmable shading to make use of computational resources that may be constructed in accordance with code associated with prototype and / or other code as needed.

For example, another function described above maintains a master list of rays under cross testing and / or awaiting cross testing, and distributes a subset of the master rays between distributed cache memories associated with the means for cross testing. . Such functionality may be implemented by means including processors or groups of processors that utilize integrated or separate memory control devices to interface with memory for storing data under the control of programming that implements such functionality. Such programming can be partly included in drivers that are associated with or control cross test functionality.

Various aspects of the described and / or claimed functions and methods may be implemented on a specific purpose or general purpose computer (including computer hardware), as will be described in detail herein. Such hardware, firmware, and software can also be implemented on video cards or external or internal computer system peripherals. Various functionality can be provided in a customized FPGA or ASIC or other configurable processor. On the other hand, some functionality is provided to the management or host processor. This processing functionality includes personal computers, desktop computers, laptop computers, message processors, hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, game consoles, network PCs, minicomputers, mainframe computers, It can be used for mobile phones, PDAs, pagers, and the like.

Further, as with links 112, 121, and 118 in FIG. 1 and similar links in other figures, the communication links and other data flow configurations shown in the figures may be implemented in various ways depending on the implementation of the identified functionality. Can be. For example, if the cross test unit 109 includes a plurality of threads running on one or more CPUs, the link 118 may provide the physical memory access resources of such CPUs and the appropriate memory controller hardware / firmware / software. And provide access to the ray data storage 105. As a further example, cross-test area 140 is located on a graphics card connected to host 140 by a PCI express bus, and links 121 and 112 may be implemented using a PCI express bus.

Cross testing, as described in this specification, generally occurs in large systems and system components. For example, processing may be distributed across a network (eg, a local or wide area network), and may be implemented using peer to peer technology, and the like. Separation of tasks may be determined based on the performance or system of the desired product, the desired price point, or a combination thereof. In an embodiment that implements some or all of any unit described in software, computer-executable instructions representing unit functionality are stored on a computer-readable medium (eg, magnetic or optical disk, flash memory, USB device). Or stored on a network of storage devices such as NAS or SAN devices. Other suitable information (eg, data for processing) may be stored on this medium.

In addition, in some instances where terms are used herein, they are believed to convey characteristic points to those skilled in the art to which such terms relate to embodiments disclosed and that encompass aspects of the invention. It should not be understood as limiting scope. For example, light rays are often referred to as having origins and directions, and each such individual item may be shown to represent a point vector in three-dimensional space and a direction vector in three-dimensional space, respectively, for understanding of various aspects of the disclosure. However, within the scope of the present invention, various different ways of expressing light rays can be provided. For example, the ray direction may be expressed in spherical coordinates. In addition, data provided in one format may be transformed or mapped to another format while maintaining the meaning of the information of the originally expressed data.

The above-described embodiments of the present invention are for illustration and description only, and are not intended to limit the present invention to the described form. Accordingly, various changes and modifications can be made to those skilled in the art to which the present invention pertains. In addition, the detailed description of this specification does not limit the scope of the present invention. The scope of the invention is defined by the appended claims.

Claims (23)

In a system for controlling ray tracing in rendering a two-dimensional representation of a three-dimensional scene consisting of primitives, the system is:
One or more cross test resources having access to a separate cache memory that stores a subset of the master copy of the ray data;
In a separate test resource having access to definition data for a ray in the respective cache memory, the control logic for assigning an identifier for each ray and controlling a test of each ray, wherein the control comprises a plurality of individual ray identifiers. Control logic, characterized in that by providing as a cross test resource; And
Output queue that stores data for the crossed circle and data for identifying the ray that completed the cross test by crossing the circle.
Ray tracing control system comprising a. The method of claim 1,
Further comprising a plurality of computational resources for executing shader code routines associated with the prototype,
And the control logic identifies a shader code routine to be executed based on data obtained from the output queue. The method of claim 2,
Execution of the shader code routine generates a new beam of cross tests,
Further comprising an input queue to a plurality of cross test resources for receiving the new ray,
And the control logic starts the cross test of the new light beam as another light beam completes the cross test. The method according to any one of claims 1 to 3,
Each cross test resource is configured to, in response to receipt of a ray identifier stored in a separate memory, test against the intersection of the identified rays with a set of geometric shapes on the data provided by the ray identifier. Control system. The method according to any one of claims 1 to 4,
The crossover test is made between a ray and a geometric shape comprising an acceleration structural element selected from one or more of a cutting plane, an axially aligned bounding box and a sphere of the kD-tree. 6. The method according to any one of claims 1 to 5,
Each cross-test resource is configured to receive a packet of ray identifiers, determine whether individual memory stores definition data for the identified ray, and test the identified geometry and the identified ray in the packet. Ray tracing control system. The method according to claim 6,
The plurality of cross test resources is configured to continuously deliver the packet to a next one of the plurality of cross test resources until all cross test resources storing data for light in the packet have received the packet. Ray tracing control system. The method according to any one of claims 6 to 7,
Each cross test resource stores the results of an acceleration device test in the packet and stores the primary test results for each light in a separate cache memory of the cross test resources until the light beam completes the cross test in the scene. And a ray tracing control system. A method of controlling ray tracing of a scene consisting of a plurality of primitives in a system having a plurality of computational resources, each computational resource coupled to a separate local memory and a shared main memory, wherein the main memory has a greater latency than the local memory. Wherein the method is:
Distributing data defining local subsets of rays to be cross-tested in the scene between local memories of the plurality of computational resources;
Determining a group of rays, the members of the group of rays collectively stored in a plurality of local memories, to test for intersection with a geometric shape;
Providing data for the geometric shape and the ray identifier to the one or more computational resources such that the one or more computational resources having local memory storing definition data for each ray of the group receive the geometric shape data and the ray identifiers; And
Receiving from the computing resource an identification result of the detected intersection between the group of light rays and the geometric shape,
And the identification result is a test result of each ray of the group in one or more arithmetic resources including a local memory for storing definition data for the ray. The method of claim 9,
Fetching data defining the shape from the main memory, wherein providing data for the geometric shape provides the shape definition data to an arithmetic resource having the group of ray identifiers. Ray tracing control method. The method according to any one of claims 9 to 10,
The identification result includes data on the intersection between the geometric acceleration element and the ray, the group of rays being formed by collecting the rays determined to intersect the same geometric acceleration element,
And deferring further testing of the geometric acceleration elements associated with the geometric acceleration elements until the required number of rays have been collected. The method according to any one of claims 9 to 11,
And the local memory further comprises a cache member, and further comprising preventing a specified ray from being overwritten in the cache until the ray has completed the crossover test. The method according to any one of claims 9 to 12,
Maintaining, in separate local memory, the current closest intersection detected for the ray having the ray definition data stored in the local memory, and each identification result for receiving in response to an identification result of the nearest intersection between the circular and the specified ray. Steps to generate
Ray tracing control method comprising a. 14. The method according to any one of claims 9 to 13,
Data for the geometric shape is selected from a set of references identifying one or more shapes to be tested and a set of data defining one or more shapes to be tested. 15. The method according to any one of claims 9 to 14,
The providing step includes queuing a ray identifier with a first queue to which the computational resource is connected for reception;
And the receiving step comprises receiving an identification result from a second queue. The method according to any one of claims 9 to 15,
And keeping a master copy of the rays in said main memory. A computer readable medium storing, in at least one computing resource, a module comprising computer executable code for implementing a method according to any one of claims 9 to 16. In a system for rendering a two-dimensional representation of a three-dimensional scene consisting of a plurality of circles using ray tracing,
A memory for storing a plurality of prototypes constituting a three-dimensional scene;
A plurality of cross test resources for respectively testing at least one of the plurality of circles and at least one ray crossing the scene, and outputting identification results of the detected intersections;
A plurality of shader resources for driving a shading routine for the detected ray / circle intersections;
A first communication link for outputting display indices of intersections detected as the shader resources; And
A second communication link for transmitting a new light beam generated as a result of driving said shading routine to said cross test resource,
A new ray is sent to the cross test resource and completes the cross test in a different order than the ray sent relative order. The method of claim 18,
Further comprising a channel for passing messages between a plurality of cross-test resources,
And the cross test resource is configured to interpret data in a received message as each includes a plurality of ray identifiers, and cross test the selected ray identified in the message. The method of claim 18,
And wherein the cross test resource consists of a ring for passing packets of a ray identifier between the cross test resources. The method of claim 18,
Each of the cross test resources may be configured to generate individual beams for testing according to a determination of whether the cache associated with the cross test resource stores definition data for one of the beams identified in the message passed between the cross test resources. Selecting rendering system. The method of claim 18,
Wherein the plurality of cross-test resources are implemented as threads of computer-executable instructions executing on one or more computing cores, the computing cores each allowing localized cache memory access to a subset of rays traversing the scene. Rendering system. The method of claim 18,
A memory for storing prototypes constituting a three-dimensional scene is implemented as a main memory for one or more computing cores, wherein the one or more computing cores collectively execute a plurality of threads simultaneously, and the plurality of threads are subject to time-varying changes. Accordingly, the rendering system is allocated between implementing the cross test resource and the shader resource.

Images