optymalizacja wydajności

Istnieje wiele parametrów konfiguracyjnych w $HOME/.config/darktable/darktablerc, które mogą pomóc w dostrojeniu wydajności OpenCL twojego systemu. Wydajność w tym kontekście oznacza przede wszystkim opóźnienie darktable podczas pracy interaktywnej (tj. czas potrzebny na ponowne przetworzenie kolejki). Dla wygodnego przepływu pracy ważne jest, aby utrzymać niskie opóźnienia.

Aby uzyskać informacje o profilowaniu, musisz uruchomić darktable z terminala za pomocą darktable -d opencl -d perf.

Po każdym ponownym przetworzeniu kolejki — spowodowanym zmianami parametrów modułu, powiększaniem, panoramowaniem itp. — zobaczysz całkowity czas spędzony w kolejce oraz czas spędzony w każdym z jąder OpenCL. Najbardziej wiarygodną wartością jest całkowity czas spędzony w kolejce przetwarzania. Należy pamiętać, że czasy podane dla poszczególnych modułów są zawodne podczas asynchronicznego uruchamiania potoku pikselowego OpenCL (patrz poniżej opencl_async_pixelpipe).

Aby umożliwić szybkie przetwarzanie kolejki z OpenCL, ważne jest, abyśmy mieli zajęte GPU. Wszelkie przerwania lub zatrzymany przepływ danych wydłużają całkowity czas przetwarzania. Jest to szczególnie ważne w przypadku małych buforów obrazu, z którymi musimy sobie radzić podczas pracy interaktywnej. Mogą one być szybko przetworzone przez szybki procesor graficzny. Jednak nawet krótkotrwałe przestoje kolejki mogą łatwo stać się wąskim gardłem.

Z drugiej strony wydajność darktable podczas eksportowania plików jest mniej więcej zależna od szybkości naszych algorytmów i mocy twojego GPU. Krótkoterminowe przestoje nie będą miały zauważalnego wpływu na całkowity czas eksportu.

darktable ma domyślne ustawienia, które powinny zapewnić przyzwoitą wydajność GPU na większości systemów. Jeśli jednak chcesz pokombinować trochę sam i spróbować dalej optymalizować, oto opis odpowiednich parametrów konfiguracyjnych.

opencl_async_pixelpipe
Ta flaga kontroluje, jak często darktable blokuje kolejkę OpenCL, aby uzyskać status powodzenia/porażki jąder, które zostały uruchomione. Aby uzyskać optymalną latencję, ustaw to na TRUE, aby darktable uruchamiał kolejkę asynchronicznie i próbował użyć jak najmniejszej liczby przerwań. Jeśli wystąpią błędy OpenCL, takie jak wadliwe jądra, ustaw parametr na FALSE. darktable będzie wtedy przerywał po każdym module, dzięki czemu łatwiej można wyizolować problem. Zgłaszano problemy z niektórymi starszymi kartami AMD/ATI, takimi jak HD57xx, które mogą generować zniekształcone dane wyjściowe, jeśli ten parametr jest ustawiony na TRUE. W razie wątpliwości pozostaw domyślną wartość FALSE.
opencl_number_event_handlers
Handlery zdarzeń są używane, aby darktable mógł monitorować sukces/porażkę jądra i informacje o profilowaniu, nawet jeśli kolejka jest wykonywana asynchronicznie. Liczba uchwytów zdarzeń jest ograniczonym zasobem sterownika OpenCL. Na pewno można je poddać recyklingowi, ale istnieje ograniczona liczba, które można wykorzystać w tym samym czasie. Niestety nie ma sposobu, aby dowiedzieć się, jakie są limity zasobów, więc darktable musi zgadywać. Domyślna wartość 25 jest dość konserwatywna. Możesz chcieć sprawdzić, czy wyższe wartości, takie jak 100, zapewniają lepszą wydajność OpenCL. Jeśli twojemu sterownikowi zabraknie wolnych handlerów, możesz doświadczyć awarii jąder OpenCL z kodem błędu -5 (CL_OUT_OF_RESOURCES) lub nawet awarii lub zawieszenia się systemu. Jeśli tak się stanie, ponownie zmniejsz liczbę. Wartość 0 zablokuje darktable przed używaniem jakichkolwiek uchwytów zdarzeń. Uniemożliwi to darktable prawidłowe monitorowanie sukcesu jąder OpenCL, ale zaoszczędzi trochę kosztów związanych ze sterownikami. Konsekwencją jest to, że wszelkie awarie prawdopodobnie doprowadzą do zniekształcenia danych wyjściowych bez zauważenia przez darktable. Jest to zalecane tylko wtedy, gdy wiesz na pewno, że twój system działa solidnie. Możesz również ustawić ten parametr na -1, co oznacza, że darktable nie zakłada żadnych ograniczeń co do liczby uchwytów zdarzeń. Nie jest to zalecane.
opencl_synch_cache
Ten parametr, jeśli jest ustawiony na „true”, zmusi darktable do pobierania buforów obrazu z twojego GPU po każdym module i przechowywania ich w pamięci podręcznej kolejki. Jest to operacja pochłaniająca zasoby, ale może mieć sens w zależności od twojego GPU (w tym, jeśli GPU jest raczej wolny). W tym przypadku darktable może w rzeczywistości zaoszczędzić trochę czasu po zmianie parametrów modułu, ponieważ może wrócić do jakiegoś buforowanego stanu pośredniego i ponownie przetworzyć tylko część kolejki. W wielu przypadkach ten parametr powinien być ustawiony na „aktywny moduł” (domyślnie), co spowoduje buforowanie tylko danych wejściowych aktualnie aktywnego modułu.
opencl_micro_nap
W idealnym przypadku podczas ponownego przetwarzania kolejki zachowasz zajętość GPU na 100%. To dobrze. Z drugiej strony procesor graficzny może być również potrzebny do regularnych aktualizacji GUI. Może się zdarzyć, że na to zadanie zabraknie czasu. Konsekwencją byłaby gwałtowna reakcja GUI na przesuwanie, powiększanie lub przesuwanie suwaków. Aby rozwiązać ten problem, darktable może dodawać krótkie drzemki do przetwarzania kolejek, aby GPU złapało oddech i wykonało czynności związane z GUI. Parametr opencl_micro_nap kontroluje czas trwania tych drzemek w mikrosekundach. Będziesz musiał poeksperymentować, aby znaleźć optymalną wartość dla swojego systemu. Wartości 0, 100, 500 i 1000 to dobry punkt wyjścia do wypróbowania. Wartość domyślna to 1000.
opencl_use_pinned_memory
Podczas kafelkowania między hostem a urządzeniem muszą zostać przeniesione ogromne ilości pamięci. Na niektórych urządzeniach (konkretnie AMD) bezpośrednie transfery pamięci do i z dowolnego regionu pamięci hosta mogą spowodować ogromny spadek wydajności. Jest to szczególnie widoczne podczas eksportowania dużych obrazów. Ustawienie tego parametru konfiguracyjnego na TRUE mówi darktable, aby używał specjalnego rodzaju bufora pośredniego do przesyłania danych host-urządzenie. Na niektórych urządzeniach może to przyspieszyć eksportowanie dużych plików dwu- lub trzykrotnie. Wydaje się, że urządzenia i sterowniki NVIDIA mają bardziej wydajną technikę transferu pamięci, nawet w przypadku określonych regionów pamięci. Ponieważ mogą one nie wykazywać żadnego wzrostu wydajności, a nawet mogą generować zniekształcone dane wyjściowe, dla tych urządzeń należy pozostawić opcję opencl_use_pinned_memory z domyślną wartością FAŁSZ.
opencl_building_gpuXXX
Ręcznie dodaj to ustawienie do darktablerc, aby dodać dodatkowe opcje kompilacji OpenCL dla swoich GPU, gdzie XXX to nazwa GPU. Te opcje są używane podczas kompilowania jąder OpenCL i mogą być dostarczane do dostrajania wydajności lub do obejścia błędów. Musisz usunąć wszystkie istniejące jądra, aby ponownie je skompilować z nowymi opcjami. Podaj pusty ciąg do ponownej kompilacji bez żadnych opcji. Całkowicie usuń ustawienie, aby ponownie skompilować z domyślnymi opcjami.

Możesz odwoływać się do GPU według jego identyfikatora (np. opencl_building_gpu0) lub jego nazwy kanonicznej (np. opencl_building_gpugeforce10606gb). Uruchom darktable za pomocą darktable -d opencl, aby znaleźć swoją kanoniczną nazwę GPU i domyślne opcje kompilacji.

Poniższe wiersze dodają na przykład dodatkowe opcje kompilacji dla GPU o identyfikatorze 0 oraz dla GPU o nazwie „geforce10606gb”:

opencl_building_gpu0=-cl-mad-enable -cl-no-signed-zeros -cl-unsafe-math-optimizations -cl-finite-math-only -cl-fast-relaxed-math
opencl_building_gpugeforce10606gb=-cl-mad-enable -cl-no-signed-zeros

translations