US 7012604 B1
A system and method for generating images of three-dimensional objects. The system includes one or more tracing processors, and one or more shading processors. Each of the tracing processors may be configured to (a) perform a first set of computations on a corresponding group of primary rays emanating from a viewpoint resulting in a ray tree and a set of one or more light trees for each primary ray of the corresponding group, (b) transfer the ray trees and associated light trees to one of the shading processors, and (c) repeat (a) and (b). Each of the shading processors may be configured to (d) receive ray trees and associated light trees from one of the tracing processors, (e) perform a second set of computations on the received ray trees and associated light trees to determine pixel color values, and (f) repeat (d) and (e) a plurality of times.
1. A system for generating images of three-dimensional objects, the system comprising:
one or more tracing processors;
one or more shading processors;
wherein each of said tracing processors is configured to (a) perform a first set of computations on a primary ray emanating from a viewpoint resulting in a ray tree and a set of one or more light trees, (b) transfer the ray tree and set of one or more light trees to one of said shading processors, and (c) repeat (a) and (b) for each ray of a plurality of primary rays emanating from the viewpoint;
wherein each of said shading processors is configured to (d) receive a ray tree and set of one or more light trees from one of said tracing processors, (e) perform a second set of computations on said received ray tree and corresponding set of one or more light trees to determine a color value that determines at least a portion of a pixel in an output image, and (f) repeat (d) and (e) a plurality of times;
wherein each of said tracing processors is configured to receive ray spawning code in response to one or more commands asserted by a software application executing on a host computer;
wherein said first set of computations includes one or more ray spawning operations, wherein each of the tracing processors performs the ray spawning operations by executing the ray spawning code.
2. The system of
3. The system of
4. The system of
5. The system of
6. The system of
7. The system of
8. The system of
9. The system of
10. The system of
11. The system of
a ray tracing computation which propagates a ray to determine an intersection with a nearest object along the ray's path;
a shadow information computation to determine visibility of one or more light sources at the intersection point; and
a ray spawning computation to compute a reflective ray and transmissive ray at the intersection.
12. The system of
13. The system of
14. The system of
15. The system of
16. The system of
17. A method for generating images of three-dimensional objects, the method comprising:
transferring ray spawning code to a first processing unit in response to a command from a software application executing on a host computer;
performing a first set of computations on the first processing unit to determine a ray tree and one or more light trees, wherein the first set of computations includes one or more ray spawning operations, wherein the first processing unit performs the ray spawning operations by executing the ray spawning code;
transferring the ray tree and the one or more light trees from the first processing unit to a second processing unit;
the second processing unit performing a second set of computations on the ray tree and one or more light trees to determine a color value, wherein the color value determines at least a portion of a pixel in an output image.
18. The method of
transferring global light combine code to the second processing unit, wherein said second processing unit performing the second set of computations includes performing a global light combine operation by executing the global light combine code.
19. The method of
20. A system comprising:
one or more tracing processors configured to generate ray trees and light trees corresponding to primary rays emanating from a viewpoint in an object space;
one or more shading processors coupled to the tracing processors and configured to receive the ray trees and light trees and to operate on the ray trees and light trees to generate pixel values, wherein the pixel values determine an output image;
wherein each of said tracing processors is configured to receive ray spawning code in response to one or more commands asserted by a software application executing on a host computer;
wherein said generation of ray trees and light trees includes performing ray spawning operations, wherein each of the tracing processors performs the ray spawning operations by executing the ray spawning code.
21. The system of
22. The system of
23. The system of
1. Field of the Invention
This invention relates to a system for generating images, and more particularly, to a ray-tracing system for generating images of three-dimension scenes in real-time.
2. Description of the Related Art
Ray tracing is the term used to describe a method for generating images of three-dimensional scenes. The method involves sending out a system of rays from a viewpoint in a world space. The world space may be populated by a collection of three-dimensional objects. Color values are computed for each of these rays, and the color values determine the pixels of a displayable image. To compute a color value (e.g. a RGB color vector) for a given ray may involve a set of computations such as the following. The point where the ray encounters its first intersection with an object may be determined. At this “primary” intersection point, a reflection ray and a transmission ray may be determined. (The transmission ray may be computed on the basis of Snell's law of optics.) The reflection ray and transmission ray propagate until they intersect with an object. At each of these two “secondary” intersection points, new reflection and transmission rays may be determined. Now the four rays propagate until they hit four intersection points. For the sake of discussion, assume the propagation of rays stops with the four intersection points. Next, a local lighting computation is performed at the four intersection points to determine color values. Then color values at the two secondary intersection points are determined based on local lighting and some linear combination of the color values at the four intersection points. Finally, a color value at the primary intersection point is determine based on local lighting and a linear combination of the color values at the secondary intersection points. Obviously the number of intersection points grows exponentially with the number N of ray spawning stages. Thus, ray tracing is a computationally expensive process. However, the images generated with ray tracing are often more realistic and/or visually pleasing than images generated by other means. Thus, in general, there exists a need for systems and methodologies for performing ray tracing with increased speed.
In one set of embodiments, a visualization system for generating images of three-dimensional objects may include one or more tracing processors, and one or more shading processors. Each of the tracing processors may be configured to:
The first set of computations may operate on a set of vertices and corresponding normal vectors. The set of vertices define triangles for objects in a scene (e.g. a frame in a 3D animation or a computer-aided design). The normal vectors represent surface normals for the objects. Nodes of the ray tree correspond to intersections between the objects and rays derived from the primary ray. Each of the light trees includes lighting information with respect to a corresponding light source for each of the intersections in the associated ray tree. In some embodiments, other types of graphical elements (such as higher-order surfaces, etc.) may be supported in addition to or instead of triangles or polygons.
The first set of computations may include repeated applications of a ray tracing computation, a shadow information computation and a ray spawning computation. The ray tracing computation propagates a ray to determine an intersection with a nearest object along the ray's path. The shadow information computation determines the visibility (or amount of visibility) of one or more light sources at the intersection point. The ray spawning computation computes a reflective ray and transmissive ray at the intersection.
The ray spawning computation may be application programmable by a software application executing on a host computer (e.g., a desktop computer, a workstation, a computer coupled to the visualization system through one or more networks, etc.). In one embodiment, a ray spawning computation may be determined by ray spawning code transferred to each of the tracing processors in response to one or more commands asserted by the software application. In addition, the shadow information computation may be application programmable by a software application executing on a host computer.
The second set of computations may include a global lighting combine operation which combines information from the ray tree and the associated light trees in a bottom-up fashion to determine the pixel color. The global lighting combine operation may be application programmable by the host software application.
In another set of embodiments, a method for generating images of three-dimensional objects may be arranged as follows. A host program executing on a host computer may invoke the transfer of ray spawning code to a first processing unit. The first processing unit may perform a first set of computations to determine a ray tree and one or more light trees. The first set of computations may include one or more ray tracing operations and one or more ray spawning operations. The first processing unit performs the ray spawning operations by executing the ray spawning code. The first processor transfers the ray tree and the associated light trees to a second processing unit. The second processing unit performs a second set of computations on the ray tree and associated light trees to determine pixel color. The pixel color determines a pixel in an output image. The output image may be a frame in a real-time video stream.
In yet another set of embodiments, a system 3D image generation system may include one or more tracing processors and one or more shading processors. The tracing processors may be configured to generate ray trees corresponding to primary rays emanating from a viewpoint in an object space. The shading processors couple to the tracing processors and may be configured to operate on the ray trees to generate pixel values. The pixel values determine an output image. One or more of the tracing processors may include a general-purpose CPU as the algorithms for accelerating ray tracing performance are expected to improve over time. The shading processors may include specialized processors configured to support a virtual graphics language.
The number and type of tracing processors, and the number and type of shading processors may vary from one implementation to the next. A designer of the visualization system may determine these numbers and types to achieve a desired balance of cost and performance. To support maximum flexibility in the range of choices available for the tracing processors and the shading processors to be incorporated in the visualization system, the data structures which are transferred from the tracing processors to the shading processors are configured to be application programmable.
While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the appended claims.
Ray tracing is a very compute intensive process. However, next generation central processing units (CPUs) and multi-processor (MP) systems will be more capable of delivering the computer power required for real time ray tracing (RTRT).
Ray tracing may be performed with different types of graphical elements such as triangles, spheres and parameterized surfaces (e.g. higher-order surfaces determined by control parameters). The following discussion focuses mostly on the use of triangles. However, the mechanisms described herein may be used with a variety of different element types.
In one set of embodiments, a method for rendering three-dimensional objects (or N-dimensional objects where N is a positive integer) may be arranged as illustrated in
Stage 1: Transformation
Stage 1A: Global Light preprocessing
Stage 2: Tracing
Stage 3: Shading
Each of these stages may use its own processor (or set of processors). In the following descriptions the processor for the transform stage 100 is called the transform processor (XFP); the processor for the tracing stage 300 is called the tracing processor (TRP), and the processor for the shading stage 500 is called the shading processor (SHP).
Any or all of these stages may be parallelized. Thus, any or all of the XFP, TRP and SHP may include multiple parallel physical processors. In some embodiments, parallelizing the transform and tracing stages may involve two or more intermediate buffers, e.g. a first buffer to store the transformed triangles of a scene, and a second buffer to store the corresponding object descriptors (i.e. materials, textures, etc.).
In one embodiment, the TRP performs the transform stage processing as well as the tracing stage processing. Thus, the XFP and the intermediate buffers between the XFP and TRP may be eliminated in this embodiment.
2. Architecture of the Processors
Each of the XFP, TRP and SHP may be realized by a general purpose CPU or a specialized processor (SP). As used herein, the term “specialized processor” includes any circuit, device or system whose hardware organization has been optimized to perform a set of graphical computations such as three-dimensional rendering computations. Specialized processors may have fixed functionality, or alternatively, may have varying levels of programmability. For example, a specialized processor may be configured to support a graphics API (application programmer's interface) such as DirectX 8 Vertex Virtual Machine (DX8 VVM), Renderman, OpenGL and so on. The AR250 chip manufactured by Advanced Rendering Technology is an example of a specialized processor.
One or more specialized processors may be used to implement the XFP because the transform stage operations are well defined. However, in some alternative embodiments, one or more general-purpose processors may be used to implement the XFP.
As noted above, in some embodiments the transform stage processing may be performed by the TRP, and thus, the XFP may be omitted.
Algorithms for improving the performance of ray tracing rely on reducing the number of intersection tests rather than speeding up the intersection tests. These algorithms are expected to change and improve over time. Furthermore, these algorithms involve conditional branching operations (such as “if condition X is true, execute Y; else execute Z”). Thus, in one set of embodiments, the TRP may be realized by a set of one or more general-purpose CPUs. As used herein, the term “general-purpose CPU” is intended to include any of a variety of microprocessors or microprocessor-based systems such as those manufactured by Advanced Micro Devices, Inc.
The shading stage operations are fairly stable and have mostly linear control flow (i.e. do not require branches very often). Furthermore, the shading stage operations are very compute intensive (e.g., as when multiple textures and bump mapping are applied). These properties suggest that specialized hardware may be of benefit for implementing the SHP. Thus, in one set of embodiments, the SHP may be realized by a set of one or more specialized processors.
In one set of embodiments, the TRP is implemented using a general-purpose CPU, and the SHP is implemented using a specialized processor.
In one alternative embodiment, the SHP is implemented with a general-purpose CPU.
In some embodiments, either or both of the TRP and the SHP may be realized by multiple parallel processors. Support for symmetrical multi-processing (SMP) may be implemented in the system architecture of these embodiments.
2.1 Application Programmable TRP and SHP
In addition to being programmable, a processor (such as the XFP, TRP or SHP) may be application programmable. As used herein the term “application programmable” as applied to a processor means that a software application running on a host computer can specify the functionality of the processor (i.e. the computational algorithms to be performed by the processor). For example, in one set of embodiments, the software application may specify the functionality of the processor by calling pre-defined functions of an API (e.g. a graphics API such as OpenGL or DirectX 8 Vertex Virtual Machine). The API functions have a well-defined software interface that application developers can rely upon. Furthermore, the API functions handle the hardware-oriented details of interacting with the processor.
In another set of embodiments, the software application may specify the functionality of the processor by downloading machine code to the processor. The processor executes the machine code to enact the application specified functionality.
In yet another set of embodiments, the software application may specify the functionality of the processor by downloading a set of machine-independent instructions to a translation agent. The translation agent may translate the machine-independent instructions into machine code executable by the processor, and forward the machine code to a memory accessible by the processor.
In one set of embodiments, the TRP and the SHP are application programmable. Thus, the functions performed by the TRP and the SHP may be defined by a software application (within the limits of programmability imposed by selections of a TRP and an SHP).
Certain operations or algorithms within the tracing stage and/or shading stage may be defined by the software application using a virtual graphics language (VGL) such as Microsoft's DX8 VVM, OpenGL or Renderman. As defined herein, the term “virtual graphics language” refers to a language which allows programmers to invoke graphics operations in a hardware-independent fashion.
In one collection of embodiments, the programmability of the different stages is as follows.
The local lighting computation may include the computation of diffuse and/or specular color values at the intersection points.
The application program may rely on predefined standard instruction sequences (e.g. may call macros comprising such predefined instruction sequences) to specify the application programmable portions of the transform, tracing and/or shading stages.
In one set of embodiments, the operation of a real-time ray tracing system may be described as follows.
In some embodiments, the TRP may implement the operations described by the following pseudeo-code:
In some embodiments, the SHP may implement the operations described by the following pseudo-code:
The TRP may process multiple rays before passing the results to the SHP. This batch processing methodology makes the TRP processing and interfacing (with SHP) more efficient. Thus, assume that the TRP processes NB rays in a batch. For example, NB may equal 16 in one embodiment. Also, assume that each ray tree has a depth DR, where DR is a positive integer. For example, if DR equals three, reflective and transmissive rays are spawned up to the third intersection as suggested by
In one set of embodiments, the TRP may perform the following ray-processing sequence:
Early termination of the rays (e.g. no reflective ray) is handled within the corresponding steps. The appropriate intermediate data is stored in the corresponding BatchRayTree and LightRayTree structures.
3.1 Tracing Processsor (TRP) Operation
In some embodiments, the TRP may perform the following operations.
B. Tracing of rays
C. Determine Local Lighting
D. Transfer to SHP
In various embodiments, the SHP may have varying computational capabilities. The TRP may be configured to interface with SHPs which span a spectrum of computational capabilities. The host application may provide the TRP with an indication of the computational capabilities of the specific SHP with which it will interact.
In one embodiment of the SHP, the SHP may be configured to perform local lighting. In this case, the TRP will not perform the local lighting computation; instead it will pass the necessary parameters to the SHP. The TRP determines for a given light source, whether the light source is visible (no shadow) or invisible (shadow) from a given intersection point. The resulting information is then stored in the corresponding light tree.
If the SHP cannot perform local lighting, the local lighting code (e.g. VGL code) may be executed by the TRP before passing the results to the SHP.
In one set of embodiments, the SHP capabilities (as represented by the SHP_CAPS indicator) may be classified as follows.
For the sake of simplicity, in many of the examples to follow, it may be implicitly assumed that the SHP performs the local lighting computation. However, it should be borne in mind that the TRP may be configured to perform local lighting in embodiments where the SHP is not so configured.
It is very desirable to create a flexible interface between the TRP and the SHP, i.e. an interface that will allow the various embodiments of the SHP to perform tasks of varying complexity.
Therefore the data structures may be divided up into two main structures. An additional static parameter structure may contain static parameters for the light source and the attenuation factors for the distance traveled. The static parameter structure may change infrequently. For example, it may be static for at least one frame. This static parameter structure is further defined in section 4.4.
The two main data structures may contain information corresponding to a batch of NB primary rays (e.g. NB=16).
The first structure BatchRayTree contains the NB RayTree structures corresponding to the NB primary rays. The RayTree structures contain intersection information.
The second structure BatchLightTree contains the LightTree structures for the NB rays. The LightTree structures contain the lighting related information. One LightTree structure is generated per primary ray and per light source. The BatchLightTree structure may be a simple array of LightTree structures. Each primary ray of a batch is associated with a segment of the array. For example, if two light sources are used, the lighting information for primary ray #1 can be found at index 2 and 3; for primary ray #3 at index 6 and 7. So the size of the array may be:
This BatchLightTree organization has the advantage that all the lighting information spans one contiguous memory region. The same applies to the BatchRayTree structure. The TRP may then maintain only two pointers, one to the RayTree and another to the LightTree structure.
This is done to allow the SHP to effectively DMA or access the data with just two pointers.
In some embodiments, a buffer memory may intervene between the TRP and SHP. The TRP writes the BatchRayTree data structures and the BatchLightTree data structures to the buffer memory, and the SHP reads these data structures from the buffer memory. The buffer memory may be double buffered to allow overlapped TRP and SHP operations. Swapping of buffer segments in the memory buffer may occur on frame boundaries.
The RayTree and LightTree data structures may also be used as the internal data structures of the TRP. Thus, no unnecessary copying of data is required.
In one set of embodiments, the Batch structures may be defined as follows:
The structure of the ray tree and the structure of the light tree may be very similar. They may have the same node topology, but their nodes may contain different information. The ray tree may contain intersection information, whereas the light tree may contain lighting information at a given node.
A ray tree having depth D has 1+2+4+ . . . +2(D−1)=2D−1 nodes. For example, for depth D=3, the ray tree has seven nodes. Each node stores information concerning a corresponding intersection point. Each local light structure may have the same depth and number of entries as suggested by
4.1 Symmetric Multi-Processing (SMP) Support
In one set of embodiments, the TRP and/or the SHP may support multiple processors (e.g. symmetric multi-processors). The TRPs may communicate to the SHP which rays in a batch are ready to be processed and which are not. Therefore, a status flag may be included in each ray tree. The status flag indicates whether a ray is ready to be shaded or not.
Each processor of the TRP operates on a different batch of primary rays. When a primary ray within a batch is ready to be shaded, meaning that the primary ray has been traced completely, the processor sets the status flag to the ready-to-shade state.
When SHP detects that the status flag of a given ray tree is set to ReadyToShade, it will load the shading parameters of the ray tree and its corresponding light trees, and then restore the status flag to the available state. The TRP waits until after a status flag has been set to the available state before putting new information into the ray tree and corresponding light trees.
The buffer (which stores the ray trees and light trees) may contain any number of ray trees as mentioned above. The individual ray trees in the BatchRayTree may be configured (e.g. padded) so that they fall into different cache lines to avoid coherency ping-pong between the different TRP processors. Similarly, packets of light trees belonging to different ray trees may be configured so that they fall into different cache lines.
This flag-based handshaking mechanism is very flexible with regard to the distribution of the rays from the TRP to the SHP. It also hides the nature of the TRP from the SHP. Regardless of whether there is one processor or multiple processors in the TRP, the buffer and the synchronization are identical. This mechanism also avoids the difficulty of having to synchronize the TRP processors before the buffer is updated.
In one set of embodiments, the SHP automatically scans each flag to determine whether to process the corresponding primary ray. Alternatively, to reduce memory traffic, the SHP may use the first flag in a BatchRayTree as a trigger event to process the first primary ray and then scan the other primary rays in the batch.
The stride between successive ray trees in the BatchRayTree may be indicated to the SHP. The stride is a global parameter, and may either be put into the static parameter structure or directly programmed into the SHP.
In addition to multiple TRPs processing multiple batches in parallel, multiple SHPs may also process multiple batches in parallel. The same flag-based handshaking mechanism as described above may be used.
This handshaking mechanism supports any number of TRPs and SHPs without modification. This mechanism allows the number NT of TRP processors and the number NS of SHP processors to be independent. In fact, NT and/or NS may be changed dynamically.
4.2 Ray Tree Structure
A ray tree structure contains the intersection information for the rays derived from a single primary ray. The following describes an exemplary structure for the ray tree. It is noted that the ray tree may have any of various structures for various special embodiments. Assuming a depth level of 3, the ray tree structure has 7 entries as follows.
To support multiple processors with SMP for either the TRP and/or the SHP, the TRPs may indicate to the SHP which primary rays (i.e. which ray trees) are ready to be processed and which are not. Therefore, a status flag may be included in each ray tree. The status flag indicates whether the primary ray (i.e. the ray tree) is ready to be shaded or not. Each processor of the TRP may process different batches of rays.
The stRayTreeElement structure may contain the following information:
The distance traveled may be used to attenuate the ray contribution. The attenuation function may have any desired form. For example, in one embodiment, the attenuation function may be a quadratic polynomial with three coefficients such as Att(x)=a+bx+cx2, where x is the distance traveled from the light source to the intersection point.
4.3 Light Tree Structure
A light tree structure may contain the lighting information for each of the intersection points of a given ray tree for one light source. Each node of the light tree may relate to a corresponding node of the ray tree. There may be one light tree structure for each light source.
In one embodiment, the light tree structure has the following form. Assuming a depth level of 3, the light tree structure has 7 entries as follows.
The SHP uses the light tree as an input. The VGL shader code and the SHP capabilities indicator determine what kind of processing can be performed by the SHP.
The state of the SHP capabilities (SHP_CAPS) indicator may determine what information is stored in the stLightTreeElement structure. If the SHP can perform local lighting (e.g. SHP_CAPS=SHP LOCL_X), then the TRP will put the appropriate information including shadow flag into the light tree. The SHP will then perform local lighting and the global lighting combine step as described below.
If the SHP cannot perform local lighting (e.g. SHP_CAPS=SHP_NULL), the TRP will perform the local lighting, and store the final diffuse and specular values for each intersection point into the light tree structure. The SHP will then perform the global lighting combine step.
Thus, the stLightTreeElement structure may be assembled according to the state of the SHP_CAPS indicator.
In some embodiments, the stLightTreeElement structure may contain the following information.
Local Lighting information
The following entries may be used if the SHP performs local lighting (e.g. SHP_CAPS=SHP_LOCL_X):
The static parameter structure may contain parameters which are static for at least one frame. It may contain the following entries.
The light source parameters may be stored in an array. The index used to access successive records in this array may be identical to the index used to access successive light trees in the BatchLightTree. This one-to-one correspondence makes addressing easy.
If it is anticipated that the light source parameters will change frequently, the light source parameters may be appended to the light trees. The light source parameters for a given light source may be appended to the corresponding light tree. Similarly, the attenuation factors may also be appended to the ray trees.
5. Global Lighting Combine
The global lighting combine (GLC) step may be performed after the local lighting step and before rasterizing the pixel. The GLC step may be application programmable (e.g. with VGL instructions).
The GLC step combines the local lighting values in a light tree. Initially, the diffuse and specular components may be added to obtain a local color value at each node of the light tree. (Recall that the nodes of the light tree correspond to the intersection nodes of the ray tree). In one set of embodiments, the light tree may then be processed (in conjunction with the ray tree) from bottom to top as follows:
The example above has been described in terms of a ray tree and light tree with depth D=3. However, the example naturally generalizes to trees of arbitrary depth.
The example above illustrates one possible method for performing the GLC step, and is not intended to be limiting. A wide variety of methods are contemplated. In fact, the specific method to be used may be determined by the application designer (e.g. through VGL code programming).
Texturing may apply any desired transformation to the local lighting. Texture alpha values may be used during tracing to determine transparency. A final transparency coefficient is determined in the tracing stage and placed into the tracing coefficient field of the light tree. The pOBJ descriptor contains information on how to compute the final transparency value from the object transparency and the texture alpha value (TBD).
An example of the GLC computation is shown below. For the sake of simplicity, part of the computation is suppressed. However, the suppressed portion (i.e. the computation of Tot_T) may easily be derived based on parallelism of structure with respect to the disclosed portion (i.e. the computation of Tot_R).
In one set of embodiments, the transfer of ray trees and light trees between the TRP and SHP may be distributed across multiple links as described in the following. In one embodiment, one or more of these links could be realized by the Lighting Data Transfer Busses (LDTs) manufactured by Advanced Micro Devices (AMD).
In some embodiments, multiple parallel TRPs and SHPs are utilized. Logically, there are three distinct cases regarding the number NTRP of TRPs and the number NSHP of SHPs:
These three cases are described in more detail in the following sections.
6.1 Identical count of TRPs and SHPs
Suppose that the number of TRPs and the number of SHPs are identical. In one set of embodiments, each TRP may couple to a corresponding SHP through a dedicated link as suggested by
In some embodiments, the links are configured so that almost all of the data is transferred through the links in one direction: i.e. downstream from the TRPs to the SHPs. In one particular embodiment, the links are configured so that no turnaround is required. Because, the TRP doesn't have to wait for any results from the SHP, high link utilization may be achieved. Also unidirectional dataflow allows more freedom for the computational stages in the TRP to be pipelined heavily without negatively impacting performance.
The SHP may control the state of a ready-to-receive flag. The ready-to-receive flag indicates to the TRP whether the SHP is ready to receive information from the TRP. This ready-to-receive flag may be implemented in the hardware (HW) control flow mechanism of the underlying link. In this case the TRP may check the link to determine whether it may send data or not. On the SHP receiving side, a first-in first-out (FIFO) may buffer the input data.
The SHP may have a FIFO sufficiently deep to store at least a tree bucket (i.e. a ray tree and light trees corresponding to a single pixel). In one set of embodiments, the synchronization mechanism may operate as follows.
This synchronization mechanism requires little overhead and is fast.
The SHPs may also access some common memory which stores global data such as the object descriptors, texture maps, etc. The SHPs may have special cache memories to decouple accesses to the common memory.
6.2 TRP Count Greater than SHP Count
In the case where the number of TRPs is greater than the number of SHPs, each SHP may receive data from multiple TRPs. The communication between each SHP and the multiple TRPs which feed it may be achieved using a bridge component as suggested by
The synchronization protocol may be very similar to that described above except that additional information may be used to indicate the TRP which sent a given bucket. This additional information may not be required for the shading process itself but may be used for the transmission of the ready-to-receive flag. Thus, the SHP may selectively control the data transfers for each TRP.
There are at least two possibilities for including the additional information. One possibility is to use the source address of the link as in Advanced Micro Devices' LDT. The second possibility is to include a tag as an additional field in the ray tree structure. The tag identifies the TRP which sent the data. Thus, the SHP may use that information to send the ready-to-receive flag to the corresponding TRP.
6.3 TRP Count Less than SHP Count
In the case where the number of TRPs is less than the number of SHPs, each TRP may send data to multiple SHPs. Each TRP may send data to the corresponding multiple SHPs using a bridge component. The bridge component may connect the single TRP link to multiple SHP links as suggested in
The synchronization protocol may be very to the protocol in section 6.2. However here the additional tag may be used to send the ready-to-receive flag back to the TRP and not to the other SHPs (link addressing).
The TRP may send buckets to the SHPs in a certain order to split up the work load for the SHPs. Multiple distribution methods may be used such as round robin or any of various load-balancing schemes.
Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.