Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
Zones noires dans certains modules
#16
(16-03-19, 17:42)JacoTux a écrit : 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.
Aurélien, photographe portraitiste, spécialiste calcul.
Développeur de filmique, égaliseur de tons, balance couleur, etc.
darktable est mon métier, pensez à m'aider :
[Image: 2FAd4rc]
Répondre


Messages dans ce sujet
RE: Zones noires dans certains modules - par aurelienpierre - 16-03-19, 18:15

Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)