Analyse des performances. Pourquoi ?

Mon système fonctionne-t-il aussi bien qu’il le devrait ?

• Darktable utilise-t-il l’accélération matérielle de mon GPU ou fonctionne-t-il uniquement sur le CPU ?
• Un mauvais réglage ralentit-il mon matériel ?
• Je souhaite acheter un appareil photo avec une meilleure résolution : mon système est-il suffisant ?
• J’utilise Linux : quels pilotes OpenCL dois-je utiliser ?

Mon système fonctionne bien, mais comment puis-je travailler de manière plus fluide dans darktable ?

L’analyse des performances vous aide à comprendre ce qui se passe « sous le capot ». Nous vous expliquons ici les concepts les plus importants.

Dans la suite de cette section, nous utilisons des termes tels que CPU, (i)GPU ou (V)RAM. Vous trouverez les explications (en rapport avec darktable) dans notre petit glossaire du matériel.

Vitesse d’exportation via darktable-cli

L’outil Analyseur de Performance DT-PA vous permet de mesurer la vitesse d’exportation sur votre système.

Une exportation performante est un bon indicateur des performances globales du système et permet d’établir un lien avec la vitesse de traitement interactif dans la chambre noire.

Étapes à suivre pour effectuer l’analyse

1. Téléchargez les fichiers ZIP contenant les fichiers RAW et XMP pour l’un ou l’autre :
   • 24 MP – Le cas de figure classique pour de nombreux appareils photo, dans lequel les systèmes modernes devraient permettre des temps d’exportation très courts.
   • 61 MP – Un scénario de charge importante pour les capteurs haute résolution qui met davantage en évidence les faiblesses du processeur, du processeur graphique et de la bande passante mémoire.
2. Décompressez-les dans un répertoire à partir duquel vous effectuerez l’analyse.
3. Créez ou copiez une ligne de commande à l’aide de notre Générateur de Commandes afin que votre système puisse effectuer les analyses nécessaires sur une image de 24 MP ou de 61 MP.
4. Exécutez les commandes dans un terminal :
   • Accédez au répertoire dans lequel les images ont été décompressées.
   • Exécuter la commande.
   • Patientez jusqu’à ce que la commande se termine correctement ou affiche un message d’erreur.
   • Le processus crée un fichier journal dans le même répertoire que celui où se trouvent les images.
5. Accédez à l’outil Analyseur de Performance DT-PA et téléchargez-y votre ou vos fichiers journaux.
   • Cela vous permettra d’analyser le fonctionnement de votre système avec darktable.
6. Si vous souhaitez comparer vos résultats avec ceux d’autres configurations système, rendez-vous sur la page de benchmark correspondante et cliquez sur le bouton « Ajouter des fichiers journaux »:
   • Benchmark: 24MP
   • Benchmark: 61MP

Une fois le fichier lu, le navigateur affiche directement les données que vous avez saisies. Ces données ne seront conservées que jusqu’à ce que vous quittiez la page. Nous ne conservons par ailleurs aucun journal sur le serveur.

• Votre système est aussi rapide que les autres, mais vous avez quand même l’impression qu’il est lent ? Dans ce cas, passez simplement à la section suivante.
• Votre système est beaucoup plus lent ? Nous vous expliquons ci-dessous les causes possibles et comment y remédier.

Traitement interactif en chambre noire

Selon le matériel utilisé, le traitement en chambre noire peut être jusqu’à 10 fois plus rapide.

Si vous souhaitez connaître les valeurs exactes, vous pouvez utiliser notre outil Moniteur Temps-Réel DT-RM (lire ce mode d’emploi). Il vous indique la durée exacte de chaque étape de montage, en temps réel.

La vitesse de traitement et le temps d’exportation dépendent fortement des modules utilisés. Alors que les corrections de base (par exemple, l’Exposition) s’effectuent presque toujours sans délai, les modules nécessitant une puissance de calcul importante (tels que Diffusion ou Netteté, Aberrations Chromatiques ou Réduction du Bruit (avec profil)) peuvent entraîner des temps de réponse notables, même sur du matériel performant.

Causes d’un traitement lent

Le Pixelpipe : une chaîne de montage pour les données

On peut se représenter le traitement dans darktable comme une chaîne de montage. L’image passe d’un module à l’autre (par exemple : Dématriçage ⭢ Exposition ⭢ Balance des Blancs ⭢ Mappage des Tons (par exemple : AgX)).

L’objectif est de charger l’image une seule fois sur la carte graphique (GPU), d’y effectuer toutes les étapes nécessaires, puis d’exporter l’image finale. Tous les modules ne peuvent pas être exécutés efficacement sur le GPU, et le sont alors sur le CPU.

Uniquement CPU (sans OpenCL)

Les algorithmes modernes de traitement d’images effectuent des millions de calculs par pixel.

• Un CPU comporte quelques cœurs très complexes (par exemple, 16 cœurs).
• Un GPU comporte des milliers de cœurs simples (par exemple, 4 000 unités de shaders).

Pour le traitement d’images, où chaque pixel peut être traité en parallèle, le GPU est généralement plus performant que le CPU. L’exemple suivant illustre cette différence : une exportation qui prend 3 secondes sur le GPU peut nécessiter 40 secondes sur le CPU.

L’effet « ping-pong » (CPU vs GPU)

Un goulot d’étranglement courant en matière de performances n’est pas nécessairement dû à un GPU trop lent, mais plutôt au transfert de données entre le GPU et le CPU et aux calculs effectués sur le CPU.

• Cas idéal : Image ⭢ GPU ⭢ Module A ⭢ Module B ⭢ Module C ⭢ Sortie.
• Cas problématique : Image ⭢ GPU ⭢ Module A ⭢ CPU Module B (les données doivent être renvoyées vers la RAM) le CPU effectue les calculs ⭢ Retour vers le GPU ⭢ Module C (« ping-pong »).

Quand ce problème se produit-il ?

• Le module ne prend pas en charge OpenCL : le traitement s’effectue donc sur le processeur.
• Le GPU dispose de trop peu de mémoire (VRAM) pour un module :
  Tous les modules ne peuvent pas utiliser le tuilage (voir la section suivante). Si la mémoire du GPU est insuffisante, il ne reste plus qu’à passer par le CPU.

Tuilage

Les cartes graphiques disposent d’une mémoire (VRAM) très rapide mais limitée. Une image de 24 mégapixels occupe souvent plusieurs gigaoctets de VRAM pendant son traitement.

• Que se passe-t-il ? Si l’image ne tient pas en entier dans la mémoire vidéo (VRAM) du GPU, darktable la divise en tuiles.
• Inconvénient : chaque tuile doit être calculée individuellement. Pour qu’aucun bord ne soit visible, les tuiles doivent (la plupart du temps) se chevaucher (« effet fantôme »). Ces zones de chevauchement sont donc calculées deux fois.
• Résultat : le tuilage permet d’exporter des images volumineuses sur des cartes graphiques peu puissantes, mais cela se fait souvent au détriment des performances. Cela dit, le traitement par le processeur est (nettement) plus lent.

Les pilotes : qui communique avec le matériel ?

Darktable utilise OpenCL (ou Nvidia CUDA) pour communiquer avec la carte graphique. Mais la manière dont OpenCL est implémenté fait toute la différence.

Exemple: AMD RX 9060 XT avec 8 GB (gfx1200) – OpenCL-Mesa (RustiCl) vs. ROCm

Important : cet exemple ne permet pas de déterminer si ROCm est globalement plus rapide qu’OpenCL-Mesa (RustiCl) ! Cela peut varier en fonction du système.

• Exemple AMD 7945HX 64 GB + RX 9060 XT 8 GB – ROCm plus rapide
• Exemple AMD AI 395 Max+ – RustiCl plus rapide

ROCm (Radeon Open Compute)

Il s’agit de l’approche moderne d’AMD en matière de calcul haute performance sous Linux.

• Avantage : souvent très rapide et stable avec les cartes récentes (séries RX 6000/7000/9000). Exploite le matériel de manière très efficace.
• Inconvénient : officiellement pris en charge uniquement pour certaines distributions et certaines cartes ; l’installation peut parfois s’avérer délicate.

RustiCl (OpenCL-Mesa)

Un pilote OpenCL plus récent, écrit en Rust, qui fait partie du projet Mesa.

• Avantage : fonctionne souvent « dès l’installation » sur de nombreux systèmes Linux et prend également en charge du matériel plus ancien ou des cartes graphiques intégrées (iGPU) qui ne sont plus pris en charge par les pilotes propriétaires.
• Performance : par ailleurs, ils sont souvent aussi performants que les pilotes propriétaires, voire parfois plus rapides pour certaines tâches et sur certains matériels.

Pilotes propriétaires (AMD Pro / Nvidia)

• Nvidia : Il n’y a pratiquement pas d’alternative dans ce domaine. Le pilote propriétaire est extrêmement abouti et très performant.
• AMD Pro : Il est globalement fiable, mais sous Linux, il est de plus en plus souvent remplacé par ROCm ou RustiCl.

Et maintenant, en quoi cela m’aide-t-il ?

Cette analyse sert d’outil de diagnostic : si darktable s’arrête ou si l’exportation prend trop de temps, vous pouvez immédiatement identifier le composant (CPU, GPU ou RAM) qui constitue le goulot d’étranglement. Cela vous permet de cibler précisément les points où votre matériel présente des limites ou où un pilote graphique fait défaut (CPU seul).

Options disponibles dans darktable

Lorsque vous travaillez dans darktable :

• Activez OpenCL
• Désactivez temporairement certains modules : n’activez les modules gourmands en ressources qui ne sont pas essentiels pour le rendu à ce stade (par exemple Diffusion ou Netteté, Réduction de Bruit (avec profil), Aberrations Chromatiques), soit en toute fin de retouche, soit en les omettant complètement. Cela permet de garantir une prévisualisation fluide.
  Important : l’ordre des modules dans le pipeline de pixels de darktable est fixe. Même si vous activez un module « plus tard », celui-ci est calculé à l’emplacement techniquement correct ; il est donc préférable de laisser les « modules lourds » désactivés jusqu’à la fin.
• Pilote OpenCL (Linux/AMD) : vérifiez si votre carte AMD fonctionne mieux avec le pilote ROCm ou avec la pile RustiCl, plus récente. Un simple test comparatif du temps d’exportation permet de se faire rapidement une idée.

Grâce au Moniteur en Temps-Réel DT-RM, vous disposez d’un aperçu de toutes les informations essentielles à chaque étape, en temps réel.

• Device (Périphérique) : indique si OpenCL est utilisé et, le cas échéant, de quel type il s’agit (par exemple, RustiCL, ROCm, CUDA, etc.).
• Les noms des modules sont identifiés par des codes couleur : bleu = GPU, violet = CPU

Dans cet exemple, on pourrait désactiver temporairement les paramètres « cacorrectrgb » et « diffuse ».

Paramètres matériels – iGPU

Gestion de la mémoire de l’iGPU : si vous n’utilisez pas de carte graphique dédiée, attribuez davantage de mémoire vive système à l’iGPU dans le BIOS. Si 4 Go suffisent pour des montages simples, 8 ou 16 Go offrent des performances nettement supérieures avec des capteurs haute résolution et des modules complexes.

20 avril 2026