In $HOME/.config/darktable/darktablerc trovate alcuni parametri di configurazione che possono aiutarvi a regolare con precisione le prestazioni di OpenCL. In questo contesto 'prestazione' significa soprattutto la latenza di darktable durante il lavoro interattivo ovvero il tempo necessario a processare il flusso di sviluppo. Affinché il vostro flusso di lavoro sia confortevole è necessario mantenere una bassa latenza.
Per ottenere informazioni sulla profilazione dovrete avviare darktable da un terminale con
darktable -d opencl -d perf
Dopo ogni volta che il flusso di sviluppo viene rielaborato - a causa di un cambiamento in un parametro di un modulo, una zoomata, uno scorrimento dell'immagine, ecc - dovrete attendere nuovamente per intero il tempo necessario alla rielaborazione dell'immagine e quello necessario all'esecuzione di ogni singolo kernel OpenCL. Il valore più importante, ovviamente, è quello impiegato dal flusso di sviluppo. Notate anche che il tempo indicato per ogni singolo modulo non è più affidabile se si esegue la pixelpipe OpenCL in modo asincrono (vedi opencl_async_pixelpipe sotto).
Per far sì che il flusso di sviluppo venga elaborato velocemente con OpenCL è necessario mantenere la GPU impegnata. Ogni interruzione o stallo nel flusso dei dati andrà ad aggiungersi al tempo totale di elaborazione. Questo è molto importante in particolar modo per i piccoli buffer di memoria che è necessario elaborare durante il lavoro interattivo. E' infatti possibile elaborare i buffer rapidamente con una GPU veloce ma anche uno stallo molto breve nel flusso di sviluppo diventa facilmente un collo di bottiglia.
Dall'altra parte le prestazioni di darktable durante l'esportazione dei files dipende più o meno solamente dalla velocità dei nostri algoritmi e dalla potenza della vostra GPU. Le interruzioni brevi non hanno, in questo caso, effetti importanti sul tempo necessario ad esportare un file.
darktable viene preimpostato in modo da utilizzare la GPU in modo decente sulla maggior parte dei sistemi. Tuttavia se volete fare delle prove e tentare di effettuare ulteriori ottimizzazioni trovate, di seguito, i più importanti parametri di configurazione.
opencl_async_pixelpipe
Questo flag booleano controlla quante volte il flusso di sviluppo OpenCL viene bloccato e cattura l'esito positivo/negativo di tutti i kernel che sono stati eseguiti. Per una latenza ottimale impostate questo valore a TRUE in modo da istruire darktable ad eseguire il flusso di sviluppo in modo asincrono per utilizzare meno interruzioni possibili. Se sperimentate errori sui kernel di OpenCL, riportate il parametro a FALSE. In questo modo darktable si interromperà dopo l'esecuzione di ogni singolo modulo per facilitarvi ad isolare il problema. Sono stati riportati alcuni problemi con vecchie schede grafiche AMD/ATI tipo la HD57xx che producono un output incomprensibile quando questo parametro viene impostato a TRUE. In caso di dubbio lasciate il parametro a FALSE.
opencl_number_event_handles
La gestione degli eventi viene utilizzata per controllare la buone/cattiva riuscita dei kernel e per profilare le informazioni nel caso in cui il flusso di sviluppo venisse eseguito in modo asincrono. Il numero delle gestioni eventi è una risorsa limitata del vostro driver OpenCL. Ovviamente è possibile riciclarli ma il numero utilizzabile contemporaneamente è limitato. Purtroppo non c'è un modo per quantificare questo numero e quindi occorre andare per tentativi. Il nostro valore predefinito (25) è ampiamente dentro i margini di sicurezza. Potete provare a vedere se un valore di 100 riesce a rendere OpenCL più reattivo. Nel caso in cui il vostro driver dovesse esaurire lo spazio per la gestione eventi i kernel OpenCL andranno in errore «-5 (CL_OUT_OF_RESOURCES)» oppure il sistema andrà in crash oppure potrebbe bloccarsi: in questa eventualità riducete il valore di configurazione. Al contrario, se impostate un valore uguale a 0 darktable non potrà utilizzare la gestione eventi. In questo modo non sarà più possibile monitorare l'esito dei kernel OpenCL se non qualche informazione generica sui drivers. Di conseguenza qualsiasi errore potrebbe causare un output incomprensibile dato che darktable non sarà in grado di tracciarlo: la raccomandazione, quindi, è quella di utilizzare questa funzione solo se siete sicuri che il vostro darktable è stato configurato a prova di errore! Potete anche assegnare a questo parametro un valore di -1 che indica a darktable di non limitare la quantità delle gestione eventi ma non ve lo raccomandiamo.
opencl_synch_cache
This parameter, if set to "true", will force darktable to fetch image buffers from your GPU after each module and store them in its pixelpipe cache. This is a resource consuming operation, but makes sense depending on your GPU (including if the GPU is rather slow). In that case darktable might in fact save some time when module parameters have changed, as it can go back to some cached intermediate state and reprocess only part of the pixelpipe. In many cases this parameter should be set to "active module" (default), which will only cache the input of the currently focused module.
opencl_micro_nap
Come detto in precedenza la situazione ideale sarebbe quella di avere la GPU impegnata al 100% durante l'elaborazione del flusso di sviluppo. D'altra parte occorre considerare che la GPU deve anche svolgere la sua normale attività ma potrebbe accadere che non ci sia tempo sufficiente. In questo caso potreste notare dei funzionamenti a singhiozzo dell'interfaccia grafica quando zoomate oppure vi spostate sull'immagine centrale o ancora quando utilizzate i selettori scorrevoli dei moduli. darktable, per ovviare a questo, introduce automaticamente alcuni brevissimi periodi di riposo nel processo di elaborazione del flusso di sviluppo per dare alla GPU il tempo di respirare ed eseguire le richieste dell'interfaccia utente. Il parametro opencl_micro_nap controlla la durata di queste interruzioni in microsecondi. Dovrete fare delle prove per trovare un valore ottimale per il vostro sistema. Valori uguali a 0, 100, 500 e 1000 sono dei buoni punti di partenza. Il predefinito è 1000.
opencl_use_pinned_memory
Durante l'operazione di piastrellamento c'è la necessità di spostare enormi quantità di memoria tra la scheda video e il PC. Su alcune schede (soprattutto AMD) il trasferimento diretto della memoria da e per una regione di memoria arbitraria sul PC può causare un forte calo delle prestazioni. Questo fenomeno peggiora ulteriormente se si sta elaborando un'immagine molto grande. Impostando questo parametro a TRUE si indica a darktable di utilizzare un particolare buffer intermedio per il trasferimento dei dati dalla scheda al PC. Su alcune schede è stato rilevato un aumento delle prestazioni (nel caso di esportazione di files) di 2 o 3 volte superiori. Le schede e i drivers NVIDIA sembrano avere una tecnica di trasferimento della memoria molto più efficiente anche nel caso di regioni di memoria arbitrarie. Dal momento che queste schede non evidenziano problemi di prestazioni e neppure producono output incomprensibile, opencl_use_pinned_memory dovrebbe essere lasciato a FALSE in questi casi.
