Las aplicaciones CUDA se agotan y fallan después de varios segundos. ¿Cómo solucionar esto?

Me he dado cuenta de que las aplicaciones CUDA tienden a tener un tiempo de ejecución máximo aproximado de 5-15 segundos antes de que fallen y salgan. Me doy cuenta de que es ideal no tener la aplicación CUDA durante tanto tiempo, pero suponiendo que es la opción correcta para usar CUDA y debido a la cantidad de trabajo secuencial por hilo debe durar tanto tiempo, ¿hay alguna manera de extender este período de tiempo o para evitarlo?

No soy un experto en CUDA, — he estado desarrollando con AMD Stream SDK, que AFAIK es más o menos comparable.

Puede desactivar el temporizador de vigilancia de Windows, pero eso no es recomendable , por razones que deberían ser obvias. Para deshabilitarlo, debe regenerizar HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Watchdog\Display\DisableBugCheck , crear un REG_DWORD y configurarlo en 1. También es posible que necesite hacer algo en el panel de control de NVidia. Busque alguna referencia a “Recuperación de VPU” en los documentos de CUDA.

Idealmente, debería poder dividir las operaciones de su kernel en múltiples pasadas sobre sus datos para dividirlo en operaciones que se ejecutan en el límite de tiempo.

Alternativamente, puede dividir el dominio del problema para que esté computando menos píxeles de salida por comando. Es decir, en lugar de calcular 1,000,000 de píxeles de salida de una sola vez, emita 10 comandos a la GPU para calcular 100,000 cada uno.

La unidad básica que tiene que caber dentro del intervalo de tiempo no es toda su aplicación, sino la ejecución de un único búfer de comando. En el AMD Stream SDK, una secuencia larga de operaciones se puede dividir en varias franjas horarias al enjuagar explícitamente la cola de comandos con una llamada CtxFlush (). Tal vez CUDA tiene algo similar?

No debería tener que leer todos sus datos de ida y vuelta en el bus PCIX cada vez; puedes dejar tus texturas, etc. en la memoria local gpu; solo tiene algunos búferes de comandos completos de vez en cuando, para demostrar al sistema operativo que no está atrapado en un bucle infinito.

Finalmente, las GPU son rápidas , así que si tu aplicación no puede hacer un trabajo útil en esos 5 o 10 segundos, tomaría eso como una señal de que algo anda mal.

[EDITAR Mar 2010 para actualizar: ] (desactualizado de nuevo, consulte las actualizaciones a continuación para obtener la información más reciente) La clave de registro anterior está desactualizada. Creo que esa fue la clave para Windows XP de 64 bits. Hay nuevas claves de registro para Vista y Windows 7. Puede encontrarlas aquí: http://www.microsoft.com/whdc/device/display/wddm_timeout.mspx o aquí: http://msdn.microsoft.com/en -us / library / ee817001.aspx

[EDITAR Abr 2015 para actualizar: ] Esto se está realmente desactualizado. La forma más fácil de deshabilitar TDR para progtwigción Cuda, suponiendo que tiene instaladas las herramientas NVIDIA Nsight, es abrir el monitor Nsight, hacer clic en “Opciones de monitor Nsight” y en “General” configurar “TDR WDDM habilitado” en falso. Esto cambiará la configuración del registro para usted. Cierra y reinicia. Cualquier cambio en la configuración del registro TDR no tendrá efecto hasta que reinicie.

[EDITAR Agosto de 2018 para actualizar:] Aunque las herramientas de NVIDIA ahora permiten deshabilitar el TDR, la misma pregunta es relevante para los desarrolladores de AMD / OpenCL. Para aquellos: el enlace actual que documenta la configuración de TDR está en https://docs.microsoft.com/en-us/windows-hardware/drivers/display/tdr-registry-keys

En Windows, el controlador de gráficos tiene un temporizador de vigilancia que elimina cualquier progtwig de sombreado que se ejecute durante más de 5 segundos. Tenga en cuenta que los controladores Xorg / XFree86 no hacen esto, por lo que una solución posible es ejecutar las aplicaciones CUDA en Linux.

AFAIK no es posible desactivar el temporizador de vigilancia en Windows. La única forma de evitar esto en Windows es usar una segunda tarjeta que no tenga pantallas desplegadas. No tiene que ser un Tesla, pero no debe tener pantallas activas.

Resolve Timeout Detection and Recovery – WINDOWS 7 (32/64 bit)

Cree una clave de registro en Windows para cambiar la configuración de TDR a una cantidad mayor, de modo que Windows permita un retraso mayor antes de que comience el proceso de TDR.

Abre Regedit desde Run o DOS.

En Windows 7 vaya al área de clave de registro correcta para crear la nueva clave:

HKEY_LOCAL_MACHINE> SYSTEM> CurrentControlSet> Control> GraphicsDrivers .

Probablemente habrá una clave llamada DxgKrnlVersion como DWord.

Haga clic con el botón derecho y seleccione para crear una nueva clave REG_DWORD y asígnele el nombre TdrDelay . El valor que se le asigna es el número de segundos antes de que TDR entre en acción – it> actualmente es 2 automáticamente en Windows (aunque el valor de la clave de registro no exista> hasta que lo cree). Asignarlo con un nuevo valor (probé 4 segundos), que dobla el tiempo antes de TDR. Luego reinicia la PC. Debe reiniciar la PC antes de que el valor funcione.

Fuente de Win7 TDR (Driver Timeout Detection & Recovery) También he verificado esto y funciona bien.

Esto no es posible El tiempo de espera está ahí para evitar que los errores en los cálculos ocupen la GPU durante largos períodos de tiempo.

Si usa una tarjeta dedicada para el trabajo de CUDA, el límite de tiempo se levanta. No estoy seguro si esto requiere una tarjeta Tesla, o si se puede usar una GeForce sin monitor conectado.

La solución más básica es elegir un punto en el cálculo en un porcentaje del camino, estoy seguro de que la GPU con la que estoy trabajando es capaz de completarla a tiempo, guardar toda la información de estado y detenerla, y luego comenzar de nuevo.

Actualización: para Linux: Salir de X le permitirá ejecutar aplicaciones CUDA todo el tiempo que desee. No se requiere Tesla (se utilizó un A 9600 para probar esto)

Una cosa a tener en cuenta, sin embargo, es que si X nunca se ingresa, los controladores probablemente no se cargarán y no funcionará.

También parece que para Linux, el simple hecho de que no se muestre ninguna X en el momento también funcionará, por lo que no es necesario salir de X, siempre que la pantalla se muestre en un terminal de pantalla completa que no sea X.

La solución que uso es:

1. Pase toda la información al dispositivo.
2. Ejecute versiones iterativas de algoritmos, donde cada iteración invoca el kernel en la memoria ya almacenada dentro del dispositivo.
3. Finalmente, transfiera la memoria al host solo después de que hayan finalizado todas las iteraciones.

Esto permite controlar las iteraciones desde la CPU (incluida la opción de abortar), sin las costosas transferencias de memoria de host del dispositivo <-> entre iteraciones.

El temporizador de vigilancia solo se aplica a las GPU con una pantalla adjunta.

En Windows, el temporizador es parte de WDDM, es posible modificar la configuración (tiempo de espera, comportamiento al alcanzar el tiempo de espera, etc.) con algunas claves de registro; consulte este artículo de Microsoft para obtener más información.

Es posible desactivar este comportamiento en Linux. Aunque el “perro guardián” tiene un propósito obvio, puede causar algunos resultados muy inesperados al hacer extensos cálculos usando sombreadores / CUDA.

La opción puede alternarse en su configuración de X (probablemente /etc/X11/xorg.conf)

Agregar: la opción “Interactivo” “0” en la sección del dispositivo de su GPU hace el trabajo.

ver la opción de configuración X ‘Interactive’ de CUDA Visual Profiler?

Para detalles sobre la configuración

y

ver ftp://download.nvidia.com/XFree86/Linux-x86/270.41.06/README/xconfigoptions.html#Interactive

Para una descripción del parámetro.