interface
====== Differences ====== This shows you the differences between two versions of the page.
|
interface [2013/02/06 01:08] morr created |
interface [2013/02/08 16:58] (current) jthestness |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | Proposed Future GPGPU-Sim Interface: | + | ===== Proposed Future GPGPU-Sim Interface ===== |
| - | NOTE: JASON IS CURRENTLY WORKING ON THIS SOME | + | |
| - | We foresee gem5-gpu as being a | + | Since gem5 (Ruby) models the memory hierarchy, future revisions of GPGPU-Sim could more rigorously define the interface between the shader pipeline and the memories. In particular, neither the fetch or memory access (ldst_unit) pipeline stages in GPGPU-Sim export a clear API for connecting with caches. We propose a more rigorous use of pipeline registers to communicate to and from the fetch and ldst units (e.g. see gem5/src/cpu/inorder/*). These units can then be implemented either within or outside GPGPU-Sim, depending on integration aims. If the desire is to implement the fetch and/or ldst units within GPGPU-Sim but to allow tight integration with gem5, we recommend that GPGPU-Sim export the gem5 port interface (gem5/src/mem/port.*) to be connected to the gem5 memory system. |
| - | Since gem5 (Ruby) models the memory hierarchy, future revisions of GPGPU-Sim could more rigorously define the interface between the shader pipeline and the memories. In particular, neither the fetch or memory access (ldst_unit) pipeline stages in GPGPU-Sim export a clear API for connecting with caches. We propose a more rigorous use of pipeline registers to communicate to and from the fetch and ldst units (e.g. see gem5/src/cpu/inorder/*). These units can then be implemented either within or outside GPGPU-Sim, depending on integration aims. If the desire is to implement the fetch and/or ldst units within GPGPU-Sim but to allow tight integration with gem5, we recommend that GPGPU-Sim export the gem5 port interface (gem5/src/mem/port.*) to be connected to the gem5 memory system. | + | |
| - | Specifically, the LSQPort objects in the CudaCore and the executeMemOp function belong in GPGPU-Sim. In fact, the whole CudaCore is just a thin wrapper around the GPGPU-Sim shader_core_ctx and should be eliminated as the integration between GPGPU-Sim and gem5 becomes tighter. | + | All of the files in gem5-gpu/gpu/gpgpu-sim are thin wrappers around GPGPU-Sim objects. We foresee generalizing these interfaces with C++ inheritance. Depending on how this is implemented, these wrappers could live in either gem5-gpu or GPGPU-Sim. |
| - | Similarly, much of CudaGPU could be moved into GPGPU-Sim. | + | |
| + | While generalizing these interfaces the [[future-arch|Future gem5-gpu Software Architecture Vision]] will likely be followed. In particular, the CudaContext - a construct orthogonal to the choice of GPU simulator - will be moved out of CudaGPU to slim it down. | ||
interface.1360134504.txt.gz · Last modified: 2013/02/06 01:08 by morr
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 3.0 Unported
