Zones noires dans certains modules

[aurelienpierre]

1. les modules impactés (Orton, passe-haut/bas, renforcer la netteté) utilisent tous un flou gaussien sur le canal L de l'espace Lab. Ce sont aussi des modules qui datent tous de 2011, du même auteur, et n'ont pas été testés avec l'option openmp_simd=true (qui est expérimentale). Le problème rencontré avec cette option activée ressemble à un bug que j'ai déjà réglé pour le module contraste de couleur (https://github.com/darktable-org/darktable/pull/1917), où le canal L n'était pas recopié correctement dans la sortie. Étant donné que, par défaut openmp_simd=false, ces parties du code ne sont en pratique jamais utilisées, donc pas débugguées.

2. Les problèmes de sections d'image noires ressemblent à des valeurs NaN de pixels qui sont improprement gérées. Ça se produit notamment quand on divise par zéro, le résultat n'est pas un nombre (NaN = Not A Number). Suivant la plateforme et le compilateur, les NaN ne sont pas gérés de la même manière (les joies du développement multi-plateforme). Si l'option "développement de haute qualité" est activée, l'interpolation est réalisée à la toute fin du pipe, donc les erreurs des modules précédents sont propagées aux pixels voisins. Comme l'interpolation est plus ou moins une moyenne des n pixels voisins, elle propage les NaN de proche en proche. L'interpolation bilinéaire utilise les 4 pixels les plus proches, l'interpolation Lanczos 3 utilise les 9 pixels les plus proches, donc le fait que les méthodes les plus simples rendent le problème moins visible est cohérent. De toute façon, je recommande de laisser l'option "développement de haute qualité" désactivée tout le temps, vu qu'elle revient à interpoler des pixels encodés non-linéairement (et n'est pas donc de si haute qualité que ça).

3. Le fait que l'option openmp_simd=true ralentisse le calcul est normal. L'option par défaut (sse2) utilise des fonctions vectorisées à la main. L'option openmp utilise des fonctions vectorisées automatiquement par le compilateur, qui déduit tout seul ce qu'il peut vectoriser ou pas, et implique donc d'écrire son code d'une certaine manière, pour donner des indices au compilateur (ce qui n'est pas une pratique courante dans le développement de darktable). Donc en pratique, avec openmp_simd, le code n'est pas vectorisé, ou presque pas.

Rapidement, la vectorisation, c'est une façon de tirer parti des processeurs modernes en traitant les pixels de façon jointe. Dans un code non vectorisé (= scalaire), on traite chaque canal RGB de chaque pixel individuellement. Ça veut dire qu'on va chercher la valeur d'une composante RGB dans la RAM, on la copie dans le processeur, le processeur calcule la sortie, recopie le résultat dans la RAM et passe à la composante suivante. C'est lent.

Dans un code vectorisé, on copie un vecteur, c'est à dire 4 (génération SSE/SSE2 ~ 1999 - 2004), 8 (génération SSE3/SS4 ~ 2005 - 2007), voire 16 (génération AVX512 ~ 2013) composantes RGB en une seule fois (donc on traite 1, 2, ou 4 pixels à la fois), de la RAM au processeur, le processeur les calcule d'un seul coup, et recopie tout le monde à la fin. C'est beaucoup plus rapide, mais ça impose que les composantes RGB soient indépendantes les unes des autres (en gros : la valeur G ne dépend ni de la valeur R ou B). Du coup, quand le compilateur détecte une possibilité (même fausse) de dépendance entre les composantes du vecteur RGB, il annule la vectorisation et opte pour l'option scalaire, lente mais sécuritaire pour le calcul.

Tout ça n'a rien à voir avec la quantité de RAM ou les performances « brutes » du processeur (fréquence d'horloge, taille du cache, etc.). C'est vraiment juste au niveau de la capacité du code à tirer partie des possibilités du processeur, qu'on active ou pas, suivant comment le code est écrit et ce que le compilateur comprend.