¿Cuál es el propósito de usar múltiples banderas “arch” en el comstackdor NVCC de Nvidia?

Recientemente me he enterado de cómo NVCC comstack código de dispositivo CUDA para diferentes architectures de cálculo.

Desde mi punto de vista, al usar la opción de código de NVCC, “arco” es la architecture informática mínima requerida por la aplicación del progtwigdor, y también la architecture mínima de cálculo del dispositivo que el comstackdor JIT de NVCC comstackrá para el código PTX.

También entiendo que el parámetro “código” de -gencode es la architecture de cálculo para la cual NVCC comstack por completo la aplicación, de modo que no es necesaria ninguna comstackción JIT.

Después de la inspección de varios Makefiles del proyecto CUDA, he notado que lo siguiente ocurre regularmente:

-gencode arch=compute_20,code=sm_20 -gencode arch=compute_20,code=sm_21 -gencode arch=compute_21,code=sm_21 

y después de leerlo, descubrí que se podían comstackr varias architectures de dispositivos en un único archivo binario, en este caso sm_20, sm_21.

Mis preguntas son: ¿por qué son necesarios tantos pares de arco / código? ¿Se usan todos los valores de “arco” en el anterior?

cuál es la diferencia entre eso y decir:

 -arch compute_20 -code sm_20 -code sm_21 

¿La architecture virtual más antigua en los campos de “arco” se selecciona automáticamente, o hay algún otro comportamiento oscuro?

¿Hay algún otro comportamiento de comstackción y ejecución que deba tener en cuenta?

He leído el manual, http://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html#gpu-comstacktion y todavía no estoy seguro de lo que sucede en la comstackción o en el tiempo de ejecución.

Aclamaciones,

James.

En términos generales, el flujo de comstackción de código es el siguiente:

Fuente del código del dispositivo CUDA C / C ++ -> PTX -> SASS

La architecture virtual (p. compute_20 , compute_20 , lo que sea especificado por -arch compute... ) determina qué tipo de código PTX se generará. Los conmutadores adicionales (por ejemplo, el -code sm_21 ) determinan qué tipo de código SASS se generará. SASS es en realidad código de objeto ejecutable para una GPU (lenguaje de máquina). Un archivo ejecutable puede contener varias versiones de SASS y / o PTX, y hay un mecanismo de cargador en tiempo de ejecución que seleccionará las versiones apropiadas en función de la GPU que realmente se esté utilizando.

Como usted señala, una de las características útiles del funcionamiento de la GPU es la comstackción JIT. La comstackción de JIT será realizada por el controlador de la GPU (no requiere la instalación del kit de herramientas de CUDA) cada vez que se encuentre disponible un código de PTX adecuado, pero no un código de SASS adecuado.

Una ventaja de incluir múltiples architectures virtuales (es decir, múltiples versiones de PTX), entonces, es que tiene compatibilidad ejecutable con una variedad más amplia de dispositivos de GPU de destino (aunque algunos dispositivos pueden activar una comstackción de JIT para crear el SASS necesario).

Una ventaja de incluir múltiples “objectives de GPU reales” (es decir, múltiples versiones de SASS) es que puede evitar el paso de comstackción de JIT, cuando uno de esos dispositivos de destino está presente.

Si especifica un conjunto incorrecto de opciones, es posible crear un archivo ejecutable que no se ejecutará (correctamente) en una GPU en particular.

Una posible desventaja de especificar muchas de estas opciones es la saturación del tamaño del código. Otra posible desventaja es el tiempo de comstackción, que generalmente será más largo a medida que especifique más opciones.

También es posible crear excutables que no contengan PTX, que pueden ser de interés para aquellos que intentan ocultar su IP.

La creación de PTX adecuada para JIT se debe hacer especificando una architecture virtual para el cambio de code .

El objective de los indicadores de -arch múltiple es utilizar la macro __CUDA_ARCH__ para la comstackción condicional (es decir, usando #ifdef ) de rutas de código optimizadas de forma diferente.

Vea aquí: http://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/index.html#virtual-architecture-identification-macro