<li><ahref="#CompileTaskflowWithCUDANaiveLinking">Link Objects Using nvcc</a></li>
<li><ahref="#CompileTaskflowWithCUDADifferentLinkers">Link Objects Using Different Linkers</a></li>
</ul>
</li>
</ul>
</nav>
<sectionid="InstallCUDACompiler"><h2><ahref="#InstallCUDACompiler">Install CUDA Compiler</a></h2><p>To compile Taskflow with CUDA code, you need a <code>nvcc</code> compiler. Please visit the official page of <ahref="https://developer.nvidia.com/cuda-downloads">Downloading CUDA Toolkit</a>.</p></section><sectionid="CompileTaskflowWithCUDADirectly"><h2><ahref="#CompileTaskflowWithCUDADirectly">Compile Source Code Directly</a></h2><p>Taskflow's GPU programming interface for CUDA is <ahref="classtf_1_1cudaFlow.html" class="m-doc">tf::<wbr/>cudaFlow</a>. Consider the following <code>simple.cu</code> program that launches a single kernel function to output a message:</p><preclass="m-code"><spanclass="cp">#include</span><spanclass="w"></span><spanclass="cpf"><taskflow/taskflow.hpp></span><spanclass="cp"></span>
<spanclass="p">}</span><spanclass="w"></span></pre><p>The easiest way to compile Taskflow with CUDA code (e.g., cudaFlow, kernels) is to use <ahref="https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html">nvcc</a>:</p><preclass="m-console"><spanclass="go">~$ nvcc -std=c++17 -I path/to/taskflow/ --extended-lambda simple.cu -o simple</span>
<spanclass="go">~$ ./simple</span>
<spanclass="go">hello cudaFlow!</span></pre></section><sectionid="CompileTaskflowWithCUDASeparately"><h2><ahref="#CompileTaskflowWithCUDASeparately">Compile Source Code Separately</a></h2><p>Large GPU applications often compile a program into separate objects and link them together to form an executable or a library. You can compile your CPU code and GPU code separately with Taskflow using <code>nvcc</code> and other compilers (such as <code>g++</code> and <code>clang++</code>). Consider the following example that defines two tasks on two different pieces (<code>main.cpp</code> and <code>cudaflow.cpp</code>) of source code:</p><preclass="m-code"><spanclass="c1">// main.cpp</span>
<spanclass="n">tf</span><spanclass="o">::</span><spanclass="n">Task</span><spanclass="w"></span><spanclass="nf">make_cudaflow</span><spanclass="p">(</span><spanclass="n">tf</span><spanclass="o">::</span><spanclass="n">Taskflow</span><spanclass="o">&</span><spanclass="w"></span><spanclass="n">taskflow</span><spanclass="p">);</span><spanclass="w"></span><spanclass="c1">// create a cudaFlow task</span>
<spanclass="p">}</span><spanclass="w"></span></pre><p>Compile each source to an object (<code>g++</code> as an example):</p><preclass="m-console"><spanclass="go">~$ g++ -std=c++17 -I path/to/taskflow -c main.cpp -o main.o</span>
<spanclass="go">~$ nvcc -std=c++17 --extended-lambda -x cu -I path/to/taskflow \</span>
<spanclass="gp"># </span>now we have the two compiled .o objects, main.o and cudaflow.o
<spanclass="go">main.o cudaflow.o </span></pre><p>The <code>–extended-lambda</code> option tells <code>nvcc</code> to generate GPU code for the lambda defined with <code><strong>device</strong></code>. The <code>-x cu</code> tells <code>nvcc</code> to treat the input files as .cu files containing both CPU and GPU code. By default, <code>nvcc</code> treats .cpp files as CPU-only code. This option is required to have <code>nvcc</code> generate device code here, but it is also a handy way to avoid renaming source files in larger projects. The <code>–dc</code> option tells <code>nvcc</code> to generate device code for later linking.</p><p>You may also need to specify the target architecture to tell <code>nvcc</code> to target on a compatible SM architecture using the option -arch. For instance, the following command requires device code linking to have compute capability 7.5 or later:</p><preclass="m-console"><spanclass="go">~$ nvcc -std=c++17 --extended-lambda -x cu -arch=sm_75 -I path/to/taskflow \</span>
<spanclass="go"> -dc cudaflow.cpp -o cudaflow.o</span></pre><sectionid="CompileTaskflowWithCUDANaiveLinking"><h3><ahref="#CompileTaskflowWithCUDANaiveLinking">Link Objects Using nvcc</a></h3><p>Using <code>nvcc</code> to link compiled object code is nothing special but replacing the normal compiler with <code>nvcc</code> and it takes care of all the necessary steps:</p><preclass="m-console"><spanclass="go">~$ nvcc main.o cudaflow.o -o main</span>
<spanclass="gp"># </span>run the main program
<spanclass="go">~$ ./main</span>
<spanclass="go">main.cpp!</span>
<spanclass="go">cudaflow.cpp!</span></pre></section><sectionid="CompileTaskflowWithCUDADifferentLinkers"><h3><ahref="#CompileTaskflowWithCUDADifferentLinkers">Link Objects Using Different Linkers</a></h3><p>You can choose to use a compiler other than <code>nvcc</code> for the final link step. Since your CPU compiler does not know how to link CUDA device code, you have to add a step in your build to have <code>nvcc</code> link the CUDA device code, using the option <code>-dlink:</code></p><preclass="m-console"><spanclass="go">~$ nvcc -o gpuCode.o -dlink main.o cudaflow.o</span></pre><p>This step links all the <em>device object code</em> and places it into <code>gpuCode.o</code>.</p><asideclass="m-note m-info"><h4>Note</h4><p>Note that this step does not link the CPU object code and discards the CPU object code in <code>main.o</code> and <code>cudaflow.o</code>.</p></aside><p>To complete the link to an executable, you can use, for example, <code>ld</code> or <code>g++</code>.</p><preclass="m-console"><spanclass="gp"># </span>replace /usr/local/cuda/lib64 with your own CUDA library installation path
<spanclass="go">cudaflow.cpp!</span></pre><p>We give <code>g++</code> all of the objects again because it needs the CPU object code, which is not in <code>gpuCode.o</code>. The device code stored in the original objects, <code>main.o</code> and <code>cudaflow.o</code>, does not conflict with the code in <code>gpuCode.o</code>. <code>g++</code> ignores device code because it does not know how to link it, and the device code in <code>gpuCode.o</code> is already linked and ready to go.</p><asideclass="m-note m-info"><h4>Note</h4><p>This intentional ignorance is extremely useful in large builds where intermediate objects may have both CPU and GPU code. In this case, we just let the GPU and CPU linkers each do its own job, noting that the CPU linker is always the last one we run. The CUDA <ahref="classtf_1_1Runtime.html" class="m-doc">Runtime</a> API library is automatically linked when we use <code>nvcc</code> for linking, but we must explicitly link it (<code>-lcudart</code>) when using another linker.</p></aside></section></section>
</div>
</div>
</div>
</article></main>
<divclass="m-doc-search" id="search">
<ahref="#!" onclick="return hideSearch()"></a>
<divclass="m-container">
<divclass="m-row">
<divclass="m-col-m-8 m-push-m-2">
<divclass="m-doc-search-header m-text m-small">
<div><spanclass="m-label m-default">Tab</span> / <spanclass="m-label m-default">T</span> to search, <spanclass="m-label m-default">Esc</span> to close</div>