mémoire
Les besoins en mémoire de darktable sont élevés. Un simple calcul rend cela clair. Si nous avons une image 20 Mpx, alors, pour des raisons de précision, darktable stockera en interne chacun de ces pixels sous la forme d’une cellule à virgule flottante 4 x 32 bits. Chaque image complète de cette taille aura donc besoin d’environ 300 Mo de mémoire. Comme nous voulons traiter l’image, nous aurons au moins besoin de 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 nécessiter plusieurs autres tampons intermédiaires de même taille. Sans optimisation supplémentaire, entre 600 Mo et 3 Go seront nécessaires simplement pour stocker et traiter les données de l’image. En plus de cela, nous avons le segment de code de darktable, le code et les données de toutes les bibliothèques système liées dynamiquement, et ne pas oublier, d’autres tampons où darktable stocke des images intermédiaires pour un accès rapide pendant le travail interactif (cache mip map).
Dans l’ensemble, darktable a besoin d’un minimum d’environ 4 Go de mémoire pour fonctionner correctement.
🔗mémoire total du système
D’après l’analyse ci-dessus, il est évident que votre ordinateur a besoin d’une configuration de mémoire raisonnable pour exécuter correctement darktable. Nous vous suggérons de disposer d’au moins 4 Go de RAM physique et de 4 à 8 Go d’espace d’échange supplémentaire.
Théoriquement, vous pouvez exécuter darktable avec des quantités inférieures de RAM et compenser avec suffisamment d’espace de swap. Cependant, cela pourrait mettre votre système «en difficulté», car il utilise le disque dur pour lire ou écrire des pages de données. Nous avons des rapports positifs selon lesquels cela fonctionne bien pour certains utilisateurs. Mais pour d’autres, leur système peut encore rester extrêmement lent. Un disque SSD peut améliorer légèrement les choses.
🔗espace d’adressage disponible
Outre la quantité totale de mémoire système, il existe un autre facteur limitant : l’espace d’adressage disponible de votre architecture matérielle. La quantité de mémoire pouvant être adressée par un processus dépend du nombre de bits d’adresse offerts par votre CPU. Pour une CPU avec des registres d’adresses 32 bits, c’est 2^32 octets, ce qui fait un total de 4 Go. C’est la limite supérieure absolue de mémoire qui peut être utilisée par un processus et cela met darktable dans une situation difficile comme nous l’avons vu ci-dessus.
La porte de sortie de darktable s’appelle le tuilage. Pour chaque module de traitement, au lieu de traiter une image en un seul gros morceau, darktable la divise en parties plus petites (des tuiles). Cela nécessite encore un tampon d’entrée et de sortie, mais ces tampons intermédiaires peuvent être suffisamment petits pour tout faire rentrer dans les limites du matériel.
🔗fragmentation de la mémoire
Malheureusement, ce n’est pas encore la fin de l’histoire. Un effet appelé fragmentation de la mémoire peut toucher et touchera les logiciels qui doivent réaliser une gestion étendue de la mémoire. Si un tel programme alloue 5 fois 300 Mo à la fois et ensuite les libère, cette mémoire devrait normalement être disponible pour une grande allocation ultérieure de 1,5 Go. Cependant ce n’est pas souvent le cas. L’allocateur de mémoire du système peut ne plus voir cette zone comme un bloc contigu de 1,5 Go mais comme une rangée de blocs séparés de 300 Mo. S’il n’y a pas d’autre zone libre de 1,5 Go disponible, une allocation ultérieure échouera. Pendant l’exécution d’un programme, ce mécanisme enlèvera de plus en plus de blocs de mémoire plus gros au profit de blocs plus petits. Le cache mip map de darktable alloue plusieurs petits blocs de mémoire par miniature, ce problème est donc encore plus important. Pour cette raison, à partir de darktable 2.0, la prise en charge des systèmes 32 bits est obsolète.
🔗autres limitations
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 4 Go sur votre carte mais que votre noyau n’en voit que 3 Go ou moins. Il vous faudra consulter le manuel de votre BIOS et les informations concernant votre variante de Linux pour plus d’informations.
🔗configurer darktable sur un système 32 bits
Comme nous l’avons vu, les systèmes 32 bits sont des environnements difficiles pour darktable. Certains les utilisent encore pour exécuter darktable, quand les exigences de base en termes de mémoire système totale et les sujets mentionnés dans les paragraphes ci-dessus sont traités correctement.
Il existe plusieurs paramètres qui nécessitent un ajustement pour le faire fonctionner. Si vous installez une nouvelle version, darktable détectera votre système et définira des valeurs prudentes par défaut. Cependant, si vous mettez à niveau darktable à partir d’une version plus ancienne, il est probable que vous ayez des paramètres défavorables dans vos préférences. Les conséquences peuvent être un abandon de darktable en raison d’échecs d’allocation ou – très typiquement – darktable ne peut pas importer correctement une nouvelle pellicule. En tant que symptôme fréquent, vous obtenez pour beaucoup de vos photos des crânes affichés au lieu des miniatures.
Si tel est le cas, prenez une minute pour optimiser vos paramètres dans les préférences. Vous les trouverez dans [préférences > traitement> cpu / gpu / mémoire]../preferences-settings/processing.md#cpu–gpu–mémoire).
Voici une brève explication des paramètres pertinents et de leurs réglages proposés :
- nombre de fils d’exécution
- Ce paramètre définit le nombre maximum de fils d’exécution autorisés à s’exécuter en parallèle pour l’importation de pellicules ou pour d’autres tâches d’arrière-plan. Pour des raisons évidentes sur les systèmes 32 bits, vous ne pouvez avoir qu’un seul fil d’exécution consommant des ressources à la fois. Vous devez donc définir ce paramètre sur 1 ; toute valeur supérieure provoquera un plantage.
- mémoire limite (en Mo) pour le tuilage
- Ce paramètre indique à darktable la quantité de mémoire (en Mo) qu’il doit supposer disponible pour stocker les tampons d’image pendant les opérations du module. Si une image ne peut pas être traitée dans ces limites en un seul bloc, le tuilage prendra le relais et traitera l’image 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.
- quantité minimale de mémoire (en Mo) pour la mémoire-tampon d’une tuile
- c’est le 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.
- mémoire en mégaoctets à utiliser pour le cache des miniatures
- 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 256 MB. 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é.
🔗darktable sur les systèmes 64-bits
Il n’y a plus 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 4 Go 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 téraoctets. 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 : «la mémoire limite (en Mo) pour le tuilage» devrait avoir une valeur de 1500 et «la 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 modifiez-le manuellement dans la boîte de dialogue des préférences de darktable si cela est nécessaire.
Typiquement il n’est pas nécessaire de se limiter dans le nombre de fils d’exécution sur un système 64-bits. Sur un système multi-processeurs un nombre de fils de deux à huit peut accélérer considérablement la génération des miniatures par rapport à l’utilisation d’un seul fil. 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) alors ces images peuvent atteindre des tailles considérables. Chaque fil d’exécution 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éduisez à un le nombre de fils d’exécution.