[Résolu] OpenCL désactivé lors de l'export avec diffusion et netteté

[Manu38]

Bonsoir,

J'ai remarqué que quand j'exporte des photos utilisant le module diffusion et netteté la charge est basculée sur le CPU ce qui ralenti énormément l'export.
En regardant dans les logs j'ai ces messages :

Code :

1398,588990 [default_process_tiling_cl_ptp] use tiling on module 'diffuse' for image with full size 6251 x 4167
1398,590146 [default_process_tiling_cl_ptp] (4 x 1) tiles with max dimensions 2112 x 4167 and overlap 64
1398,591193 [default_process_tiling_cl_ptp] tile (0, 0) with 2112 x 4167 at origin [0, 0]
1398,592096 [opencl memory] device 0: 140811264 bytes (134,3 MB) in use
1398,592800 [opencl memory] device 0: 281622528 bytes (268,6 MB) in use
1398,651393 [opencl memory] device 0: 422737920 bytes (403,2 MB) in use
1398,652164 [opencl memory] device 0: 563853312 bytes (537,7 MB) in use
1398,652891 [opencl memory] device 0: 572673024 bytes (546,1 MB) in use
1398,653616 [opencl memory] device 0: 713788416 bytes (680,7 MB) in use
1398,654341 [opencl memory] device 0: 854903808 bytes (815,3 MB) in use
1398,655066 [opencl memory] device 0: 996019200 bytes (949,9 MB) in use
1398,655791 [opencl memory] device 0: 1137134592 bytes (1084,5 MB) in use
1398,656523 [opencl memory] device 0: 1278249984 bytes (1219,0 MB) in use
1398,657264 [opencl memory] device 0: 1419365376 bytes (1353,6 MB) in use
1398,658027 [opencl memory] device 0: 1560480768 bytes (1488,2 MB) in use
1398,658771 [opencl memory] device 0: 1701596160 bytes (1622,8 MB) in use
1401,114098 [opencl_events_flush] could not get event info for '[Read Image (from device to host)]': -5
1401,116989 [opencl_events_flush] could not get event info for '[Read Image (from device to host)]': -5
1401,119789 [opencl_events_flush] could not get event info for '[Write Image (from host to device)]': -5
1401,122611 [opencl_events_flush] could not get event info for 'diffuse_blur_bspline': -5
1401,125033 [opencl_events_flush] could not get event info for 'diffuse_blur_bspline': -5
1401,127539 [opencl_events_flush] could not get event info for 'diffuse_blur_bspline': -5
1401,130036 [opencl_events_flush] could not get event info for 'diffuse_blur_bspline': -5
1401,132531 [opencl_events_flush] could not get event info for 'diffuse_blur_bspline': -5
1401,135012 [opencl_events_flush] could not get event info for 'diffuse_blur_bspline': -5
1401,137449 [opencl_events_flush] could not get event info for 'diffuse_pde': -5
1401,139640 [opencl_events_flush] could not get event info for 'diffuse_pde': -5
1401,141896 [opencl_events_flush] could not get event info for 'diffuse_pde': -5
1401,144084 [opencl_events_flush] could not get event info for 'diffuse_pde': -5
1401,146277 [opencl_events_flush] could not get event info for 'diffuse_pde': -5
1401,148488 [opencl_events_flush] could not get event info for 'diffuse_pde': -5
1401,151498 [opencl_events_flush] could not get event info for 'diffuse_blur_bspline': -5
1401,153952 [opencl_events_flush] could not get event info for 'diffuse_blur_bspline': -5
1401,156412 [opencl_events_flush] could not get event info for 'diffuse_blur_bspline': -5
1401,158845 [opencl_events_flush] could not get event info for 'diffuse_blur_bspline': -5
1401,161274 [opencl_events_flush] could not get event info for 'diffuse_blur_bspline': -5
1401,164582 [opencl_events_flush] could not get event info for 'diffuse_blur_bspline': -5
1401,167352 [opencl_events_flush] could not get event info for 'diffuse_pde': -5
1401,169536 [opencl_events_flush] could not get event info for 'diffuse_pde': -5
1401,172058 [opencl_events_flush] could not get event info for 'diffuse_pde': -5
1401,174279 [opencl_events_flush] could not get event info for 'diffuse_pde': -5
1401,182470 [opencl memory] device 0: 1560480768 bytes (1488,2 MB) in use
1401,184528 [opencl memory] device 0: 1419365376 bytes (1353,6 MB) in use
1401,189424 [opencl memory] device 0: 1410545664 bytes (1345,2 MB) in use
1401,191893 [opencl memory] device 0: 1269430272 bytes (1210,6 MB) in use
1401,198520 [opencl memory] device 0: 1128314880 bytes (1076,0 MB) in use
1401,205237 [opencl memory] device 0: 987199488 bytes (941,5 MB) in use
1401,211941 [opencl memory] device 0: 846084096 bytes (806,9 MB) in use
1401,221887 [opencl memory] device 0: 704968704 bytes (672,3 MB) in use
1401,228547 [opencl memory] device 0: 563853312 bytes (537,7 MB) in use
1401,235167 [opencl memory] device 0: 422737920 bytes (403,2 MB) in use
1401,241872 [opencl memory] device 0: 281622528 bytes (268,6 MB) in use
1401,248620 [opencl_diffuse] couldn't enqueue kernel! -5
1401,250289 [opencl memory] device 0: 140811264 bytes (134,3 MB) in use
1401,257137 [opencl memory] device 0: 0 bytes (0,0 MB) in use
1401,258883 [default_process_tiling_opencl_ptp] couldn't run process_cl() for module 'diffuse' in tiling mode: 0
1401,261953 [opencl_pixelpipe] could not run module 'diffuse' on gpu. falling back to cpu path

Quelqu'un pourrait m'expliquer ce qu'il se passe?

A noter que de temps en temps quand j'utilise ce module dans la chambre noire j'ai aussi un message qui apparait me disant qu'une erreur a été rencontrée et qu' openCL va être désactivé pour la session courante ce qui m'oblige à relancer darktable.

[pascal]

Pas assez de mémoire sur le GPU ?

[Manu38]

Effectivement je pense que ça vient de là. Il y a 4Go de mémoire sur le GPU.

Quand j'exporte une série de 7 photos en réduisant la taille de 50% je vois bien 7 montées en charge de l'utilisation de la mémoire GPU dans le gestionnaire de tache mais sans que cela ne la sature. La mémoire redescend après chaque photo et le CPU est sollicité moyennement.


Si je tente le même export en taille 100% dès la première photo la mémoire GPU est saturée et ensuite la carte graphique n'est plus sollicitée, c'est le CPU qui prend toute la charge.



Je ne me rend pas compte si 4Go de mémoire GPU est une valeur importante ou pas. C'est une carte quadro T1000 donc assez récente et plutôt destinée à un usage pro.

[manu]

Bonjour,

4Go pour un GPU me paraissent suffisants, avec une nvidia quadro K1000M et ses 2Go de RAM l'export full size d'une image de 6048x4024px passe sur mon Ubuntu.

En revanche, pour moi c'est l'inverse, j'aimerais assez que l'export bascule sur le CPU (core i7 3ème gén. 8Go RAM) plutôt que rester sur le GPU car le temps passé sur le GPU est le triple par rapport au temps passé sur le CPU : 

Code :

599,515926 [dev_pixelpipe] took 300,409 secs (300,203 CPU) processed `diffusion ou netteté' on GPU with tiling, blended on CPU [export]

Code :

132,989785 [dev_pixelpipe] took 97,563 secs (704,992 CPU) processed `diffusion ou netteté' on CPU, blended on CPU [export]

À noter comme j'ai fini par m'en rendre compte sur ce sujet, un export avec un échantillonnage haute qualité à oui (ce qui n'est pas le cas dans l'exemple montré ci-dessus), c'est long...

Dans le log initial de ce post-ci, on voit qu'il y a 4 tuiles et que la RAM du GPU est consommée à hauteur de 1622,8 MB, et les courbes ne semblent pas montrer un forte consommation par d'autres applis (à peine 1Go peut-être avant de monter ?).

Mais ces...

Code :

[opencl_events_flush] could not get event info for '[Read Image (from device to host)]': -5

et autres erreurs -5, ne me paraissent pas vraiment normales jusqu'à ce...

Code :

[opencl_diffuse] couldn't enqueue kernel! -5

La question serait peut-être à poser directement sur le github dt ?

[Manu38]

Merci pour ton aide.
Oui je vais poster sur github ça sera plus efficace.
Je vous tiens au courant.

[manu]

En suivant les liens figurant dans les réponses de ton ticket GH, je suis arrivé sur cette page (la version française) "optimisation des performances", l'as-tu lue ?

Des infos bien intéressantes, et en passant on y évoque les kernel -5 :

opencl_number_event_handles
Des gestionnaires d’événements sont utilisés de manière à pouvoir surveiller le succès ou l’échec des noyaux et pour obtenir des informations de profilage même si le pipeline graphique tourne de manière asynchrone. Le nombre de gestionnaires d’événements est une ressource limitée de votre pilote OpenCL. Bien entendu, ils peuvent être recyclés, mais il n’y en a qu’un certain nombre qui puissent être utilisés simultanément. Malheureusement, il n’y a aucun moyen de savoir quelles sont les limites de ressources ; darktable doit donc estimer. Notre valeur 25 par défaut est assez prudente. Vous pouvez essayer de voir si des valeurs plus importantes comme 100 donnent de meilleures performances OpenCL. Si votre pilote n’a pas assez de gestionnaires libres, vous aurez des échecs de noyaux OpenCL avec le code -5 (CL_OUT_OF_RESOURCES) ou même des plantages ou un système figé. Réduisez alors ce nombre. Une valeur 0 interdira à darktable d’utiliser un quelconque gestionnaire d’événements. Ceci empêchera darktable de surveiller correctement le succès de vos noyaux OpenCL mais évitera une certaine surcharge des pilotes. Les conséquences sont qu’un échec conduira probablement à une sortie corrompue sans notification de darktable. Ce n’est recommandé que si vous êtes certain que votre système tourne solide comme un roc. Vous pouvez aussi fixer ce paramètre à -1, ce qui signifie que darktable supposera qu’il n’y a aucune restriction du nombre de gestionnaires d’événements. Ceci n’est pas recommandé.

Ici aussi des infos qui jusqu'alors m'étaient inconnues.

[Manu38]

Merci!

Effectivement réduire la valeur de ce paramètre permet d'éviter le code erreur -5.
L'autre solution proposée sur github est d'augmenter le paramètre opencl_memory_headroom.

La discussion complète est ici : https://github.com/darktable-org/darktable/issues/11052

Au passage, belle réactivité des devs sur github. C'est beau l'open source!

[manu]

Merci pour le feedback, effectivement on imagine pas une telle participation de devs dans le logiciel propriétaire...
Cependant tous les projets Open Source n'ont pas cette "réactivité", ce n'est pas une règle générale.

opencl_memory_headroom est effectivement un sujet abordé à plusieurs reprises ici.

Il faut trouver ses valeurs à ces paramètres en fonction de sa configuration, un peu à taton.
Pourtant, on a l'impression que certaines valeurs de paramètres OpenCL "cachés", i.e. seulement éditables dans darktablerc et non via Paramètres > CPU / GPU / Mémoire, pourraient être calculées en fonction des "constantes" systèmes.

[Manu38]

En complément, une vidéo explicative des paramètres d'optimisation de traitement faite par Aurélien Pierre cette semaine :
https://www.youtube.com/watch?v=ImX0wr2z1S4