darktable-chartCe chapitre traite de différents sujets techniques qui peuvent vous aider à faire tourner darktable sur un système particulier ou d’en améliorer les performances. Il y a de nombreuses informations techniques de base et de nombreux trucs et astuces couverts de manière extensive dans une section blog que vous trouverez sur notre page d’accueil.
 |
Les exigences en mémoire de darktable sont élevées. Un simple calcul clarifie ceci. Si vous avez une image de 20 M de pixels, darktable, pour des besoins de précision, va l’enregistrer en interne en virgule flottante en utilisant pour chaque pixel une cellule de 4 × 32-bits. Chaque image complète de cette dimension demande alors environ 300 Mo de mémoire. Comme nous désirons traiter cette image, il nous faudra au moins deux tampons pour chaque module - un pour l’entrée et un pour la sortie. Si nous avons un module plus complexe, son algorithme peut avoir besoin, en plus, de plusieurs tampons intermédiaires de la même dimension. Sans autre optimisation, nous aurons besoin entre 600 Mo et 3 Go de mémoire simplement pour enregistrer et traiter les données de l’image. Nous avons en plus le segment de code de darktable, le code et les données de toutes les bibliothèques système liées dynamiquement, et il ne faut pas oublier d’autres tampons où darktable enregistre les images intermédiaires afin d’y accéder rapidement lors du travail interactif (cache mip map). L'un dans l'autre, darktable a besoin d’un minimum d’environ 4 Go de mémoire pour être exécuté avec succès.
Selon ce qui a été dit précédemment, il est évident que votre ordinateur a besoin d’une configuration mémoire saine afin de pouvoir faire tourner darktable proprement. Nous suggérons que vous ayez au moins 4Go de mémoire physique ainsi que 4 à 8Go de fichier d’échange (« swap »). Ce dernier est nécessaire afin que votre système puisse décharger sur disque des données temporairement inutilisées afin de libérer de la place en mémoire.
Théoriquement, vous pouvez aussi faire tourner darktable avec une plus faible quantité de mémoire physique et l’équilibrer avec un fichier d’échange suffisant. Cependant, vous pouvez vous attendre à ce que le système « rame » lourdement car il lit ou écrit des pages de données de et vers le disque dur. Nous avons des informations comme quoi ceci fonctionne bien pour certains utilisateurs, mais que c'est extrêmement lent pour d’autres...
En plus de la quantité totale de mémoire système, il y a un autre facteur de limitation ; l’espace d’adressage disponible de votre architecture matérielle. La quantité de mémoire qui peut être adressée par un processus dépend du nombre de bits d’adresse que propose votre CPU. Pour un CPU avec des registres d’adresse à 32 bits, cela fait 2^32 octets, ce qui donne un total de 4Go. Ceci est la limite supérieure maximum de la mémoire qui peut être utilisée par un processus et il s’agit d’une situation délicate pour darktable comme nous avons pu le voir ci-dessus.
L’échappatoire de darktable est appelée « tuilage ». Au lieu de traiter une image en un seul gros morceau, nous la découpons en plus petites parties lors de chaque étape de traitement (module). Il faudra toujours un tampon d’entrée et un tampon de sortie pour l'image entière. Mais les tampons intermédiaires seront de suffisamment petite taille pour que tout puisse tenir dans les limitations du matériel.
Malheureusement, ce n'est pas encore la fin de l'histoire. Il y a un effet appelé fragmentation de la mémoire, qui peut et va frapper les logiciels qui ont besoin d’une gestion intensive de la mémoire. Si un tel programme a besoin d’allouer 5 fois 300 Mo de mémoire à la fois et la libère ensuite, cette mémoire devrait ensuite être disponible pour une grosse allocation de 1.5 Go. Cependant, ceci n'est pas souvent le cas. L’allocateur de mémoire du système ne voit plus cette zone comme un bloc contigu de 1.5 Go mais comme une rangée de zones de 300 Mo. S’il ne reste plus d’autre zone libre de 1.5 Go disponible, il y aura un échec d’allocation. Au cours de l'exécution d’un programme, ce mécanisme va prendre de plus en plus les plus grands blocs de mémoire au lieu des plus petits. Le cache mipmap de darktable 2.0 alloue plusieurs petits blocs de mémoire pour chaque miniature, donc ce problème est encore plus grand. Pour cette raison, à partir de darktable 2.0, le support du 32 bits est déconseillé.
Comme si cela n'était pas suffisant, il y a d’autres choses qui pourraient limiter votre accès à la mémoire. Sur certaines cartes de fabrication assez ancienne, vous devez activer l’option BIOS « memory remapping » de manière à ce que toute la mémoire physique soit activée. Si, de plus, vous avez un système 32 bits, vous devrez probablement avoir un noyau avec l’option « Physical Address Extension » (PAE) activée. Ceci est souvent le cas sous Linux, mais pas toujours. De nombreuses distributions fournissent différents noyaux, certains avec et d’autres sans PAE activée, il vous faudra choisir le bon. Pour vérifier que le système est correctement configuré, utilisez la commande « free » dans un terminal et examinez la sortie. Si la sortie indique moins de RAM que celle qui est installée, vous avez alors un problème qui demande une correction : par exemple, si vous avez 4Go sur votre carte mais que votre noyau n'en voit que 3Go ou moins. Il vous faudra consulter le manuel de votre BIOS et les informations concernant votre variante de Linux pour plus d’informations.
Comme nous l'avons vu les systèmes 32-bits sont des environnements difficiles pour darktable. Cependant des utilisateurs continuent à exécuter darktable sur de tels systèmes. Ceci est possible si les exigences de base en termes de mémoire totale système et les éléments mentionnés dans les paragraphes ci-dessus ont été traités correctement.
Il y a plusieurs paramètres d’ajustement qui permettent de le faire tourner. Si vous venez d’installer darktable, il va détecter votre système et définir par défaut des valeurs conservatrices. Cependant, si vous mettez à jour darktable depuis une autre version (par exemple en venant de 0.9.3 pour aller à 1.0), il y a des chances qu'il y ait un paramétrage défavorable dans vos préférences. Les conséquences pourront être que darktable plantera en raison d’échecs d’allocation ou - assez typiquement - darktable ne pourra pas importer une nouvelle pellicule. Un symptôme fréquent est l’affichage de têtes de mort à la place des miniatures pour un grand nombre de vos images.
Si c'est le cas, prenez une minute pour optimiser votre paramétrage des préférences. Vous les trouverez dans l'onglet « cpu / gpu / mémoire » ( Section 8.8, « Cpu /gpu / mémoire ») des préférences de darktable. Vous pouvez aussi trouver ces paramètres comme variables de configuration dans le fichier $HOME/.config/darktable/darktablerc et les modifier à cet endroit.
Voici une courte explication des paramètres concernés avec leurs valeurs proposées :
Ce paramètre définit le nombre maximum de processus qui seront alloués en parallèle lors de l’importation de pellicules ou lors de l’exécution d’autres tâches en arrière-plan. Pour des raisons évidentes sur les systèmes 32 bits, vous ne pouvez avoir qu'un seul processus à la fois qui consomme des ressources. Vous devrez donc fixer ce paramètre à 1 ; toute valeur supérieure provoquera un plantage.
Ce paramètre indique à darktable la quantité de mémoire (en Mo) qu'il doit considérer comme disponible pour enregistrer les tampons d’images lors du fonctionnement des modules. Si une image ne peut pas être traitée à l’intérieur de ces limites en un seul élément, le tuilage prendra la main et l’image sera traitée en plusieurs parties, l’une après l’autre. Fixez ce paramètre à la valeur la plus faible possible, avec 500 comme point de départ. Vous pourrez par la suite tester si vous pouvez l’augmenter un peu de manière à réduire la surcharge due au tuilage.
Il y a un second paramètre qui contrôle le tuilage, il définit une limite basse pour la taille, en mégaoctets, des tampons intermédiaires. Le paramètre est nécessaire pour éviter un tuilage excessif dans certains cas (pour certains modules). Fixez ce paramètre à la faible valeur de 8. Vous pourrez tenter de l’augmenter à 16 par la suite.
Ceci contrôle combien de miniatures (ou mip maps) peuvent être stockées à la fois en mémoire. Comme point de départ fixez ce nombre à quelque chose comme 256MB. Depuis darktable 2.0, le cache doit allouer de petits buffers pour chaque miniature, causant ainsi une significative fragmentation de la mémoire. Comme expliqué auparavant, ceci pose problème aux systèmes 32-bits. Pour cette raison, à partir de darktable 2.0, le support du 32-bits est déconseillé.
Il n'y a pas grand chose à dire ici. Bien sûr, les systèmes 64 bits ont besoin d’une certaine quantité de mémoire principale, donc la recommandation de 4Go plus le swap reste vraie. D’un autre côté, l’architecture 64 bits ne souffre pas des limitations spécifiques au 32 bits comme l’espace adressable réduit et le problème de la fragmentation.
Les CPU les plus modernes d’Intel ou AMD 64 bits ont un espace mémoire adressable dans la plage de quelques Teraoctets. Le mot « moderne » est relatif dans ce contexte : tous les CPU AMD ou Intel introduits depuis 2003 et 2004 respectivement, offrent un mode 64 bits. Linux 64 bits est disponible depuis de nombreuses années.
Toutes les distributions de Linux concernées vous donnent le choix d’installer une version 32 bits ou une version 64 bits. Vous pouvez même faire tourner des binaires 32 bits sous une version 64 bits de Linux. La seule chose pour laquelle vous devrez passer un peu de temps sera la migration. Nous recommandons finalement de passer à une version 64 bits de Linux. Il n'y a vraiment aucune raison de ne pas le faire.
Sur un système à 64 bits, vous pouvez laisser en toute sécurité les paramètres de configuration du tuilage à leurs valeurs par défaut : « mémoire limite (en Mo) pour le tuilage » devrait avoir une valeur de 1500 et « quantité minimale de mémoire (en Mo) pour la mémoire-tampon d'une tuile » devrait être positionné à 16. Au cas où vous seriez en train d’effectuer une migration depuis un système 32 bits vers un système 64 bits, veuillez vérifier ce paramétrage et le modifier si cela est nécessaire dans la boîte de dialogue des préférences de darktable.
Généralement il n'est pas nécessaire de se limiter dans le nombre de threads sur un système 64 bits. Sur un système multi-processeurs un nombre de threads de deux à huit peut accélérer considérablement la génération des miniatures par rapport à l'utilisation d'un seul thread. La raison n'est pas tant de profiter au maximum de tous les cœurs de votre CPU – de toute façon, le pipeline graphique de darktable les utilise tous ensemble en parallèle – que de cacher la latence des entrées/sorties.
Une exception vaut la peine d'être mentionnée. Si vous utilisez darktable pour traiter des vues panoramiques par assemblage, par exemple des TIFFs générés par le logiciel Hugin, ces images peuvent atteindre des tailles considérables. Chaque thread d'arrière-plan a besoin d'allouer suffisamment de mémoire pour garder dans ses tampons une image complète, des intermédiaires et l'image de sortie. Ceci peut rapidement conduire à un dépassement de mémoire même avec un système 64 bits bien équipé. Dans ce cas réduire à un seul le nombre de threads d'arrière-plan.
