darktable page lede image
darktable page lede image

Optimisation des performances OpenCL

10.2.7. Optimisation des performances OpenCL

Certains paramètres de configuration dans $HOME/.config/darktable/darktablerc permettent d’ajuster finement les performances OpenCL de votre système. Performances, dans ce contexte signifie principalement la latence de darktable lors du travail interactif. Par exemple le temps qu'il faut pour retraiter votre pipeline graphique. Afin d’avoir un flux de travail confortable, il est essentiel de maintenir une faible latence.

De manière à obtenir des informations de profilage, démarrez darktable depuis un terminal avec

darktable -d opencl -d perf

Après chaque retraitement du pipeline graphique – provoqué par un changement de paramètre de module, un zoom, un déplacement latéral, etc. – vous obtiendrez le temps total et le temps de chacun des noyaux OpenCL. La valeur la plus fiable est le temps passé dans le pipeline graphique. Veuillez noter que les temps indiqués pour chaque module individuel sont imprécis lorsque le pipeline graphique OpenCL tourne de manière asynchrone (voyez opencl_async_pixelpipe ci-dessous).

Afin de permettre un traitement rapide du pipeline graphique avec OpenCL, il est essentiel de maintenir le GPU occupé. Toute interruption ou flux de données discontinu augmentera le temps de traitement total. Ceci est particulièrement important pour les petits tampons d’images que nous devons gérer rapidement lors du travail interactif. Ils peuvent être traités rapidement par un GPU rapide. Cependant, même les interruptions courtes du pipeline graphique deviendront rapidement un goulet d’étranglement.

D’un autre côté, les performances de darktable lors de l’exportation de fichiers ne sont plus ou moins influencées que par la vitesse de nos algorithmes et la puissance de votre GPU. Des ralentissements à court terme n'ont pas d’influence sur la durée totale de l’exportation.

Le paramétrage par défaut de darktable devrait donner des performances GPU correctes sur la plupart des systèmes. Cependant, si vous désirez tripoter un peu afin d’essayer d’améliorer les choses, voici une description des paramètres de configuration appropriés.

opencl_async_pixelpipe

Cet indicateur booléen contrôle la fréquence de blocage du pipeline graphique OpenCL et récupère un état succès/échec de tous les noyaux ayant tourné. Pour une latence optimisée, fixez-le à TRUE, de manière à ce que darktable traite le pipeline graphique de manière synchrone et essaie d'utiliser aussi peu d’interruptions que possible. Si vous rencontrez des erreurs OpenCL, comme des échecs de noyaux, changez ce paramètre en FALSE. darktable va alors s’interrompre après chaque module ainsi vous pourrez isoler le problème plus facilement. Des problèmes ont été signalés avec certaines cartes ATI/AMD anciennes comme les HD57xx, qui peuvent produire une sortie corrompue si ce paramètre a la valeur TRUE. En cas de doute, laissez-le à sa valeur par défaut FALSE.

opencl_number_event_handles

Des gestionnaires d’événements sont utilisés de manière à pouvoir surveiller le succès ou l’échec des noyaux et pour obtenir des informations de profilage même si le pipeline graphique tourne de manière asynchrone. Le nombre de gestionnaires d’événements est une ressource limitée de votre pilote OpenCL. Bien entendu, nous pouvons les recycler, mais il n'y en a qu'un certain nombre qui puissent être utilisés simultanément. Malheureusement, il n'y a aucun moyen de savoir quelles sont les limites de ressources ; il nous faut donc deviner. Notre valeur 25 par défaut est assez prudente. Vous pouvez essayer de voir si des valeurs plus importantes comme 100 donnent de meilleures performances OpenCL. Si votre pilote n'a pas assez de gestionnaires libres, vous aurez des échecs de noyaux OpenCL avec le code erreur « -5 (CL_OUT_OF_RESOURCES) » ou même des plantages ou un système figé, réduisez alors ce nombre. Une valeur 0 interdira à darktable d’utiliser un quelconque gestionnaire d’événements ce qui empêchera darktable de surveiller correctement le succès de vos noyaux OpenCL mais évitera une certaine surcharge des pilotes. Les conséquences sont qu'un échec conduira probablement à une sortie corrompue sans notification de darktable ; ce n'est recommandé que si vous êtes certain que votre système tourne solide comme un roc. Vous pouvez aussi fixer ce paramètre à -1, ce qui signifie que darktable supposera qu'il n'y a aucune restriction du nombre de gestionnaires d’événements, ceci n'est pas recommandé.

opencl_synch_cache

Ce paramètre, s’il est configuré à TRUE, forcera darktable à aller chercher, après chaque module, les tampons d’image depuis votre GPU et à les enregistrer dans le cache du pipeline graphique. C'est une opération qui consomme beaucoup de ressources. Elle n'est intéressante que si vous avez un GPU plutôt lent. Dans ce cas, darktable peut en fait gagner un peu de temps lorsque les paramètres de ce module ont été modifiés. Car il peut revenir à des états antérieurs mis en cache et retraiter uniquement une partie du pipeline graphique. Dans la plupart des cas, ce paramètre peut être laissé à FALSE ( sa valeur par défaut).

opencl_micro_nap

Dans le cas idéal votre GPU tournera à 100% en reprenant le traitement du pipeline graphique. Ceci est une bonne chose. D’autre part votre GPU est aussi nécessaire pour effectuer régulièrement des mises à jour de l’interface. Il peut arriver qu'il ne reste plus assez de temps pour cette tâche. En conséquence, vous aurez un affichage saccadé lors des défilements, des zooms et des déplacements des curseurs. darktable peut ajouter des petits instants de repos dans le traitement de son pipeline graphique pour laisser le GPU respirer un peu et faire des tâches liées à la gestion de l’interface graphique. Le paramètre OpenCL opencl_micro_nap contrôle la durée en microsecondes de ces instants de repos. Vous devrez faire des essais afin de trouver la valeur optimum pour votre système. Des valeurs 0, 100, 500 et 1000 sont des bons points de départ à essayer. La valeur par défaut est de 1000.

opencl_use_pinned_memory

Lors du tuilage, d’énormes quantités de mémoire doivent être transférées entre l’hôte et le périphérique. Sur certains périphériques (à savoir AMD), les transferts directs de mémoire vers et depuis une région arbitraire de la mémoire de l’hôte peuvent entraîner une perte très importante de performances. On peut le remarquer particulièrement lors de l’exportation de grosses images. Positionner ce paramètre de configuration à TRUE indique à darktable d’utiliser un type particulier de tampon intermédiaire pour les transferts de données entre l’hôte et le périphérique. Sur certains périphériques, ceci peut accélérer l’exportation des gros fichiers d’un facteur de 2 ou 3. Les périphériques et les pilotes NVIDIA semblent avoir une technique de transfert plus efficace, même pour des régions arbitraires de la mémoire. Comme ils peuvent ne pas montrer de gain de performance et même produire des sorties médiocres opencl_use_pinned_memory devrait être laissé, pour ces périphériques, à sa valeur par défaut FALSE .