gpu programming paradigm -凯发k8网页登录

cpu/gpu partitioning — identifying segments of code that run on the cpu and segments that run on the gpu. for the different ways gpu coder identifies cuda kernels, see kernel creation. memory transfer costs between cpu and gpu are a significant consideration in the kernel creation algorithm.

after kernel partitioning is complete, gpu coder analyzes the data dependency between the cpu and gpu partitions. data that is shared between the cpu and gpu are allocated on gpu memory (by using cudamalloc or cudamallocmanaged apis). the analysis also determines the minimum set of locations where data has to be copied between cpu and gpu by using cudamemcpy. if using unified memory in cuda, then the same analysis pass also determines the minimum locations in the code where cudadevicesync calls must be inserted to get the right functional behavior.

next, within each kernel, gpu coder can choose to map data to shared memory or constant memory. if used wisely, these memories are part of the gpu memory hierarchy structure and can potentially result in greater memory bandwidth. for information on how gpu coder chooses to map to shared memory, see stencil processing. for information on how gpu coder chooses to map to constant memory, see .

once partitioning and memory allocation and transfer statements are in place, gpu coder generates cuda code that follows the partitioning and memory allocation decisions. the generated source code can be compiled into a mex target to be called from within matlab or into a shared library to be integrated with an external project. for information, see .