[PD-dev] CUDA discussion

Charles Henry czhenry at gmail.com
Tue Nov 3 14:12:04 CET 2009


> top-down design issues:
> 1.  The essential CUDA<->Pd functions should be made separate from
> CUDA based Pd externals, with a separate header file, and compilable
> to shared and static libraries.
> 2.  The set of CUDA<->Pd extensions needs to be able to manage
> multiple devices, including device query, initialization and setting
> global parameter sets per GPU.  Most likely, this means a custom data
> structure and object based method system.
> 3.  Compilation--how to create the build system and handle
> dependencies for a library of CUDA based externals.  Management of
> CUDA libraries, CUDA-rt and CUDA-BLAS especially.
> 4.  Testing and initialization.  At setup time, a CUDA based external
> should be able to find out if it is legal and ready to run.
> 5.  Abstraction of major device and memory operations.  What makes up
> a sufficient and complete set of operations?  This is a list that is
> most likely to be grown through experimentation, but a good
> preliminary list of operations will help get things started on the
> right footing.
> 6.  Performance.  How to profile or benchmark and make comparisons
> between implementations?  The single greatest performance issue that I
> have identified is caching on GPU.  host<->device memory transfers can
> be eliminated in some cases, allowing CUDA based externals to follow
> one another in the DSP tree with faster scheduling and runtime
> performance.

add:
7.  Namespace.  Should be able to duplicate existing objects with
unified variations on names.




More information about the Pd-dev mailing list