.. | ||
Makefile | ||
NsightEclipse.xml | ||
p2pBandwidthLatencyTest_vs2012.sln | ||
p2pBandwidthLatencyTest_vs2012.vcxproj | ||
p2pBandwidthLatencyTest_vs2013.sln | ||
p2pBandwidthLatencyTest_vs2013.vcxproj | ||
p2pBandwidthLatencyTest_vs2015.sln | ||
p2pBandwidthLatencyTest_vs2015.vcxproj | ||
p2pBandwidthLatencyTest_vs2017.sln | ||
p2pBandwidthLatencyTest_vs2017.vcxproj | ||
p2pBandwidthLatencyTest_vs2019.sln | ||
p2pBandwidthLatencyTest_vs2019.vcxproj | ||
p2pBandwidthLatencyTest.cu | ||
README.md |
p2pBandwidthLatencyTest - Peer-to-Peer Bandwidth Latency Test with Multi-GPUs
Description
This application demonstrates the CUDA Peer-To-Peer (P2P) data transfers between pairs of GPUs and computes latency and bandwidth. Tests on GPU pairs using P2P and without P2P are tested.
Key Concepts
Performance Strategies, Asynchronous Data Transfers, Unified Virtual Address Space, Peer to Peer Data Transfers, Multi-GPU
Supported SM Architectures
SM 3.0 SM 3.5 SM 3.7 SM 5.0 SM 5.2 SM 6.0 SM 6.1 SM 7.0 SM 7.2 SM 7.5
Supported OSes
Linux, Windows, MacOSX
Supported CPU Architecture
x86_64, ppc64le, armv7l
CUDA APIs involved
CUDA Runtime API
cudaDeviceCanAccessPeer, cudaDeviceEnablePeerAccess, cudaDeviceDisablePeerAccess, cudaEventCreateWithFlags, cudaEventElapsedTime, cudaMemcpy
Prerequisites
Download and install the CUDA Toolkit 10.1 for your corresponding platform.
Build and Run
Windows
The Windows samples are built using the Visual Studio IDE. Solution files (.sln) are provided for each supported version of Visual Studio, using the format:
*_vs<version>.sln - for Visual Studio <version>
Each individual sample has its own set of solution files in its directory:
To build/examine all the samples at once, the complete solution files should be used. To build/examine a single sample, the individual sample solution files should be used.
Note: Some samples require that the Microsoft DirectX SDK (June 2010 or newer) be installed and that the VC++ directory paths are properly set up (Tools > Options...). Check DirectX Dependencies section for details."
Linux
The Linux samples are built using makefiles. To use the makefiles, change the current directory to the sample directory you wish to build, and run make:
$ cd <sample_dir>
$ make
The samples makefiles can take advantage of certain options:
-
TARGET_ARCH= - cross-compile targeting a specific architecture. Allowed architectures are x86_64, ppc64le, armv7l. By default, TARGET_ARCH is set to HOST_ARCH. On a x86_64 machine, not setting TARGET_ARCH is the equivalent of setting TARGET_ARCH=x86_64.
$ make TARGET_ARCH=x86_64
$ make TARGET_ARCH=ppc64le
$ make TARGET_ARCH=armv7l
See here for more details. -
dbg=1 - build with debug symbols
$ make dbg=1
-
SMS="A B ..." - override the SM architectures for which the sample will be built, where
"A B ..."
is a space-delimited list of SM architectures. For example, to generate SASS for SM 50 and SM 60, useSMS="50 60"
.$ make SMS="50 60"
-
HOST_COMPILER=<host_compiler> - override the default g++ host compiler. See the Linux Installation Guide for a list of supported host compilers.
$ make HOST_COMPILER=g++
Mac
The Mac samples are built using makefiles. To use the makefiles, change directory into the sample directory you wish to build, and run make:
$ cd <sample_dir>
$ make
The samples makefiles can take advantage of certain options:
-
dbg=1 - build with debug symbols
$ make dbg=1
-
SMS="A B ..." - override the SM architectures for which the sample will be built, where "A B ..." is a space-delimited list of SM architectures. For example, to generate SASS for SM 50 and SM 60, use SMS="50 60".
$ make SMS="A B ..."
-
HOST_COMPILER=<host_compiler> - override the default clang host compiler. See the Mac Installation Guide for a list of supported host compilers.
$ make HOST_COMPILER=clang