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