darktable-chartTen rozdział traktuje o kilku zagadnieniach technicznych, które mogą ci pomóc w uruchomieniu darktable na egzotycznych konfiguracjach lub optymalizacji jego pracy. Wiele kwestii technicznych i sztuczek zostało również poruszonych na blogu, znajdującym się na stronie domowej darktable.
 |
darktable ma duże wymagania co do pamięci. Prosta kalkulacja: jeśli mamy obraz 20-megapikselowy, darktable z powodu wymagań precyzji obliczeń przechowa każdy piksel jako cztery 32-bitowe, zmiennoprzecinkowe komórki pamięci. Każdy obraz o tym rozmiarze to ok. 300MB pamięci. Ponieważ chcemy przetwarzać ten obraz, potrzebujemy przynajmniej dwóch buforów na plik - na wejście i na wyjście. Algorytmy złożonych modułów mogą potrzebować dodatkowych modułów tej samej wielkości. Bez dalszej optymalizacji, na samo przechowywanie i przetwarzanie danych potrzeba pomiędzy 600MB a 3GB. Do tego wszystkiego dochodzi jeszcze narzut kodu, linkowanych dynamicznie bibliotek systemowych i dalszych buforów, w których darktable przechowuje pliki pośrednie do szybkiego dostępu w pracy interaktywnej (cache mip map). Podsumowując, do sensownej pracy darktable potrzebuje minimum 4GB pamięci.
Z powyższego wynika jasno, że twój komputer do prawidłowej pracy darktable potrzebuje prawidłowo skonfigurowanej pamięci. Sugerujemy minimum 4GB fizycznego RAM plus od 4 do 8GB pamięci wymiany. Ta ostatnia wymaga jest do zrzutów chwilowo nieużywanych danych w celu zwolnienia pamięci fizycznej.
Teoretycznie można pracować z darktable z mniejszą ilością RAMU, skompensowaną większym plikiem wymiany. Bądź jednak przygotowany na intensywne „mielenie” dyskiem, kiedy system będzie czytał i zapisywał strony pamięci na nośnik. Mamy co prawda informacje, że to działa, ale dla niektórych może okazać się to za wolne...
Poza całkowitą wielkością pamięci systemowej istnieje również inny czynnik ograniczający: dostępna pula adresowa twojej architektury sprzętowej. To, ile pamięci może zostać zaadresowane przez proces, zależy od oferowanej przez CPU ilości bitów adresowych. Dla procesora z rejestrami 32-bitowymi jest to 2^32 bitów, co daje łącznie 4GB. Jest to bezwzględny, górny limit pamięci, która może zostać użyta przez proces, co tworzy deficyt dla darktable, jak widzieliśmy to wcześniej.
Wyjściem ratunkowym, z którego korzysta darktable, jest kafelkowanie. Zamiast przetwarzać zdjęcie w jednej części, rozdzielamy obraz na mniejsze części, odpowiadające etapom przetwarzania (modułom). To wciąż wymaga jednego pełnego modułu wejścia i wyjścia, ale bufory pośrednie mogą być na tyle małe, żeby zmieścić się w ograniczeniach sprzętowych.
Niestety nie jest to koniec problemów. Może bowiem pojawić się efekt zwany fragmentacją pamięci, który może dotknąć i dotyka programy, wymagające optymalnego zarządzania pamięcią. Jeśli taki program alokuje pięć razy po 300MB pamięci, a następnie ją zwalnia, powinna być ona widoczna po alokacji jako wolne 1.5GB. Nie zawsze jednak tak się dzieje. Alokator pamięci systemu może nie widzieć jej dłużej jako jednego ciągłego bloku 1.5GB, ale jako szereg bloków po 300MB każdy. Jeśli nie ma dostępnego innego obszaru 1.5GB, alokacja pamięci zakończy się błędem. Podczas pracy programu mechanizm ten będzie brał więcej i więcej dużych bloków pamięci, zamiast mniejszych. mip map cache w darktable 2.0 alokuje kilka mniejszych bloków na każdą miniaturkę, więc program staje się jeszcze większy. Z tego też powodu, począwszy od wersji 2.0, wsparcie dla 32 bitów staje się przestarzałe.
Jakby tego było mało, ograniczenie dostępu do pamięci może wynikać jeszcze z innych rzeczy. Na niektórych starych płytach trzeba aktywować opcję BIOSu pod nazwą „memory remapping” w celu zapewnienia dostępu do całości zainstalowanej pamięci. Ponadto jeśli korzystasz z 32-bitowego systemu, będziesz potrzebował prawdopodobnie jądra, obsługującego „Physical Address Extension” (PAE). Problem ten dotyczy często Linuksa. Wiele dystrybucji dostarcza różne wersje jądra, z włączonym bądź wyłączonym PAE; wybierz mądrze. Poprawność ustawień możesz sprawdzić w terminalu komendą „free”, analizując odpowiedź systemu. Jeśli raportuje mniej pamięci RAM, niż zainstalowałeś, trzeba będzie to poprawić; możesz na przykład mieć na płycie 4GB, a system będzie widział tylko 3GB albo nawet mniej. Żeby sobie z tym poradzić, niezbędny może okazać się rzut oka do dokumentacji BIOSu czy dystrybucji.
Jak widzieliśmy, 32-bitowe systemy są trudnymi środowiskami dla darktable. Wciąż jednak można na nich pracować, o ile spełnione są podstawowe wymagania całkowitej pamięci systemu i inne, opisane powyżej.
Żeby to osiągnąć, można skorzystać z wielu ustawień. Przy nowej instalacji darktable przeanalizuje twoją konfigurację i ustawi domyślnie zachowawcze wartości. Jeśli jednak uaktualniasz darktable z wcześniejszej wersji (na przykład z 0.9.3 na 1.0), być może wciąż masz wprowadzone nieoptymalne ustawienia. W konsekwencji darktable może nieoczekiwanie kończyć działanie wskutek błędów alokacji lub też – typowo – nie być w stanie zaimportować poprawnie nowej rolki. Częstym objawem jest wyświetlanie czaszek zamiast miniaturek dla większej ilości zdjęć.
Jeśli to jest przyczyną, poświęć chwilę na optymalizację parametrów pracy programu. Znajdziesz je w zakładce „cpu / gpu /pamięć” (Sekcja 8.8, „CPU / GPU / pamięć”) okna preferencji programu. Możesz także edytować te parametry jako zmienne konfiguracyjne w pliku $HOME/.config/darktable/darktablerc.
Poniżej znajduje się wyjaśnienie odpowiednich parametrów i ich sugerowane ustawienia:
Ten parametr określa maksymalną liczbę wątków, zaangażowanych równolegle do obsługi importu rolek filmowych i innych zadań w tle. Z przyczyn oczywistych na systemach 32-bitowych możesz zatrudnić do tego tylko jeden wątek naraz. Możesz więc ustawić ten parametr tylko na 1; wszystko powyżej zabije system.
Ten parametr określa, ile pamięci (w MB) darktable powinno przeznaczyć na przechowanie buforów zdjęcia podczas operacji modułowych. Jeśli obraz nie może być przetworzony na tych warunkach, uruchomi się kafelkowanie, które przetworzy go w częściach, jedna po drugiej. Na początek ustaw ten parametr na najniższą możliwą wartość 500. Później możesz eksperymentować, aby zwiększając ten limit ograniczyć narzut kafelkowania.
To drugi parametr, kontrolujący kafelkowanie. Ustawia on dolną granicę rozmiaru średnich buforów zdjęć (w MB). Parametr jest potrzebny, aby ograniczyć agresywne kafelkowanie w niektórych przypadkach dla niektórych modułów. Ustaw go na niską wartość 8. Później możesz go eksperymentalnie zwiększyć to 16.
Opcja określa, ile miniaturek (mipmap) może być naraz przechowywanych w pamięci. Na początku ustaw to na około 256MB. Począwszy od wersji 2.0, pamięć podręczna darktable alokuje kilka małych buforów na każdą miniaturkę, powodując znaczącą fragmentację pamięci. Jak wyjaśniono powyżej, jest to problem dla systemów 32-bitowych. Z tego też powodu, wsparcie dla systemów 32-bitowych jest ograniczane od wersji darktable 2.0.
Nic dodać, nic ująć. Oczywiście również 64-bitowe systemy wymagają odpowiedniej ilości pamięci głównej i rekomendacja "4GB i swap" pozostaje aktualna. Z drugiej zaś strony 64-bitowe systemy pozbawione są ograniczeń wersji 32-bitowej, takich jak niewielka przestrzeń adresowa czy problemy z fragmentacją.
Najnowocześniejsze procesory Intel i AMD 64-nit potrafią zaadresować wiele terabajtów pamięci. Słowo „nowoczesne” jest w tym kontekście względne; wszystkie procesory AMD i Intela stworzone odpowiednio od 2003 czy 2004 roku oferują tryb 64-bitowy. 64-bitowy Linux dostępny jest od wielu lat.
Wszystkie poważne dystrybucje Linuksa dają bezkosztowy wybór pomiędzy swoją wersją 32- a 64-bitową. Możesz nawet uruchamiać stare, 32-bitowe binarki na systemie 64-bitowym. Jedyną rzeczą, której potrzebujesz, jest trochę czasu na migrację. Mocno doradzamy przejście na 64-bitowego Linuksa. Naprawdę nie ma sensu zostawać przy wersji 32-bitowej.
W systemie 64-bitowym parametry konfiguracyjne kafelkowania można spokojnie pozostawić na ich wartościach domyślnych: „ograniczenie pamięci (w MB) dla kafli” winno mieć wartość 1500, a „najmniejsza ilość pamięci (w MB) dla pojedynczego bufora kafli” – 16. W przypadku migracji z systemu 32- do 64-bitowego należy sprawdzić te ustawienia i w razie potrzeby dostosować je ręcznie w oknie preferencji.
Nie ma potrzeby narzucania sobie ograniczeń w liczbie wątków w tle na systemach 64-bitowych. W systemie wieloprocesorowym dwa do ośmiu wątków może znacząco przyspieszyć generowanie miniaturek w porównaniu z zaledwie jednym. Przyczyna leży nie w korzystaniu ze wszystkich rdzeni procesora – sekwencja darktable i tak użyje ich równolegle – lecz w ukryciu latencji wejścia/wyjścia.
Warto wspomnieć o jednym wyjątku. Kiedy używasz darktable do obróbki składanych zdjęć panoramicznych, na przykład TIFFów wygenerowanych przez Hugin, zdjęcia mogą osiągnąć znaczący rozmiar. Każdy wątek w tle potrzebuje pamięci wystarczającej na jedno zdjęcie, przejścia oraz wyjście. To szybko może wyczerpać pamięć nawet na solidnej konfiguracji 64-bitowej. W takim przypadku zmniejsz liczbę wątków w tle do jednego.
