Permalink
Browse files

mediawiki fix

  • Loading branch information...
1 parent 5b088bd commit 192af234c584d324993e3b17e1a4d16c926b9d8b @derenrich committed May 19, 2012
Showing with 1 addition and 2 deletions.
  1. +1 −2 README.mediawiki
View
@@ -38,8 +38,7 @@ Panpotes is a research code base that has not achieved a complete
implementation of CUDA. Notable limitatations (and the rationale for them)
currently include:
* Mapped memory accesses from the GPU. Panoptes currently reports to callers of cudaGetDeviceProperties the flag canMapHostMemory to be zero. Supporting direct access requires we maintain two sets of validity bits, one for the device and one for the host, keeping the state of the two sets reasonably consistent. We could make the host "authoritative," exposing the validity bits for mapped regions stored by Valgrind directly to the device. Doing so would require tight coupling with Valgrind's internals as well as likely patching Valgrind to disable its compression technique for validity bits (as Panoptes uses 1:1 bit level shadowing). We could make the device authoritative. Upon a kernel launch, we would need to speculatively transfer any dirty, host-stored validity bits out of Valgrind and onto the device. Upon a host access, we would have to load the validity bits off of the device and place them into Valgrind.
-* Peer-to-Peer Support. Panoptes currently does not implement the peer-to-peer
- functionality exposed in CUDA 4. Implementing this is currently limited by the fact that each device maintains its own master list of chunks in its address space. Devices that can communicate with peer-to-peer need to share some of those portions of their address space (relatedly, cudaGetDeviceProperties under Panoptes reports that unified addressing is not supported). Since this is a common use case for multi-GPU systems, it is expected to be implemented in the near future.
+* Peer-to-Peer Support. Panoptes currently does not implement the peer-to-peer functionality exposed in CUDA 4. Implementing this is currently limited by the fact that each device maintains its own master list of chunks in its address space. Devices that can communicate with peer-to-peer need to share some of those portions of their address space (relatedly, cudaGetDeviceProperties under Panoptes reports that unified addressing is not supported). Since this is a common use case for multi-GPU systems, it is expected to be implemented in the near future.
* Instruction support. Not all parts of the PTX instruction set are supported. Further, parts of the PTX instruction set that are supported have largely been tested by generating kernels written in C/C++ with nvcc. It is possible that there are untested edge cases that would only be exposed by use of inline PTX.
** Atomic operations: These currently are not checked for addressability nor are validity bits considered.
** Textures/Surfaces: Texture/surface support is currently being tested, but is not released.

0 comments on commit 192af23

Please sign in to comment.