Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
OpenCL vs denoiseprofile
#11
Tout à fait d'accord, la fluidité est aussi importante que la vitesse d'exportation. En ce sens, ce petit test qui n'est pas très scientifique, permet cependant de mettre facilement en évidence un défaut de configuration. Une fois celui-ci corrigé, l'exportation ET la fluidité en seront améliorées.
Mes photos : jpverrue.fr
Répondre
#12
Merci JPVerrue. J'ai fait le test. Je passe de 27s à 5s. Mais je dois mettre opencl_memory_headroom à 1150 au moins avec mon écran 4K.

Est-ce que quelqu'un sait à quoi correspond darktablerc: host_memory_limit ? Il y a une explication ici mais je ne comprends pas bien : https://www.darktable.org/2012/03/darktable-and-memory/

Il vaut mieux que ce soit petit ou grand ?
Répondre
#13
il vaut mieux que ça soit grand, dans la limite que ce que ton système supporte.

Si c'est trop petit, darktable découpe ton image en tuiles (tiles en EN) qu'il traite séparément. Plus c'est petit, plus tu as de tuiles. Et le tuilage consomme du processeur (overhead en EN). Du coup, moins de tuiles = moins d'overhead = plus de rapidité. C'est un compromis classique où la minimisation de l'espace RAM maximise le nombre de calculs, et réciproquement (en gros).
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
#14
Avec la photo de bateau, j'avais finalement dû monter à 1280 parce que parfois, de manière non prévisible (en tous cas par moi), un module n'employait pas le GPU. Mais j'ai poursuivi mes expérimentations et avec des photos de 24MP issues d'un Fuji, et j'ai dû monter jusque 

Code :
opencl_memory_headroom=1664

Avec une carte de 3Go, ça tuile un peu mais quand même, c'est très efficace. Sur une image très bruitée avec un traitement du bruit modéré (un module pour chroma et un autre pour luminance, le dernier avec un masque surtout sur les ombres), je passe de 29s à 8s, ce qui n'est pas si mal. Sur des images moins bruités, je suis à 5s. En laissant juste un seul denoise-profile sur le CPU (un i5@3.4Ghz), les 5s se transforment en 11s.

Moralité : ne testez pas que sur le bâteau mais sur les images que vous traitez en vrai, et plutôt avec des images avec bcp de bruit traité et des modules gourmands. Prenez donc un peu de marge. AMHA ça vaut le coup de se laisser un poil de marge quitte à tuiler un peu. On perd très légèrement à chaque coup, mais on est sûr d'éviter les pires des cas où là, ça peut être pénible. Typiquement, même en divisant par 2 la mémoire restante, c'est de 10% à 15% que je perds. En prenant 10% de marge sur opencl_memory_headroom, je ne perds rien en perfs.

Mais quand même si c'était à refaire, je prendrais un CG avec 6GB de RAM pour être tranquille.
Répondre


Atteindre :


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