pamięć

Wymagania dotyczące pamięci darktable są wysokie. Wyjaśni to prosta kalkulacja. Jeśli masz obraz o rozdzielczości 20 MPx, ze względu na precyzję, darktable zapisze go wewnętrznie jako 4 x 32-bitową komórkę zmiennoprzecinkową dla każdego piksela. Każdy pełny obraz tego rozmiaru będzie zatem potrzebował około 300 MB pamięci. Ponieważ chcemy przetworzyć obraz, będziemy potrzebować co najmniej dwóch buforów dla każdego modułu – jednego wejściowego i jednego wyjściowego. Jeśli mamy bardziej złożony moduł, jego algorytm może dodatkowo wymagać kilku buforów pośrednich o tej samej wielkości. Bez dalszej optymalizacji wystarczyłoby tylko do przechowywania i przetwarzania danych obrazu od 600 MB do 3 GB. Oprócz tego mamy segment kodu darktable, kod i dane wszystkich dynamicznie dołączanych bibliotek systemowych, a także dodatkowe bufory, w których darktable przechowuje obrazy pośrednie dla szybkiego dostępu podczas interaktywnej pracy (cache mip map).

Zasadniczo darktable potrzebuje minimum 4GB pamięci, żeby jakkolwiek wystartować.

🔗całkowita pamięć systemowa

Z powyższych rozważań widać od razu, że twój komputer potrzebuje sensownej konfiguracji pamięci do normalnej pracy z darktable. Rekomendujemy co najmniej 4GB pamięci fizycznej oraz od 4 do 8GB w pliku wymiany.

Teoretycznie możesz uruchomić darktable z mniejszą ilością pamięci RAM, kompensując to dużym plikiem wymiany. Może to jednak powodować przycięcia pracy podczas odczytu i zapisu stron pamięci na twardy dysk. Wiemy od użytkowników, że takie rozwiązanie działa, ale dla wielu może to być nieznośnie wolne. Ból złagodzi w pewnym stopniu dysk SSD.

🔗dostępna przestrzeń adresowa

Poza całkowitą ilością pamięci systemowej pozostaje jeszcze jeden czynnik ograniczający: przestrzeń adresowa, dostępna w twojej architekturze sprzętowej. To, ile pamięci może zostać zaadresowane przez proces, zależy od liczby bitów adresu, którą oferuje twoje CPI. Dla procesorów z 32-bitowymi rejestrami adresowymi jest to 2^32 bitów, czyli 4GB. Jest to górna granica pamięci, możliwej do użycia przez proces i powoduje ona nieciekawą sytuację dla darktable, którą widzieliśmy wcześniej.

Wyjście awaryjne darktable to kafelkowanie. Zamiast przetwarzać obraz w jednym dużym kawałku, darktable dzieli obraz na mniejsze części dla każdego modułu produkcyjnego. To nadal wymaga jednego pełnego bufora wejściowego i wyjściowego, ale bufory pośrednie mogą być na tyle małe, aby zmieścić wszystko w ograniczeniach sprzętowych.

🔗fragmentacja pamięci

Niestety to nie koniec problemów. Efekt zwany fragmentacją pamięci może uderzyć i na pewno uderzy w oprogramowanie, które wymaga rozbudowanego zarządzania pamięcią. Jeśli taki program przydzieli 5 razy 300 MB na raz i zwolni je ponownie, ta pamięć powinna normalnie być dostępna dla jednego dużego przydziału 1,5 GB później. Jednak często tak nie jest. Systemowy alokator pamięci może już nie widzieć tego obszaru jako jednego ciągłego bloku 1,5 GB, ale jako rząd oddzielnych obszarów 300 MB. Jeśli nie ma innego wolnego obszaru 1,5 GB, kolejna alokacja zakończy się niepowodzeniem. Podczas działania programu mechanizm ten zabiera coraz więcej większych bloków pamięci na rzecz mniejszych. Pamięć podręczna mip map darktable alokuje kilka małych bloków pamięci na miniaturkę, więc ten problem jest jeszcze większy. Z tego powodu, począwszy od darktable 2.0, obsługa 32-bitów jest przestarzała.

🔗dalsze ograniczenia

Jakby to nie było jeszcze wystarczająco trudne, są również inne rzeczy, które mogą ograniczyć dostęp darktable do pamięci. Na niektórych starszych płytach musisz aktywować opcję BIOS „mapowanie pamięci”, aby mieć włączoną całą fizycznie zainstalowaną pamięć. Ponadto, jeśli korzystasz z 32-bitowego systemu operacyjnego, prawdopodobnie będziesz potrzebować wersji jądra z włączoną opcją „Rozszerzenie adresu fizycznego” (ang. Physical Address Extension – PAE). Tak jest często, ale nie zawsze, w przypadku Linuksa. Wiele dystrybucji dostarcza różne jądra, niektóre z aktywowanym PAE, a inne bez; musisz wybrać właściwą. Aby sprawdzić, czy system jest poprawnie skonfigurowany, użyj polecenia „free” w terminalu i sprawdź dane wyjściowe. Jeśli dane wyjściowe zgłaszają mniej pamięci RAM niż zainstalowałeś, masz problem wymagający naprawy; na przykład masz 4GB na swojej płycie, ale twoje jądro widzi tylko 3GB lub mniej. Aby uzyskać dalszą pomoc, zapoznaj się z instrukcją BIOS i informacjami na temat swojej dystrybucji Linuksa.

🔗konfiguracja darktable na systemach 32-bitowych

Jak widzieliśmy, systemy 32-bitowe są trudnym środowiskiem dla darktable. Mimo to niektórzy użytkownicy używają na nich darktable, jeśli podstawowe wymagania w zakresie całkowitej pamięci systemu i tematy wymienione w powyższych akapitach są odpowiednio rozwiązane.

Istnieje kilka parametrów, które wymagają dostosowania, aby działały. Jeśli zainstalujesz od zera, darktable wykryje twój system i domyślnie ustawi konserwatywne wartości. Jeśli jednak zaktualizujesz darktable ze starszej wersji, prawdopodobnie masz w ustawieniach złe wartości. Konsekwencją może być przerwanie przez darktable z powodu błędów alokacji lub – bardzo typowo – niemożność prawidłowego importowania przez darktable nowej rolki filmu. Częstym objawem wielu zdjęć jest wyświetlanie czaszek zamiast miniatur.

W takim przypadku poświęć chwilę na zoptymalizowanie ustawień preferencji. Znajdziesz je w ustawienia > przetwarzanie > cpu/gpu/memory.

Poniżej krótkie wyjaśnienie odpowiednich parametrów oraz ich proponowane wartości:

liczba wątków w tle: Ten parametr określa maksymalną liczbę wątków, mogących pracować równolegle, podczas importu rolek filmów bądź wykonywania innych czynności w tle. Z oczywistych względów na systemach 32-bitowych dopuszczalny jest tylko jeden zasobożerny wątek na raz. Musisz więc ustawić ten parametr na 1; jakakolwiek wyższa wartość zabije twój system.
ograniczenie pamięci (w MB) dla kafli: Ten parametr mówi darktable, jaka ilość pamięci (w MB) powinna być dostępna do przechowywania buforów obrazu podczas działania modułu. Jeśli obrazu nie można przetworzyć w tych granicach w jednym kawałku, kafelkowanie przejmie i przetworzy obraz w kilku częściach, jedna po drugiej. Jako punkt początkowy ustaw najniższą możliwą wartość 500. Możesz później poeksperymentować, czy możesz go nieco zwiększyć, aby zmniejszyć narzut, związany z kafelkowaniem.
najmniejsza ilość pamięci (w MB) dla pojedynczego bufora kafli: Jest to drugi parametr, który kontroluje kafelkowanie. Określa dolny limit rozmiaru pośrednich buforów obrazu w megabajtach. Parametr jest potrzebny, aby w niektórych przypadkach uniknąć nadmiernego kafelkowania (dla niektórych modułów). Ustaw ten parametr na niską wartość 8. Możesz później wstępnie zwiększyć go do 16.
rozmiar pamięci (MB) dla pamięci podręcznej miniaturek: Kontroluje, ile miniatur (lub map mip) może być jednocześnie przechowywanych w pamięci. Jako punkt wyjścia ustaw to na około 256 MB. Od wersji darktable 2.0 pamięć podręczna przydziela kilka małych buforów na miniaturę w pamięci podręcznej, powodując w ten sposób znaczną fragmentację pamięci. Jak wyjaśniono wcześniej, stanowi to problem dla systemów 32-bitowych. Z tego powodu, począwszy od darktable 2.0, obsługa 32-bitów jest przestarzała.

🔗darktable na systemach 64-bitowych

Nie mamy tu wiele do powiedzenia. Oczywiście systemy 64-bitowe również wymagają wystarczającej pamięci głównej, więc zalecenie 4GB plus pamięć wymiany pozostaje w mocy. Z drugiej strony architektura 64-bitowa wolna jest od ograniczeń specyfikacji 32-bitowej, takich jak mała przestrzeń adresowa czy obłęd fragmentacji.

Większość nowoczesnych 64-bitowych procesorów Intel lub AMD będzie miała dostępną przestrzeń adresową w zakresie kilku terabajtów. Słowo „nowoczesny” jest w tym kontekście względne: wszystkie procesory AMD i Intel wprowadzone odpowiednio od 2003 i 2004 roku oferują tryb 64-bitowy. Linux w tej wersji jest dostępny od wielu lat.

Wszystkie odpowiednie dystrybucje Linuksa dają możliwość zainstalowania wersji 32-bitowej lub 64-bitowej bez dodatkowych kosztów. Możesz nawet uruchamiać stare 32-bitowe pliki binarne na 64-bitowym systemie Linux. Jedyne, co musisz zrobić, to zainwestować trochę czasu w migrację. Na koniec zdecydowanie zalecamy przejście na 64-bitową wersję Linuksa. Naprawdę nie ma powodu, żeby tego nie robić.

W systemie 64-bitowym można bezpiecznie pozostawić domyślne parametry konfiguracyjne, związane z kafelkowaniem: „ograniczenie pamięci (w MB) dla kafli” powinien mieć wartość 1500 i „najmniejsza ilość pamięci (w MB) dla pojedynczego bufora kafli” powinna być ustawiona na 16. Jeśli przeprowadzasz migrację z systemu 32-bitowego do 64-bitowego, będziesz musiał sprawdzić te ustawienia i ręcznie zmienić je w razie potrzeby w oknie ustawień darktable.

Zazwyczaj nie ma potrzeby ograniczania liczby wątków w tle w systemie 64-bitowym. W systemie wieloprocesorowym liczba od dwóch do ośmiu wątków może znacznie przyspieszyć generowanie miniatur w porównaniu z tylko jednym wątkiem. Powodem nie jest maksymalne wykorzystanie wszystkich rdzeni procesora – kolejka w darktable i tak wykorzystuje je wszystkie równolegle – ale ukrywanie opóźnień we/wy.

Warto wspomnieć o jednym wyjątku. Jeśli używasz darktable do przetwarzania połączonych panoram (np. TIFF generowanych przez Hugin), te obrazy mogą osiągnąć znaczne rozmiary. Każdy wątek w tle musi przydzielić wystarczającą ilość pamięci, aby zachować jeden pełny obraz oraz dane pośrednie i wyjściowe w swoich buforach. Może to spowodować szybkie wyczerpanie pamięci nawet w dobrze wyposażonym systemie 64-bitowym. W takim przypadku zmniejsz liczbę wątków w tle tylko do jednego.