US 7355601 B2
A CPU module includes a host element configured to perform a high-level host-related task, and one or more data-generating processing elements configured to perform a data-generating task associated with the high-level host-related task. Each data-generating processing element includes logic configured to receive input data, and logic configured to process the input data to produce output data.
1. A system comprising:
a system memory;
a computer processing module, including:
a host processing element configured to perform a task;
a data-generating processing element configured to perform a subtask within the task, including:
logic configured to receive input data; and
logic configured to process the input data to produce output data, wherein an amount of output data is greater than an amount of input data, a ratio of the amount of input data to the amount of output data defining a decompression ratio, wherein the output data generated by the data-generating processing element is not contained in the system memory prior to it being generated by the data-generating processing element;
a cache memory coupled to the data-generating processing element for receiving the output data;
a computer processing module interface for outputting the output data from the cache memory;
coherent cacheable memory of the computer processing module separate from the cache memory coupled to the data-generating processing element;
a communication bus;
a data processing module, including:
a data processing module interface coupling to the computer processing module interface via the communication bus for receiving the output data; and
a data processing engine for receiving and processing the output data from the cache memory, wherein the data processing engine uses a tail pointer to indicate a location within the cache memory from which it has just retrieved data;
wherein, in a write streaming mode of operation, the computer processing module is configured to allocate a portion of the cache memory for the purpose of receiving streaming write output data from the data-generating processing element, wherein, in the write streaming mode of operation, the system is configured to forward output data from said allocated portion of the cache memory to the data processing module rather than from the system memory, and
wherein the data processing module is configured to forward the tail pointer to the coherent cacheable memory of the computer processing module, the tail pointer informing the data-generating processing element of the location within the cache memory from which the data processing module has just retrieved data.
2. The system of
3. The system of
4. The system of
5. The system of
6. The system of
7. The system of
maintaining cache lines of the L2 cache in a modified state, after data from the cache lines have been transferred to the data processing module.
8. The system of
9. A computer system, comprising:
a graphics processing unit (GPU); and
a central processing unit (CPU) having
a plurality of processing elements each having an L1 cache,
a multi-set L2 cache shared between the processing elements, wherein in a write streaming mode of operation one or more sets of the cache are allocated to a locked set for transferring data between the CPU and the L2 cache for access by the GPU without writing the generated data to the system memory,
cacheable memory separate from the L2 cache for storing a tail pointer indicating a location within the L2 cache from which the GPU has accessed data, and
interface logic configured to receive a write request from the GPU to update a tail pointer value stored in the cacheable memory and, in response, invalidate copies of the tail pointer in the L2 cache and the L1 cache of at least one processing element.
10. The computer system of
11. The computer system of
12. The computer system of
13. The computer system of
14. A central processor unit (CPU), comprising:
a plurality of processing elements each having an L1 cache;
a multi-set L2 cache shared between the processing elements, wherein in a write streaming mode of operation one or more sets of the cache are allocated to a locked set for transferring data between the CPU and the L2 cache for access by a graphics processor unit (GPU) without writing the generated data to the system memory;
cacheable memory on the processor separate from the L2 cache for storing a tail pointer indicating a location within the L2 cache from which the GPU has accessed data; and
interface logic configured to receive a write request from the GPU to update a tail pointer value stored in the cacheable memory and, in response, invalidate copies of the tail pointer in the L2 cache and the L1 cache of at least one processing element.
15. The processor of
16. The processor of
17. processor of
18. A method for transferring data generated by a central processing unit (CPU) to a graphics processing unit (GPU) without writing the generated data to external memory, comprising:
allocating a plurality of cache lines of an L2 cache residing on the CPU for use in a locked set;
storing, by the CPU, data in one or more cache lines allocated to the locked set while bypassing an L1 cache;
reading, by the GPU, data from the locked set of the CPU without accessing external memory;
receiving, by the CPU, a request from the GPU to update a tail pointer stored in cacheable memory on the CPU separate from the L2 cache, the tail pointer indicating a location within the locked set from which the GPU has read data; and
in response to the request, invalidating copies of the tail pointer in the L1 and L2 caches and updating the tail pointer stored in the cacheable memory.
19. The method of
in response to a request to load the tail pointer, accessing the updated tail pointer from the cacheable memory and storing copies of the updated tail pointer in the L1 and L2 caches.
20. The method of
This application is a continuation-in-part of, and claims the benefit of, co-pending U.S. application Ser. No. 11/027,454 filed on Dec. 30, 2004, which is a continuation of, and claims the benefit of, U.S. application Ser. No. 10/611,415, filed on Jun. 30, 2003, which issued as U.S. Pat. No. 6,862,027 on Mar. 1, 2005, all of which are incorporated herein by reference in their entirety.
1. Field of the Invention
This invention relates to a system and method for the parallel execution of data generation tasks, and, in a more particular implementation, to a system and method for the parallel execution of geometry-related data generation tasks in a three dimensional graphics application.
2. Description of the Related Art
Designers of computer graphics applications continually strive to provide more interesting rendered scenes to viewers. For instance, many game developers work toward increasing the realism of rendered scenes. A scene that provides a realistic depiction of characters and background scenery is more likely to capture the interest of a player, that is, by immersing the player in the game. The player's heightened interest, if shared by many players, may translate into increased profitability of the game.
A number of difficulties confront game developers when attempting to improve the realism of rendered scenes. Increasing the appeal of a scene usually equates to increasing the complexity of the scene. The increased complexity manifests itself in a marked increase in the amount of data associated with the scene. More specifically, graphics applications represent objects (e.g., models) within a scene using a mesh of polygons—typically triangles—which, in turn, comprise a number of vertices (loosely referred to as “geometry data” herein). Increasing the complexity of the scene typically equates to a marked increase in the amount of geometry data. For example, consider the case of a simple game which pits two characters against each other. Each character is represented by a model, which, in turn, comprises of a set of geometry data. If a game developer desired to improve the realism of the game by increasing the amount of detail associated with the characters, or by adding more characters to the scene, then the amount of geometry data involved in rendering this scene could be expected to markedly increase. A scene that presented a whole army of such characters might be regarded as too complex to viably render in many game-playing platforms currently on the market.
More specifically, the above-described processing constraints arise from the demanding need to generate and process a large amount of game-related geometry data in the short amount of time necessary to render a scene in a typical game playing platform environment (e.g., a typical game renders a scene frame every 16 ms). This requires efficient algorithms for generating and processing the game-related data, as well as efficient strategies for moving this data from one module to another within the game console. More particularly, a typical bottleneck in graphics processing is the transfer of large amounts of data between the processing elements of the game console (e.g., the computer processing unit and/or the graphics processing unit) and the memory of the game console (e.g., the RAM memory of the game console).
Still additional drawbacks (to be specified in the following discussion) exist which may prevent game developers from improving the complexity, efficiency, and/or realism of rendered scenes.
Accordingly, there is an exemplary need in the art to provide more efficient systems and techniques for increasing the complexity of rendered scenes. There are analogous needs in the art to provide more efficient systems and techniques for processing large amounts of data in other data processing fields, such as audio and video processing.
One embodiment provides a system generally including a system memory a computer processing module, a communications bus, and a data processing module. The computer processing module generally includes a host processing element configured to perform a task, a data-generating processing element configured to perform a subtask within the task, a cache memory coupled to the data-generating processing element, and a computer processing module interface.
The data processing module generally includes a data processing module interface coupling to the computer processing module interface via the communication bus for receiving the output data and a data processing engine for receiving and processing the output data from the cache memory, wherein the data processing engine uses a tail pointer to indicate a location within the cache memory from which it has just retrieved data.
In a write streaming mode of operation, the computer processing module is configured to allocate a portion of the cache memory for the purpose of receiving streaming write output data from the data-generating processing element, wherein, in the write streaming mode of operation, the system is configured to forward output data from said allocated portion of the cache memory to the data processing module rather than from the system memory. The data processing module is configured to forward the tail pointer to the coherent cacheable memory of the computer processing module, the tail pointer informing the data-generating processing element of the location within the cache memory from which the data processing module has just retrieved data.
Another embodiment provides a computer system. The computer system generally includes system memory, a graphics processing unit (GPU), and a central processing unit (CPU). The CPU generally includes a plurality of processing elements each having an L1 cache, a multi-set L2 cache shared between the processing elements, wherein in a write streaming mode of operation one or more sets of the cache are allocated to a locked set for transferring data between the CPU and the L2 cache for access by the GPU without writing the generated data to the system memory. The CPU also includes cacheable memory for storing a tail pointer indicating a location within the L2 cache from which the GPU has accessed data, and interface logic configured to receive a write request from the GPU to update a tail pointer value stored in the cacheable memory and, in response, invalidate copies of the tail pointer in the L2 cache and the L1 cache of at least one processing element.
Another embodiment provides a processor. The processor generally includes a plurality of processing elements each having an L1 cache, a multi-set L2 cache shared between the processing elements, wherein in a write streaming mode of operation one or more sets of the cache are allocated to a locked set for transferring data between the CPU and the L2 cache for access by the GPU without writing the generated data to the system memory. The processor also includes cacheable memory for storing a tail pointer indicating a location within the L2 cache from which the GPU has accessed data, and interface logic configured to receive a write request from the GPU to update a tail pointer value stored in the cacheable memory and, in response, invalidate copies of the tail pointer in the L2 cache and the L1 cache of at least one processing element.
Another embodiment provides a method for transferring data generated by a central processing unit (CPU) to a graphics processing unit (GPU) without writing the generated data to external memory. The method generally includes allocating a plurality of cache lines of an L2 cache residing on the CPU for use in a locked set, storing, by the CPU, data in one or more cache lines allocated to the locked set while bypassing an L1 cache, reading, by the GPU, data from the locked set of the CPU without accessing external memory. The method also includes receiving, by the CPU, a request from the GPU to update a tail pointer stored in cacheable memory on the CPU, the tail pointer indicating a location within the locked set from which the GPU has read data, and, in response to the request, invalidating copies of the tail pointer in the L1 and L2 caches and updating the tail pointer stored in the cacheable memory.
The same numbers are used throughout the disclosure and figures to reference like components and features. Series 100 numbers refer to features originally found in
This disclosure pertains to an architecture and related technique for parallel execution of data-generation tasks. Such data-generation tasks generally refer to an operation that entails receiving a first set of data and then generating a second set of data based on the first set of data, where the second set of data represents a greater amount of information than the first set of data. The ratio between the first set of data and the second set of data defines a decompression ratio. An application that provides a relatively high decompression ratio can effectively address some of the problems identified in the background discussion. For instance, an application that can generate a great amount of data from a relatively small set of input data eliminates (or reduces) the need to create this data beforehand, store such data in system memory, and then retrieve this data when it is time to process such data. Hence, such applications can avoid the deleterious latency and bandwidth problems associated with transferring data between system memory and the processing modules of an application. Further, such applications can also reduce the amount of information that needs to be stored in system memory, which is often a limiting resource, especially in game consoles. These improvements may also reduce the cost associated with various components of the game consoles.
A great number of applications of the above-described design strategy are envisioned, including applications involving graphical data, applications involving audio data, applications involving video data, etc. However, to facilitate explanation, the following discussion describes the application of the design strategy to the field of three dimensional computer graphics, and more specifically, to the field of three dimensional game-related computer graphics. Computer graphics applications represent data-intensive processing environments. Further, game-playing console environments require that a sizeable amount of data be processed in timely fashion (e.g., to render scenes at 16 ms per frame, etc.), and also require that this data be processed using an architecture that typically has relatively limited system memory resources. Hence, three-dimensional game applications represent an ideal application of the above design strategy. However, as noted above, the architectures and techniques described here are not to be construed as limited to such exemplary applications.
This disclosure contains the following principal sections. Section A describes an exemplary system for implementing the above-described design strategy. Section B describes an exemplary manner of operation of the system discussed in Section A. And Section C describes the application of systems and techniques described in Sections A and B to a game-playing environment.
A. Exemplary System Architecture
A.1. Overview of System
In one exemplary implementation, the system 100 includes a computer processing unit module 102 (referred to below as a “CPU module” 102 for brevity) coupled to a graphics processing unit module 104 (referred to below as a “GPU module” 104 for brevity) via a front side bus 106. The CPU module 102 includes a collection of any number of computer processing units (CPUs), such as CPU 1 (108), CPU 2 (110), and CPU n (112) (where “n” generally indicates the last of the collection of CPUs). These CPUs (108, 110, . . . 112) provide general purpose computing units for processing data based on a series of program instructions specified by a graphics game developer. The GPU module 104 includes a graphics engine 114 that performs lower level 3D graphics processing tasks on received data.
The two major modules in
Starting with the CPU module 102, the CPU module 102 allocates different roles to its CPUs (108, 110, . . . 112). For instance, CPU 1 (108) functions as a host processing 11 unit, whereas CPUs 2 to n (110, . . . 112) function as geometry processing units. The tasks associated with these roles differ for different applications. In a typical gaming application, the host CPU 1 (108) performs the high-level tasks associated with the game, such as receiving a player's input, performing scene management, performing the computations used to simulate the physical phenomena represented by the application, performing any artificial intelligence provided by the game, and so on. The CPUs 2 to n (110, . . . 112) perform more fine-grained processing associated with a game. In one application, these CPUs (110, . . . 112) generate geometry data associated with one or more objects in the scene. For instance, as will be described, each of these processors may include logic for performing procedural geometry. Such logic receives input data defining tasks to be performed, and then executes such tasks to provide output geometry data (e.g., a collection of vertices). To provide merely one example, a game designer could provide procedural logic to generate geometry data associated with individual leaves on a tree. Such procedural logic would receive a relatively limited amount of information associated with such a task, such as a location of an individual leaf, a direction of any simulated wind in the scene, and so on. Based on this information, the procedural logic could generate vertices that define an individual leaf on the tree. The CPUs that perform geometry-related tasks are referred to as geometry-generating CPUs.
In another application, the geometry-generating CPUs 2 to n (110, . . . 112) can perform tessellation of higher-order surfaces. A higher-order surface refers to the representation of an object in another parametric format other than a simple mesh of triangles. Most three dimensional processing engines, however, only process objects that are represented as simple polygons, such as triangles. The process of tessellation breaks these higher order surfaces into more primitive polygons, such as triangles. Thus, the geometry-generating CPUs 2 to n (110, . . . 112) can be used to execute such tessellation, that is, by receiving higher order surfaces and breaking these surfaces into more elementary forms. Exemplary higher order surfaces include B-spline surfaces, Bezier surfaces, n-patches, etc.
The geometry-generating CPUs 2 to n (110, . . . 112) can provide the above-described procedural geometry and/or higher order surface tessellation in conjunction with level-of-detail (LOD) processing. In LOD processing, the level of complexity (and hence geometry data) associated with an object in a scene is varied as a function of the distance between the viewer and any object (or any sub-object pieces) within the scene. The LOD processing can apply different decompression ratios to achieve different levels of complexity. This will have the effect of applying higher levels of decompression for objects that are “close” to the viewer, producing higher levels of detail.
The examples provided above pertain to the generation of geometry data (e.g., color, texture coordinates, normals, etc.). However, the CPUs 2 to n (100, . . . 112) can be used to procedurally generate other kinds of data, such as GPU commands.
As noted above, while n CPUs (108, 110, . . . 112) are illustrated in
In one application, the system 100 can be configured to statically assign roles to the CPUs (108, 110, . . . 112), e.g., by assigning a CPU to the role of either a host CPU or a geometry-generating CPU. In another application, the system 100 can allocate these roles in a dynamic fashion, possibly on a frame by frame basis, or even many times within a frame (e.g., on an intra-frame basis). Thus, in one application, all of the CPUs (108, 110, . . . 112) can be assigned the role of handling host-related tasks. This might be appropriate in those cases where a programmer does not wish to make use of the special features provided by the geometry-generating CPUs 2 and n (110, . . . 112). In another case, the system 100 can assign the role of geometry-related processing to all of the CPUs (108, 110, . . . 112) for some portion of the frame time. In another case, as will be discussed below, the system can include two or more CPU modules 102. In this case, the system 100 can allocate the same role to all of the CPUs in one of the CPU modules 102 (such as geometry processing). In this scenario, it may be considered beneficial to locate the CPU module 102 assigned the role of host processing closest to a system memory 130 (because, in some environments, the host may be more negatively impacted by random access read misses than the geometry processing functionality, and therefore has more of a need for lower latency compared to the geometry processing functionality).
Each CPU includes an internal L1 cache. For instance, CPU 1 (108) includes an internal L1 cache 116, CPU 2 (110) includes an internal L1 cache 118, and CPU n (112) includes an internal L1 cache 120. A cache refers to a readily accessible storage space for storing data that is likely to be used by the CPU. Although not shown, in a conventional manner, the L1 caches (116, 118, 120) can include a portion allocated to storing instruction-related information, and a portion allocated to storing data. Further, although not shown, each of the CPUs (108, 110, . . . 112) will include a collection of 11 storage registers. Storage registers provide even more readily accessible storage locations than the L1 caches (116, 118, 120).
The CPUs (108, 110, . . . 112) are coupled to a shared L2 cache 122 through multiple ports via bus interface units 124, 126, and 128, respectively. As the name suggests, each of the CPUs (108, 110, . . . 112) share (e.g., use) the L2 cache 122. To complete the explanation of the memory hierarchy shown in
The L2 cache 122, like the individual L1 caches (116, 118, 120), provides storage for information that is likely to be requested by the CPUs (108, 110, . . . 112) and the GPU module 104. That is, the caches (116, 118, 120, 122) allow the processing functionality in system 100 to access data without having to read from or write to the system memory 130. It is generally desirable to avoid reading from or writing to the system memory 130, as such operations will impose latency delays (e.g., in one exemplary implementation, delays of possibly greater than 100 cycles). However, if data cannot be obtained from one of the caches (116, 118, 120, 122), then the processing functionality in system 100 will access such data from the system memory 130. The shared L2 cache 122 can be implemented as an n-way set associative cache, as will be discussed further in connection with
The CPU module 102 further includes a crossbar coupling mechanism 134 (referred to below as simply a crossbar 134 for brevity). The crossbar 134 comprises a switching mechanism that selectively connects any one of a plurality of input ports to any one of a plurality of output ports. There are different ways to implement the crossbar 134, such as by using a multiplexing mechanism.
The crossbar 134 provides connectively to a number of entities, such as I/O module 136 via I/O interface 138. The I/O module 136 generally represents any functionality for receiving input and/or providing output in connection with a specific application. In a game application, the I/O module 136 can receive a game player's input using various controllers via a Universal Serial Bus (USB) mechanism, etc. This I/O module 136 can also provide network connectivity, audio system coupling, etc.
The crossbar 134 also provides optional connectivity to other CPU processing modules 140 via a Symmetric Multiprocessing (SMP) interface 142. Symmetric multiprocessing refers to an arrangement in which multiple CPUs share the same memory space and operating system. The optional other CPU modules 140 provide additional processing power to the system 100 if such functionality is deemed desirable for a particular application.
The crossbar 134 also provides connectivity to the GPU module 104 via GPU interface 144 and CPU interface 146. The front side bus 106 couples the GPU interface 144 and CPU interface 146. This bus 106 should have sufficient bandwidth to handle the large amount of data generated by geometry-generating CPUs 2 to n (110, . . . 112), as well as host bandwidth and coherency traffic. Another crossbar 148 in the GPU module 104 directs the geometry data received from the CPUs 2 to n (110, . . . 112) (as well as other data) to the graphics engine 114. The graphics engine 114 can perform a variety of graphics-related operations. Such operations can include various tasks associated with a conventional three dimensional graphics processing pipeline, including vertex processing (which generally involves geometrically transforming the vertex data and applying lighting, e.g., shading, to the vertex data), backface culling processing, clipping processing, triangle set-up processing, rasterization, pixel-based shader processing, fog processing, alpha testing, depth testing, stencil testing, alpha blending, dithering, etc. An exemplary overview of conventional graphics pipeline processing is presented in, for instance, Wolfgang F. Engel, Direct3D: ShaderX: Vertex and Pixel Shader Tips and Tricks, 2002, Wordware Publishing, Inc. In one exemplary implementation, the CPUs (108, 110, . . . 112) differ from the functionality provided by the GPU module 104 in a number of respects; for instance, the CPUs (108, 110, . . . 112) typically have a much more general software programming model, perform significantly better on single threaded applications, and enable more decision-based branching than the GPU module 104. In other implementations, the distinction between the functionality provided by the CPUs (108, 110, . . . 112) and the functionality provided by the GPU module 104 may be less pronounced.
As will be discussed in Section B below, in one exemplary implementation, the GPU module 104 interacts with memory using a Direct Memory Access (DMA) protocol. For instance, the system 100 performs a command list fetch using a DMA mechanism. The DMA mechanism does not “know” where the data is being obtained from; it is the function of the crossbars to fetch data from the correct location. In one implementation, to fetch data over the front side bus 106, the system 100 forms a particular packet to initiate a “read” from the CPU module 102.
A coherency module 150 optionally ensures that CPU cache resident data remains coherent with main memory. The coherency module 150 also provides functionality that is specifically tailored to the data streaming provided by the system 100, where such functionality differs in one or more respects from traditional cache coherency. Additional details regarding the operation of the coherency module 150 will be presented 11 in Section B below.
In one exemplary implementation, the CPU module 102 is implemented as a first chip in a game-playing console, and the GPU module 104 is implemented as a second chip in the game-laying console. Additional CPU module chips can be included, along with associated GPU module chips. In other implementations, the functionality described in
n general, as is well known in the art, a thread refers to a task performed by a processing unit, typically comprising a series of subtasks performed in a specific order forming a sequence of such subtasks. An exemplary processing unit that accommodates two threads allocates resources between two such tasks. For instance, in one example, a processing unit can execute a first task (thread) comprising a plurality of subtasks. If, in the course of executing these subtasks, a data hazard is encountered, then there will be a delay in processing the subtasks. For example, if data cannot be obtained from an immediately accessible cache location, then the system must retrieve the data from a less readily accessible source, such as the system memory 130. This operation can introduce a delay in the performance of the first thread of potentially several hundred cycles. Such a delay represents a “bubble” in the execution of the first thread. So that the processing unit will not be idle during this bubble, the processing unit is configured to use the idle resources of the processing unit to perform subtasks in the second thread. In this manner, the processing unit makes more efficient use of its resources and also potentially expedites the rendering of scenes.
In the arrangement 200 shown in
Although not illustrated, the GPU module 104 can also perform its allotted functions using one or more threads.
Further, the ensuing discussion (e.g., with reference to
A.3. Bandwidth Considerations
The buses provided in
In one entirely exemplary implementation, the CPUs can produce an aggregate stream of geometry data of thousands or millions of vertices per second, or some other quantity per second depending on the requirements of a particular data processing environment. In one exemplary implementation, using uncompressed data of several bytes per vertex (e.g., 32, 64, 128, etc.), this amounts to a bandwidth in the MB/s range or the GB/s range from the CPU module 102 to the GPU module 104, although smaller or larger rates can be provided too.
The above-described high levels of decompression have a number of benefits. In the context of a game console, for example, the high levels of decompression can improve the performance of the console (e.g., by reducing latency) and reduce the system memory requirements (and associated cost) of the console. Providing high levels of decompression in the CPU module 102 can also reduce the complexity and associated cost of other components in the game console, such as system busses, distribution media (e.g., DVD), peripheral busses, network connections, and so on. For instance, the decompression applied in the CPU module 102 can reduce the complexity and associated cost of compression/decompression schemes conventionally used in other components in the game console, or even, in some cases, eliminate such traditional compression schemes.
A.4. L2 Cache
By way of introduction, the system 100 shown in
Different strategies can be used to provide the locked set 502. For instance, cache lines are typically cast out of a cache based on various factors, such as a determination of how recently the cache line was accessed (for either a read or write operation). Thus, the set 502 can be locked by configuring cache management logic (not shown) to indicate that the entries within the locked set 502 are always the most recently accessed entries within the L2 cache 122. This would prevent these entries from being retired (e.g., “cast out”). Still additional strategies exist for accomplishing the same locking functionality.
Multiple First-In-First-Out (FIFO) buffers 506, 508, 510, and 512 are formed within the locked set 502. In this exemplary case, four buffers are illustrated; although a and bottom bits of an address 514. The top and bottom bits of the address 514 are denoted by “don't care” bit fields 516 and 518, respectively (denoted in the
Providing the locked set 502 in the L2 cache 122 is desirable to prevent the high write bandwidth associated with the output of geometry-generating threads (206, 208, 210, 212) from “thrashing” the L2 cache 122. Namely, the host-related threads (202, 204) require the use of the L2 cache 122 for conventional cache-related purposes, namely to store data that is most likely to be accessed by these threads (202, 204). However, in view of the replacement strategies used by cache memories, without locking a set in the L2 cache 122, the high volume of data writes generated by the geometry-generating threads (206, 208, 210, 212) will effectively cast the host's data out of the cache 122 (because the data provided by the geometry-generating threads will quickly assume the position of the most-recently used data). If this happens, the host-related processing threads (202, 204) will be required to access their required data from a remote memory, such as the system memory 130, which will incur a processing delay. This deleterious phenomenon constitutes the above-mentioned “thrashing.” To prevent this from happening, the system 100 separates the demands of the host-related processing threads (202, 204) from the geometry-generating processing threads (206, 208, 210, 212). This locking provision prevents the above-described thrashing. In addition, without using a locked set, some of the data provided by the geometry generating threads can itself also be cast out of the cache, making the round trip to system memory before the GPU can use it. Given the huge amounts of data generated, this would induce unacceptable bandwidth demands. It would also introduce latencies that would reduce overall performance by making the GPU module 104 wait.
As mentioned above, the system 100 shown in
Each FIFO has a discrete starting location and ending location. Thus, a CPU associated with a FIFO must periodically monitor the storage locations in the FIFO to ensure that the CPU does not attempt to store data past the end of the FIFO. When a CPU stores to the last storage location in its respective FIFO, the CPU should wrap around to store the next data at a first storage location in its FIFO. In this manner, the CPU uses the FIFO as a circular buffer. However, one disadvantage of this technique is that the CPU must periodically monitor its progress through the FIFO to ensure that it does not overshoot the end of the FIFO. Performing this checking can increase the complexity of the streaming write operation, and also can potentially introduce delays in the streaming write operation. One technique for addressing this problem is to wrap within the FIFO using a middle portion of an address. For instance, consider FIFO 512 associated with thread 212. Wrapping is performed in the FIFO 512 by ignoring the top 122 can likewise change in dynamic fashion. For instance, where a game developer does not wish to make use of the special functionality provided by geometry-generating CPUs 2 to n (110, 112), then the system 100 can allocate the entire cache 122 to host-related functions. Alternatively, the system 100 can allocate more than one set of the L2 cache 122 to geometry-related threads involved in the streaming write operation.
A.5. Instruction Set Modifications
To begin with,
In one implementation, the logic 700 involves receiving the uncompressed geometry data in a first CPU register, performing compression on the geometry data as specified by an instruction in a program, and then loading the compressed geometry data into another CPU register. In another implementation, the compression operation can be combined within whatever functionality provides for outputting information from the CPU.
As to the compression itself, various known strategies can be used to compress the geometry data, such as the compression technique employed by Microsoft.RTM. DirectX.RTM. 9.(n), provided by Microsoft Corporation of Redmond, Wash. More specifically, different types of information associated with a vertex can be compressed using different techniques. Further, different types of information associated with a vertex can receive different degrees of compression. For instance, a first type of information can receive 2 to 1 compression, while another type of compression can receive 4 to 1 compression ratio, etc. In this sense, the compression provided by logic 700 is referred to as variable compression (meaning that it varies for different types of information within a vertex). Further, compression can vary for the same type of information depending on an application's needs. For example, geometric coordinates may be compressed to 8-bit values for some meshes, but can be 16-bit or 32-bit values for other meshes where fineness of placement is deemed to be important.
Compressing the geometry data that is output from the CPUs (108, 110, . . . 112) helps reduce the bandwidth of geometry data traveling between the CPU module 102 and the GPU module 104. Further, compressing the geometry data also enables the FIFOs in the locked set 502 of the L2 cache 122 to store more geometry data.
In another implementation, the instruction set also includes logic for decompressing information that is received by a CPU. This decompression can again be considered variable in that different pieces of data are subject to different techniques for decompression and possibly different degrees of decompression. The decompression can be implemented as a register to register operation, or can be integrated into whatever functionality the CPU uses to input data. In the latter technique, the decompression can be integrated as part of the normal load cycle of the CPU. The decompression functionality has several advantages. First, it makes the compression/decompression functionality symmetric such that a CPU can read and write compressed data stored at various levels of the memory hierarchy (e.g., main memory, read-only content media, or L1/L2 caches). Various game functions often produce data that is used significantly later (e.g., long enough such that the data has a very low likelihood of remaining in the CPU's caches). For these cases, the compressed data produced by the CPU for later use by another game function in the CPU will require much less main memory footprint, less write bandwidth to memory and less read bandwidth from memory. All these footprint and bandwidth improvements lead to the ability to store more data and/or achieve better game function performance by providing greater quantities of data in an efficient manner.
More specifically, to achieve best performance, many current CPU instruction a sets require a user to perform a dot product using the Structure of Arrays (SOA) approach, as opposed to the more intuitive and user friendly Array of Structure (AOS) approach. In the former approach, the operand data used to perform the dot product is loaded into appropriate registers provided by the CPU. Then, this operand data is manipulated by “rotating” it in such a manner to accommodate the SOA approach used by the CPU. Namely, to perform a multiplication of one vector by another, this SOA technique effectively turns a 1.times.4 vector on its side to provide a 4.times.1 vector. This results in an inefficient use of register capacity, as only one lane of each register is now used to store vector data Further, the operation of rotating a vector on its side (accomplished in a so-called “swizzling” operation) requires execution cycles that are “empty” in the sense of not performing any meaningful conversion of the vector data (that is, not performing any mathematical operations on the data). Allowing programmers to keep their data in AOS format greatly simplifies optimization efforts; by contrast, SOA is at odds with natural data structure design, and Application Program Interface (API) parameter passing. Further, SOA generally complicates the programmer's use of SIMD vector math instruction usage. The logic 800 overcomes these drawbacks by using the aforesaid AOS approach. (However, the CPUs employed in the present system 100 can be configured to perform the dot product using the SOA approach too; the user is thus afforded the option of performing the dot product using either the AOS approach or the SOA approach.)
More specially, the logic 800 includes receiving operands that will be used to perform the dot product (as indicated in operation block 802), performing the dot product using the AOS approach (as indicated in operation block 804), and then outputting the dot product result (as indicated in operation block 806).
B. Exemplary Method of Operation
The read streaming and write streaming operations are described in greater detail below, followed by a summary of the operation of the entire system 100 shown in
B.1. Read Streaming
There are different techniques that can be used for loading information into the CPU 904. In one technique represented by path 914, the L1 cache 908 is implemented as an n-way set-associative cache (e.g., a Sway or more set associative cache). In this technique, the information is received directly into a locked set of the L1 cache 908, bypassing the L2 cache 910. The information can then be transferred from the L1 cache 908 to the registers 906. In another technique represented by path 916, the information is transferred directly into the registers 906. In yet another technique presented by path 918, the information is transferred into a locked set of the L2 cache 910, and thereafter transferred to the registers 906. In yet another technique (not shown), the information can be streamed into a 2 or more way L1 cache, but with no set locking. Whatever technique is used, in preferred implementations, the CPU 902 prefetches the read information, which means that it requests this information in advance of its use (that is, it receives this data multiple cycles in advance of its use, such as approximately, 100 or more cycles in advance of its use, although a smaller number of prefetch cycles can be used as well). The prefetching facilitates the streaming operation by reducing the impact of data read stalls that may cause undesirable delays in processing. The above-described techniques may offer different respective advantages, depending on a particular processing environment. For example, the technique that involves locking a set in the L1 cache only affects the CPU associated with that L1 cache, whereas locking the shared L2 cache will affect all of the CPUs coupled to this cache.
Bypassing the L1 cache 908 or the L2 cache 910 in the manner described above does not negatively affect the operation of the CPU 902 because the CPU 902 is unlikely to reread the input information from the L1 cache 908 or the L2 cache 910. Therefore, the L1 cache 908 and the L2 cache 910 do not need to store a copy of the information read into the CPU 902. In other words, since the CPU 902 is unlikely to reread the input information, the L1 or L2 caches do not have to serve their conventional roles of providing a readily accessible copy of recently received information for later reading. Bypassing these caches is desirable because it avoids causing other data that is likely to be reused (such as data that is not associated with the streaming operation) to be cast out of the caches. That is, bypassing the caches prevents the streaming operation from thrashing the caches.
B.2. Write Streaming
Data paths 1016 and 1018 describe the operations performed in the write streaming operation. However, before these operations take place, the system 100 performs a preliminary step of locking the set 1010 (or potentially, more than one set) in the L2 cache. Setting up the FIFOs also involves properly setting up the cache by marking the lines in the locked set 1010 as valid and so-called “dirty.” This operation also involves allocating tags and data to the cache lines in the locked set. This operation is referred to as a “create dirty” procedure and does not perform a read allocation with its requisite read access to the system memory 130.
After the L2 cache is locked and properly initialized, the write streaming operation proceeds by forwarding geometry data from the CPU 1002 directly into FIFO 1012 of the locked set 1010 of the L2 cache (e.g., by bypassing the L1 cache 1008). This can be performed by writing the geometry data to an appropriate address location associated with the storage locations in the FIFO 1012 that will receive the geometry 11 data. This operation is represented by data path 1016. Bypassing the L1 cache 1008 prevents the heavy output bandwidth of the procedural geometry logic 1004 from thrashing the L1 cache 1008. The bypassing of the L1 cache 1008 does not negatively affect the performance of the CPU 1002 because the write streaming data will not likely be reread by the CPU 1002 (and thus, there is no need to maintain a copy of this data in the L1 cache 1008). In an alternative implementation (not shown), an n-way set associative cache can be used to implement the L1 cache 1008, and one of the sets provided in such a cache can be locked to prevent the write streaming operation from thrashing the L1 cache 1008.
After the FIFO 1012 has stored a predetermined amount of geometry data, or after some other conditions regarding the transfer of information have been met (e.g., after all geometry requested by a given API call to generate geometry is complete), the system 100 “kicks off” the GPU module 1014. This prompts the GPU module 1014 to fetch the information from the FIFO 1012. More specifically, the GPU module 1014 can use a DMA protocol to retrieve information from the FIFO 1012. In the DMA protocol, the GPU module 1014 retrieves blocks of data from FIFO 1012 at an address provided to it by the system 100. However, conventional DMA typically coordinates transfer of information between a system memory and an I/O device. In the present case, in one exemplary case, it is desirable to eliminate performing these data transfers with the system memory 130. To this end, a coherency module (e.g., coherency module 150 shown in
Although not illustrated in
Finally, the above discussion emphasized the use of data streaming to move large amounts of data generated by decompression logic (e.g., procedural geometry or higher 8 order surface tessellation) from the CPU module to the GPU module. However, the techniques described above can be used to transfer any kind of data from the CPU module to the GPU module (that is, including data that is not generated by decompression logic).
B.2.1 Exemplary Operations for Write Streaming and Initialization
As discussed above, prior to performing write streaming operations, preliminary (initialization) steps, may be taken to prepare the L2 cache. The operations may be designed to configure the L2 cache in such a way that data may be written to a cache line in the L2 cache by a CPU module while bypassing the L1 cache, in order to prevent thrashing of the L1 cache. For some embodiments, this may be accomplished using operations described below with reference to
Interface logic in the CPU module may be configured to receive requests for data stored in the L2 cache lines from a GPU module and return the data to the GPU module without changing the cache state (e.g., by maintaining the L2 cache state for an accessed cache line as modified). To accomplish this, one or more specific bus commands, such a “Read Once” or “Read With No Intent To Cache” issued by the GPU module, may be implemented to support write streaming. By keeping the state of an accessed cache line as modified, the CPU module may store data to the same cache line again without having to spend the clock cycles required to reallocate the cache line, thereby resulting in a very efficient write streaming mechanism.
The operations 1400 begin, at step 1402, by issuing a set of data cache block set to zero (DCBZ) instructions to a cache line address to be allocated to the locked set. The function of the DCBZ instruction is to perform a zeroing function on, and gain exclusive access to, a block of cache without actually reading old data. A DCBZ instruction may be issued for each cache line to be allocated to the lock set. Accordingly, the number of DCBZ instructions may depend on how many cache lines are to be contained in the lock set, while the addresses specified with the DCBZ instructions may determine which portion of the L2 cache is used as the lock set.
If the cache line addressed by the DCBZ instruction hits in the L1 cache (i.e., the line is present in the L1 cache), as determined at step 1404, the line is evicted at step 1406. If the L2 directory state of the line is invalid (I), ownership is gained, at step 1408. At step 1410, the line in the L2 cache is zeroed and the L2 directory is updated to modified. For some embodiments, the CPU module may contain “snoop logic” to monitor GPU transactions and update a snoop directory, in accordance, to reflect the state of cache lines involved therein, as well.
At step 1412, the CPU module stores data directly to the L2 cache, bypassing the L1 cache, for access by the GPU.
The operations 1500 begin, at step 1502, by issuing a store to an address of a cache line allocated to the L2 locked set. Assuming the operations of
As previously described, the locked set may be operated in a first-in, first-out (FIFO) manner allowing the CPU module to overwrite locations after they have been read by the GPU module. In such embodiments, data stored in the locked set may be passed between the CPU module and the GPU module using a head pointer and tail pointer scheme. According to this scheme, the CPU module writes, to a head pointer on the GPU module, an “end” address of data that has been updated and is ready to be read.
For such embodiments, at step 1510, the CPU module may update a head pointer on the GPU module. The CPU module may send update the head pointer via a non-cacheable memory unit down to the GPU module. In response, the GPU module may begin reading data from the L2 cache of the CPU module up to the address indicated by the head pointer.
As previously described, for some embodiments, the request may be designed to indicate that the data will be used only once by the GPU module and will not be cached. For example, the request may be a Read Once or Read With No Intent to Cache request, such that the CPU module will not have to change the corresponding cache state. Therefore, at step 1606, the cache state for the accessed cache line in the L2 directory and snoop directory are maintained as modified. By maintaining the cache line state as modified, the CPU module may be able to again write to the cache line without costly allocation operations.
B.3. Tail Pointer Considerations
With reference to
The GPU module 1112 periodically informs the CPU 1102 of the current value of the tail pointer 1114 by transferring the tail pointer to the L2 cache 1110. This operation is indicated in
The CPU 1102 periodically polls the tail pointer stored in the L1 cache 1108 to determine whether there is sufficient space in the FIFO (not shown) for receiving geometry data generated by procedural geometry logic 1104. Polling of local memory associated with the CPU 1102 is much more efficient than the polling of system memory 130, since main memory polling would waste bandwidth on internal CPU busses, the CPU-GPU bus, GPU busses, and main memory. Since the polling is done on an L1 cacheable tail pointer location, all the polling bandwidth is local to the CPU 1102 and does not consume shared resources elsewhere in the system, and does not incur the latency problems associated with other polling strategies that involve system memory.
B.3.1 Exemplary Tail Pointer Implementation
For some specific embodiments, the GPU module may write a tail pointer to some type of coherent cacheable memory (e.g., that is cacheable but is not itself cache), as shown in
For some embodiments, the CPU module may poll the tail pointer by accessing the CCM 1700 directly. However, by mapping some portion of the CCM 1700 used for storing the tail pointer (e.g., one or more MMIO registers) to a cacheable address, tail pointer polling by the CPU module may happen quickly from the L1 cache 1108. For some embodiments, the tail pointer may be stored at an address location offset from a base address. For some embodiments, the base address may be written by software to a register (e.g., a Cacheable Base Register).
For some embodiments, as illustrated in
The updating operations 1900 begin, at step 1902, by receiving a request to update the tail pointer from the GPU module. At step 1904, the request is forwarded to the L2 controller to invalidate copies of the tail pointer in the L1 and L2 caches. At step 1906, the tail pointer in the cacheable memory 1700 is updated. For example, the write request may be a write request and logic in the bus interface logic 1800 (shown in
As a result, when the CPU issues a subsequent load instruction, at step 2002, the load instruction will miss in the L1 and L2 caches, at step 2004. Therefore, the updated tail pointer will be fetched from the cacheable coherent memory 1700, at step 2006, and copies of the updated tail pointer will be placed in the L1 and L2 caches, at step 2008. Subsequent loads of the tail pointer, at step 2010, prior to another update of the tail pointer, will be from the L1 cache.
B.4. Summary of Operation of the System
Exemplary operations performed in the CPUs will be described with reference to geometry-processing CPU 1204. These operations include step 1214 which entails reading information into the CPU 1204. This information may constitute a relatively meager amount of data used by the CPU 1204 to perform procedural geometry operations (or higher order surface tessellation). For instance, in the above-mentioned example of the rendering of a tree, the received information might constitute data regarding the positions of different parts of the tree, as well as the direction and velocity of any simulated wind that will move the leaves in the rendered scene. Step 1216 entails decompressing the received information (if it is received in compressed form). Step 1218 entails performing procedural geometry (or higher order surface tessellation) based on the received information. Step 1218 results in the generation of a set of output vertices. In the case of the example of the tree, the vertices constitute meshes of triangles used to render individual respective leaves. Further, the computations performed in step 1218 can include performing dot product operations using the AOS approach described in
On the right side of
The foregoing discussion in Section B presented merely one exemplary technique for transferring data from cache memory into the GPU module 104. Other techniques can be used. For example, in the above discussion, the coherency module 150 plays a role in coordinating the transfer of data in the streaming operation using a duplicate tag store scheme. In another strategy, the system 100 can allocate separate address ranges to the FIFOs (506-512) in the locked set 502 of the L2 cache 122, where these addresses do not map to system memory 130. In this approach, the system 100 does not need to consult a duplicate tag store to determine that information is stored in the locked set 502 of the L2 cache 122. The coherency module 130 in this approach is therefore only used to maintain coherency between the CPU module 102's caches and system memory 130 for all data besides that stored in the streaming write FIFOs (506-512).
C. Exemplary Application to a Gaming Environment
The game console 1302 has four slots 1310 on its front face to support up to four controllers, although the number and arrangement of slots may be modified. A power button 1312 and an eject button 1314 are also positioned on the front face of the game console 1302. The power button 1312 switches power to the game console and the eject button 1314 alternately opens and closes a tray of the portable media drive 1306 to allow insertion and extraction of the storage disc 1308.
The game console 1302 connects to a television or other display (not shown) via A/V interfacing cables 1320. A power cable 1322 provides power to the game console. The game console 1302 may further be equipped with internal or externally added network capabilities, as represented by the cable or modem connector 1324 to facilitate access to a network, such as a local area network (LAN) or the Internet.
Each controller 1304 is coupled to the game console 1302 via a wire or wireless interface. In the illustrated implementation, the controllers are USB (Universal Serial Bus) compatible and are connected to the console 1302 via serial cables 1330. The controller 1302 may be equipped with any of a wide variety of user interaction mechanisms. As illustrated in
A memory unit (MU) 1340 may be inserted into the controller 1304 to provide additional and portable storage. Portable memory units enable users to store game parameters and transport them for play on other consoles. In the described implementation, each controller is configured to accommodate two memory units 1340, although more or less than two units may be employed in other implementations.
Although not shown, the gaming system 1300 can include a processing architecture that corresponds to system 100 shown in
Architecture and related methods for parallel execution of data-generating tasks were disclosed. In one exemplary application, the architecture and related methods provide a large amount of geometry data for use in rendering a complex and realistic scene. At the same time, the architecture and related methods provide strategies for reducing the amount of system memory data transfer operations.
Although the invention has been described in language specific to structural features and/or methodological acts, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed invention.