matlab - imagenes - enlace mexicano del código de cuda en modo de compilación por separado

en html, el atributo alt se emplea para

Question

Estoy tratando de usar el código CUDA dentro de MATLAB mex, bajo Linux. Con el modo "compilación de todo el programa", funciona bien para mí. Doy los siguientes dos pasos dentro de Nsight:

(1) Agregue "-fPIC" como una opción de compilación a cada archivo .cpp o .cu, luego compílelos por separado, cada uno produciendo un archivo .o.

(2) Configure el comando del enlazador para que sea "mex" y agregue "-cxx" para indicar que el tipo de todos los archivos de entrada .o son archivos cpp, y agregue la ruta de la biblioteca para cuda. También agregue un archivo cpp que contenga la entrada mexFunction como una entrada adicional.

Esto funciona bien y el archivo mex resultante funciona bien bajo MATLAB. Después de eso, cuando necesito usar el paralelismo dinámico, tengo que cambiar al "modo de compilación por separado" en Nsight. Intenté lo mismo más arriba pero el enlazador produce muchos errores de referencia faltante, que no pude resolver.

Luego revisé los pasos de compilación y enlace del modo "compilación por separado". Me confundí por lo que está haciendo. Parece que Nsight realiza dos pasos de compilación para cada archivo .cpp o .cu y produce un archivo .o y un archivo .d. Me gusta esto:

/usr/local/cuda-5.5/bin/nvcc -O3 -gencode arch=compute_35,code=sm_35 -odir "src" -M -o "src/tn_matrix.d" "../src/tn_matrix.cu"
/usr/local/cuda-5.5/bin/nvcc --device-c -O3 -gencode arch=compute_35,code=compute_35 -gencode arch=compute_35,code=sm_35  -x cu -o  "src/tn_matrix.o" "../src/tn_matrix.cu"

El comando de enlace es así:

/usr/local/cuda-5.5/bin/nvcc --cudart static --relocatable-device-code=true -gencode arch=compute_35,code=compute_35 -gencode arch=compute_35,code=sm_35 -link -o  "test7"  ./src/cu_base.o ./src/exp_bp_wsj_dev_mex.o ./src/tn_main.o ./src/tn_matlab_helper.o ./src/tn_matrix.o ./src/tn_matrix_lib_dev.o ./src/tn_matrix_lib_host.o ./src/tn_model_wsj_dev.o ./src/tn_model_wsj_host.o ./src/tn_utility.o   -lcudadevrt -lmx -lcusparse -lcurand -lcublas

Lo interesante es que el enlazador no toma el archivo .d como entrada. Entonces, no estoy seguro de cómo lidió con estos archivos y cómo debo procesarlos con el comando "mex" al enlazar?

Otro problema es que la etapa de enlace tiene muchas opciones que no entiendo (--cudart static --relocatable-device-code = true), que supongo que es la razón por la que no puedo hacer que funcione como en el "todo modo de compilación de programa. Entonces intenté lo siguiente:

(1) Compilar de la misma manera que al comienzo de la publicación.

(2) Conservar el comando de enlace proporcionado por Nsight, pero cambie para usar la opción "-shared", de modo que el enlazador produzca un archivo lib.

(3) Invoque mex con la entrada del archivo lib y otro archivo cpp que contenga la entrada mexFunction.

De esta forma, la compilación mex funciona y produce un ejecutable mex como salida. Sin embargo, ejecutar el ejecutable mex resultante bajo MATLAB produce un error de segmentación inmediatamente y bloquea MATLAB.

No estoy seguro de si esta forma de vincular causaría algún problema. Más extraño aún, descubrí que el paso de enlace de mex parece terminar trivialmente sin siquiera verificar la integridad del ejecutable, porque incluso si pierdo un archivo .cpp por alguna función que utilice el mexFunction, aún compila.

EDITAR:

Descubrí cómo vincular manualmente un ejecutable mex que puede ejecutarse correctamente bajo MATLAB, pero no he descubierto cómo hacerlo automáticamente en Nsight, lo que puedo hacer en el modo de "compilación de todo el programa". Aquí está mi enfoque:

(1) Excluir de compilar el archivo cpp que contiene la entrada mexFunction. Compile manualmente con el comando "mex -c".

(2) Agregue "-fPIC" como una opción del compilador a cada uno de los archivos .cpp o .cu restantes, luego compílelos por separado, cada uno produciendo un archivo .o.

(3) El enlace fallará porque no puede encontrar la función principal. No lo tenemos porque usamos MexFunction y está excluido. Esto no importa y simplemente lo dejo ahí.

(4) Siga el método en la publicación siguiente para vincular manualmente los archivos .o en un archivo de objeto de dispositivo

cuda shared library linking: referencia indefinida a cudaRegisterLinkedBinary

Por ejemplo, si el paso (2) produce ao y bo, aquí lo hacemos

nvcc -gencode arch=compute_35,code=sm_35 -Xcompiler ''-fPIC'' -dlink a.o b.o -o mex_dev.o -lcudadevrt

Tenga en cuenta que aquí el archivo de salida mex_dev.o no debería existir, de lo contrario, el comando anterior fallará.

(5) Utilice el comando mex para vincular todos los archivos .o producidos en el paso (2) y el paso (4), con todas las bibliotecas necesarias.

Esto funciona y produce el ejecutable Mex ejecutable. La razón por la que no puedo automatizar el paso (1) dentro de Nsight es porque si cambio el comando de compilación a "mex", Nsight también usará este comando para generar un archivo de dependencia (el archivo .d mencionado en el texto de la pregunta). Y la razón por la que no puedo automatizar el paso (4) y el paso (5) en Nsight es porque involucra dos comandos, que no sé cómo ponerlos. Por favor, avíseme si sabe cómo hacer esto. ¡Gracias!

Answer 1

En primer lugar, debería ser posible configurar Night para utilizar un Makefile personalizado en lugar de generarlo automáticamente. Consulte Configuración de Nsight para ejecutarse con el proyecto Makefile existente .

Una vez que tenemos un Makefile personalizado, es posible automatizar (1), (4) y (5). La ventaja de un Makefile personalizado es que usted sabe exactamente qué comandos de compilación tendrán lugar.

Un ejemplo escueto:

all: mx.mexa64

mx.mexa64: mx.o
    mex -o mx.mexa64 mx.o -L/usr/local/cuda/lib64 -lcudart -lcudadevrt

mx.o: mxfunc.o helper.o
    nvcc -arch=sm_35 -Xcompiler -fPIC -o mx.o -dlink helper.o mxfunc.o -lcudadevrt

mxfunc.o: mxfunc.c
    mex -c -o mxfunc.o mxfunc.c

helper.o: helper.c
    nvcc -arch=sm_35 -Xcompiler -fPIC -c -o helper.o helper.c

clean:
    rm -fv mx.mexa64 *.o

... donde mxfunc.c contiene la función mxFunction pero helper.c no.

EDITAR : Puede lograr el mismo efecto en el sistema de compilación automático. Haga clic derecho en cada archivo fuente y seleccione Propiedades , y obtendrá una ventana donde puede agregar algunas opciones de compilación para ese archivo individual. Para vincular opciones, abra Propiedades del proyecto. Haga algunos experimentos y preste atención a los comandos de compilación reales que aparecen en la consola. En mi experiencia, las opciones personalizadas a veces interactúan con el sistema automático de una manera extraña. Si este método resulta demasiado problemático para usted, le sugiero que haga un Makefile personalizado; De esta manera, al menos no nos atrapan los efectos secundarios inesperados.

Answer 2

OK, descubrí la solución. Estos son los pasos completos para compilar programas mex con "modo de compilación por separado" en Nsight:

1. Crea un proyecto cuda.

2. En el nivel del proyecto, cambie la opción de compilación para lo siguiente:

   • Encienda -fPIC en la opción del compilador del "compilador NVCC" en el nivel del proyecto.
   • Agregue -dlink -Xcompiler ''-fPIC'' a "Configuración experta" "Patrón de línea de comando" del enlazador "Conector NVCC"
   • Agregue la letra o a "Build Artifact" -> "Artifact Extension", ya que mediante -dlink en el último paso estamos haciendo que la salida sea un archivo .o .
   • Agregue mex -cxx -o path_to_mex_bin/mex_bin_filename ./*.o ./src/*.o -lcudadevrt a "Post Build Steps", (agregue otras librerías necesarias)

   ACTUALIZACIÓN: En mi proyecto real, moví el último paso a un archivo .m en MATLAB porque, de lo contrario, si lo hago mientras mi programa mex se está ejecutando, podría causar la falla de MATLAB.

3. Para los archivos se debe compilar con mex, cambie estas opciones de compilación para cada uno de ellos:

   • Cambie el compilador al compilador GCC C++ Compiler en Tool Chain Editor.
   • Regrese a la configuración del compilador GCC C++ Compiler y cambie Command a mex
   • Cambie el patrón de línea de comando a ${COMMAND} -c -outdir "src" ${INPUTS}

Varias notas adicionales:

(1) Los detalles específicos de Cuda (como las funciones del kernel y las llamadas a las funciones del kernel) deben estar ocultos del compilador mex. Por lo tanto, deben colocarse en los archivos .cu en lugar de en los archivos de encabezado. Aquí hay un truco para colocar plantillas que incluyan detalles de cuda en archivos .cu.

En el archivo de encabezado (por ejemplo, fh ), solo pone la declaración de la función como esta:

template<typename ValueType>
void func(ValueType x);

Agregue un nuevo archivo llamado f.inc , que contiene la definición

template<>
void func(ValueType x) {
  // possible kernel launches which should be hidden from mex
}

En el archivo de código fuente (por ejemplo, f.cu ), pones esto

#define ValueType float
#include "f.inc"
#undef ValueType

#define ValueType double
#include "f.inc"
#undef ValueType

// Add other types you want.

Este truco se puede generalizar fácilmente para que las clases con plantillas oculten detalles.

(2) Los detalles específicos de mex también deben estar ocultos de los archivos fuente de cuda, ya que el mex.h alterará las definiciones de algunas funciones del sistema, como printf . Por lo tanto, la inclusión de "mex.h" no debería aparecer en los archivos de encabezado que potencialmente se pueden incluir en los archivos fuente de cuda.

(3) En el archivo de código fuente mex que contiene la entrada mexFunction, se puede usar la macro del compilador MATLAB_MEX_FILE para compilar selectivamente secciones de código. De esta forma, el archivo de código fuente se puede compilar tanto en el ejecutable mex como en el ejecutable ordinario, lo que permite la depuración en Nsight sin matlab. Aquí hay un truco para construir múltiples objetivos bajo Nsight: construir múltiples binarios dentro de un proyecto de Eclipse