El OpenCL en darktable

He visto que el tema del OpenCL es algo que interesa sobretodo por su rendimiento en darktable. Por ello me he atrevido a trasladar lo que dice el Manual de darktable 3.6 sobre este aspecto del programa.

La tabla de contenido en amarillo nos llevara a la pagina web del manual de darktable. La otra nos lleva a los apartados en el foro

opencl

el trasfondo

El procesamiento de imágenes de alta resolución es una tarea exigente que requiere una computadora moderna. En términos de memoria y potencia de la CPU, sacar lo mejor de una imagen típica de 15, 20 o 25 megapíxeles puede llevar rápidamente a su computadora al límite.

Los requisitos de darktable no son una excepción. Todos los cálculos se realizan en números de coma flotante de 4 x 32 bits. Es más lento que el álgebra de enteros de 8 o 16 bits “ordinaria”, pero elimina todos los problemas de rupturas tonales o pérdida de información.

Se ha realizado una gran cantidad de optimización para hacer darktable lo más rápido posible. Si ejecuta una versión actual de darktable en una computadora moderna, es posible que no note ninguna “lentitud”. Sin embargo, hay condiciones y ciertos módulos en los que sentirá (o escuchará el aullido del ventilador de su CPU) cuánto tiene que luchar su pobre procesador de múltiples núcleos.

Ahí es donde OpenCL entra en juego. OpenCL permite que darktable aproveche el enorme poder de las tarjetas gráficas modernas. La demanda de los jugadores de mundos 3D altamente detallados en los juegos de disparos modernos (así como la minería de criptomonedas) ha fomentado el rápido desarrollo de la GPU. AMD, NVIDIA y compañía tuvieron que poner una enorme potencia de procesamiento en sus GPU para satisfacer estas demandas. El resultado son tarjetas gráficas modernas con GPU altamente paralelizadas que pueden calcular rápidamente superficies y texturas a altas velocidades de cuadro.

¿No eres un jugador y no aprovechas ese poder? Bueno, ¡al menos deberías usarlo en darktable! Para la tarea de cálculos de punto flotante altamente paralelos, las GPU modernas son mucho más rápidas que las CPU. Esto es especialmente cierto cuando desea repetir los mismos pasos de procesamiento millones de veces. Caso de uso típico: procesamiento de imágenes de altos megapíxeles.

cómo funciona opencl

Como puede imaginar, la arquitectura de hardware de las GPU puede variar significativamente. Hay diferentes fabricantes, e incluso diferentes generaciones de GPU del mismo fabricante pueden no ser comparables. Al mismo tiempo, los fabricantes de GPU normalmente no divulgan todos los detalles del hardware de sus productos al público. Una de las consecuencias de esto es la necesidad de usar controladores propietarios bajo Linux, si desea aprovechar al máximo su tarjeta gráfica.

Afortunadamente, un consorcio de la industria liderado por The Khronos Group ha desarrollado una interfaz abierta y estandarizada llamada OpenCL, que permite que su GPU se utilice como un dispositivo de procesamiento numérico. OpenCL ofrece un lenguaje de programación similar a C99 con un fuerte enfoque en la computación paralela. Una aplicación que quiera usar OpenCL necesitará el código fuente OpenCL que entrega a un compilador específico de hardware en tiempo de ejecución. De esta forma, las aplicaciones pueden usar OpenCL en diferentes arquitecturas de GPU (incluso al mismo tiempo). Todos los “secretos” de hardware están ocultos en este compilador y normalmente no son visibles para el usuario (o la aplicación). El código OpenCL compilado se carga en su GPU y, con ciertas llamadas a la API, está listo para realizar cálculos por usted.

activando opencl en darktable

El uso de OpenCL en darktable requiere que su PC esté equipada con una tarjeta gráfica adecuada y que tenga instaladas las bibliotecas necesarias. La mayoría de las tarjetas gráficas modernas de NVIDIA y AMD vienen con soporte completo para OpenCL. El compilador OpenCL normalmente se envía como parte del controlador de gráficos propietario y se usa como una biblioteca dinámica llamada libOpenCL.so . Esta biblioteca debe estar en una carpeta donde la pueda encontrar el enlazador dinámico de su sistema.

Cuando se inicie darktable, primero intentará encontrar y cargar libOpenCL.so y, si tiene éxito, comprobará si la tarjeta gráfica disponible viene con soporte OpenCL. Debe haber una cantidad suficiente de memoria gráfica (1GB +) disponible para que darktable aproveche la GPU. Si esa verificación pasa, darktable intenta configurar su entorno OpenCL: se debe inicializar un contexto de procesamiento, se debe iniciar una canalización de cálculo, se deben leer y compilar los archivos de código fuente OpenCL (la extensión es .cl ) y las rutinas incluidas (Kernels OpenCL) deben estar preparados para los módulos de darktable. Si todo eso se completa con éxito, la preparación está completa.

De forma predeterminada, el soporte de OpenCL está activado en darktable si todos los pasos anteriores fueron exitosos. Si desea desactivarlo, puede hacerlo en preferencias> cpu / gpu / memoria. Este parámetro de configuración aparece atenuado si falla la inicialización de OpenCL.

Puede activar y desactivar la compatibilidad con OpenCL en cualquier momento sin necesidad de reiniciar. Dependiendo del tipo de módulos que esté utilizando, notará el efecto como una aceleración general durante el trabajo interactivo y la exportación. La mayoría de los módulos en darktable pueden aprovechar OpenCL, pero no todos los módulos son lo suficientemente exigentes como para marcar una diferencia notable. Para sentir una diferencia real, use módulos como sombras y luces , enfoque , paso bajo , paso alto o incluso más extremos ecualizador de constraste y reducción de ruido (perfilado) .

Si está interesado en las estadísticas de creación de perfiles, puede iniciar darktable con los parámetros de la línea de comandos -d opencl -d perf . Después de cada ejecución del pixelpipe, se le mostrarán detalles del tiempo de procesamiento de cada módulo más un perfil aún más detallado para todos los kernels OpenCL usados.

Aparte de la aceleración, no debería ver ninguna diferencia en los resultados entre el procesamiento de la CPU y la GPU. Excepto por algunos errores de redondeo, los resultados están diseñados para ser idénticos. Si, por alguna razón, darktable no completa correctamente un cálculo de GPU, normalmente detectará el error y automáticamente (y de forma transparente) recurrirá al procesamiento de la CPU.

configurando opencl

La enorme diversidad de sistemas y las marcadas diferencias entre los proveedores de OpenCL y las versiones de los controladores hace que sea imposible ofrecer una descripción general completa de cómo configurar OpenCL. Solo podemos darle un ejemplo, en este caso para la versión 331.89 del controlador NVIDIA en Ubuntu 14.04. Esperamos que esto le sirva como una introducción básica y le ayude a resolver cualquier problema específico de su configuración.

El principio de flujo de la función OpenCL es así:

`darktable

libOpenCL.so > libnvidia-opencl.so.1 > kernel driver
module(s) > GPU`

  • darktable carga dinámicamente libOpenCL.so – una biblioteca del sistema que debe ser accesible para el cargador dinámico del sistema (ld.so ).
  • libOpenCL.so lee el archivo de información específico del proveedor (/etc/OpenCL/vendors/nvidia.icd ) para encontrar la biblioteca que contiene la implementación de OpenCL específica del proveedor.
  • La implementación de OpenCL específica del proveedor viene como una biblioteca libnvidia-opencl.so.1 (que en nuestro caso es un enlace simbólico a libnvidia-opencl.so.331.89 ).
  • libnvidia-opencl.so.1 necesita comunicarse con los módulos del kernel específicos del proveedor nvidia y nvidia_uvm a través de archivos especiales de dispositivo /dev/nvidia0 , /dev/nvidiactl , y /dev/nvidia-uvm .

Al iniciar el sistema, es necesario crear los archivos especiales del dispositivo necesarios (/dev/nvidia* ). Si esto no sucede en su sistema por defecto, la forma más fácil de configurarlos y asegurarse de que todos los módulos estén cargados es instalando el paquete nvidia-modprobe .

Una cuenta de usuario que necesita hacer uso de OpenCL desde darktable debe tener acceso de lectura/escritura a los archivos especiales del dispositivo de NVIDIA. En algunos sistemas, estos archivos permiten el acceso mundial de lectura y escritura de forma predeterminada, lo que evita problemas de permisos, pero puede ser discutible en términos de seguridad del sistema. Otros sistemas restringen el acceso a un grupo de usuarios, p. ej. “video”. En este caso, su cuenta de usuario debe ser miembro de ese grupo.

En resumen, los paquetes que debían instalarse en este caso específico fueron:

nvidia-331 (331.89-0ubuntu1~xedgers14.04.2)
nvidia-331-dev (331.89-0ubuntu1~xedgers14.04.2)
nvidia-331-uvm (331.89-0ubuntu1~xedgers14.04.2)
nvidia-libopencl1-331 (331.89-0ubuntu1~xedgers14.04.2)
nvidia-modprobe (340.24-1)
nvidia-opencl-dev:amd64 (5.5.22-3ubuntu1)
nvidia-opencl-icd-331 (331.89-0ubuntu1~xedgers14.04.2)
nvidia-settings (340.24-0ubuntu1~xedgers14.04.1)
nvidia-settings-304 (340.24-0ubuntu1~xedgers14.04.1)
nvidia-libopencl1-331 (331.89-0ubuntu1~xedgers14.04.2)
nvidia-opencl-dev:amd64 (5.5.22-3ubuntu1)
nvidia-opencl-icd-331 (331.89-0ubuntu1~xedgers14.04.2)
opencl-headers (1.2-2013.10.23-1)

La lista de módulos del kernel relacionados con NVIDIA según lo informado por lsmod fue:

nvidia
nvidia_uvm

La lista de archivos especiales de dispositivos relacionados con NVIDIA (ls -l /dev/nvidia* ) debería leerse así:

crw-rw-rw- 1 root root 195,   0 Jul 28 21:13 /dev/nvidia0
crw-rw-rw- 1 root root 195, 255 Jul 28 21:13 /dev/nvidiactl
crw-rw-rw- 1 root root 250,   0 Jul 28 21:13 /dev/nvidia-uvm

Tenga en cuenta que los números mayores/menores (por ejemplo, 250/0 para /dev/nvidia-uvm en este ejemplo) pueden variar según su sistema.

posibles problemas y soluciones

darktable detectará automáticamente los errores en tiempo de ejecución de OpenCL. Al detectar un error, volverá a procesar todo en la CPU. Si bien esto ralentizará el procesamiento, no debería afectar el resultado final.

Puede haber varias razones por las que OpenCL puede fallar durante la fase de inicialización. OpenCL depende de los requisitos de hardware y de la presencia de ciertos controladores y bibliotecas. Además, todos estos deben ajustarse en términos de fabricante, modelo y número de revisión. Si algo no encaja (por ejemplo, su controlador de gráficos, cargado como un módulo del kernel, no coincide con la versión de su libOpenCL.so ), es probable que el soporte OpenCL no esté disponible.

En este caso, lo mejor es iniciar darktable desde una consola con darktable -d opencl .

Esto proporcionará resultados de depuración adicionales sobre la inicialización y el uso de OpenCL. Primero, si encuentra una línea que comienza con [opencl_init] FINALLY ... eso debería indicarle si el soporte OpenCL está disponible para usted o no. Si la inicialización falló, mire los mensajes de arriba para cualquier cosa que diga como could not be detected (no se pudo detectar) o could not be created (no se pudo crear). Compruebe si hay alguna pista sobre dónde falló.

A continuación, se muestran algunos casos que se han observado en el pasado:

  • darktable indica que no se detecta ninguna tarjeta gráfica compatible con OpenCL o que la memoria disponible en su GPU es demasiado baja y el dispositivo se descarta. En ese caso, es posible que deba comprar una nueva tarjeta si realmente desea compatibilidad con OpenCL.
  • darktable encuentra su libOpenCL.so pero luego le dice que no pudo obtener una plataforma. Los controladores de NVIDIA a menudo darán el código de error -1001 en este caso. Esto sucede porque libOpenCL.so es solo una biblioteca contenedora. Para el trabajo real, es necesario cargar más bibliotecas específicas de proveedores. Esto ha fallado por alguna razón. Hay una estructura de archivos en /etc/OpenCL en su sistema que libOpenCL.so consulta para encontrar estas bibliotecas. Vea si puede encontrar algo sospechoso allí e intente arreglarlo. A menudo, el cargador dinámico de su sistema no puede encontrar las bibliotecas necesarias. Dar nombres de ruta completos puede ayudar.
  • darktable indica que no se pudo crear un contexto. Esto a menudo indica una discrepancia de versión entre el controlador de gráficos cargado y libOpenCL. Compruebe si le sobraron módulos de kernel o bibliotecas de gráficos de una instalación anterior y tome las medidas adecuadas. En caso de duda, realice una reinstalación limpia de su controlador de gráficos. A veces, inmediatamente después de la actualización de un controlador, el controlador del kernel cargado no coincide con las bibliotecas recién instaladas. En este caso, reinicie su sistema antes de volver a intentarlo.
  • darktable se bloquea durante el inicio. Esto puede suceder si su configuración de OpenCL está completamente rota o si su controlador/biblioteca contiene un error grave. Si no puede solucionarlo, aún puede usar darktable con la opción --disable-opencl , que omitirá todo el paso de inicialización de OpenCL.
  • darktable no puede compilar sus archivos fuente OpenCL en tiempo de ejecución. En este caso, verá una serie de mensajes de error que parecen errores típicos del compilador. Esto podría indicar una incompatibilidad entre su implementación de OpenCL y la interpretación de darktable del estándar. En ese caso, por favor reporte el problema en github y trataremos de ayudarlo. Informe también si observa diferencias significativas entre el procesamiento de una imagen por CPU y GPU.

También existen algunas implementaciones de OpenCL en CPU, que vienen como controladores proporcionados por INTEL o AMD. Hemos observado que no proporcionan ninguna ganancia de velocidad en comparación con nuestro código de CPU optimizado a mano. Por lo tanto, darktable simplemente descarta estos dispositivos por defecto. Este comportamiento se puede cambiar estableciendo la variable de configuración opencl_use_cpu_devices (en$HOME/.config/darktablerc ) en TRUE .

dispositivos amd/ati

Si bien los dispositivos NVIDIA y la mayoría de los dispositivos AMD / ATI modernos a menudo se ejecutan desde el primer momento, hay más que hacer con las tarjetas gráficas AMD / ATI más antiguas, es decir, las anteriores a la serie HD7xxx. Esto comienza con el hecho de que esos dispositivos solo informarán parte de su memoria GPU total a darktable. Para un dispositivo de 1 GB, esto generalmente equivale a solo 512 MB, un valor que darktable en su configuración estándar rechazará como insuficiente. En consecuencia, el dispositivo no se utilizará.

En la web, puede encontrar un consejo para establecer la variable de entorno GPU_MAX_HEAP_SIZE en 100 si esto sucede. De hecho, esto hará que el controlador AMD / ATI informe la memoria instalada completa a darktable. Sin embargo, existe un problema. En muchas (¿la mayoría?) Tarjetas, esto hará que se asignen búferes en su computadora (host) y no en la tarjeta de video. En este caso, todos los accesos a la memoria deberán pasar por el bus PCIe lento. Esto le costará un factor de rendimiento de 10 veces o más y hará que OpenCL sea inútil para usted, especialmente al exportar archivos.

Otra variable de entorno que cambia el comportamiento del controlador es GPU_MAX_ALLOC_PERCENT . Puede establecer esto en 100 para permitir asignaciones de memoria de hasta 1 GB en su tarjeta AMD / ATI. El problema es que esto tiende a hacer que darktable se bloquee tarde o temprano.

Por lo tanto, nuestra recomendación es dejar intacta esta configuración. A menudo, su tarjeta será reconocida con 512 MB de memoria y un tamaño máximo de asignación de 128 MB. Hay tres parámetros de configuración que puede establecer en $HOME/.config/darktable/darktablerc para que todo funcione. Aquí están los detalles:

opencl_memory_requirement

Establezca este parámetro en 500 para que darktable acepte que su memoria gráfica de 512 MB tiene suficiente memoria.

opencl_memory_headroom

Este parámetro controla la cantidad de memoria gráfica (de la informada por su tarjeta) que darktable debe dejar intacta para el uso del controlador y la pantalla. Dado que para los dispositivos AMD / ATI solo podemos obtener la mitad de la RAM disponible de todos modos, es seguro establecer esto en cero para que darktable pueda usar todos los 512 MB.

opencl_avoid_atomics

Las operaciones atómicas en OpenCL son un método especial de sincronización de datos. Solo se utilizan en unos pocos núcleos. Desafortunadamente, algunos (¿la mayoría?) De los dispositivos AMD / ATI son extremadamente lentos en el procesamiento de atómicos. Es mejor procesar los módulos afectados en la CPU en lugar de aceptar una ruta de código de GPU ultra lenta. Por lo tanto, establezca este parámetro en TRUE si experimenta un procesamiento lento de módulos como sombras y luces , monócromo , contraste local , o _mapeo tonal global (obsoleto) _ o si el sistema se congela de forma intermitente.

Estas recomendaciones no se aplican a la serie Radeon HD7xxx más reciente con arquitectura GCN. Además de ser muy rápidos en términos de computación GPU, normalmente se ejecutan desde el primer momento, aunque podría considerar probar algunas de las opciones de optimización del rendimiento que se describen en la siguiente sección.

optimización del rendimiento

Hay una serie de parámetros de configuración en $HOME/.config/darktable/darktablerc que pueden ayudar a ajustar el rendimiento de OpenCL de su sistema. El rendimiento en este contexto significa principalmente la latencia de darktable durante el trabajo interactivo (es decir, cuánto tiempo lleva reprocesar el pixelpipe). Para un flujo de trabajo cómodo, es esencial mantener baja la latencia.

Para obtener información de creación de perfiles, debe iniciar darktable desde una terminal con darktable -d opencl -d perf .

Después de cada reprocesamiento del pixelpipe – causado por cambios en los parámetros del módulo, zoom, panorámica, etc. – verá el tiempo total pasado en el pixelpipe y el tiempo gastado en cada uno de los kernels OpenCL. El valor más confiable es el tiempo total invertido en pixelpipe. Tenga en cuenta que los tiempos dados para cada módulo individual no son confiables cuando se ejecuta OpenCL pixelpipe de forma asíncrona (consulte opencl_async_pixelpipe a continuación).

Para permitir un procesamiento rápido de píxeles con OpenCL, es esencial que mantengamos ocupada la GPU. Cualquier interrupción o un flujo de datos estancado se sumará al tiempo total de procesamiento. Esto es especialmente importante para los pequeños búferes de imágenes que necesitamos manejar durante el trabajo interactivo. Estos se pueden procesar rápidamente con una GPU rápida. Sin embargo, incluso las paradas a corto plazo del pixelpipe pueden convertirse fácilmente en un cuello de botella.

Por otro lado, el rendimiento de darktable durante las exportaciones de archivos se rige más o menos solo por la velocidad de nuestros algoritmos y la potencia de su GPU. Los puestos a corto plazo no tendrán un efecto notable en el tiempo total de una exportación.

darktable viene con una configuración predeterminada que debería ofrecer un rendimiento de GPU decente en la mayoría de los sistemas. Sin embargo, si desea jugar un poco por sí mismo e intentar optimizar las cosas aún más, aquí hay una descripción de los parámetros de configuración relevantes.

opencl_async_pixelpipe

Esta bandera controla la frecuencia con la que darktable bloquea el pixelpipe de OpenCL para obtener un estado de éxito/fracaso de los núcleos que se han ejecutado. Para una latencia óptima, establezca esto en TRUE, de modo que darktable ejecute el pixelpipe de forma asincrónica e intente utilizar la menor cantidad de interrupciones posible. Si experimenta errores de OpenCL como kernels defectuosos, establezca el parámetro en FALSE. darktable interrumpirá después de cada módulo para que pueda aislar más fácilmente el problema. Se han informado problemas con algunas tarjetas AMD / ATI más antiguas, como la HD57xx, que pueden producir una salida confusa si este parámetro se establece en TRUE. En caso de duda, déjelo en su valor predeterminado de FALSO.

opencl_number_event_handles

Los identificadores de eventos se utilizan para que darktable pueda monitorear el éxito / fracaso de los kernels y la información de creación de perfiles, incluso si el pixelpipe se ejecuta de forma asincrónica. El número de controladores de eventos es un recurso limitado de su controlador OpenCL. Seguro que se pueden reciclar, pero hay un número limitado que se puede utilizar al mismo tiempo. Desafortunadamente, no hay forma de averiguar cuáles son los límites de recursos, por lo que darktable debe adivinar. El valor predeterminado de 25 es bastante conservador. Es posible que desee ver si valores más altos como 100 ofrecen un mejor rendimiento de OpenCL. Si su controlador se queda sin identificadores libres, experimentará fallas en los kernels OpenCL con el código de error -5 (CL_OUT_OF_RESOURCES) o incluso fallas o el sistema se congela. Reduzca el número nuevamente si eso sucede. Un valor de 0 impedirá que darktable use cualquier controlador de eventos. Esto evitará que darktable monitoree adecuadamente el éxito de sus núcleos OpenCL, pero ahorra algunos gastos generales del controlador. La consecuencia es que cualquier falla probablemente dará lugar a una salida distorsionada sin que se dé cuenta de darktable. Esto solo se recomienda si está seguro de que su sistema funciona perfectamente. También puede establecer este parámetro en -1, lo que significa que darktable no asume ninguna restricción en el número de controladores de eventos. No se recomienda.

opencl_synch_cache

Este parámetro, si se establece en “true”, forzará a darktable a buscar búferes de imagen de su GPU después de cada módulo y almacenarlos en su caché de pixelpipe. Esta es una operación que consume recursos, pero puede tener sentido dependiendo de su GPU (incluso si la GPU es bastante lenta). En este caso, darktable podría, de hecho, ahorrar algo de tiempo cuando los parámetros del módulo hayan cambiado, ya que puede volver a algún estado intermedio almacenado en caché y reprocesar solo una parte del pixelpipe. En muchos casos, este parámetro debe establecerse en “módulo activo” (el predeterminado), que solo almacenará en caché la entrada del módulo actualmente enfocado.

opencl_micro_nap

En un caso ideal, mantendrá su GPU ocupada al 100% al reprocesar el pixelpipe. Eso es bueno. Por otro lado, es posible que su GPU también sea necesaria para realizar actualizaciones regulares de la GUI. Puede suceder que no quede tiempo suficiente para esta tarea. La consecuencia sería una reacción entrecortada de su GUI al hacer panorámicas, hacer zoom o al mover los controles deslizantes. Para resolver este problema, darktable puede agregar pequeñas siestas en su procesamiento pixelpipe para que la GPU recupere el aliento y realice actividades relacionadas con la GUI. El parámetro opencl_micro_nap controla la duración de estas siestas en microsegundos. Deberá experimentar para encontrar un valor óptimo para su sistema. Los valores de 0, 100, 500 y 1000 son buenos puntos de partida para probar. El valor predeterminado es 1000.

opencl_use_pinned_memory

Durante el proceso de mosaico, es necesario transferir grandes cantidades de memoria entre el host y el dispositivo. En algunos dispositivos (a saber, AMD), las transferencias de memoria directa desde y hacia una región de memoria del host arbitraria pueden suponer una gran penalización en el rendimiento. Esto se nota especialmente al exportar imágenes grandes. Establecer este parámetro de configuración en TRUE le dice a darktable que use un tipo especial de búfer intermedio para las transferencias de datos del dispositivo host. En algunos dispositivos, esto puede acelerar la exportación de archivos grandes en un factor de 2 a 3. Los dispositivos y controladores NVIDIA parecen tener una técnica de transferencia de memoria más eficiente incluso para regiones de memoria arbitrarias. Como pueden no mostrar ninguna ganancia de rendimiento e incluso pueden producir resultados confusos, opencl_use_pinned_memory debe dejarse en su valor predeterminado FALSE para esos dispositivos.

perfil de programación

darktable puede usar la CPU y una o varias GPU compatibles con OpenCL. Dependiendo del rendimiento relativo de estos dispositivos, los usuarios pueden elegir entre ciertos perfiles de programación para optimizar el rendimiento. Esto se logra estableciendo el parámetro de configuración preferencias> cpu / gpu / memoria> perfil de programación OpenCL, que ofrece las siguientes opciones:

default

Si se encuentra una GPU compatible con OpenCL, darktable la usa para procesar la vista de imagen central mientras la ventana de vista previa de navegación se procesa en la CPU en paralelo. Esta es la configuración preferida para sistemas con una CPU razonablemente rápida y una GPU moderadamente rápida. La asignación exacta de dispositivos a los distintos tipos de pixelpipe se puede ajustar con el parámetro de configuración “opencl_device_priority” (vea múltiples dispositivos).

very fast GPU

Con este perfil de programación, darktable procesa secuencialmente la vista de la imagen central y la ventana de vista previa en la GPU. Esta es la configuración preferida para sistemas con una GPU que supera con creces a la CPU.

multiple GPUs

Esta configuración se dirige a sistemas con varias GPU cuyo rendimiento relativo no difiere significativamente. Siempre que se inicia un trabajo de procesamiento, darktable utiliza cualquier GPU inactiva actualmente, pero no la CPU. Los usuarios de sistemas con una variedad de GPU necesitarán un mejor control de su prioridad relativa. Sería mejor que seleccionaran el perfil “predeterminado” y ajustaran su sistema con el parámetro de configuración “opencl_device_priority” (consulte múltiples dispositivos).

En la primera puesta en marcha o después de cualquier cambio detectado en la configuración de la GPU de su sistema, darktable intenta identificar el perfil más adecuado para usted. Puede cambiarlo en cualquier momento en preferencias> cpu / gpu / memoria.

múltiples dispositivos

La programación de dispositivos OpenCL se puede optimizar en la mayoría de los sistemas mediante la configuración del “perfil de programación OpenCL”. Sin embargo, si su sistema está equipado con más de una GPU, es posible que desee establecer manualmente la prioridad relativa del dispositivo. Para hacer esto, debe seleccionar el perfil de programación “predeterminado” y cambiar la configuración en el parámetro de configuración “opencl_device_priority”.

Es importante comprender cómo usa darktable los dispositivos OpenCL. Cada secuencia de procesamiento de una imagen, para convertir una entrada en la salida final utilizando una pila de historial, se ejecuta en un pixelpipe. Hay cuatro tipos diferentes de pixelpipe en darktable. Un tipo es responsable de procesar la vista de la imagen central (o vista completa) en el modo de cuarto oscuro, otro pixelpipe procesa la imagen de vista previa (ventana de navegación). Puede haber uno de cada uno de estos dos pixelpipes ejecutándose en cualquier momento, con los pixelpipes completos y de vista previa ejecutándose en paralelo. Además, puede haber varios píxeles paralelos que realizan exportaciones de archivos, así como varios píxeles paralelos que generan miniaturas. Si hay un dispositivo OpenCL disponible, darktable lo asigna dinámicamente a un pixelpipe específico para una ejecución y luego lo libera.

La demanda computacional varía significativamente según el tipo de pixelpipe que se esté ejecutando. La imagen de vista previa y las miniaturas son de baja resolución y se pueden procesar rápidamente, mientras que procesar la vista de la imagen central es más exigente. Un pixelpipe de exportación completo es aún más exigente.

El parámetro de configuración “opencl \ _device \ _priority” contiene una cadena con la siguiente estructura: a,b,c.../k,l,m.../o,p,q.../x,y,z... . Cada letra representa un dispositivo OpenCL específico. Hay cuatro campos en la cadena de parámetros separados por una barra, cada uno representando un tipo de pixelpipe. a,b,c... define los dispositivos que pueden procesar el pixelpipe (completo) de la imagen central. Asimismo, los dispositivos k,l,m... pueden procesar el pixelpipe de vista previa, los dispositivos o,p,q... los pixelpipes de exportación y finalmente los dispositivos x,y,z... los pixelpipes en miniatura. Un campo vacío significa que ningún dispositivo OpenCL puede servir este tipo de pixelpipe.

darktable tiene un sistema de numeración interno, mediante el cual el primer dispositivo OpenCL disponible recibe el número 0. Todos los demás dispositivos se numeran consecutivamente. Este número, junto con el nombre del dispositivo, se muestra cuando inicia darktable con darktable -d opencl . Puede especificar un dispositivo por número o por nombre (las mayúsculas/minúsculas y los espacios en blanco no importan). Si tiene más de un dispositivo con el mismo nombre, debe usar los números de dispositivo para diferenciarlos.

Un especificador de dispositivo puede tener como prefijo un signo de exclamación ! , En cuyo caso el dispositivo se excluye del procesamiento de un pixelpipe determinado. También puede usar un asterisco * como comodín, que representa todos los dispositivos que no se mencionaron explícitamente anteriormente en ese grupo.

El orden de secuencia dentro de un grupo es importante – darktable leerá la lista de izquierda a derecha y cada vez que intente asignar un dispositivo OpenCL a un pixelpipe, escaneará los dispositivos en ese orden, tomando el primer dispositivo libre que encuentre.

Si un proceso de pixelpipe está a punto de iniciarse y todas las GPU del grupo correspondiente están ocupadas, darktable procesa automáticamente la imagen en la CPU de forma predeterminada. Puede imponer el procesamiento de la GPU prefijando la lista de GPU permitidas con un signo más “+”. En este caso, darktable no utilizará la CPU, sino que suspenderá el procesamiento hasta que esté disponible el siguiente dispositivo OpenCL permitido.

el ajuste por defecto de darktable para “opencl_device_priority” es */!0,*/*/* .

Cualquier dispositivo OpenCL detectado puede procesar la imagen de la vista central. El primer dispositivo OpenCL (0) no puede procesar el pixelpipe de vista previa. Como consecuencia, si solo hay una GPU disponible en su sistema, el pixelpipe de vista previa siempre se procesará en la CPU, manteniendo su única GPU exclusivamente para la vista de imagen central más exigente. Esta es una configuración razonable para la mayoría de los sistemas. No se aplican tales restricciones a la exportación y las miniaturas de píxeles.

El valor predeterminado es una buena opción si solo tiene un dispositivo. Si tiene varios dispositivos, constituye un punto de partida razonable. Sin embargo, como sus dispositivos pueden tener niveles bastante diferentes de potencia de procesamiento, tiene sentido invertir algo de tiempo en optimizar su lista de prioridades.

Aquí hay un ejemplo. Supongamos que tenemos un sistema con dos dispositivos, una Radeon HD7950 rápida y una GeForce GTS450 más antigua y lenta. darktable (comenzado con darktable -d opencl ) reportará los siguientes dispositivos:

[opencl_init] successfully initialized.
[opencl_init] here are the internal numbers and names of
        
OpenCL devices available to darktable:
[opencl_init]   0       'GeForce GTS 450'
[opencl_init]   1       'Tahiti'
[opencl_init] FINALLY: opencl is AVAILABLE on this system.

Aquí, la GeForce GTS 450 se detecta como el primer dispositivo y la Radeon HD7950 (‘Tahití’) como el segundo. Este orden normalmente no cambiará a menos que se modifique la configuración del hardware o del controlador, pero es mejor usar nombres de dispositivos en lugar de números para estar seguro.

Dado que GTS450 es más lenta que HD7950, un “opencl_device_priority” optimizado podría ser: !GeForce GTS450,*/!Tahiti,*/Tahiti,*/Tahiti,* .

El GTS450 está explícitamente excluido del procesamiento del pixelpipe de la imagen central; esto está reservado para “todos” los demás dispositivos (es decir, el HD7950 / Tahiti). Por el contrario, para el pixelpipe de vista previa, se excluye el Tahiti, por lo que solo el GTS450 puede realizar el trabajo.

Para la exportación de archivos y la generación de miniaturas queremos que todos se pongan manos a la obra. Sin embargo, darktable debería comprobar primero si el dispositivo Tahiti está libre, porque es más rápido. Si no está libre, se verifican todos los demás dispositivos, de hecho solo el GTS450.

opencl sigue sin funcionar para mí

Como se ha mencionado, los sistemas OpenCL vienen con una gran variedad de configuraciones: diferentes fabricantes y modelos de GPU, diferentes cantidades de memoria de GPU, diferentes controladores, diferentes distribuciones, etc.

Muchos de los problemas potenciales solo aparecerán con combinaciones muy específicas de estos factores. Como los desarrolladores de darktable solo tienen acceso a una pequeña fracción de estas variaciones, comprenda que es posible que no podamos solucionar su problema específico. No hay mucho que podamos hacer si no podemos reproducir su problema.

Si nada más ayuda, la mejor opción probablemente sea comenzar darktable con

darktable --disable-opencl

Al final, no hay nada en darktable que solo se ejecute en GPU. No dejes que la falta de OpenCL te desanime: ¡el código de CPU de darktable también está altamente optimizado para el rendimiento!

4 Me gusta

Muchas gracias, por el trabajo.

SAludos.

En mi caso y debido a que la gráfica es demasiado nuevo no puedo activar opencl en el portátil. De todas formas, después de probarlo en otro pc con una Amd 5500 no veo mucha diferencia de rendimiento y lo que me he encontrado es con algunos problemas de gestión de la imagen. Así que de momento Darktable sin opencl es mi opción preferida.

Ya sabes que tengo tu opinión como referencia, y que tengo ese amd entre ceja y ceja, pero si que es cierto que si exportas cantidad de imágenes el openCl si que se nota. Lo he probado, con mi portátil.
Aunque todo depende del grado de paciencia que uno soporte. Yo podría vivir sin la gráfica dedicada y con ese Slimbook :joy: