Mémoire et optimisation des performances

🔗Besoins en mémoire

Le traitement d’une image RAW dans darktable nécessite une grande quantité de mémoire système. Un simple calcul clarifiera ceci : darktable utilise une cellule en virgule flottante de 4x32 bits pour stocker chaque pixel d’une image, ce qui signifie que pour une image de 20 mégapixels il faudra environ 300 Mo de mémoire uniquement pour stocker les données de l’image. Afin de traiter réellement cette image via un module donné, darktable a besoin d’au moins deux tampons (entrée et sortie) de cette taille, des modules plus complexes nécessitant potentiellement plusieurs tampons supplémentaires pour les données intermédiaires. Sans optimisation, entre 600 Mo et 3 Go de mémoire peuvent être nécessaires pour stocker et traiter les données de l’image pendant l’exécution du pipeline graphique. En plus de cela il y a en mémoire le segment de code de darktable, le code et les données de toutes les bibliothèques système liées dynamiquement, ainsi que d’autres tampons que darktable utilise pour stocker les états intermédiaires (cache) pour un accès rapide pendant le travail interactif.

Dans l’ensemble, pour fonctionner, darktable a besoin d’au moins 4 Go de RAM physique et de 4 à 8 Go d’espace de swap supplémentaire, mais plus vous aurez de mémoire mieux il fonctionnera.

En plus de s’exécuter sur votre CPU, de nombreux modules de darktable ont aussi des implémentations OpenCL qui peuvent pleinement tirer parti du traitement parallèle offert par votre carte graphique (GPU). Et, plus vous aurez de mémoire GPU, meilleures seront les performances de darktable.

🔗Tuilage

Si darktable ne dispose pas de suffisamment de mémoire pour traiter en une seule fois l’intégralité de l’image, les modules peuvent choisir d’utiliser une stratégie de tuilage, dans laquelle l’image est divisée en parties plus petites (tuiles) qui sont traitées indépendamment, puis rassemblées à la fin du traitement. Bien que cela permette de traiter les images avec une empreinte mémoire beaucoup plus petite, cela présente également certains inconvénients :

le tuilage est toujours plus lent – parfois jusqu’à 10 fois plus lent, bien que pour certains modules, la différence soit négligeable,
le tuilage est techniquement impossible pour certains modules en raison de la nature des algorithmes sous-jacents

Pour la plupart des systèmes, le tuilage ne sera probablement utilisé que pour les exportations d’images en taille réelle, le travail interactif dans la Chambre noire étant traité de manière plus efficace. Pour de meilleures performances (et éviter les modes de tuilage), vous devriez exécuter darktable simultanément avec le moins d’autres applications que possible et le configurer pour utiliser autant de mémoire système et GPU que possible.

🔗Optimisation des performances

There are a number of configuration parameters that can help you to fine-tune your system’s performance. Some of these parameters are available in preferences > processing > CPU / memory and others need to be modified directly in darktable’s configuration file (found in $HOME/.config/darktable/darktablerc).

Cette section fournit des conseils sur la façon d’ajuster ces réglages.

🔗Comment tester

Afin de déterminer dans quelle mesure vos modifications améliorent (ou non) les performances de darktable, vous aurez besoin d’un ou plusieurs exemples d’images à tester, et d’une méthode d’évaluation de la vitesse du pipeline graphique.

Pour les exemples d’images, il est conseillé d’utiliser certains des modules les plus intensifs, tels que Diffusion ou netteté ou [Réduction bruit (profil)](../ module-reference/processing-modules/denoise-profiled.md). Les exportations sont susceptibles d’avoir des durées plus cohérentes et comparables entre les exécutions que le travail interactif (et pousseront également davantage votre matériel).

Afin d’obtenir des informations de profilage, démarrez darktable depuis un terminal avec la commande darktable -d opencl -d perf. Si vous souhaitez plus d’informations sur le tuilage, vous utiliserez darktable -d opencl -d tiling -d perf.

Chaque fois que le pipeline graphique est exécuté (lorsque vous modifiez les paramètres d’un module, le zoom, le panoramique, l’exportation, etc.), vous verrez (dans votre session de terminal) 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 total passé dans le pipeline graphique et vous devez l’utiliser pour évaluer vos modifications.

Remarque : les durées indiquées pour chaque module individuel ne sont pas fiables lors de l’exécution asynchrone du pipeline OpenCL (voir mode asynchrone ci-dessous).

Afin de permettre un traitement efficace du pipeline graphique avec OpenCL, il est essentiel de maintenir le GPU occupé. Des interruptions ou un flux de données bloqué augmenteront le temps de traitement total. Ceci est particulièrement important, lors du travail interactif, pour les petits tampons d’image utilisés qui 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 sont plus ou moins régies uniquement par la vitesse des algorithmes et la puissance de votre GPU. Les courts arrêts d’exécution n’auront pas d’effet notable sur la durée totale d’une exportation.

🔗Ressources de darktable

The “darktable resources” preference (in preferences > processing > CPU / memory) allows you to choose between four different approaches to allocating your system’s resources to darktable. Each of these options controls multiple individual parameters, which are defined independently in $HOME/.config/darktable/darktablerc. You can amend any of these directly within your darktablerc file to tweak values for your selected resource level, though you cannot add your own custom resource level to the preferences drop-down.

Remarque : le mode Sans restriction prend tout. Cela peut sembler être le meilleur réglage à utiliser, mais, en particulier lors de l’exportation de grandes images de haute qualité, l’utilisation illimitée de la mémoire peut provoquer des échanges, ce qui peut conduire à des performances réduites ou à la destruction silencieuse de darktable par votre système d’exploitation.

Chacune des quatre options Ressources de darktable est définie comme suit :

ressource_défaut=512 8 128 700
ressource_importantes=700 16 128 900
ressource_faibles=128 4 64 400
ressource_sans restriction=16384 1024 128 900

Plus généralement, celles-ci peuvent être représentées par ressource_niveau=a b c d où a - d sont définis comme suit :

a. Mémoire système pour le traitement des modules: La quantité maximale de mémoire système rendue disponible pour le traitement du module. Des valeurs inférieures forcent les modules gourmands en mémoire à traiter les images avec un nombre croissant de tuiles. Ce nombre est une fraction de la quantité totale de mémoire système, divisée par 1024. Par exemple, sur un système avec 16 Go de mémoire système totale, la quantité attribuée par ressource_défaut (en Go) est 16 * 512 / 1024, ou 8 Go de RAM système.
b. Taille minimale du tampon de tuilage: taille minimale d’un seul tampon de tuilage, exprimée de la même manière sous forme de fraction de la mémoire système totale. Par exemple, sur un système avec 16 Go de mémoire système totale, la quantité attribuée par ressource_défaut (en Go) est de 16 * 8 / 1024, soit 0,125 Go de RAM système. Notez que ce paramètre est en grande partie historique et n’est plus d’une grande utilité pratique – il est conseillé de le laisser à sa valeur par défaut.
c. Mémoire cache des miniatures: La quantité de mémoire à utiliser pour le cache des miniatures. Encore une fois, cela est exprimé comme une fraction de la mémoire système totale et, sur un système de 16 Go, la quantité attribuée par ressource_défaut est 16 * 128/1024, soit 2 Go de RAM système.
d. Mémoire OpenCL (GPU): La quantité maximale de mémoire GPU mise à disposition pour le traitement des modules. Comme pour la mémoire système, des valeurs plus faibles obligeront les modules gourmands en mémoire à traiter des images avec un nombre croissant de tuiles. La mémoire de votre GPU sera probablement utilisée par d’autres applications sur votre système. Cependant, contrairement à la mémoire système, votre GPU n’est pas en mesure de profiter des fichiers d’échange et il est impossible pour darktable de connaître la quantité de mémoire disponible à un moment donné. Si ce paramètre est trop élevé, darktable pourrait être forcé de revenir au traitement par le CPU (qui sera significativement plus lent, mais stable et avec des données correctement traitées) ou darktable pourrait se planter et même rendre votre système inutilisable. Pour cette raison, la fraction de paramètres de la mémoire du GPU inclut également une marge supplémentaire de 600 Mo pour tenter d’éviter une sur-allocation de la mémoire. Par exemple, sur un GPU avec 6GB de mémoire, darktable utilisera approximativement (6 - 0.6) * 700 / 1024, ou 3.5GB de RAM GPU en utilisant le niveau ressource_défaut.

En plus des niveaux de ressources présentés dans l’interface utilisateur, les options suivantes peuvent être définies via la ligne de commande (par exemple, darktable --conf resourcelevel="notebook"). Ces modes sont conçus pour déboguer les problèmes de tuilage et tester les performances des systèmes communs sur des machines de développement plus grandes. Les options suivantes sont fournies :

“mini” (1 Go de RAM, 2 Mo de tampon unique, 128 Mo de cache pour les miniatures, 200 Mo de mémoire OpenCL)
“notebook” (4 Go de RAM, 32 Mo de tampon unique, 512 Mo de cache pour les miniatures, 1 Go de mémoire OpenCL)
“reference” (8 Go de RAM, 32 Mo de tampon unique, 512 Mo de cache pour les miniatures, 2 Go de mémoire OpenCL)

🔗Réglage de l’utilisation de la mémoire GPU

Si vous souhaitez utiliser au maximum la mémoire de votre GPU pour OpenCL, vous avez trois options :

Choisissez le niveau de ressource Importantes. Pour une carte de 6 Go, cela utilisera environ 5 Go de mémoire GPU, laissant 1 Go pour le reste de votre système. (recommandé)
Modifiez darktablerc pour augmenter le dernier nombre (la fraction de mémoire OpenCL) pour le niveau de ressource sélectionné. Par exemple, augmenter la fraction de mémoire OpenCL à 950 augmenterait la mémoire disponible sur un GPU de 6 Go à environ 5,3 Go. (absolument déconseillé)
Set preferences > processing > OpenCL > use all device memory to “on”, which will use all of your device’s memory, less a 600MB headroom. Please see the section below for “per device setting” of headroom.

🔗Comparaison entre OpenCL et le tuilage CPU

Dans la plupart des cas, l’exécution d’un module de traitement sur un GPU puissant (utiliser le code OpenCL) est significativement plus rapide que l’exécution du même module en utilisant le code CPU. Cependant, de nombreux utilisateurs disposent de CPU multicœurs rapides avec une grande quantité de mémoire vive, mais par contre, d’un GPU aux capacités nettement inférieures (typiquement, des processeurs graphiques intégrés avec de petites quantités de mémoire dédiée). L’utilisation du code OpenCL dans ces cas peut conduire à un tuilage excessif. Il est souvent préférable d’exécuter un module sans tuilage en utilisant le code du CPU plutôt que d’essayer d’utiliser OpenCL avec un tuilage important.

Pendant le traitement du pipeline, darktable tente de déterminer quel mode sera le meilleur pour un module donné en estimant les charges de travail attendues pour les codes OpenCL et CPU. Dans la plupart des cas, il préférera le code OpenCL, même si cela signifie que l’image est tuilée, car OpenCL est généralement beaucoup plus rapide que l’exécution du code CPU (souvent jusqu’à 10 fois plus rapide s’il s’agit d’une carte dédiée).

Si le ratio des charges de travail estimées (CPU vs GPU) est plus grand que l’advantage int (voir ci-dessous), darktable utilisera le CPU pour traiter ce module, sinon il utilisera le GPU.

🔗Configuration OpenCL spécifique au périphérique

Le paramétrage par défaut de darktable devrait fournir des performances GPU raisonnables sur la plupart des systèmes. Cependant, si vous souhaitez essayer d’optimiser davantage les choses, cette section décrit les paramètres de configuration appropriés (tous définis dans votre fichier darktablerc).

La plupart des options liées à OpenCL sont gérées avec une stratégie par périphérique. Le paramètre de configuration de chaque périphérique ressemble à :

cldevice_v5_nvidiacudaquadrortx4000=0 250 0 16 16 128 0 0 0.000 0.000 0.500

ou, plus généralement

cldevice_version_canonicalname=a b c d e f g h i j k

Une entrée sera automatiquement créée dans darktablerc pour chaque périphérique nouvellement détecté lorsque vous lancerez darktable pour la première fois, avec le nom de périphérique canonique correct et le numéro de version. Les paramètres a - k sont définis comme suit et peuvent être modifiés manuellement :

a. Éviter les opérations atomiques (défaut): 1 = éviter les opérations atomiques ; 0 = les utiliser; Les opérations atomiques dans OpenCL sont des méthodes spéciales de synchronisation des données et ne sont utilisées que dans quelques modules. Malheureusement, certains anciens périphériques AMD/ATI sont extrêmement lents dans le traitement des opérations atomiques et, sur ces cartes, il est préférable de traiter les modules concernés sur le CPU plutôt que d’utiliser du code GPU ultra-lent. Définissez ce paramètre sur 1 si vous constatez un traitement lent dans des modules tels que Ombres et hautes lumières, [Monochrome](../. ./module-reference/processing-modules/monochrome.md), Contraste local, ou [Tone mapping (déprécié)](. ./../module-reference/processing-modules/global-tonemap) ou si vous obtenez des blocages intermittents du système. Veuillez noter que cela ne devrait affecter aucune carte fabriquée depuis 2015.
b. Micro nap: par défaut 250; Dans un cas idéal, vous garderez votre GPU occupé à 100 % lors du traitement du pipeline graphique. Cependant, si votre GPU doit également mettre à jour votre écran et que darktable l’utilise à 100 %, il se peut qu’il ne reste pas suffisamment de temps pour cette tâche. Cela se manifeste généralement par des mises à jour saccadées de l’interface graphique lors du panoramique, du zoom ou du déplacement des curseurs. Pour résoudre ce problème, darktable peut ajouter de petites pauses dans son traitement du pipeline graphique afin que le GPU puisse reprendre son souffle et effectuer des activités liées à l’interface graphique. Le paramètre Micro nap contrôle la durée de ces pauses en microsecondes.; Sur tous les systèmes actuels, la valeur par défaut est sûre. Si vous utilisez plusieurs appareils ou si vous n’utilisez pas votre GPU discret pour dessiner sur votre écran, cette valeur peut être fixée à 0 pour tous les appareils qui ne sont pas des ordinateurs de bureau, ce qui permet d’améliorer les performances.
c. Mémoire épinglée: 0 = utiliser l’interface utilisateur pour sélectionner le mode ; 1 = désactiver le transfert épinglé (par défaut) ; 2 = désactiver1 = appliquer le transfert épinglé.; Pendant le 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, les transferts directs de mémoire vers et depuis une région arbitraire de la mémoire hôte peuvent entraîner une forte baisse des performances. Ceci est particulièrement visible lors de l’exportation de grandes images avec des cartes graphiques plus petites ou lors de l’utilisation de modules plus récents tels que Diffusion ou netteté ou le mode Laplaciens guidés dans Reconstruire hautes lumières.; Il n’existe pas de méthode sûre ou de règle générale pour prédire si ce paramètre apportera ou non un avantage en termes de performances, vous devrez donc expérimenter par vous-même. Cependant, la probabilité que le transfert épinglé conduise à une amélioration est assez faible si votre carte a été fabriquée après 2015.
d. Clroundup wh / e. clroundup ht: Ces paramètres doivent être laissés à cette valeur par défaut – les tests n’ont montré aucun avantage à utiliser d’autres valeurs.
f. Nombre de descripteurs d’événement: par défaut 128; Les gestionnaires d’événements sont utilisés par darktable pour surveiller les succès/échecs des noyaux et fournir des informations de profilage même si le pipeline graphique est exécuté de manière asynchrone. Le nombre de gestionnaires d’événements est une ressource limitée de votre pilote OpenCL - bien qu’ils puissent être recyclés, il y a un nombre limité qui peut être utilisé en même temps. Malheureusement, il n’y a aucun moyen de savoir quelles sont les limites de ressources pour un périphérique donné (ceci est dû au fait que darktable utilise l’API OpenCL V.1.2 pour supporter toutes les plateformes), donc darktable utilise une estimation conservatrice de 128 par défaut. Sur la plupart des périphériques et pilotes actuels, vous pouvez vous attendre à ce qu’un nombre allant jusqu’à 1024 soit sûr (à coup sûr si votre pilote / carte signale OpenCL V.2.0 ou plus), ce qui conduit à une performance OpenCL légèrement meilleure. Si votre pilote n’a plus de capacités libres, vous aurez des noyaux OpenCL défaillants avec le message d’erreur CL_OUT_OF_RESOURCES ou même des plantages ou des gels du système (si vous rencontrez ce problème, veuillez ouvrir une question sur github).; Une valeur de 0 empêchera darktable d’utiliser des descripteurs d’événement. Cela empêchera darktable de surveiller correctement le succès de vos noyaux OpenCL, mais économisera une certaine surcharge du pilote, ce qui améliorera les performances (moins de 5%). La conséquence est que toute défaillance entraînera probablement une sortie confuse sans que darktable ne s’en aperçoive. Ceci n’est recommandé que si vous savez avec certitude que votre système fonctionne parfaitement.
g. Mode asynchrone: 1 = utiliser le mode asynchrone ; 0 = ne pas l’utiliser (défaut); Cet indicateur contrôle la fréquence à laquelle darktable bloque le pipeline OpenCL pour obtenir un statut de succès/échec des noyaux qui ont été exécutés. Pour une latence optimale, réglez-le sur 1, de sorte que darktable exécute le pipeline de manière asynchrone et essaie d’utiliser le moins d’interruptions/événements possible. Si vous rencontrez des erreurs OpenCL telles que des noyaux défaillants, réinitialisez le paramètre sur 0 . Cela entraînera l’interruption de darktable après chaque module afin que vous puissiez isoler plus facilement tout problème. Des problèmes ont été signalés avec certaines cartes AMD/ATI plus anciennes (comme la HD57xx) qui peuvent produire une sortie brouillée si ce paramètre est défini sur 1. En cas de doute, laissez-le à sa valeur par défaut de 0.
h. Désactiver le périphérique: 0 = activer le périphérique ; 1 = désactiver le périphérique; Si darktable détecte un périphérique défectueux, il le marquera automatiquement comme tel en définissant ce paramètre sur 1. Si vous avez un périphérique qui signale de nombreuses erreurs, vous pouvez le désactiver manuellement en définissant ce champ sur 1. Si darktable a désactivé le périphérique mais que vous êtes sûr qu’il doit être utilisé, vous pouvez le réactiver en mettant ce champ à 0.

i. Réservé :

j. Avantage hint: Ceci définit l’indice d’avantage décrit dans la section Comparaison entre OpenCL et le tuilage CPU. Si vous avez une carte graphique rapide avec beaucoup de mémoire, vous pouvez laisser ce paramètre à sa valeur par défaut de 0.000. Cependant, si vous souhaitez adapter ce nombre à votre propre système, vous devez suivre la procédure suivante :

Lancez darktable avec l’option de débogage tiling (`darktable -d tiling) et commencez à éditer une image dans la Chambre noire. Ouvrez le module Reconstruction hautes lumières et utilisez la méthode Laplaciens guidés , en réglant le Diamètre de reconstruction à une valeur élevée, tout en vous assurant que le tuilage ne se produit pas (vérifiez les informations de débogage dans votre session de terminal pendant que vous ajustez le curseur).
Vérifiez les temps d’exécution de ce module avec OpenCL activé et désactivé (en exécutant darktable -d perf pour examiner la performance).
Réglez l’option Avantage hint à environ (temps d’exécution CPU / temps d’exécution GPU).

k. Fraction de mémoire partagée: Certains dispositifs OpenCL n’ont pas de mémoire dédiée mais la partagent avec le CPU – le silicium ARM d’Apple en est un exemple, mais aussi les dispositifs embarqués d’Intel, d’AMD ou les SOC ARM. Comme nous voulons garder la mémoire du système disponible pour la mise en cache ou les chemins de code du CPU, nous limitons la quantité de toute la mémoire utilisée à la fraction donnée. Ainsi, avec une valeur par défaut de 0,5 et un ordinateur Apple doté de 16 Go de mémoire vive, OpenCL pourra utiliser 8 Go.

Remarque : si darktable détecte une clé de configuration de périphérique “boguée”, elle sera réécrite aux valeurs par défaut.

🔗Configuration OpenCL spécifique à l’id

Une seconde clé de configuration spécifique au périphérique est également fournie ; elle prend en compte à la fois le nom et l’id du périphérique (juste au cas où vous auriez deux périphériques identiques). Dans ce cas, le nom de clé habituel cldevice_version_canonicalname est suivi de _idX, X étant l’identifiant du périphérique. Par exemple, si l’exemple de périphérique ci-dessus était appelé périphérique 0, le deuxième paramètre de configuration serait (par défaut) cldevice_v45_quadrortx4000_id0=4600.

Cette clé de configuration n’a actuellement qu’un seul paramètre défini :

forced headroom (default 600): The amount of memory (in MB) that will not be used by darktable during OpenCL processing. This setting is only valid if you set preferences > processing > OpenCL > use all device memory to “on”.; Si vous êtes certain qu’aucune application (ou votre système d’exploitation) n’utilise le périphérique spécifique, vous pouvez définir sur 0 le paramètre de ce périphérique, utilisé nulle part ailleurs, afin que darktable utilise toute sa mémoire.; La valeur par défaut de 600 Mo devrait convenir à la plupart des systèmes. Si vous rencontrez des problèmes de performance dus au fait que darktable retombe sur le CPU, essayez de passer à 800 ou plus.

🔗Autres paramètres de configuration

Les options de configuration supplémentaires suivantes sont également disponibles dans darktablerc :

Cldevice_version_canonicalname_building: Cette option est utilisée lors de la compilation des noyaux OpenCL et peut être fournie 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 pour recompiler sans aucune option. Supprimez entièrement le paramètre pour recompiler avec les options par défaut, la valeur par défaut est -cl-fast-relaxed-math, pour les pilotes nvidia, toutes les autres cartes n’ont pas cette option de compilateur.; L’option -cl-fast-relaxed-mat améliore significativement les performances mais modifie les mathématiques dans le code de traitement du module, ce qui peut conduire à des résultats différents. Pour les implémentations Intel actuelles, cette option du compilateur conduit à des résultats visiblement erronés, sur les cartes AMD les résultats ne sont pas concluants. Certaines combinaisons carte/pilote fonctionnent bien, d’autres non. Comme les pilotes AMD changent constamment, nous ne recommandons pas de l’utiliser sur les cartes AMD.
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. Depuis darktable 4.4, l’efficacité du cache pipeline graphique s’est beaucoup améliorée, donc le fait de le mettre en “module actif” (par défaut) est une bonne chose dans la plupart des cas.
Opencl_mandatory_timeout: default 400; Si darktable veut utiliser un périphérique OpenCL, il doit le réserver pour une utilisation ultérieure. Si ce périphérique est actuellement utilisé, darktable attendra jusqu’à opencl_mandatory_timeout * 5ms avant d’effectuer un repli sur le CPU. Augmentez cette valeur si vous préférez utiliser OpenCL (parce que votre carte est vraiment rapide et que votre CPU ne l’est pas).