Zones noires dans certains modules

[pascalG]

@ pascalG

Ton i5-7500 3,40 Ghz est en mesure de se débrouiller seul.
Mais ton i5-750 2,67 Ghz est épaulé par une carte graphique qui va faire le job et le gpu externe compense
....

Plutôt un i5-7200U à 2,5 GHz, le gpu intégré étant un HD Graphics 620. Et ma vieille radeon n'est pas non plus un foudre de guerre ...
Bref, tout ça pour dire que ça me semble être davantage un problème matériel même si la gestion de l'affichage est sûrement différente entre Windows et Linux (et en supposant que les pilotes soient à jour).

[JacoTux]

@ pascalG

Oui mais l'union fait la force, i5-750 + HD 7770 + 12 Go de ram + l'OpenCL et ce PC un peu ancien supporte a priori les derniers développements de dt même avec un OS exigeant en ressources.

Avec l'apparition de filmique pas besoin de mesures, je ressens bien que certains traitements sont plus longs et le ventilateur qui monte dans les tours bien plus souvent qu'avant ne trompent pas.

Ceci en guise de conclusion, pour ceux qui ont le problème décrit ici il faut chercher à le contourner en utilisant les algorithmes d'affichage les moins exigeants, §8.2 du manuel, au besoin lire ou relire le §10 concernant les optimisations de mémoire, surtout avec peu de ram embarquée.

[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.

[jpg54]

Encore une super explication Aurélien, c'est sûr que l'on est très loin du temps ou le processeur était composé qu'une mémoire de travail et un accumulateur.

[JacoTux]

Merci Aurelien pour ces explications détaillées et argumentées toujours très instructives, ma démarche pour essayer de comprendre le  problème n'étant pas basée sur une connaissance du code, que je n'ai pas, est forcément plus empirique.

1. Oui, je plussois, si pascalG n'a pas le soucis c'est probablement que son openmp_simd est à false, tout comme moi avec ma version de dt corrigée pour Linux, pas sous ma WIN10 où il est à true. Bon à savoir pour ces modules, du coup ce serait bien de revisiter leur code avant la 2.6.2.
Quoique pour renforcer la netteté je n'en suis pas sûr, n'ayant pu reproduire ces affichages de zones vides avec lui.

2. Effectivement ces pixels sont sans valeurs si issus d'une /0 qui sort le résultat du domaine fini et passent NaN.

3. Eh oui bien sûr c'est normal, mais sur ma version corrigée ce paramètre est à false, il n'empêche que les ressources demandées en calcul ont dû progresser depuis la 2.6.0, "ressenti" de ma part je n'ai pas fait de mesure pour le quantifier mais avec filmique je n'utilise plus certains modules, remplacés par d'autres. Balance couleur ou l’égaliseur, par exemple, qui sollicitent fortement le cpu, ceci expliquant peut-être cela.

A priori si j’interprète bien ce que tu dis le code de dt est "malin", il sait exploiter au mieux soit cpu ou gpu et au besoin passer dans un mode sécuritaire et c'est tant mieux, il n'empêche que mon i5-2430-M pédale à 100% de tous ses "core" pendant de longues secondes pour arriver à bout des calculs avec certains modules. Dt est forcement exigeant en calculs, si l'aspect matériel n'est pas à l'origine du problème décrit ici, et transparent encore une fois pour ceux qui accèdent à l'OpenCL, il n'empêche qu'il respire mieux avec un processeur puissant.

[aurelienpierre]

Merci Aurelien pour ces explications détaillées et argumentées toujours très instructives, ma démarche pour essayer de comprendre le  problème n'étant pas basée sur une connaissance du code, que je n'ai pas, est forcément plus empirique.

1. Oui, je plussois, si pascalG n'a pas le soucis c'est probablement que son openmp_simd est à false, tout comme moi avec ma version de dt corrigée pour Linux, pas sous ma WIN10 où il est à true. Bon à savoir pour ces modules, du coup ce serait bien de revisiter leur code avant la 2.6.2.
Quoique pour renforcer la netteté je n'en suis pas sûr, n'ayant pu reproduire ces affichages de zones vides avec lui.

2. Effectivement ces pixels sont sans valeurs si issus d'une /0 qui sort le résultat du domaine fini et passent NaN.

3. Eh oui bien sûr c'est normal, mais sur ma version corrigée ce paramètre est à false, il n'empêche que les ressources demandées en calcul ont dû progresser depuis la 2.6.0, "ressenti" de ma part je n'ai pas fait de mesure pour le quantifier mais avec filmique je n'utilise plus certains modules, remplacés par d'autres. Balance couleur ou l’égaliseur, par exemple, qui sollicitent fortement le cpu, ceci expliquant peut-être cela.

A priori si j’interprète bien ce que tu dis le code de dt est "malin", il sait exploiter au mieux soit cpu ou gpu et au besoin passer dans un mode sécuritaire et c'est tant mieux, il n'empêche que mon i5-2430-M pédale à 100% de tous ses "core" pendant de longues secondes pour arriver à bout des calculs avec certains modules. Dt est forcement exigeant en calculs, si l'aspect matériel n'est pas à l'origine du problème décrit ici, et transparent encore une fois pour ceux qui accèdent à l'OpenCL, il n'empêche qu'il respire mieux avec un processeur puissant.

Je monitore attentivement les performances quand je programme, a priori il ne devrait pas y avoir de différence entre dt 2.6.0 et 2.6.1. Si tu peux me fournir des mesures (en lançant

Code :

darktable -d perf

en console), ça m'aiderait (en particulier pour la balance couleur, chez moi ça tourne entre 35 et 45 ms en résolution 4K sur CPU, je suis surpris - est-ce que tu utilises la fusion avec adoucissement du masque ?).

dt n'est pas vraiment malin, c'est le compilateur qui fait ce qu'il peut en fonction de ce qu'il a. J'ai plusieurs pistes d'optimisation en cours, dont une qui consiste à précompiler les fonctions pour différentes générations de processeur (SSE2/3/4, AVX2/512) de sorte que les paquets précompilés aient des optimisations spécialisées. Pour l'instant, les paquets des dépôts utilisent des optimisations SSE2 basiques (supportées par toutes les architectures), pour bénéficier des optimisations spécifiques pour ton matos, il faut compiler toi même avec le flag -O3 (ou sh build.sh --sudo --build-type Release --install). Du coup, ça veut dire que pour l'essentiel des utilisateurs, dt utilise peut-être 50-75 % du potentiel CPU.

[Roger]

Du coup, ça veut dire que pour l'essentiel des utilisateurs, dt utilise peut-être 50-75 % du potentiel CPU.

Ah ouais, quand même ! Il faut vraiment que je m'y mette. C'est quand même dommage de ne utiliser dt à plein. Je pensais que la différence entre dépots/compil était plutôt de l'ordre de 10% (précision pifométrique).

[JacoTux]

Si tu peux me fournir des mesures (en lançant

Code :

darktable -d perf

en console), ça m'aiderait (en particulier pour la balance couleur, chez moi ça tourne entre 35 et 45 ms en résolution 4K sur CPU, je suis surpris - est-ce que tu utilises la fusion avec adoucissement du masque ?).

Oui il n'y a pas de différence notable entre la 2.6.0 et la 2.6.1 et les modules égaliseur ou balance couleur existaient avant, mais filmique apparu avec la 2.6.0 pousse à utiliser dt différemment en utilisant des modules plus exigeants, c'est surtout ça qui doit faire la différence pour moi.
Je vais y regarder de plus près en lançant dt en console, j'ai quelques photos à traiter de sujets architecturaux qui nécessitent pivotement et correction de perspective, masques dessinés + paramétriques qui ajoutent encore une dose de calculs, quand dt doit refaire une passe du pixelpipe suite à un changement c'est là que mon CPU monte dans les tours.

En attendant j'ai repris à partir du début cette photo pour laquelle je n’utilise que très peu de modules mais balance couleur y est, voilà le retour de ma console. Là pas de soucis d'attente exagéré, mais je vais utiliser la méthode pour identifier les modules non indispensables que l'on peut activer qu'en fin de battue, retouche, perspective...

est-ce que tu utilises la fusion avec adoucissement du masque ?).

Oui, depuis que cette possibilité existe, je l'utilise très fréquemment tant elle est pratique... sans rien lui trouver à redire. 


pour bénéficier des optimisations spécifiques pour ton matos, il faut compiler toi même avec le flag -O3 (ou sh build.sh --sudo --build-type Release --install).

Ce n'est pas tombé dans l’oreille d'un sourd, je crois bien que je vais revoir ma copie.

[aurelienpierre]

Si tu utilises les masques fusionnés avec l'adoucissement, c'est normal. Les filtres guidés sont plutôt gourmands en puissance.