Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
[RÉSOLU] Module diffuse ou netteté : export très long avec OpenCL
#1
Bonjour,

J'essaie de me familiariser avec le nouveau module diffusion ou netteté, notamment en examinant les presets par rapport au rendu et ce que j'ai pu en comprendre ici ou là... (l'anisotropie, c'est quand on force trop sur le pastis ?)

Comme c'est dit et redit, plus y'a d'itérations plus ça prend du temps à calculer donc à afficher, OK. Mais je trouve que ça reste raisonnable : 3 ou 4 secondes pour 24 itérations, c'est pas si terrible, surtout si comme recommandé on active le module quand on en a fini avec les autres.

Mais c'est à l'export que ça se complique. Lorsqu'OpenCL est activé, l'export d'une photo en jpg est beaucoup plus long que sans OpenCL, mon dernier test montre qu'avec OpenCL (défaut ou rapide, c'est pareil !) l'étape "diffuse" dure 139 secondes, soient de l'ordre de 2min.30 alors que sans, elle dure 30 sec.
Cinq foix plus rapide sans OpenCL, y'a pas un truc qui cloche un peu ?

La config : un HP Core i7-3740QM @ 2.70GHz, 8Go RAM, SSD, Ubuntu 20.04 et dt 3.8.0-1.1 (d'opensuse.org)
Les outils (top, nvtop) me montrent que, avec OpenCL activé dt prend 100% du CPU et du GPU et qu'il monte à 65-68% de mémoire du GPU, une Quadro K1000M avec 2Go de mémoire.

A priori l'idée d'utiliser le GPU, qui par ailleurs fait parfaitement son office, y compris avec les autres modules qui l'utilisent, devrait permettre d'accélérer certains traitements, si je ne me trompe pas...

Il faudrait donc un GPU bien plus puissant/capacitif pour ce module ?
Ça me va moyen, parce que les autres modules exploitent bien OpenCL et que c'est peut-être dommage de désactiver OpenCL pour un seul module. Il faudrait plutôt, dans ce cas, pouvoir choisir de renvoyer le module sur le CPU plutôt que sur le GPU.
dt stable / Ubuntu 22.04
Répondre
#2
Oui normale, tu exportes l'image complète et donc il y a beaucoup plus de pixels. Si tes paramètres sont pas bien positionnés alors du va utiliser le tuilage qui en plus déborde du nombre de pixel pour le recouvrement... Tu commences à voir le problème Smile

Le première chose à faire et de donner de la place à dt pour éviter le tuilage autant que possible. Dans "mémoire limite (en Mo) pour le tuilage" alloue 70% de ta mémoire vive.
--
Pascal - GNU/Debian (sid) - version darktable git/master
http://photos.obry.net
Répondre
#3
Merci @pascal pour cet aide.

J'avais remarqué précédemment dans le log que l'export de diffuse se faisait sur 2 tuiles, avec une "mémoire limite (en Mo) pour le tuilage" à 3000.
Je suis monté à 5700 (soit ~70% de 8Go), et c'était identique.

D'ailleurs, parlant de ce paramètre dont on lit dans la doc :
Citation :Afin de gérer de grandes images sur des systèmes avec une mémoire limitée, darktable effectue un traitement par tuiles. Cette variable contrôle la quantité maximale de mémoire (en Mo) qu’un module peut utiliser pendant le développement. Des petites valeurs forceront les modules gourmands en mémoire à utiliser de nombreuses tuiles. Mettre cette variable à 0 pour une infinité de tuiles. Les valeurs inférieures à 500 seront traitées comme 500. Nécessite un redémarrage en cas de modification (par défaut 1500).

La quantité maximale de mémoire qu'un module peut utiliser pendant le développement, OK mais la mémoire du GPU ou de la machine ?

Dans le doute, j'ai descendu cette valeur à ~70% des 2Go du GPU et c'est strictement identique en termes de tuiles et de temps de traitement.
Idem en mettant 0 pour une infinité de tuiles.

Quant à la "quantité minimale de mémoire (en Mo) pour la mémoire tampon d’une tuile", elle est à 64 sur cette config.

Mais j'ai trouvé, et même si l'affichage était figé pendant ces exports super longs, j'ai largement eu loisir de regarder pas mal de trucs à l'écran dont les Options d'enregistrement, et c'est là que ça se passait !

En effet, pour mon jpeg 90% en 600px pour le grand côté, l'échantillonnage haute qualité était à oui... Et comme le dit la doc à ce sujet :
Citation :Mettez sur « oui » pour effectuer un ré-échantillonnage de haute qualité sur l’image. L’image sera traitée en pleine résolution et uniquement réduite à la toute fin. Cela donne parfois une meilleure qualité, mais le traitement sera toujours plus lent.

Et comment ! On est passé dans mes tests d'aujourd'hui de...
Code :
583,405432 [dev_pixelpipe] took 200,142 secs (200,063 CPU) processed `diffusion ou netteté' on GPU with tiling, blended on CPU [export]
à
Code :
285,075463 [dev_pixelpipe] took 9,187 secs (9,189 CPU) processed `diffusion ou netteté' on GPU, blended on GPU [full]

Plus lent oui... Big Grin

La qualité s'paye ma pauv'dame !
dt stable / Ubuntu 22.04
Répondre
#4
Ah effectivement l'échantillonnage haute qualité ça coûte cher Smile
--
Pascal - GNU/Debian (sid) - version darktable git/master
http://photos.obry.net
Répondre


Atteindre :


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