optimisation des performances

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.

Afin d’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 de panneau, etc. – vous obtiendrez le temps total passé dans le pipeline graphique et le temps passé dans 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 est exécuté de manière asynchrone (voir 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’image 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 peuvent rapidement devenir un goulet d’étranglement.

D’autre part, 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. Les courts arrêts d’exécution 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 bidouiller 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 été exécutés. Pour une latence optimisée, fixez-le à VRAI, pour 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 pa ramètre en FAUX. 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 VRAI. En cas de doute, laissez-le à sa valeur par défaut FAUX.
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, ils peuvent être recyclés, 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 ; darktable doit donc estimer. 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 -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. Ceci 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 défini à “vrai”, 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, mais elle a du sens en fonction de votre GPU (même si le GPU est plutôt lent). Dans ce cas, darktable peut en fait gagner du temps lorsque les paramètres du 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é à “module actif” (sa valeur par défaut), qui mettra en cache uniquement l’entrée du module actuellement ciblé.
opencl_micro_nap
Dans un cas idéal vous garderez votre GPU occupé à 100% lors retraitement 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. Pour résoudre ce problème 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 hôte et 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 VRAI indique à darktable d’utiliser un type particulier de tampon intermédiaire pour les transferts de données entre hôte et périphérique. Sur certains périphériques, ceci peut accélérer l’exportation des gros fichiers d’un facteur 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 déformées opencl_use_pinned_memory devrait être laissé à FAUX, pour ces périphériques, sa valeur par défaut.
opencl_building_gpuXXX
Ajoutez manuellement ce paramètre à darktablerc pour ajouter des options de compilation OpenCL supplémentaires pour votre ou vos GPU, où XXX est le nom du GPU. Ces options sont utilisées lors de la compilation des noyaux OpenCL et peuvent être fournies pour le réglage des performances ou pour contourner les bogues. Vous devez supprimer tous les noyaux existants afin de les recompiler avec les nouvelles options. Fournissez une chaîne vide à recompiler sans aucune option. Supprimez entièrement le paramètre pour recompiler avec les options par défaut.

Vous pouvez référencer votre GPU par son ID (par exemple opencl_building_gpu0) ou par son nom canonique (par exemple opencl_building_gpugeforce10606gb). Démarrez darktable avec darktable -d opencl pour trouver votre nom de GPU canonique et les options de compilation par défaut.

Par exemple, les lignes suivantes ajouteraient des options de compilation supplémentaires pour le GPU avec l’ID 0 et pour le GPU nommé “geforce10606gb” :

opencl_building_gpu0=-cl-mad-enable -cl-no-signed-zeros -cl-unsafe-math-optimizations -cl-finite-math-only -cl-fast-relaxed-math
opencl_building_gpugeforce10606gb=-cl-mad-enable -cl-no-signed-zeros

translations