Cache Utilization Optimized Ray Traversal Algorithm with Minimized Memory Bandwidth Requirements

Abstract

Embodiments of the invention provide methods and apparatus for recording the traversal history of a ray through a spatial index structure and utilizing the recorded traversal history. An image processing system may initially determine which nodes a ray intersects as it traverses through a spatial index. Results of the node intersection determinations may be recorded as the ray traverses the spatial index, and the recorded determinations may be associated with the ray. Furthermore, the image processing system may decide upon a traversal path based upon some probability of striking primitives corresponding to the nodes which make up the spatial index. This traversal path may also be recorded and associated with the ray. If the image processing system needs to re-traverse the spatial index at a later time, the recorded traversal history may be used to eliminate the need to recalculate ray-node intersections, and eliminate incorrect traversal path determinations.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

Embodiments of the invention generally relate to the field of image processing.

2. Description of the Related Art

The process of rendering two-dimensional images from three-dimensional scenes is commonly referred to as image processing. As the modern computer industry evolves image processing evolves as well. One particular goal in the evolution of image processing is to make two-dimensional simulations or renditions of three-dimensional scenes as realistic as possible. One limitation of rendering realistic images is that modern monitors display images through the use of pixels.

A pixel is the smallest area of space which can be illuminated on a monitor. Most modern computer monitors will use a combination of hundreds of thousands or millions of pixels to compose the entire display or rendered scene. The individual pixels are arranged in a grid pattern and collectively cover the entire viewing area of the monitor. Each individual pixel may be illuminated to render a final picture for viewing.

One technique for rendering a real world three-dimensional scene onto a two-dimensional monitor using pixels is called rasterization. Rasterization is the process of taking a two-dimensional image represented in vector format (mathematical representations of geometric objects within a scene) and converting the image into individual pixels for display on the monitor. Rasterization is effective at rendering graphics quickly and using relatively low amounts of computational power; however, rasterization suffers from some drawbacks. For example, rasterization often suffers from a lack of realism because it is not based on the physical properties of light, rather rasterization is based on the shape of three-dimensional geometric objects in a scene projected onto a two dimensional plane. Furthermore, the computational power required to render a scene with rasterization scales directly with an increase in the complexity of the scene to be rendered. As image processing becomes more realistic, rendered scenes also become more complex. Therefore, rasterization suffers as image processing evolves, because rasterization scales directly with complexity.

Another technique for rendering a real world three-dimensional scene onto a two-dimensional monitor using pixels is called ray tracing. The ray tracing technique traces the propagation of imaginary rays, rays which behave similar to rays of light, into a three-dimensional scene which is to be rendered onto a computer screen. The rays originate from the eye(s) of a viewer sitting behind the computer screen and traverse through pixels, which make up the computer screen, towards the three-dimensional scene. Each traced ray proceeds into the scene and may intersect with objects within the scene. If a ray intersects an object within the scene, properties of the object and several other contributing factors are used to calculate the amount of color and light, or lack thereof, the ray is exposed to. These calculations are then used to determine the final color of the pixel through which the traced ray passed.

The process of tracing rays is carried out many times for a single scene. For example, a single ray may be traced for each pixel in the display. Once a sufficient number of rays have been traced to determine the color of all of the pixels which make up the two-dimensional display of the computer screen, the two dimensional synthesis of the three-dimensional scene can be displayed on the computer screen to the viewer.

Ray tracing typically renders real world three dimensional scenes with more realism than rasterization. This is partially due to the fact that ray tracing simulates how light travels and behaves in a real world environment, rather than simply projecting a three dimensional shape onto a two dimensional plane as is done with rasterization. Therefore, graphics rendered using ray tracing more accurately depict on a monitor what our eyes are accustomed to seeing in the real world.

Furthermore, ray tracing also handles increases in scene complexity better than rasterization as scenes become more complex. Ray tracing scales logarithmically with scene complexity. This is due to the fact that the same number of rays may be cast into a scene, even if the scene becomes more complex. Therefore, ray tracing does not suffer in terms of computational power requirements as scenes become more complex as rasterization does.

One major drawback of ray tracing is the large number of calculations, and thus processing power, required to render scenes. This leads to problems when fast rendering is needed. For example, when an image processing system is to render graphics for animation purposes such as in a game console. Due to the increased computational requirements for ray tracing it is difficult to render animation quickly enough to seem realistic (realistic animation is approximately twenty to twenty-four frames per second).

Therefore, there exists a need for more efficient techniques and devices to perform ray tracing.

SUMMARY OF THE INVENTION

Embodiments of the present invention generally provide methods and apparatus for performing ray tracing.

According to one embodiment of the invention a method of ray tracing utilizing a spatial index having nodes defining bounded volumes of a three dimensional scene is provided. The method generally comprising: generating a ray into the scene; traversing the spatial index by taking branches from internal nodes until a leaf node is reached, wherein branches are taken based on whether the ray intersects bounding volumes defined by the nodes; recording a traversal history indicating one or more nodes defining bounding volumes the ray intersects and branches taken when traversing the spatial index; determining if the ray hits a primitive contained in the bounding volume defined by the leaf node; and if the ray does not hit a primitive contained in the bounding volume defined by the leaf node, re-traversing the spatial index using the recorded traversal history.

According to another embodiment of the invention a computer readable medium containing a program which, when executed, performs an operation for ray tracing utilizing a spatial index having nodes defining bounded volumes of a three dimensional scene is provided. The operation generally comprising: generating a ray into the scene; traversing the spatial index by taking branches from internal nodes until a leaf node is reached, wherein branches are taken based on whether the ray intersects bounding volumes defined by the nodes; recording a traversal history indicating one or more nodes defining bounding volumes the ray intersects and branches taken when traversing the spatial index; determining if the ray hits a primitive contained in the bounding volume defined by the leaf node; and if the ray does not hit a primitive contained in the bounding volume defined by the leaf node, re-traversing the spatial index using the recorded traversal history.

According to another embodiment of the invention a system, is provided. The system generally comprising a spatial index having nodes defining bounded volumes of a three dimensional scene; and a first processing element, wherein the first processing element is generally configured to: generate a ray into the scene; traverse the spatial index by taking branches from internal nodes until a leaf node is reached, wherein branches are taken based on whether the ray intersects bounding volumes defined by the nodes; record a traversal history indicating one or more nodes defining bounding volumes the ray intersects and branches taken when traversing the spatial index; determine if the ray hits a primitive contained in the bounding volume defined by the leaf node; and if the ray does not hit a primitive contained in the bounding volume defined by the leaf node, re-traverse the spatial index using the recorded traversal history.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a multiple core processing element, according to one embodiment of the invention.

FIG. 2 illustrates multiple core processing element network, according to one embodiment of the invention.

FIG. 3 is an exemplary three dimensional scene to be rendered by an image processing system, according to one embodiment of the invention.

FIGS. 4A-4C illustrate a two dimensional space to be rendered by an image processing system and a corresponding spatial index created by an image processing system, according to one embodiment of the invention.

FIG. 5 illustrates a spatial index and a corresponding data structure for storing traversal history of a ray through the spatial index, according to one embodiment of the invention.

FIGS. 6 and 7 are flowcharts illustrating methods for traversing a spatial index, according to one embodiment of the invention.

FIG. 8 is an exemplary two dimensional space to be rendered by an image processing system, according to one embodiment of the invention.

FIGS. 9A-9G illustrate the traversal of a ray through a spatial index, according to one embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Embodiments of the invention provide techniques and systems for recording the traversal history of a ray through a spatial index structure and utilizing the recorded traversal history of a ray through the spatial index. An image processing system may initially determine which nodes a ray intersects as it traverses through a spatial index. Results of the node intersection determinations may be recorded as the ray traverses the spatial index, and the recorded determinations may be associated with the ray. Furthermore, the image processing system may decide upon a traversal path based upon some probability of striking primitives corresponding to the nodes which make up the spatial index. This traversal path may also be recorded and associated with the ray. If the image processing system needs to re-traverse the spatial index at a later time, the recorded traversal history may be used to eliminate the need to recalculate ray-node intersections, and eliminate incorrect traversal path determinations.

In the following, reference is made to embodiments of the invention. However, it should be understood that the invention is not limited to specific described embodiments. Instead, any combination of the following features and elements, whether related to different embodiments or not, is contemplated to implement and practice the invention. Furthermore, in various embodiments the invention provides numerous advantages over the prior art. However, although embodiments of the invention may achieve advantages over other possible solutions and/or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the invention. Thus, the following aspects, features, embodiments and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s). Likewise, reference to “the invention” shall not be construed as a generalization of any inventive subject matter disclosed herein and shall not be considered to be an element or limitation of the appended claims except where explicitly recited in a claim(s).

An Exemplary Processor Layout and Communications Network

FIG. 1 illustrates a multiple core processing element 100, according to one embodiment of the invention. The multiple core processing element 100 includes a plurality of basic throughput engines 105 (BTEs). A BTE 105 may contain a plurality of processing threads and a core cache (e.g., an L1 cache). The processing threads located within each BTE may have access to a shared multiple core processing element cache 110 (e.g., an L2 cache).

The BTEs 105 may also have access to a plurality of inboxes 115. The inboxes 115 may be memory mapped address space. The inboxes 115 may be mapped to the processing threads located within each of the BTEs 105. Each thread located within the BTEs may have a memory mapped inbox and access to all of the other memory mapped inboxes 115. The inboxes 115 make up a low latency and high bandwidth communications network used by the BTEs 105.

The BTEs may use the inboxes 115 as a network to communicate with each other and redistribute data processing work amongst the BTEs. For some embodiments, separate outboxes may be used in the communications network, for example, to receive the results of processing by BTEs 105. For other embodiments, inboxes 115 may also serve as outboxes, for example, with one BTE 105 writing the results of a processing function directly to the inbox of another BTE 105 that will use the results.

The aggregate performance of an image processing system may be tied to how well the BTEs can partition and redistribute work. The network of inboxes 115 may be used to collect and distribute work to other BTEs without corrupting the shared multiple core processing element cache 110 with BTE communication data packets that have no frame to frame coherency. An image processing system which can render many millions of triangles per frame may include many BTEs 105 connected in this manner.

In one embodiment of the invention, the threads of one BTE 105 may be assigned to a workload manager. An image processing system may use various software and hardware components to render a two dimensional image from a three dimensional scene. According to one embodiment of the invention, an image processing system may use a workload manager to traverse a spatial index with a ray issued by the image processing system. A spatial index, as described further below with regards to FIG. 4, may be implemented as a tree type data structure used to partition a relatively large three dimensional scene into smaller bounding volumes. An image processing system using a ray tracing methodology for image processing may use a spatial index to quickly determine ray-bounding volume intersections. In one embodiment of the invention, the workload manager may perform ray-bounding volume intersection tests by using the spatial index.

In one embodiment of the invention, other threads of the multiple core processing element BTEs 105 on the multiple core processing element 100 may be vector throughput engines. After a workload manager determines a ray-bounding volume intersection, the workload manager may issue (send), via the inboxes 115, the ray to one of a plurality of vector throughput engines. The vector throughput engines may then determine if the ray intersects a primitive contained within the bounding volume. The vector throughput engines may also perform operations relating to determining the color of the pixel through which the ray passed.

FIG. 2 illustrates a network of multiple core processing elements 200, according to one embodiment of the invention. FIG. 2 also illustrates one embodiment of the invention where the threads of one of the BTEs of the multiple core processing element 100 is a workload manager 205. Each multiple core processing element 220_1-N in the network of multiple core processing elements 200 may contain one workload manager 205_1-N, according to one embodiment of the invention. Each processor 220 in the network of multiple core processing elements 200 may also contain a plurality of vector throughput engines 210, according to one embodiment of the invention.

The workload managers 220_1-N may use a high speed bus 225 to communicate with other workload managers 220_1-N and/or vector throughput engines 210 of other multiple core processing elements 220, according to one embodiment of the invention. Each of the vector throughput engines 210 may use the high speed bus 225 to communicate with other vector throughput engines 210 or the workload managers 205. The workload manager processors 205 may use the high speed bus 225 to collect and distribute image processing related tasks to other workload manager processors 205, and/or distribute tasks to other vector throughput engines 210. The use of a high speed bus 225 may allow the workload managers 205_1-N to communicate without affecting the caches 230 with data packets related to workload manager 205 communications.

An Exemplary Three Dimensional Scene

FIG. 3 is an exemplary three dimensional scene 305 to be rendered by an image processing system. Within the three dimensional scene 305 may be objects 320. The objects 320 in FIG. 3 are of different geometric shapes. Although only four objects 320 are illustrated in FIG. 3, the number of objects in a typical three dimensional scene may be more or less. Commonly, three dimensional scenes will have many more objects than illustrated in FIG. 3.

As can be seen in FIG. 3 the objects are of varying geometric shape and size. For example, one object in FIG. 3 is a pyramid 320_A. Other objects in FIG. 3 are boxes 320_B-D. In many modern image processing systems objects are often broken up into smaller geometric shapes (e.g., squares, circles, triangles, etc.). The larger objects are then represented by a number of the smaller simple geometric shapes. These smaller geometric shapes are often referred to as primitives.

Also illustrated in the scene 305 are light sources 325_A-B. The light sources may illuminate the objects 320 located within the scene 305. Furthermore, depending on the location of the light sources 325 and the objects 320 within the scene 305, the light sources may cause shadows to be cast onto objects within the scene 305.

The three dimensional scene 305 may be rendered into a two-dimensional picture by an image processing system. The image processing system may also cause the two-dimensional picture to be displayed on a monitor 310. The monitor 310 may use many pixels 330 of different colors to render the final two-dimensional picture.

One method used by image processing systems to rendering a three-dimensional scene 320 into a two dimensional picture is called ray tracing. Ray tracing is accomplished by the image processing system “issuing” or “shooting” rays from the perspective of a viewer 315 into the three-dimensional scene 320. The rays have properties and behavior similar to light rays.

One ray 340, that originates at the position of the viewer 315 and traverses through the three-dimensional scene 305, can be seen in FIG. 3. As the ray 340 traverses from the viewer 315 to the three-dimensional scene 305, the ray 340 passes through a plane where the final two-dimensional picture will be rendered by the image processing system. In FIG. 3 this plane is represented by the monitor 310. The point the ray 340 passes through the plane, or monitor 310, is represented by a pixel 335.

As briefly discussed earlier, most image processing systems use a grid 330 of thousands (if not millions) of pixels to render the final scene on the monitor 310. Each individual pixel may display a different color to render the final composite two-dimensional picture on the monitor 310. An image processing system using a ray tracing image processing methodology to render a two dimensional picture from a three-dimensional scene will calculate the colors that the issued ray or rays encounters in the three dimensional scene. The image processing scene will then assign the colors encountered by the ray to the pixel through which the ray passed on its way from the viewer to the three-dimensional scene.

The number of rays issued per pixel may vary. Some pixels may have many rays issued for a particular scene to be rendered. In which case the final color of the pixel is determined by the each color contribution from all of the rays that were issued for the pixel. Other pixels may only have a single ray issued to determine the resulting color of the pixel in the two-dimensional picture. Some pixels may not have any rays issued by the image processing system, in which case their color may be determined, approximated or assigned by algorithms within the image processing system.

To determine the final color of the pixel 335 in the two dimensional picture, the image processing system must determine if the ray 340 intersects an object within the scene. If the ray does not intersect an object within the scene it may be assigned a default background color (e.g., blue or black, representing the day or night sky). Conversely, as the ray 340 traverses through the three dimensional scene the ray 340 may strike objects. As the rays strike objects within the scene the color of the object may be assigned the pixel through which the ray passes. However, the color of the object must be determined before it is assigned to the pixel.

Many factors may contribute to the color of the object struck by the original ray 340. For example, light sources within the three dimensional scene may illuminate the object. Furthermore, physical properties of the object may contribute to the color of the object. For example, if the object is reflective or transparent, other non-light source objects may then contribute to the color of the object.

In order to determine the effects from other objects within the three dimensional scene, secondary rays may be issued from the point where the original ray 340 intersected the object. For example, one type of secondary ray may be a shadow ray. A shadow ray may be used to determine the contribution of light to the point where the original ray 340 intersected the object. Another type of secondary ray may be a transmitted ray. A transmitted ray may be used to determine what color or light may be transmitted through the body of the object. Furthermore, a third type of secondary ray may be a reflected ray. A reflected ray may be used to determine what color or light is reflected onto the object.

As noted above, one type of secondary ray may be a shadow ray. Each shadow ray may be traced from the point of intersection of the original ray and the object, to a light source within the three-dimensional scene 305. If the ray reaches the light source without encountering another object before the ray reaches the light source, then the light source will illuminate the object struck by the original ray at the point where the original ray struck the object.

For example, shadow ray 341_A may be issued from the point where original ray 340 intersected the object 320_A, and may traverse in a direction towards the light source 325_A. The shadow ray 341_A reaches the light source 325_A without encountering any other objects 320 within the scene 305. Therefore, the light source 325_A will illuminate the object 320_A at the point where the original ray 340 intersected the object 320_A.

Other shadow rays may have their path between the point where the original ray struck the object and the light source blocked by another object within the three-dimensional scene. If the object obstructing the path between the point on the object the original ray struck and the light source is opaque, then the light source will not illuminate the object at the point where the original ray struck the object. Thus, the light source may not contribute to the color of the original ray and consequently neither to the color of the pixel to be rendered in the two-dimensional picture. However, if the object is translucent or transparent, then the light source may illuminate the object at the point where the original ray struck the object.

For example, shadow ray 341_B may be issued from the point where the original ray 340 intersected with the object 320_A, and may traverse in a direction towards the light source 325_B. In this example, the path of the shadow ray 341_B is blocked by an object 320_D. If the object 320_D is opaque, then the light source 325_B will not illuminate the object 320_A at the point where the original ray 340 intersected the object 320_A. However, if the object 320_D which the shadow ray is translucent or transparent the light source 325_B may illuminate the object 320_A at the point where the original ray 340 intersected the object 320_A.

Another type of secondary ray is a transmitted ray. A transmitted ray may be issued by the image processing system if the object with which the original ray intersected has transparent or translucent properties (e.g., glass). A transmitted ray traverses through the object at an angle relative to the angle at which the original ray struck the object. For example, transmitted ray 344 is seen traversing through the object 320_A which the original ray 340 intersected.

Another type of secondary ray is a reflected ray. If the object with which the original ray intersected has reflective properties (e.g. a metal finish), then a reflected ray will be issued by the image processing system to determine what color or light may be reflected by the object. Reflected rays traverse away from the object at an angle relative to the angle at which the original ray intersected the object. For example, reflected ray 343 may be issued by the image processing system to determine what color or light may be reflected by the object 320_A which the original ray 340 intersected.

The total contribution of color and light of all secondary rays (e.g., shadow rays, transmitted rays, reflected rays, etc.) will result in the final color of the pixel through which the original ray passed.

An Exemplary kd-Tree

One problem encountered when performing ray tracing is determining quickly and efficiently if an issued ray intersects any objects within the scene to be rendered. One methodology known by those of ordinary skill in the art to make the ray intersection determination more efficient is to use a spatial index. A spatial index divides a three-dimensional scene or world into smaller volumes (smaller relative to the entire three-dimensional scene) which may or may not contain primitives. An image processing system can then use the known boundaries of these smaller volumes to determine if a ray may intersect primitives contained within the smaller volumes. If a ray does intersect a volume containing primitives, then a ray intersection test can be run using the trajectory of the ray against the known location and dimensions of the primitives contained within that volume. If a ray does not intersect a particular volume then there is no need to run ray-primitive intersection tests against the primitives contained within that volume. Furthermore, if a ray intersects a bounding volume which does not contain primitives then there is no need to run ray-primitive intersections tests against that bounding volume. Thus, by reducing the number of ray-primitive intersection tests which may be necessary, the use of a spatial index greatly increases the performance of a ray tracing image processing system. Some examples of different spatial index acceleration data structures are octrees, k dimensional Trees (kd-Trees), and binary space partitioning trees (BSP trees). While several different spatial index structures exist, for ease of describing embodiments of the present invention, a kd-Tree will be used in the examples to follow. However, those skilled in the art will readily recognize that embodiments of the invention may be applied to any of the different types of spatial indexes.

A kd-Tree uses axis aligned bounding volumes to partition the entire scene or space into smaller volumes. That is, the kd-Tree may divide a three dimensional space encompassed by a scene through the use of splitting planes which are parallel to known axes. The splitting planes partition a larger space into smaller bounding volumes. Together the smaller bounding volumes make up the entire space in the scene. The determination to partition (divide) a larger bounding volume into two smaller bounding volumes may be made by the image processing system through the use of a kd-tree construction algorithm.

One criterion for determining when to partition a bounding volume into smaller volumes may be the number of primitives contained within the bounding volume. That is, as long as a bounding volume contains more primitives than a predetermined threshold, the tree construction algorithm may continue to divide volumes by drawing more splitting planes. Another criterion for determining when to partition a bounding volume into smaller volumes may be the amount of space contained within the bounding volume. Furthermore, a decision to continue partitioning the bounding volume may also be based on how many primitives may be intersected by the plane which creates the bounding volume.

The partitioning of the scene may be represented by a binary tree structure made up of nodes, branches and leaves. Each internal node within the tree may represent a relatively large bounding volume, while the node may contain branches to sub-nodes which may represent two relatively smaller partitioned volumes resulting after a partitioning of the relatively large bounding volume by a splitting plane. In an axis-aligned kd-Tree, each internal node may contain only two branches to other nodes. The internal node may contain branches (i.e., pointers) to one or two leaf nodes. A leaf node is a node which is not further sub-divided into smaller volumes and contains pointers to primitives. An internal node may also contain branches to other internal nodes which are further sub-divided. An internal node may also contain the information needed to determine along what axis the splitting plane was drawn and where along the axis the splitting plane was drawn.

Exemplary Bounding Volumes

FIGS. 4A-4C illustrate a two dimensional space to be rendered by an image processing system and a corresponding kd-tree. For simplicity, a two dimensional scene is used to illustrate the building of a kd-Tree, however kd-Trees may also be used to represent three dimensional scenes. In the two dimensional illustration of FIGS. 4A-4C splitting lines are illustrated instead of splitting planes, and bounding areas are illustrated instead of bounding volumes as would be used in a three dimensional structure. However, one skilled in the art will quickly recognize that the concepts may easily be applied to a three dimensional scene containing objects.

FIG. 4A illustrates a two dimensional scene 405 containing primitives 410 to be rendered in the final picture to be displayed on a monitor 310. The largest volume which represents the entire volume of the scene is encompassed by bounding volume 1 (BV₁). In the corresponding kd-Tree this may be represented by the top level node 450, also known as the root or world node. In one embodiment of an image processing system, an image processing system may continue to partition bounding volumes into smaller bounding volumes when the bounding volume contains, for example, more than two primitives. As noted earlier the decision to continue partitioning a bounding volume into smaller bounding volumes may be based on many factors, however for ease of explanation in this example the decision to continue partitioning a bounding volume is based only on the number of primitives. As can be seen in FIG. 4A, BV₁ contains six primitives, therefore kd-Tree construction algorithm may partition BV₁ into smaller bounding volumes.

FIG. 4B illustrates the same two dimensional scene 405 as illustrated in FIG. 4A. However, in FIG. 4B the tree construction algorithm has partitioned BV₁ into two smaller bounding volumes BV₂ and BV₃. The partitioning of BV₁, was accomplished, by drawing a splitting plane SP₁ 415 along the x-axis at point x₁. This partitioning of BV₁ is also reflected in the kd-Tree as the two nodes 455 and 460, corresponding to BV₂ and BV₃ respectively, under the internal or parent node BV₁ 450. The internal node representing BV₁ may now store information such as, but not limited to, pointers to the two nodes beneath BV₁ (e.g., BV₂ and BV₃), along which axis the splitting plane was drawn (e.g., x-axis), and where along the axis the splitting plane was drawn (e.g., at point x₁).

The kd-Tree construction algorithm may continue to partition bounding volume BV₃ because it contains more than the predetermined threshold of primitives (e.g., more than two primitives). However, the kd-Tree construction algorithm may not continue to partition bounding volume BV₂, because bounding volume BV₂ contains less than or equal to the number of primitives (e.g., only two primitives 410_A). Nodes which are not partitioned or sub-divided any further, such as BV₂, are referred to as leaf nodes.

FIG. 4C illustrates the same two dimensional scene 405 as illustrated in FIG. 4B. However, in FIG. 4C the kd-Tree construction algorithm has partitioned BV₃ into two smaller bounding volumes BV₄ and BV₅. The kd-construction algorithm has partitioned BV₃ using a partitioning plane along the y-axis at point y₁. Since BV₃ has been partitioned into two sub-nodes it may now be referred to as an internal node. The partitioning of BV₃ is also reflected in the kd-Tree as the two leaf nodes 465 and 470, corresponding to BV₄ and BV₅ respectively. BV₄ and BV₅ are leaf nodes because the volumes they represent are not further divided into smaller bounding volumes. The two leaf nodes, BV₄ and BV₅, are located under the internal node BV₃ which represents the bounding volume which was partitioned in the kd-Tree.

The internal node representing BV₃ may store information such as, but not limited to, pointers to the two leaf nodes (i.e., BV₄ and BV₅), along which axis the splitting plane was drawn (i.e., y-axis), and where along the axis the splitting plane was drawn (i.e., at point y₁).

The kd-Tree construction algorithm may now stop partitioning the bounding volumes because all bounding volumes located within the scene contain less than or equal to the maximum predetermined number of primitives which may be enclosed within a bounding volume. The leaf nodes may contain pointers to the primitives which are enclosed within the bounding volumes each leaf represents. For example, leaf node BV₂ may contain pointers to primitives 410_A, leaf node BV₄ may contain pointers to primitives 410B, and leaf node BV₅ may contain pointers to primitives 410_C.

A ray tracing image processing system may use the workload manager 205 to traverse the spatial index (kd-Tree). Traversing the kd-Tree may include selecting a branch to a node on a lower level (sub-node) of the kd-Tree to take or proceed to in order to determine if the ray intersects any primitives contained within the sub-node. A workload manager 205 may use the coordinates and trajectory of an issued ray to traverse or navigate through the kd-Tree. By executing ray-bounding volume intersection tests, the workload manager 205 may determine if the ray intersects a plane of the bounding volumes represented by nodes within the kd-Tree structure. If the ray intersects a bounding volume which contains only primitives (i.e., a leaf node), then the workload manager 205 may send the ray and associated information to a vector throughput engine 210 for ray-primitive intersection tests. A ray-primitive intersection test may be executed to determine if the ray intersects the primitives within the bounding volume. This methodology results in fewer ray-primitive intersection tests needed to determine if a ray intersects an object within the scene, in comparison to running ray-primitive intersection tests for a ray against each primitive contained within the scene.

The resulting kd-Tree structure, or other spatial index structure, may be stored in a processor cache 230. The kd-Tree and the size of corresponding data which comprises the kd-Tree may be optimized for storage in a processor cache 230. The storage of the kd-Tree in a processor cache 230 may allow a workload manager 205 to traverse the kd-Tree with a ray that has been issued by the image processing system without having to retrieve the kd-Tree from memory every time a ray is issued by the image processing system.

An Exemplary kd-Tree and Corresponding Node History Data Structure

A node history may be stored for each level of internal node depth within the spatial index (e.g., kd-Tree). The node level history may be used to store information relating to bounding volume-ray intersection tests and kd-Tree traversal. By saving the results of previous tests and kd-Tree traversal the image processing system may take advantage of prior test results to reduce the amount processing necessary to determine a ray-primitive intersection. According to one embodiment of the invention, node history bits for each level may be stored in a nibble of a node history data structure sent along with (e.g., appended to) the information which describes the ray.

FIG. 5 illustrates an exemplary kd-Tree 550 and a corresponding exemplary node history data structure 545, according to one embodiment of the invention. The exemplary kd-Tree 550 is illustrated as containing eight levels of internal node depth (L₁-L₈). According to one embodiment of the invention, the corresponding node history 545 may contain the same number of nibbles as the kd-Tree 550 contains internal node levels (L₁-L₈). Therefore, according to one embodiment of the invention, the node history 545 may contain eight nibbles (i.e., 32 bits) which may record the history of ray-intersection tests and kd-Tree traversal. According to one embodiment of the invention, the most significant nibble L₁ may correspond to the first level L₁ (i.e., the root or world node) within the kd-Tree 550 and the least significant nibble L₈ may correspond to the lowest level L₈ within the kd-tree 550.

Each nibble within the node history data structure 545 may contain four bits. The two most significant bits 525 of each nibble may correspond to a node located to the left and below an internal node. The two least significant bits 530 of each nibble may relate to a node located to the right and below an internal node. The most significant bit 505 of each nibble may be set (e.g., to a high state, or a “1”) if the ray-bounding volume intersection test was executed and the ray intersected the bounding volume represented by the node to the left and below an internal node. The second most significant bit 505 may be set if the workload manager 205 “took” the branch or traversed to the node, located to the left and below the internal node, while traversing the kd-tree. As used herein, a path is considered “taken” if the kd-tree was traversed to reach an internal or leaf node along the path.

The third most significant bit 515 may be set if the ray-bounding volume intersection test was executed and the ray intersected the bounding volume represented by the node located to the right and below the internal node. The least significant bit 520 may be set if the workload manager 205 “took” the branch or traversed to the node, located to the right and below the internal node, while traversing the kd-tree 550.

Thus, one nibble of history bits per level is all that is needed to record the results of ray-bounding volume intersection tests and whether a path has been taken or not. Of course, to determine which node has been reached at any particular level, the history bits at the preceding level(s) need to be examined. Thus, once all paths at a particular level have been taken when searching for a leaf node with primitives that a given ray intersects, node history bits at that level and below should be cleared and a different path from a higher level should be taken.

An Exemplary kd-Tree Traversal Algorithm Utilizing Node History

FIG. 6 is a flowchart illustrating a method 600 for traversing a kd-Tree. The method 600 beings at step 605 when an image processing system issues a ray to be traced into a three dimensional scene. The image processing system may use the workload manager 205 to execute tasks related to traversing the kd-Tree with an issued ray. Next, at step 610, the image processing system starts at the root or world node. From the root node, the image processing system may proceed to step 615 where the image processing system may select a branch to take.

Step 615 may initiate within the image processing system a sub-routine which traverses the kd-Tree according to node history bits as described in greater detail below with reference to FIG. 7.

FIG. 7 is a flowchart which illustrates the method of traversing the kd-Tree according to node history bits 500. The method 700 begins at, step 705, when the image processing system reaches an internal node (i.e., a node containing branches to sub-nodes). Next, at step 710, the image processing system may determine if there is node level history information corresponding to the issued ray. If not, the image processing system proceeds to step 715 where the workload manager 205 may perform ray-bounding volume intersection tests for each of the bounding volumes represented by the nodes branched to from the internal node currently being traversed. Next, at step 720, the image processing system may update the node level history bits corresponding to the node level. Specifically, the image processing system may update the “hit node” bits 505 and 515 which represent whether or not the ray intersected the bounding volume corresponding to each of the nodes branched to from the internal node. Next, the image processing system may proceed to step 725.

At step 725 the image processing system may determine if both bounding volumes represented by the nodes which are branched to by the internal node were intersected by the ray. If both bounding volumes were intersected the image processing system may proceed to step 727 where the image processing system may select the path to the node nearest to the origin of the ray. However, if only one node was intersected, at step 729 the image processing system may select the path to the node which was intersected. After steps 727 and 729, the image processing system may proceed to step 730. At step 730 the image processing system updates the taken bit in the node level history to reflect the path/branch selected by the image processing system. After step 730, the image processing system takes the selected path/branch at step 735.

If, at step 710, the image processing system determined that the ray did have node level history information, the image processing system may proceed to step 740. At step 740, the image processing system may determine the lowest node depth that the image processing system has previously determined that a bounding volume was intersected by the ray, but the image processing system did not take the path/branch to that bounding volume.

A ray which has stored node level history information is a ray that the image processing system has traversed the spatial index (e.g., the kd-Tree) with, however the ray did not intersect a primitive within the bounding volume against which ray-primitive intersection tests were run (i.e., a miss occurred). After a miss, in order to determine the lowest internal node depth at which a bounding volume was intersected but not taken, the image processing system may specifically look for the occurrence of a ‘10’ in a node level history. The image processing system may look for a ‘10’ in either the pair which makes up the most significant two bits of the node level history, or the pair of bits which makes up the least significant two bits of the node level history. A ‘10’ in either of those two pairs represents that the bounding volume represented by that node was intersected by the ray, but a ray primitive intersection test has yet to be run for one of the bounding volumes beneath that node level (i.e., that corresponding path was not taken).

For example, at a certain level of the kd-Tree a ray may intersect both bounding volumes represented by the sub-nodes beneath an internal node. The image processing system may have determined during a previous traversal of the kd-Tree that the bounding volume represented by the sub-node to the left and below the internal node of the kd-Tree was intersected by the ray before the bounding volume represented by the sub-node to the right and below the internal node. The image processing system may have taken the sub-node on the left and a history bit may have been updated to show such traversal.

As an example, according to one embodiment of the invention, if each node level is represented by a nibble, the node history bits corresponding to this internal node level would be ‘1110’ which can be read as: hit left node, took branch to left node, hit right node, branch to right node not yet taken. The sub-node to the right and below the internal node was intersected by the ray but has not been tested for a ray-primitive intersection, as is represented by the ‘10’ in the internal node level history.

After determining the lowest node level history where a bounding volume was intersected but not taken the image processing system may proceed to step 745. At step 745 the image processing system may clear all of the node level history bits for internal node levels below the lowest node level where a bounding volume was intersected but not taken level. This step ensures that as the image processing system traverses the kd-Tree, any history previously recorded for branches, nodes, or leaf nodes below the point at which an incorrect traversal path decision was made does not affect the future traversal of the kd-Tree.

Next, at step 750, the image processing system may traverse the kd-Tree based on the node level history from the root node to the lowest node depth at which a bounding volume was intersected but not taken. Step 750 may ensure that the proper pointers to internal nodes on lower levels or to leaf nodes are retrieved by the image processing system from the cache 230. Next, at step 755, the image processing system selects the path/branch to the node that has not been taken by the image processing system (i.e., the path represented by the ‘10’ in the node history for the lowest node level where a bounding volume was intersected but not taken). After step 755, the image processing system proceeds to step 730. At step 730 the image processing system updates the taken bit in the node level history to reflect the path selected by the image processing system. After step 730, the image processing system takes the selected path at step 735.

After the path has been taken the image processing system returns to method 600. The image processing system resumes the method 600 at step 620. At step 620, the image processing system determines whether the path taken has resulted in the image processing system reaching a leaf node. If not, the image processing system returns to step 615 to select a branch to take.

However, if the workload manager 205 determined at step 620 that the path taken resulted in the workload manager 205 reaching a leaf node, the workload manager 205 may send, via the inboxes 115 or via the network 225, the ray, the ray history data structure, and the leaf node information (e.g., pointers to the primitives bound by the leaf node) to a vector throughput engine 210 for ray-primitive intersection tests.

The vector throughput engine 210 may execute the ray-primitive tests to determine whether or not the ray which hit the bounding volume represented by the leaf node actually hit any of the primitives contained within the bounding volume. If the ray did hit any of the primitives within the bounding volume, the vector throughput engine 210 may assign a color (e.g., the color of the primitive) to the ray. However, the vector throughput engine 210 may also determine that the ray did not hit any of the primitives within the bounding volume.

Some time later, the vector throughput engine 210 returns the ray and an indication of whether or not the ray hit or missed the primitives contained within the bounding volume. The image processing system, at step 630, may then determine if the information returned by the vector throughput engine 210 indicates that the ray hit a primitive, or if the information indicates that the ray missed all of the primitives contained within the bounding volume.

If the ray hit a primitive, the image processing system may then assign the color returned from the vector throughput engine 210 to the pixel 335 on the monitor 310 through which the ray passed. The image processing system may then proceed to issue another ray to traverse the kd-Tree or perform other operations related to rendering the two dimensional picture from the three dimensional scene.

If the vector throughput engine 210 determined that the ray missed the primitives contained within the bounding volume, the workload manager 205 may return to step 610. At step 610, the workload manager 205 may begin traversing the kd-Tree again starting at the root node, with the ray history helping to avoid unnecessarily re-running ray-bounding volume intersection tests, as well as avoiding traversing the tree to paths that lead to leaf nodes having primitives a given ray did not inersect.

kd-Tree Traversal Example

FIG. 8 illustrates an exemplary scene 800 which has been partitioned into bounding volumes (BV₁-BV₅). FIG. 8 is similar to the scene used in FIG. 4 to illustrate the building of a kd-Tree. Also illustrated in FIG. 8 is a ray 805 issued by the image processing system. The ray 805 may be used to traverse the kd-Tree. The ray intersects BV₂ at a first point 805 and exits BV₂ at a second point 815. The ray intersects BV₃ and BV₄ at the second point 815 and exits BV₃ and BV₄ at a third point 820.

FIG. 9A is an exemplary kd-Tree 900 corresponding to the partitioned scene 800 in FIG. 8. FIG. 9A also illustrates a first nibble 905 of an exemplary internal node history data structure associated with the ray 805 and the first level of the kd-Tree 900 (i.e., the root node BV₁). Furthermore, also illustrated is a second nibble 910 of the exemplary internal node history data structure associated with the ray 805 and the second level of the kd-Tree. FIG. 9A illustrates the initial state (all bits unasserted) of the node history data structure before the workload manager 205 has begun traversing the kd-Tree with the ray 805.

As described with respect to method 500 in FIG. 5, the workload manager 205 may perform operations related to traversing the kd-Tree 900 after a ray 805 has been issued by the image processing system. For example, as was described in step 615 of method 600, the workload manager 205 may execute ray-bounding volume intersection tests to determine if the ray 805 intersects the bounding volumes corresponding to the child nodes, BV₂ and BV₃, of the root node BV₁. As can be seen in FIG. 8, the ray 805 intersects both of the bounding volumes corresponding to the child nodes, BV₂ and BV₃. The ray 805 intersects BV₂ at a first point 810, and exits BV₂ at a second point 815. The ray intersects BV₃ at the second point 815 and exits BV₃ at a third point 820.

After the workload manager 205 has executed the ray-bounding volume intersection tests, the workload manager 205 may update the node history nibble 905 corresponding to the root node BV₁ level to reflect the results of the ray-bounding volume intersection test. The updating of the root node level history nibble 905 is illustrated in FIG. 9B. Due to the fact that the ray 805 intersects both of the child nodes, BV₂ and BV₃, the workload manager 205 may assert the “hit node” bits in the node level history which correspond to each of the child nodes, BV₂ and BV₃. Therefore, the workload manager 205 may assert the most significant bit of the root node level history 905, which represents that the ray 805 hit the bounding volume corresponding to the left child node (BV₂). Furthermore, the workload manager 205 may assert the third most significant bit of the root node level history 905, which represents that the ray 805 hit the bounding volume corresponding to the right child node (BV₃).

Next, the workload manager 205 may determine a path to be taken down the kd-Tree 900 based on the bounding volume intersection tests. As illustrated in FIG. 9C, in one embodiment of the invention, if both child nodes, BV₂ and BV₃, of the parent node BV₁, in this case the root node, the workload manager 205 may proceed to the first (e.g., nearest) bounding volume which was intersected by the ray. In the immediate example, the ray 805 first intersects BV₂. Therefore, the workload manager 205 may traverse to BV₂ and update the root node level history 905 to show the workload manager 205 “took” the branch to BV₂ (i.e., took left node). The updating of the node level history for the root node is illustrated in FIG. 9C.

The workload manager 205 may now determine whether or not the BV₂ is a leaf node (i.e., a node that does not branch to other nodes). Since the node BV₂ is a leaf node, the workload manager 205 may now send the ray 805, the node history 905 and 910 for the ray, and pointers to the primitives contained within the leaf node BV₂ to the vector throughput engine 210 as illustrated in FIG. 9D. The vector throughput engine 210 may then execute ray-primitive intersection tests to determine if the ray 805 intersects (hits) any primitives contained within BV₂.

As illustrated in FIG. 8, the ray 805 does not intersect any primitives located within BV₂. Therefore, the vector throughput engine 210 may return the ray and the corresponding history to the workload manager 205 indicating that the ray 805 did not intersect any primitives within BV₂ (i.e., a miss).

After the ray is returned from the vector throughput engine 210, the workload manager 205 may determine that the ray node level history contains information. The workload manager 205 may utilize the history to facilitate traversal of the kd-Tree. The workload manager 205 may utilize the ray history to determine the lowest level node history indicating where a bounding volume was intersected but a corresponding branch was not taken. This may be accomplished by determining the lowest node history which contains a ‘10’ in the node history. Thus, as illustrated in FIG. 9E, the workload manager 205 may determine that the root node level of the kd-Tree is the lowest level on the kd-Tree where a bounding volume was intersected but not taken. This may be determined by examining the root node level history 905 which contains a ‘10’ indicating a hit in a bounding volume corresponding to the right branch, but that the right branch was not taken. After determining that the root node level was the lowest level, the workload manager 205 may clear the node level history for all node levels below the root node.

Next, the workload manager 205 may begin traversing the kd-Tree 900 at the root node BV₁. The workload manager 205 may then use the node level history 905 to aid in traversal of the kd-tree 900. Based on the node level history 905 for the root node, the workload manager may determine to take the branch that has yet to be taken. By examining the node level history 905, the workload manager may determine that both the left and the right node were intersected by the ray 805. This may be determined by examining the first and the third bits of the root node level history nibble 905. Both of these bits are asserted (i.e., a ‘1’), and therefore both were determined to have been intersected in a previous ray-bounding volume intersection test. Furthermore, the workload manager 205 may determine that the workload manager previously “took” the branch to the left sub-node (i.e., sent the ray to be tested against the primitives contained within BV₂). This is determined by examining the second bit of the node level history, which is asserted. Therefore, the workload manager may not proceed to or “take” the other branch to the right node (i.e., BV₃) which was intersected by the ray 805. As illustrated in FIG. 9F, the workload manager 205 may also update the took right bit of the root node level history nibble 905 to indicate the traversal to BV₃.

The workload manager 205 may determine if the traversed to node BV₃ is a leaf node. As can be seen in FIG. 9E, the node BV₃ is not a leaf node, but an internal node. Therefore, the workload manager 205 may execute ray-bounding volume intersection tests to determine if the ray 805 intersects the bounding volumes corresponding to the nodes beneath or on a lower level than BV₃ (i.e., BV₄ and BV₅).

As illustrated in FIG. 8 the ray 805 intersects BV₄ at point 815, however the ray does not intersect BV₅. Therefore, the results of the ray-bounding volume intersection test may indicate that the ray 805 does not intersect BV5. The workload manager 205 may now update the BV₃ node level history 910 to reflect the results of the ray-bounding volume intersection tests. Therefore, as illustrated in FIG. 9F, the workload manager 205 may place a “1,” or assert the bit, in the most significant bit location within the BV₃ node history 910 to reflect the fact that the ray intersects BV₃. Next, the workload manager 205 may determine what branch/path “to take,” based on the BV₃ node level history 910.

By examining the BV₃ node level history 910 the workload manager 205 may determine that only one node beneath BV₃ is intersected by the ray 805, and therefore the workload manager 205 may traverse to the intersected node BV₄. As illustrated in FIG. 9G, the workload manager 205 may update the BV₃ node level history 910 to reflect the traversal from node BV₃ to node BV₄ by asserting the second most significant bit (indicating left branch taken) in the BV₃ node level history.

The workload manager 205 may now determine whether or not the left child node, BV₄ is a leaf node (i.e., the node does not have children). Since the node BV₄ is a leaf node, the workload manager 205 may now send the ray 805, the node level history (905 and 910) for the ray, and pointers to the primitives contained within the leaf node BV₄ to the vector throughput engine 210. The vector throughput engine 210 may then execute ray-primitive intersection tests to determine if the ray 805 intersects (hits) any primitives contained within BV₄. As can be seen in FIG. 8, the ray 805 intersects a primitive within BV₄. Therefore, the vector throughput engine 210 may assign a color to the pixel through which the ray 805 passed and return the information to the workload manager 205.

Those skilled in the art will appreciate that when a ray does intersect with a primitive of a leaf node, additional rays may be spawned, for example, corresponding to reflection, transmission, refraction, and the like. While the iterative process of spawning such rays is well known, each of these rays may be efficiently traced using the techniques described herein to determine final pixel values.

CONCLUSION

Embodiments of the invention provide techniques and systems for recording the traversal history of a ray through a spatial index structure and utilizing the recorded traversal history of a ray through the spatial index. An image processing system may initially determine which nodes a ray intersects as it traverses through a spatial index. Results of the node intersection determinations may be recorded as the ray traverses the spatial index, and the recorded determinations may be associated with the ray. Furthermore, the image processing system may decide upon a traversal path based upon some probability of striking primitives corresponding to the nodes which make up the spatial index. This traversal path may also be recorded and associated with the ray. If the image processing system needs to traverse the spatial index at a later time, the recorded traversal history may be used to eliminate the need to recalculate ray-node intersections, and eliminate duplicating incorrect traversal path determinations.

While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.

Claims

1. A method of ray tracing utilizing a spatial index having nodes defining bounded volumes of a three dimensional scene comprising:

generating a ray into the scene;

traversing the spatial index by taking branches from internal nodes until a leaf node is reached, wherein branches are taken based on whether the ray intersects bounding volumes defined by the nodes;

recording a traversal history indicating one or more nodes defining bounding volumes the ray intersects and branches taken when traversing the spatial index;

determining if the ray hits a primitive contained in the bounding volume defined by the leaf node; and

if the ray does not hit a primitive contained in the bounding volume defined by the leaf node, re-traversing the spatial index using the recorded traversal history.

2. The method of claim 1, wherein the spatial index contains a plurality of internal node levels, and the traversal history is recorded for each node level.

3. The method of claim 1, wherein the spatial index contains a plurality of internal node levels and the traversal history comprises four bits for each internal node level of the spatial index

4. The method of claim 3, wherein two of the traversal history bits indicate whether the ray intersects bounding volumes defined by a node located within one of the internal node levels, and wherein two of the traversal history bits indicate branches taken when traversing the spatial index from the node on one of the internal node levels.

5. The method of claim 1, further comprising:

storing the ray traversal history with information defining the ray; and

transmitting information defining the ray and the traversal history from a workload manager executing on a first processing element to a vector throughput engine executing on a second processing element, wherein the workload manager and the vector throughput engine communicate through a memory mapped address space.

6. The method of claim 5, wherein the workload manager determines whether the ray intersects bounding volumes defined by the nodes, wherein the workload manager records the traversal history, and wherein the vector throughput engine determines if the ray hits a primitive contained in the bounding volume defined by the leaf node.

7. The method of claim 6, wherein the workload manager and the vector throughput engine are located on the same processing element.

8. The method of claim 6, wherein the workload manager and the vector throughput engine are located on separate processing elements.

9. The method of claim 1, wherein re-traversing the spatial index using the recorded traversal history comprises,

determining a lowest level on the spatial index where bounding volumes corresponding to a node were intersected by the ray, but a branch from the node was not taken;

traversing the spatial index based on the branches taken and recorded in the traversal history to the lowest level;

taking the branch from the node not yet taken; and

traversing the spatial index below lowest level by taking branches from internal nodes until a leaf node is reached, wherein branches are taken based on whether the ray intersects bounding volumes defined by the nodes;

recording a traversal history below the lowest level indicating one or more nodes defining bounding volumes the ray intersects and branches taken when traversing the spatial index; and

determining if the ray hits a primitive contained in the bounding volume below the lowest level and defined by the leaf node.

10. A computer readable medium containing a program which, when executed, performs an operation for ray tracing utilizing a spatial index having nodes defining bounded volumes of a three dimensional scene, the operation comprising:

generating a ray into the scene;

traversing the spatial index by taking branches from internal nodes until a leaf node is reached, wherein branches are taken based on whether the ray intersects bounding volumes defined by the nodes;

recording a traversal history indicating one or more nodes defining bounding volumes the ray intersects and branches taken when traversing the spatial index;

determining if the ray hits a primitive contained in the bounding volume defined by the leaf node; and

if the ray does not hit a primitive contained in the bounding volume defined by the leaf node, re-traversing the spatial index using the recorded traversal history.

11. The computer readable medium of claim 10, wherein the spatial index contains a plurality of internal node levels, and the traversal history is recorded for each node level.

12. The computer readable medium of claim 10,

wherein the spatial index contains a plurality of internal node levels and the traversal history comprises four bits for each internal node level of the spatial index, wherein two of the traversal history bits indicate whether the ray intersects bounding volumes defined by a node on one of the internal node levels, and wherein two of the traversal history bits indicate branches taken when traversing the spatial index from the node on one of the internal node levels.

13. The computer readable medium of claim 10, wherein the operations further comprise:

storing the ray traversal history with information defining the ray; and

transmitting information defining the ray and the traversal history from a workload manager executing on a first processing element to a vector throughput engine executing on a second processing element, wherein the workload manager and the vector throughput engine communicate through a memory mapped address space.

14. The computer readable medium of claim 13, wherein the workload manager determines whether the ray intersects bounding volumes defined by the nodes, wherein the workload manager records the traversal history, and wherein the vector throughput engine determines if the ray hits a primitive contained in the bounding volume defined by the leaf node.

15. The computer readable medium of claim 10, wherein re-traversing the spatial index using the recorded traversal history comprises:

determining a lowest level on the spatial index where bounding volumes corresponding to a node were intersected by the ray, but the branch from the node was not taken;

traversing the spatial index based on the branches taken and recorded in the traversal history to the lowest level;

taking the branch from the node not yet taken; and

traversing the spatial index below lowest level by taking branches from internal nodes until a leaf node is reached, wherein branches are taken based on whether the ray intersects bounding volumes defined by the nodes; and wherein the operations further comprise:

recording a traversal history below the lowest level indicating one or more nodes defining bounding volumes the ray intersects and branches taken when traversing the spatial index; and

determining if the ray hits a primitive contained in the bounding volume below the lowest level and defined by the leaf node.

16. A system, comprising:

a spatial index having nodes defining bounded volumes of a three dimensional scene; and

a first processing element, wherein the first processing element is configured to: generate a ray into the scene; traverse the spatial index by taking branches from internal nodes until a leaf node is reached, wherein branches are taken based on whether the ray intersects bounding volumes defined by the nodes; record a traversal history indicating one or more nodes defining bounding volumes the ray intersects and branches taken when traversing the spatial index; determine if the ray hits a primitive contained in the bounding volume defined by the leaf node; and if the ray does not hit a primitive contained in the bounding volume defined by the leaf node, re-traverse the spatial index using the recorded traversal history.

17. The system of claim 16, wherein the first processing element further comprises:

a plurality of threads; and

a memory mapped address space; and

the first processing element is further configured to: store the ray traversal history with information defining the ray; and transmit information defining the ray and the traversal history from a workload manager executing on a first processing element thread to a vector throughput engine executing on a second processing element thread, wherein the workload manager and the vector throughput engine communicate through the memory mapped address space.

18. The system of claim 17, wherein the workload manager determines whether the ray intersects bounding volumes defined by nodes, the workload manager records the traversal history, and the vector throughput engine determines if the ray hits a primitive contained in the bounding volume defined by the leaf node.

19. The system of claim 17, wherein the system further comprises:

a second processing element comprising a second plurality of threads and a second memory mapped address space;

a high speed bus coupling the first processing element to the second processing element; and

wherein the workload manager executes on the first processing element and the vector throughput engine executes on the second processing element, and wherein the workload manager and the vector throughput engine communicate through the high speed bus and the memory mapped address spaces.

20. The system of claim 16, wherein re-traversing the spatial index using the recorded traversal history comprises,

determining a lowest level on the spatial index where bounding volumes corresponding to a node that were intersected by the ray, but a branch from the node was not taken;

traversing the spatial index based on the branches taken and recorded in the traversal history to the lowest level;

taking the branch from the node not yet taken; and

traversing the spatial index below lowest level by taking branches from internal nodes until a leaf node is reached, wherein branches are taken based on whether the ray intersects bounding volumes defined by the nodes; and wherein the system is further configured to:

record a traversal history below the lowest level indicating one or more nodes defining bounding volumes the ray intersects and branches taken when the system traverses the spatial index; and

determine if the ray hits a primitive contained in the bounding volume below the lowest level and defined by the leaf node.