emulation que - Emulador de GPU para programación CUDA sin el hardware




es renderizar (6)

Para aquellos que buscan la respuesta en 2016 (e incluso 2017) ...

Renuncia

  • No he podido emular la GPU después de todo.
  • Podría ser posible usar gpuocelot si satisface su lista de dependencias.

He intentado obtener un emulador para BunsenLabs (Linux 3.16.0-4-686-pae # 1 SMP Debian 3.16.7-ckt20-1 + deb8u4 (2016-02-29) i686 GNU / Linux).

Te diré lo que he aprendido.

  1. nvcc solía tener una opción -deviceemu en CUDA Toolkit 3.0

    Descargué CUDA Toolkit 3.0, lo instalé e intenté ejecutar un programa simple:

    #include <stdio.h>
    
    __global__ void helloWorld() {
        printf("Hello world! I am %d (Warp %d) from %d.\n",
            threadIdx.x, threadIdx.x / warpSize, blockIdx.x);
    }
    
    int main() {
        int blocks, threads;
        scanf("%d%d", &blocks, &threads);
        helloWorld<<<blocks, threads>>>();
        cudaDeviceSynchronize();
        return 0;
    }
    

    Tenga en cuenta que en CUDA Toolkit 3.0 nvcc estaba en /usr/local/cuda/bin/ .

    Resultó que tuve dificultades para compilarlo:

    NOTE: device emulation mode is deprecated in this release
          and will be removed in a future release.
    
    /usr/include/i386-linux-gnu/bits/byteswap.h(47): error: identifier "__builtin_bswap32" is undefined
    
    /usr/include/i386-linux-gnu/bits/byteswap.h(111): error: identifier "__builtin_bswap64" is undefined
    
    /home/user/Downloads/helloworld.cu(12): error: identifier "cudaDeviceSynchronize" is undefined
    
    3 errors detected in the compilation of "/tmp/tmpxft_000011c2_00000000-4_helloworld.cpp1.ii".
    

    He encontrado en Internet que si utilizo gcc-4.2 o similar en lugar de gcc-4.9.2 los errores pueden desaparecer. Me di por vencido.

  2. gpuocelot

    La respuesta de Stringer tiene un enlace a un sitio web muy antiguo del proyecto gpuocelot . Así que al principio pensé que el proyecto fue abandonado en 2012 más o menos. En realidad, fue abandonado pocos años después.

    Aquí hay algunos sitios web actualizados:

    Intenté instalar gpuocelot siguiendo la guía . Aunque tuve varios errores durante la instalación y me di por vencido nuevamente. gpuocelot ya no es compatible y depende de un conjunto de versiones muy específicas de bibliotecas y software.

    Puede intentar seguir este tutorial a partir de julio de 2015, pero no garantizo que funcionará. No lo he probado.

  3. MCUDA

    El marco de traducción de MCUDA es una herramienta basada en Linux diseñada para compilar efectivamente el modelo de programación CUDA a una arquitectura de CPU.

    Puede ser útil. Aquí hay un enlace al sitio web .

  4. Residuos de CUDA

    Es un emulador para usar en Windows 7 y 8. No lo he probado. Parece que ya no está desarrollado (el último compromiso está fechado el 4 de julio de 2013).

    Aquí está el enlace al sitio web del proyecto: https://code.google.com/archive/p/cuda-waste/

  1. CU2CL

    Última actualización: 12.03.2017

    Como señaló dashesy en los comentarios, CU2CL parece ser un proyecto interesante. Parece ser capaz de traducir el código CUDA a código OpenCL. Entonces, si su GPU es capaz de ejecutar código OpenCL, entonces el proyecto CU2CL podría ser de su interés.

    Campo de golf:

Pregunta: ¿Existe un emulador para una tarjeta Geforce que me permita programar y probar CUDA sin tener el hardware real?

Información:

Estoy buscando acelerar algunas simulaciones mías en CUDA, pero mi problema es que no siempre estoy cerca de mi escritorio para hacer este desarrollo. Me gustaría hacer algo de trabajo en mi netbook, pero mi netbook no tiene una GPU. Ahora, que yo sepa, necesitas una GPU con capacidad CUDA para ejecutar CUDA. ¿Hay alguna forma de evitar esto? Parecería que la única forma es un emulador de GPU (que obviamente sería muy lento, pero funcionaría). Pero de cualquier manera que haya para hacer esto, me gustaría escuchar.

Estoy programando en Ubuntu 10.04 LTS.


Esta respuesta puede ser demasiado tarde, pero vale la pena señalar de todos modos. GPU Ocelot ( del cual soy uno de los contribuidores principales ) se puede compilar sin los controladores de dispositivo CUDA (libcuda.so) instalados si desea usar el emulador o los backends LLVM. He demostrado el emulador en sistemas sin GPU NVIDIA.

El emulador intenta implementar fielmente las especificaciones PTX 1.4 y PTX 2.1 que pueden incluir características que las GPU anteriores no son compatibles. El traductor de LLVM se esfuerza por una traducción correcta y eficiente de PTX a x86 que, con suerte, hará que CUDA sea una forma efectiva de programar CPU multinúcleo y GPU. -deviceemu ha sido una característica obsoleta de CUDA durante bastante tiempo, pero el traductor de LLVM siempre ha sido más rápido.

Además, varios controles de corrección están integrados en el emulador para verificar: los accesos de memoria alineados, los accesos a la memoria compartida están sincronizados correctamente y la eliminación de referencias de memoria global accede a las regiones de memoria asignadas. También hemos implementado un depurador interactivo de línea de comando inspirado en gran medida por gdb para pasar de un solo paso a través de kernels CUDA, establecer puntos de interrupción y puntos de observación, etc. Estas herramientas se desarrollaron específicamente para agilizar la depuración de los programas CUDA; puedes encontrarlos útiles.

Perdón por el aspecto solo de Linux. Hemos comenzado una sucursal de Windows ( así como un puerto Mac OS X ) pero la carga de ingeniería ya es lo suficientemente grande como para enfatizar nuestras búsquedas de investigación. Si alguien tiene tiempo e interés, ¡pueden ayudarnos a brindar asistencia para Windows!

Espero que esto ayude.


También puede verificar el proyecto gpuocelot que es un verdadero emulador en el sentido de que PTX (bytecode en el que se convierte el código CUDA) será emulado.

También hay un traductor de LLVM, sería interesante probar si es más rápido que con el uso de -deviceemu.


El kit de herramientas de CUDA tenía uno integrado hasta el ciclo de lanzamiento de CUDA 3.0. Si usas una de estas versiones muy antiguas de CUDA, asegúrate de usar -deviceemu cuando compiles con nvcc.



La memoria es la memoria. Pero diferentes cosas pueden acceder a esa memoria. La GPU puede acceder a la memoria, la CPU puede acceder a la memoria, tal vez a otros bits de hardware, lo que sea.

Una cosa en particular tiene acceso "coherente" a la memoria si los cambios realizados por otros en esa memoria son visibles para el lector. Ahora, podrías pensar que esto es una tontería. Después de todo, si se ha cambiado la memoria, ¿cómo es posible que alguien no pueda verla?

En pocas palabras, cachés.

Resulta que cambiar la memoria es costoso. Así que hacemos todo lo posible para evitar cambiar la memoria a menos que sea absolutamente necesario. Cuando escribe un solo byte de la CPU a un puntero en la memoria, la CPU todavía no escribe ese byte. O al menos, no a la memoria. Lo escribe en una copia local de esa memoria llamada "caché".

La razón de esto es que, en general, las aplicaciones no escriben (o leen) bytes individuales. Es más probable que escriban (y lean) muchos bytes, en partes pequeñas. Entonces, si va a realizar una operación costosa como una carga de memoria o un almacenamiento, debe cargar o almacenar una gran parte de la memoria. Por lo tanto, almacena todos los cambios que va a realizar en un caché de la memoria, y luego hace una sola escritura de ese trozo en caché en la memoria real en algún momento en el futuro.

Pero si tiene dos dispositivos separados que usan la misma memoria, necesita alguna forma de asegurarse de que las escrituras de un dispositivo sean visibles para otros dispositivos. La mayoría de las GPU no pueden leer el caché de la CPU. Y la mayoría de los lenguajes de la CPU no tienen soporte en el idioma para decir "hey, esas cosas que escribí en la memoria? Realmente quiero que lo escribas en la memoria ahora". Por lo tanto, normalmente se necesita algo para asegurar la visibilidad de los cambios.

En Vulkan, la memoria que está etiquetada como "HOST_COHERENT" significa que, si escribe en esa memoria (a través de un puntero asignado, ya que esa es la única forma en que Vulkan le permite escribir directamente en la memoria), no necesita usar funciones especiales para hacer Seguro que la GPU puede ver esos cambios. La visibilidad de la GPU de cualquier cambio está garantizada. Si esa marca no está disponible en la memoria, entonces debe usar las API de Vulkan para garantizar la coherencia de las regiones específicas de datos a las que desea acceder.

Con la memoria coherente, una de dos cosas está sucediendo en términos de hardware. El acceso de la CPU a la memoria no se almacena en caché en ninguna de las memorias caché de la CPU, o la GPU tiene acceso directo a las memorias caché de la CPU (tal vez debido a que está en el mismo dado que la (s) CPU (s)). Por lo general, se puede decir que esto último está sucediendo, porque las implementaciones de Vulkan en la GPU en la matriz no se molestan en ofrecer opciones de memoria no coherentes.





cuda gpu emulation cpu