在调查可重定位设备代码的一些问题时,我偶然发现了一些我不太了解的事情。
这是slide 6上图片的用例。我使用answer of Robert Crovella作为repro代码的基础。我们的想法是将一些可重定位的设备代码编译成静态库(例如某些数学/工具箱库),并且我们希望将该预编译库的一些函数用于我们程序的另一个设备库中:
libutil.a ---> libtest.so ---> test_pgm
让我们说这个外部库包含以下功能:
__device__ int my_square (int a);
libutil.a
例如按以下方式生成(在另一个项目中):
nvcc ${NVCC_FLAGS} -dc util.cu
nvcc ${NVCC_FLAGS} -dlink util.o -o util_dlink.o
nvcc ${NVCC_FLAGS} -lib util_dlink.o util.o -o libutil.a
然后,在我们的项目中,生成libtest.so
:
nvcc ${NVCC_FLAGS} -dc test.cu
nvcc ${NVCC_FLAGS} -dlink test.o libutil.a -o test_dlink.o
g++ -shared -Wl,-soname,libtest.so -o libtest.so test.o test_dlink.o libutil.a -L${CUDA_LIBDIR} -lcudart
但是在生成test_dlink.o
:
nvlink error : Undefined reference to '_Z9my_squarei' in 'test.o'
链接器找不到我们的虚拟my_square(int)
函数。如果我们改为使用(假设我们可以访问util.o
):
nvcc ${NVCC_FLAGS} -dlink test.o util.o -o test_dlink.o
链接器成功,一切正常。
进一步调查:
$ nm -C libutil.a
util_dlink.o:
U atexit
U __cudaRegisterFatBinary
0000000000000015 T __cudaRegisterLinkedBinary_39_tmpxft_0000106a_00000000_6_util_cpp1_ii_843d693d
...
util.o:
U __cudaInitModule
U __cudaRegisterLinkedBinary_39_tmpxft_0000106a_00000000_6_util_cpp1_ii_843d693d
...
0000000000000015 T my_square(int)
...
存档的util.o
中有符号,但nvlink
(由nvcc
调用)似乎找不到它。这是为什么?根据{{3}}:
设备链接器能够读取静态主机库 格式(Linux和Mac上的.a,Windows上的.lib)。
我们当然可以提取目标文件并与之链接:
ar x libutil.a `ar t libutil.a | grep -v "dlink"`
nvcc ${NVCC_FLAGS} -dlink test.o util.o -o test_dlink.o
但这并不像预期的解决方案......那么我在这里缺少什么?解决这个问题的另一个nvcc
选项?生成libutil.a
和/或libtest.so
?
请注意,这是在Arch Linux上使用CUDA 6.5进行测试的。
NVCC_FLAGS=-m64 -arch=sm_20 -Xcompiler '-fPIC'
CUDA_LIBDIR=${CUDA_HOME}/lib64
testmain : main.cpp libtest.so
g++ -c main.cpp
g++ -o testmain -L. -ldl -Wl,-rpath,. -ltest -L${CUDA_LIBDIR} -lcudart main.o
libutil.a : util.cu util.cuh
nvcc ${NVCC_FLAGS} -dc util.cu
# ---> FOLLOWING LINES THAT WERE WRONG <---
# nvcc ${NVCC_FLAGS} -dlink util.o -o util_dlink.o
# nvcc ${NVCC_FLAGS} -lib util.o util_dlink.o -o libutil.a
# INSTEAD:
nvcc ${NVCC_FLAGS} -lib util.o -o libutil.a
# Assuming util is an external library, so util.o is not available
rm util.o
libtest.so : test.cu test.h libutil.a util.cuh
nvcc ${NVCC_FLAGS} -dc test.cu
# Use NVCC for device linking + G++
nvcc -v ${NVCC_FLAGS} -dlink test.o libutil.a -o test_dlink.o
g++ -shared -o libtest.so test.o test_dlink.o libutil.a -L${CUDA_LIBDIR} -lcudart
# Or let NVCC generate the shared library
#nvcc -v ${NVCC_FLAGS} -shared -L. -lutil test.o -o libtest.so
clean :
rm -f testmain *.o *.a *.so
#ifndef TEST_H
# define TEST_H
int my_test_func();
#endif //! TEST_H
#include <stdio.h>
#include "test.h"
#include "util.cuh"
#define DSIZE 1024
#define DVAL 10
#define SQVAL 3
#define nTPB 256
#define cudaCheckErrors(msg) \
do { \
cudaError_t __err = cudaGetLastError(); \
if (__err != cudaSuccess) { \
fprintf(stderr, "Fatal error: %s (%s at %s:%d)\n", \
msg, cudaGetErrorString(__err), \
__FILE__, __LINE__); \
fprintf(stderr, "*** FAILED - ABORTING\n"); \
exit(1); \
} \
} while (0)
__global__ void my_kernel(int *data){
int idx = threadIdx.x + (blockDim.x *blockIdx.x);
if (idx < DSIZE) data[idx] =+ DVAL + my_square (SQVAL);
}
int my_test_func()
{
int *d_data, *h_data;
h_data = (int *) malloc(DSIZE * sizeof(int));
if (h_data == 0) {printf("malloc fail\n"); exit(1);}
cudaMalloc((void **)&d_data, DSIZE * sizeof(int));
cudaCheckErrors("cudaMalloc fail");
for (int i = 0; i < DSIZE; i++) h_data[i] = 0;
cudaMemcpy(d_data, h_data, DSIZE * sizeof(int), cudaMemcpyHostToDevice);
cudaCheckErrors("cudaMemcpy fail");
my_kernel<<<((DSIZE+nTPB-1)/nTPB), nTPB>>>(d_data);
cudaDeviceSynchronize();
cudaCheckErrors("kernel");
cudaMemcpy(h_data, d_data, DSIZE * sizeof(int), cudaMemcpyDeviceToHost);
cudaCheckErrors("cudaMemcpy 2");
for (int i = 0; i < DSIZE; i++)
if (h_data[i] != DVAL + SQVAL*SQVAL)
{
printf("Results check failed at offset %d, data was: %d, should be %d\n",
i, h_data[i], DVAL);
exit(1);
}
printf("Results check passed!\n");
return 0;
}
#ifndef UTIL_CUH
# define UTIL_CUH
__device__ int my_square (int a);
#endif //! UTIL_CUH
#include "util.cuh"
__device__ int my_square (int a)
{
return a * a;
}
#include "test.h"
int main()
{
my_test_func();
return 0;
}
答案 0 :(得分:3)
我建议在问题中加上一个完整的简单示例,就像我在下面所做的那样。代码的外部链接不受欢迎。当它们变得陈旧时,问题变得不那么有价值了。
是的,生成libutil.a
时出错。创建带有公开设备链接的静态库与创建共享库(根据定义)没有公开的设备链接不同。请注意我在上一个问题中提到的“无CUDA包装”。此问题中的示例暴露了设备链接,因为my_square
位于库中,但由库外部的代码使用。
查看nvcc relocatable device code compiling examples,您将找到一个生成可设备链接的静态库的文件。静态库创建中没有设备链接步骤。设备链接步骤在最终的可执行文件创建时完成(或者在这种情况下,在创建所谓的“CUDA边界”时)。静态库创建中的“额外”设备链接操作是您观察到的错误的近端原因。
这是一个完全有效的例子:
$ cat util.h
__device__ float my_square(float);
$ cat util.cu
__device__ float my_square(float val){ return val*val;}
$ cat test.h
float dbl_sq(float val);
$ cat test.cu
#include "util.h"
__global__ void my_dbl_sq(float *val){
*val = 2*my_square(*val);
}
float dbl_sq(float val){
float *d_val, h_val;
cudaMalloc(&d_val, sizeof(float));
h_val = val;
cudaMemcpy(d_val, &h_val, sizeof(float), cudaMemcpyHostToDevice);
my_dbl_sq<<<1,1>>>(d_val);
cudaMemcpy(&h_val, d_val, sizeof(float), cudaMemcpyDeviceToHost);
return h_val;
}
$ cat main.cpp
#include <stdio.h>
#include "test.h"
int main(){
printf("%f\n", dbl_sq(2.0f));
return 0;
}
$ nvcc -arch=sm_35 -Xcompiler -fPIC -dc util.cu
$ nvcc -arch=sm_35 -Xcompiler -fPIC -lib util.o -o libutil.a
$ nvcc -arch=sm_35 -Xcompiler -fPIC -dc test.cu
$ nvcc -arch=sm_35 -shared -Xcompiler -fPIC -L. -lutil test.o -o libtest.so
$ g++ -o main main.cpp libtest.so
$ cuda-memcheck ./main
========= CUDA-MEMCHECK
8.000000
========= ERROR SUMMARY: 0 errors
$
在此示例中,设备链接自动发生在用于创建.so库的nvcc
调用中。在我的示例中,我已经设置了LD_LIBRARY_PATH
环境变量以包含我的工作目录。在CentOS 6.2上使用CUDA 6.5进行测试(请注意,在创建可执行文件期间可以执行多个设备链接操作,但这些设备链接操作必须位于单独的链接域中,即用户代码或用户代码入口点不能在域之间共享。这不是这种情况。)