Interprocessor direct cache writes

In a multiprocessor system level 2 caches are positioned on the memory side of a routing crossbar rather than on the processor side of the routing crossbar. This configuration permits the processors to store messages directly into each other's caches rather than into system memory or their own coherent caches. Therefore, inter-processor communication latency is reduced.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention generally relates to caching and more specifically to a multiprocessor system with caching on the memory side of a routing crossbar.

2. Description of the Related Art

Current multiprocessor systems include level 2 (L2) caches that are directly coupled to each processor. This configuration allows each processor to snoop writes to the caches of the other processors in the system and to access the caches with low latency compared with the number of clock cycles needed to retrieve data from system memory. System memory is typically accessed through a bridge device e.g., a Northbridge chip, and is shared with other devices in the system that are also coupled to the bridge device.

As the number of processors in multiprocessor systems increases, the complexity of the snooping and accessing of caches that are coupled to other processors increases. Therefore, the complexity and access latency increases as the parallelism increases.

Accordingly, what is needed in the art is a system and method for configuring caches in a multiprocessor system that allows for increased parallelism without increasing complexity and cache access latency.

SUMMARY OF THE INVENTION

In a multiprocessor system L2 caches are positioned on the memory side of a routing crossbar rather than on the processor side of the routing crossbar. This configuration permits the processors to store messages directly into each other's caches rather than into system memory or their own coherent caches. Therefore inter-processor communication latency is reduced. Processor parallelism may be increased by adding processors and corresponding L2 caches to the routing crossbar to improve overall system processing throughput without increasing the complexity of accessing the L2 caches. Each processor may access a cache line in any one of the L2 caches by determining the correct memory controller based on the physical cache line address and then issuing a request directly to that memory controller using the available routing fabric. Therefore, cache misses are not broadcast to all of the memory controllers. Additionally, a central processing unit (CPU) may write data to the L2 caches of the multiprocessor system and one or more of the processors in the multiprocessor system can read the data from the L2 caches. The number of clock cycles need to transfer data from the CPU to the processors in the multiprocessor system is reduced compared with other transfer mechanisms, such as having the processors read from the CPU system memory or an L2 cache coupled to the CPU or having the CPU write to the multiprocessor system memory.

Various embodiments of a method of the invention for transmitting messages in a multiprocessor system include outputting a message produced by a central processing unit (CPU) to a level 2 cache of a processing core, translating a virtual address corresponding to the message into a physical address corresponding to a location in a processing core memory that is coupled to the level 2 cache, storing the message and at least a portion of the physical address in the level 2 cache, updating a ready value to indicate that the message is available in the level 2 cache, and reading the message from the level 2 cache by the processing core.

Various embodiments of the invention for a multiprocessor system that includes a parallel processing unit and a central processing unit (CPU). The parallel processing unit includes a plurality of processing cores configured to execute instructions to process data, a parallel processing memory configured to store messages including the instructions and the data, a plurality of level 2 caches that are coupled to the parallel processing memory and configured to store the messages, and a memory crossbar that is coupled between the plurality of processing cores and the plurality of level 2 caches and configured to route the messages between each one of the processing cores and each one of the level 2 caches. The CPU is configured to produce the messages and write the messages to the plurality of level 2 caches.

DETAILED DESCRIPTION

System Overview

FIG. 1is a block diagram illustrating a computer system configured to implement one or more aspects of the present invention.FIG. 1is a block diagram of a computer system100according to an embodiment of the present invention. Computer system100includes one or more central processing units (CPU)102, caches103, and a system memory104communicating via a bus path that includes a memory bridge105. In general, a computer system100includes a number P of CPUs and caches, where P≧1. (Herein, multiple instances of like objects are denoted with reference numbers identifying the object and parenthetical numbers identifying the instance where needed.) CPUs102and caches103may be implemented, e.g., using one or more integrated circuit devices such as programmable processors, application specific integrated circuits (ASICs), and memory devices.

System memory104includes a device driver101that is configured to provide one or more messages that specify the data and program instructions for processing by parallel processing subsystem112. The messages may be stored in system memory104, caches103, or memory within other devices of system100. Device driver101is executed by CPUs102to translate instructions for execution by parallel processing subsystem112based on the specific capabilities of parallel processing subsystem112. The instructions may be specified by an application programming interface (API) which may be a conventional graphics API such as Direct3D or OpenGL.

Memory bridge105, which may be, e.g., a Northbridge chip, is connected via a bus or other communication path106(e.g., a HyperTransport link) to an I/O (input/output) bridge107. I/O bridge107, which may be, e.g., a Southbridge chip, receives user input from one or more user input devices108(e.g., keyboard, mouse) and forwards the input to CPUs102via communication path106and memory bridge105. A parallel processing subsystem112is coupled to memory bridge105via a bus or other communication path113(e.g., a PCI Express, Accelerated Graphics Port, or HyperTransport link). In one embodiment parallel processing subsystem112is a graphics subsystem that delivers pixels to a display device110(e.g., a conventional CRT or LCD based monitor).

A system disk114is also connected to I/O bridge107. A switch116provides connections between I/O bridge107and other components such as a network adapter118and various add-in cards120and121. Other components (not explicitly shown), including USB or other port connections, CD drives, DVD drives, film recording devices, and the like, may also be connected to I/O bridge107. Communication paths interconnecting the various components inFIG. 1may be implemented using any suitable protocols, such as PCI (Peripheral Component Interconnect), PCI Express (PCI-E), AGP (Accelerated Graphics Port), HyperTransport, or any other bus or point-to-point communication protocol(s), and connections between different devices may use different protocols as is known in the art.

An embodiment of parallel processing subsystem112is shown inFIG. 2. Although only a single parallel processing unit (PPU)202is shown inFIG. 2, parallel processing subsystem112may include one or more PPUs202, each of which is coupled to a local parallel processing (PP) memory204. One or more messages that specify the location of data and program instructions for execution by each PPU202may be stored in each PP memory204. In general, a parallel processing subsystem includes a number U of PPUs, where U≧1. PPU202and PP memory204may be implemented, e.g., using one or more integrated circuit devices such as programmable processors, application specific integrated circuits (ASICs), and memory devices.

As shown in detail for PPU202(0), each PPU202includes a host interface206that communicates with the rest of system100via communication path113, which connects to memory bridge105(or, in one alternative embodiment, directly to CPUs102or caches103). In one embodiment, communication path113is a PCI-E link, in which dedicated lanes are allocated to each PPU202as is known in the art. Other communication paths may also be used. Host interface206outputs messages (or other signals) for transmission on communication path113and also receives all incoming messages (or other signals) from communication path113and directs them to appropriate components of PPU202. For example, messages related to processing tasks may be directed to a work distribution unit200while messages related to memory operations (e.g., reading from or writing to PP memory204) may be directed to a memory crossbar210. Host interface206, work distribution unit200, and memory crossbar210may be of generally conventional design, and a detailed description is omitted as not being critical to the present invention.

Each PPU202advantageously implements a highly parallel processor. As shown in detail for PPU202(0), a PPU202includes a number C of cores205and corresponding caches208, where C≧1. Each cache208is coupled to a corresponding portion of PP memory204, shown as a memory204(0) and204(1) through204(C−1). The cache/memory pairs, e.g., cache208(0) and memory204(0) do not communicate with each other. Each processing core205is capable of executing a large number (e.g., tens or hundreds) of threads concurrently, where each thread is an instance of a program; one embodiment of a multithreaded processing core205is described in conjunction withFIG. 3. A processing context encompasses a complete set of state through PPU202, while a thread may encompass only the state required to shade a single pixel. Threads run inside processing contexts: one processing context might contain thousands of running threads. Cores208receive processing tasks to be executed via a work distribution unit200. Work distribution unit200can implement a variety of algorithms for distributing work. For instance, in one embodiment, work distribution unit200receives a “ready” signal from each core205indicating whether that core has sufficient resources to accept a new processing task. When a new processing task arrives, work distribution unit200assigns the task to a core205that is asserting the ready signal; if no core205is asserting the ready signal, work distribution unit200holds the new processing task until a ready signal is asserted by a core205.

In some embodiments of the present invention, a message implements a remote procedure call (RPC) that includes a bundle of data that is included with the handle of a routine for processing the data. When the data has been processed by cores205, host interface206sends a return message that includes data to CPU102.

Cores205communicate with memory crossbar214to read from or write to caches208and PP memory204. In one embodiment, memory crossbar210includes an interface adapted to communicate with local PP memory204, as well as a connection to host interface206, thereby enabling cores205to communicate with system memory104or other memory that is not local to PPU202. Similarly, one or more of CPUs102can read from or write to caches208and/or PP memory204through memory crossbar210. Importantly, read and write accesses from CPUs102pass through host interface206which performs memory address translation to convert virtual addresses provided by CPUs102into physical memory addresses for caches208and PP memory204.

Cores205can be programmed to execute processing tasks relating to a wide variety of applications, including but not limited to linear and nonlinear data transforms, filtering of video and/or audio data, modeling operations (e.g., applying laws of physics to determine position, velocity and other attributes of objects), image rendering operations (e.g., vertex shader, geometry shader, and/or pixel shader programs), and so on. PPU202may transfer data from system memory104, local PP memory204, and/or caches208into internal (on-chip) memory, process the data, and write result messages back to system memory104, local PP memory204, and/or caches208, where such messages can be accessed by other system components, including, e.g., CPUs102or another parallel processing subsystem112.

In some embodiments, some or all of cores205in PPU202are graphics processors with rendering pipelines that can be configured to perform various tasks related to generating pixel data from graphics data read from a message via memory bridge105and bus113, interacting with caches208and local PP memory204(which can be used as graphics memory including, e.g., a conventional frame buffer, messages, texture maps, and the like) to store and update pixel data, deliver pixel data to display device110, and the like. In some embodiments, PP subsystem112may include one or more PPU202that operate as graphics processors and one or more other PPU202that are used for general-purpose computations. The PPUs may be identical or different, and each PPU may have its own dedicated PP memory device(s) or no dedicated PP memory device(s).

Referring back toFIG. 1, in operation, one or more CPUs102are the master processors of system100, controlling and coordinating operations of other system components. In particular, CPUs102issue commands that control the operation of PPU202. In some embodiments, CPUs102write a message for each PPU202to a buffer (not explicitly shown inFIG. 1), and which may be located in system memory104, cache208, PP memory204, or another storage location accessible to both CPUs102and PPU202. PPU202reads the instructions and data from the message and executes commands asynchronously with operation of CPUs102.

The connection of PPU202to the rest of system100may also be varied. In some embodiments, PP system112is implemented as an add-in card that can be inserted into an expansion slot of system100. In other embodiments, a PPU202can be integrated on a single chip with a bus bridge, such as memory bridge105or I/O bridge107. In still other embodiments, some or all elements of PPU202may be integrated on a single chip with CPU102.

A PPU202may be provided with any amount of local PP memory204, including no local memory, and may use local memory and system memory in any combination. For instance, a PPU202can be a graphics processor in a unified memory architecture (UMA) embodiment; in such embodiments, little or no dedicated graphics (PP) memory is provided, and PPU202would use system memory exclusively or almost exclusively. In UMA embodiments, a PPU202may be integrated into a bridge chip or processor chip or provided as a discrete chip with a high-speed link (e.g., PCI-E) connecting the PPU202to system memory, e.g., via a bridge chip.

As noted above, any number of PPU202can be included in a parallel processing subsystem. For instance, multiple PPU202can be provided on a single add-in card, or multiple add-in cards can be connected to communication path113, or one or more of the PPU202could be integrated into a bridge chip. The PPU202in a multi-PPU system may be identical to or different from each other; for instance, different PPU202might have different numbers of cores, different amounts of local PP memory, and so on. Where multiple PPU202are present, they may be operated in parallel to process data at higher throughput than is possible with a single PPU202. Systems incorporating one or more PPU202may be implemented in a variety of configurations and form factors, including desktop, laptop, or handheld personal computers, servers, workstations, game consoles, embedded systems, and so on.

CPU to Core Communication

Various techniques may be used to transmit messages produced by CPUs102to consumers of the messages, such as PPU202. The messages may contain instructions, command, and/or data. Conventional systems have been configured to have the producer of the data write the messages to system memory or to the consumer's memory, e.g. system memory104, or PP memory204, and have the consumer read the messages. Alternatively, the produce writes the messages to cache103and the consumer reads the messages from cache103. In order to ensure that the consumer reads valid messages, the producer writes a value indicating that a message is ready and the consumer polls the ready value, only reading the message when the value indicates that the message is valid.

Assuming that it takes T clock cycles for the producer to write to system memory, i.e., from the initiate of the write until the result is posted in system memory, various relative times can be determined for other memory accesses. T clock cycles are also needed for a processor (producer or consumer) to read from system memory. A typical value for T is 250 clock cycles. 2T clock cycles are needed for a processor to read from or write to another processor's memory, i.e., for CPU102to read from or write to PP memory204. T/5 clock cycles are needed for a processor to read from or write to its own L2 cache, i.e., CPU102to read from or write to cache103and core205to read from or write to cache208. 6T/5 clock cycles are needed for a processor to read from or write to another processor's cache, i.e., CPU102to read from or write to cache208and core205to read from or write to cache103. Furthermore, because writes are pipelined, each additional write in a group that is unbroken by a read adds a cost of 1 clock cycle. Reads are not pipelined.

Given the number of clock cycles that are needed for the various read and write operations, a minimum time needed to pass a message of length K may be computed in terms of T for each message transmission technique. TABLE 1 lists the message transmit time for four different configurations. The first column describes the system configuration. The second column specifies the number of clock cycles for the producer of the message to write the message to memory and set the ready value. The third column specifies the number of clock cycles needed for the consumer of the message to read the ready value. The fourth column specifies the number of clock cycles needed for the consumer to read the message from the memory and the fifth column specifies the total number of clock cycles needed for communication of the message between the producer and consumer.

In a first system configuration, “read/write system memory,” the message producer, CPU102writes to system memory104and a core205reads the message from system memory104. Since the producer writes its own memory and writes are pipelined, the number of clock cycles needed to write memory and set the ready value is T+K+1. Since the consumer needs to read the ready value from the producer's memory, the read takes 2T clock cycles. Likewise, since the consumer reads the message from the producer's memory, the message read takes 2KT clock cycles.

In a second system configuration, “read/write PPU memory,” the message producer, CPU102writes to PPU memory204and a core205reads the message from PPU memory204. Since the producer writes the consumer's memory and writes are pipelined, the number of clock cycles needed to write memory and set the ready value is 2T+K+1. Since the consumer needs to read the ready value from its own memory, the read takes T clock cycles. Likewise, since the consumer reads the message from its own memory, the message read takes KT clock cycles. This configuration of communicating between CPU102and a core205reduces the number of clock cycles by 1KT compared with the first system configuration.

In a third system configuration, “read/write CPU cache,” the message producer, CPU102writes to cache103and a core205reads the message from cache103. Since the producer writes its own memory and writes are pipelined, the number of clock cycles needed to write memory and set the ready value is T/5+K+1. Since the consumer needs to read the ready value from the producer's cache, the read takes 6T/5 clock cycles. Likewise, since the consumer reads the message from the producer's cache, the message read takes 2KT*6/5T=12KT/5 clock cycles. The difference between using the third system configuration for communicating between CPU102and a core205and the second system configuration is (7KT−8T)/5, so when K>8/7 (or K>1, since K is an integer) the third configuration is faster.

In a fourth system configuration, “read/write core cache,” the message producer, CPU102writes to cache208and a core205reads the message from cache208. Since the producer writes the consumer's cache and writes are pipelined, the number of clock cycles needed to write memory and set the ready value is 6T/5+K+1. Since the consumer needs to read the ready value from its own cache, the read takes T/5 clock cycles. Likewise, since the consumer reads the message from its own cache, the message read takes KT/5 clock cycles. This configuration of communicating between CPU102and a core205reduces the number of clock cycles by 11KT/5 compared with the third system configuration. Specifically, when T is 250 and K is 16, the third system configuration requires 1012 clock cycles to transfer the message while the fourth system configuration requires only 132 clock cycles. In order to benefit from the quicker transfers, system100is configured to transfer messages from CPUs102to cores205by writing the messages to caches208, as described in conjunction withFIGS. 5 and 6. Conversely, system100is configured to transfer messages from cores205to CPUs102by writing the messages to caches103.

Core Overview

FIG. 3is a block diagram of a core205for the parallel processing subsystem112ofFIG. 2, in accordance with one or more aspects of the present invention. PPU202includes a core205(or multiple cores205) configured to execute a large number of threads in parallel, where the term “thread” refers to an instance of a context, i.e., a particular program executing on a particular set of input data. In some embodiments, single-instruction, multiple-data (SIMD) instruction issue techniques are used to support parallel execution of a large number of threads without providing multiple independent instruction units.

In one embodiment, each core205includes an array of P (e.g., 8, 16, etc.) parallel processing engines302configured to receive SIMD instructions from a single instruction unit312. Each processing engine302advantageously includes an identical set of functional units (e.g., arithmetic logic units, etc.). The functional units may be pipelined, allowing a new instruction to be issued before a previous instruction has finished, as is known in the art. Any combination of functional units may be provided. In one embodiment, the functional units support a variety of operations including integer and floating point arithmetic (e.g., addition and multiplication), comparison operations, Boolean operations (AND, OR, XOR), bit-shifting, and computation of various algebraic functions (e.g., planar interpolation, trigonometric, exponential, and logarithmic functions, etc.); and the same functional-unit hardware can be leveraged to perform different operations.

Each processing engine302uses space in a local register file (LRF)304for storing its local input data, intermediate results, and the like. In one embodiment, local register file304is physically or logically divided into P lanes, each having some number of entries (where each entry might store, e.g., a 32-bit word). One lane is assigned to each processing engine302, and corresponding entries in different lanes can be populated with data for different threads executing the same program to facilitate SIMD execution. In some embodiments, each processing engine302can only access LRF entries in the lane assigned to it. The total number of entries in local register file304is advantageously large enough to support multiple concurrent threads per processing engine302.

Each processing engine302also has access to an on-chip shared memory306that is shared among all of the processing engines302in core205. Shared memory306may be as large as desired, and in some embodiments, any processing engine302can read to or write from any location in shared memory306with equally low latency (e.g., comparable to accessing local register file304). In some embodiments, shared memory306is implemented as a shared register file; in other embodiments, shared memory306can be implemented using shared cache memory.

In addition to shared memory306, some embodiments also provide additional on-chip parameter memory and/or cache(s)308, which may be implemented, e.g., as a conventional RAM or cache. Parameter memory/cache308can be used, e.g., to hold state parameters and/or other data (e.g., various constants) that may be needed by multiple threads. Processing engines302also have access via memory crossbar210to off-chip “global” memory, which can include, e.g., PP memory204, caches208, and/or system memory104, with system memory104being accessible by memory crossbar210via host interface206as previously described. It is to be understood that any memory external to PPU202may be used as global memory. Processing engines302can be coupled to memory crossbar210via an interconnect (not explicitly shown) that allows any processing engine302to access global memory.

In one embodiment, each processing engine302is multithreaded and can execute up to some number G (e.g., 24) of threads concurrently, e.g., by maintaining current state information associated with each thread in a different portion of its assigned lane in local register file304. Processing engines302are advantageously designed to switch rapidly from one thread to another so that instructions from different threads can be issued in any sequence without loss of efficiency. Since each thread may correspond to a different context, multiple contexts may be processed over multiple cycles as different threads are issued for each cycle.

Instruction unit312is configured such that, for any given processing cycle, an instruction (INSTR) is issued to each P processing engines302. Each processing engine302may receive a different instruction for any given processing cycle when multiple contexts are being processed simultaneously. When all P processing engines302process a single context, core205implements a P-way SIMD microarchitecture. Since each processing engine302is also multithreaded, supporting up to G threads concurrently, core205in this embodiment can have up to P*G threads executing concurrently. For instance, if P=16 and G=24, then core205supports up to 384 concurrent threads for a single context or N*24 concurrent threads for each context, where N is the number of processing engines302allocated to the context.

Operation of core205is advantageously controlled via a work distribution unit200. In some embodiments, work distribution unit200receives pointers to data to be processed (e.g., primitive data, vertex data, and/or pixel data) as well as locations of messages containing data or instructions defining how the data is to be processed (e.g., what program is to be executed). Work distribution unit200can load data to be processed into shared memory306and parameters into parameter memory308. Work distribution unit200also initializes each new context in instruction unit312, then signals instruction unit312to begin executing the context. Instruction unit312reads instructions contained in messages and executes the instructions to produce processed data. When execution of a context is completed, core205advantageously notifies work distribution unit200. Work distribution unit200can then initiate other processes, e.g., to retrieve output data from shared memory306and/or to prepare core205for execution of additional contexts.

It will be appreciated that the core architecture described herein is illustrative and that variations and modifications are possible. Any number of processing engines may be included. In some embodiments, each processing engine302has its own local register file, and the allocation of local register file entries per thread can be fixed or configurable as desired. In particular, entries of local register file304may be allocated for processing each context. Further, while only one core205is shown, a PPU202may include any number of cores205, which are advantageously of identical design to each other so that execution behavior does not depend on which core205receives a particular processing task. Each core205advantageously operates independently of other cores205and has its own processing engines, shared memory, and so on.

Graphics Pipeline Architecture

FIG. 4is a conceptual diagram of a graphics processing pipeline400, in accordance with one or more aspects of the present invention. PPU202may be configured to form a graphics processing pipeline400. For example, core205may be configured to perform the functions of a vertex processing unit444, geometry processing unit448, and a fragment processing unit460. The functions of data assembler442, primitive assembler446, rasterizer455, and raster operations unit465may also be performed by core205or may be performed by host interface206. A message may include one or more of a vertex shader program, geometry shader program, and fragment shader program for execution by PPU202. A message may be written by CPU102to caches208to efficiently transfer the instructions to PPU202for processing. Similarly, data provided by CPU102may also be transferred to cache208as a message and processed data produced by PPU202may be efficiently transferred from PPU202to caches103as a message.

Data assembler442is a fixed function unit that collects vertex data for high-order surfaces, primitives, and the like, and outputs the vertex data to vertex processing unit444. Vertex processing unit444is a programmable execution unit that is configured to execute vertex shader programs, transforming vertex data as specified by the vertex shader programs. For example, vertex processing unit444may be programmed to transform the vertex data from an object-based coordinate representation (object space) to an alternatively based coordinate system such as world space or normalized device coordinates (NDC) space. Vertex processing unit444may read data that is stored in caches208or PP memory204through memory crossbar210for use in processing the vertex data.

Primitive assembler446receives processed vertex data from vertex processing unit444and constructs graphics primitives, e.g., points, lines, triangles, or the like, for processing by geometry processing unit448. Geometry processing unit448is a programmable execution unit that is configured to execute geometry shader programs, transforming graphics primitives received from primitive assembler446as specified by the geometry shader programs. For example, geometry processing unit448may be programmed to subdivide the graphics primitives into one or more new graphics primitives and calculate parameters, such as plane equation coefficients, that are used to rasterize the new graphics primitives. Geometry processing unit448outputs the parameters and new graphics primitives to rasterizer455. Geometry processing unit448may read data that is stored in caches208or PP memory204through memory crossbar210for use in processing the geometry data.

Rasterizer455scan converts the new graphics primitives and outputs fragments and coverage data to fragment processing unit260. Fragment processing unit460is a programmable execution unit that is configured to execute fragment shader programs, transforming fragments received from rasterizer455as specified by the fragment shader programs. For example, fragment processing unit460may be programmed to perform operations such as perspective correction, texture mapping, shading, blending, and the like, to produce shaded fragments that are output to raster operations unit465. Fragment processing unit460may read data that is stored in caches208or PP memory204through memory crossbar210for use in processing the fragment data. Memory crossbar210produces read requests for data stored in graphics memory, decompresses any compressed data, and performs texture filtering operations, e.g., bilinear, trilinear, anisotropic, and the like. Raster operations unit465is a fixed function unit that optionally performs near and far plane clipping and raster operations, such as stencil, z test, and the like, and outputs pixel data as processed graphics data for storage in graphics memory. The processed graphics data may be stored in graphics memory, e.g., caches208, PP memory204, and/or system memory104, for display on display device110.

Interprocessor Direct Cache Writes

FIG. 5is a flow diagram of method steps for writing and reading messages provided by CPU102to PPU202for processing, in accordance with one or more aspects of the present invention. In step500CPU102outputs a message to one or more caches208. In step515host interface206translates the virtual address of the message into a physical address for PPU memory204. In step520the message is stored in one or more caches208. In step525the ready signal is written by CPU102to indicate that the message is ready to be read. In step530one or more cores205reads the message from the one or more caches208for processing.

By writing the message into the consumer memory, particularly into caches208, the transfer is performed in fewer clock cycles compared with writing the message into cache103or system memory104and having cores205read the message from cache103or system memory104. Furthermore, since caches208are positioned on the memory side of memory crossbar210any core205can access any cache208to read a message. This configuration advantageously permits the addition of cores205and corresponding L2 caches208by adding ports to memory crossbar210. Therefore, processor parallelism may be increased to improve overall system processing throughput without increasing the complexity of accessing caches208.

FIG. 6is a block diagram showing the communication path for transferring a message, in accordance with one or more aspects of the present invention. CPU102(0) ofFIG. 1writes a message to PPU202by outputting the message to cache103(0) for routing to PPU202via memory bridge105. The message is output by memory bridge105over communication path113to PPU202. Host interface206receives the message and translates the virtual address provided with the message to a physical address corresponding to PP memory0204(0). Host interface206outputs the message with the physical address to memory crossbar210for routing to cache208(0). The message is stored in cache208(0). The value indicating that a message is ready is also written in cache208(0). Cache208(0) may evict the message and write the message to memory204(0). Importantly, CPU102is able to write cache208in order to reduce the number of clock cycles needed to transfer messages between CPU102and cores205. Each core205may access a cache line in any one of the caches208by determining the correct memory controller based on the physical cache line address and then issuing a request directly to the specific cache208corresponding to the physical cache line address using the available routing fabric. Therefore, cache misses are not broadcast to all of the cores205.

The invention has been described above with reference to specific embodiments. Persons skilled in the art, however, will understand that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. One embodiment of the invention may be implemented as a program product for use with a computer system. The program(s) of the program product define functions of the embodiments (including the methods described herein) and can be contained on a variety of computer-readable storage media. Illustrative computer-readable storage media include, but are not limited to: (i) non-writable storage media (e.g., read-only memory devices within a computer such as CD-ROM disks readable by a CD-ROM drive, flash memory, ROM chips or any type of solid-state non-volatile semiconductor memory) on which information is permanently stored; and (ii) writable storage media (e.g., floppy disks within a diskette drive or hard-disk drive or any type of solid-state random-access semiconductor memory) on which alterable information is stored. The foregoing description and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.