налаштування пам’яті та продуктивності

🔗вимоги до пам’яті

Обробка raw зображення в darktable вимагає великого обсягу системної пам’яті. Простий розрахунок робить це зрозумілим: для 20-мегапіксельного зображення darktable вимагає 4х32-бітові комірки з рухомою комою для зберігання кожного пікселя, тобто для кожного повного зображення такого розміру буде потрібно приблизно 300 МБ пам’яті лише для зберігання даних зображення. Для того, щоб фактично обробити це зображення певним модулем, darktable потребує щонайменше двох буферів (вхідний та вихідний) такого розміру, а для складніших модулів потенційно потрібно кілька додаткових буферів для проміжних даних. Якщо ми маємо більш складний модуль, його алгоритм може додатково вимагати кілька проміжних буферів того ж розміру. Без подальшої оптимізації може знадобитися від 600 МБ до 3 ГБ для зберігання та обробки даних зображення під час виконання конвеєра. Крім того, є ще сегмент коду darktable, код та дані всіх динамічно зв’язаних системних бібліотек, а також додаткові буфери, які darktable використовує для зберігання проміжних станів (кешу) для швидкого доступу під час інтерактивної роботи.

Загалом, для роботи darktable потрібно щонайменше 4 ГБ фізичної оперативної пам’яті плюс від 4 до 8 ГБ додаткового простору для свопінгу, але чим більше пам’яті у вас є, тим краще працюватиме програма.

Крім виконання на вашому CPU, багато модулів darktable також мають реалізації OpenCL, які можуть у повній мірі використовувати переваги паралельної обробки, яку пропонує ваша відеокарта (GPU). Аналогічно, чим більше у вас пам’яті графічного процесора, тим краще буде працювати darktable.

🔗тайлінг

Якщо у darktable не вистачає пам’яті для обробки всього зображення за один раз, модулі можуть вибрати “стратегію розбивки”, при якій зображення розбивається на менші частини (плитки, “тайли”), які обробляються незалежно, а потім в кінці знову з’єднуються разом. Хоча це дозволяє обробляти зображення з набагато меншим обсягом пам’яті, цей підхід також має деякі недоліки:

тайлінг завжди повільніше – іноді до 10 разів повільніше, хоча для деяких модулів різниця незначна,
тайлінг технічно неможливий для деяких модулів через природу основних алгоритмів

Для більшості систем тайлінг, імовірно, буде використовуватися лише для експорту повнорозмірних зображень, а інтерактивна робота в темній кімнаті оброблятиметься ефективніше. Для найкращої продуктивності (і уникнення режимів тайлінгу) ви повинні запускати darktable разом із якомога меншою кількістю інших програм і налаштувати darktable так, щоб використовувати якомога більше вашої системної та графічної пам’яті.

🔗налаштування продуктивності

Є ряд параметрів конфігурації, які можуть допомогти вам точно налаштувати продуктивність вашої системи. Деякі з цих параметрів доступні в налаштування > обробка > cpu / gpu / пам’ять, а інші потрібно змінювати безпосередньо у файлі конфігурації darktable (в $HOME/.config/darktable/darktablerc).

У цьому розділі наведено деякі вказівки щодо налаштування цих параметрів.

🔗як тестувати

Щоб визначити, наскільки ваші модифікації покращують (чи ні) продуктивність darktable, вам знадобиться один або кілька зразків зображень для тестування та метод оцінки швидкості конвеєра обробки.

Для зразків зображень радимо використовувати деякі модулі з більш інтенсивною обробкою, наприклад дифузія / різкість або знешумлення (профільоване). Експорт, імовірно, матиме більш консистентні та порівнянні таймінги проходження конвеєра, ніж інтерактивна робота (а також більше завантажуватиме ваше обладнання).

Для того, щоб отримати інформацію профілювання, вам потрібно запустити darktable з терміналу з командним рядком darktable -d opencl -d perf. Якщо вам потрібна додаткова інформація про тайлінг, використовуйте darktable -d opencl -d tiling -d perf.

Кожного разу, коли обробляється конвеєр (коли ви змінюєте параметри модуля, масштабуєте, панорамуєте, експортуєте тощо), ви побачите (у вашому терміналі) загальний час, витрачений на конвеєр, і час, проведений у кожному з ядер OpenCL. Найнадійнішим значенням є загальний час, проведений у конвеєрі, і вам слід використовувати саме його для оцінки змін.

Примітка: Таймінги, надані для кожного окремого модуля, є ненадійними під час асинхронного запуску OpenCL конвеєра (див. асинхронний режим нижче).

Для забезпечення ефективної обробки за допомогою OpenCL, важливо забезпечити зайнятість графічного процесора. Будь-які переривання або зупинений потік даних збільшать загальний час обробки. Це особливо важливо для невеликих буферів зображень, які використовуються під час інтерактивної роботи і які можуть швидко оброблятися швидким графічним процесором. Однак навіть короткочасні зупинки конвеєра можуть легко стати вузьким місцем.

З іншого боку, продуктивність darktable під час експорту файлів більш-менш залежить лише від швидкості алгоритмів та потужності вашого графічного процесора. Короткотермінові затримки не матимуть помітного впливу на загальний час експорту.

🔗ресурси darktable

Параметр “рівень ресурсів для darktable” (у налаштування > обробка > cpu / gpu / пам’ять) дозволяє вибрати один із чотирьох різних підходів до виділення ресурсів вашої системи для darktable. Кожна з цих опцій керує кількома окремими параметрами, які визначаються незалежно в $HOME/.config/darktable/darktablerc. Ви можете змінити будь-який з них безпосередньо у файлі darktablerc, щоб підкоригувати значення для вибраного рівня ресурсу, хоча ви не можете додати свій власний рівень ресурсу до спадного меню налаштувань.

Кожен із чотирьох параметрів “ресурсів darktable” визначається таким чином:

resource_default=512 8 128 700
resource_large=700 16 128 900
resource_small=128 4 64 400
resource_unrestricted=16384 1024 128 900

У більш загальному вигляді вони можуть бути представлені як resource_level=a b c d, де a - d визначаються таким чином:

a. системна пам’ять для обробки модулів: Максимальний обсяг системної пам’яті, доступної для обробки модуля. Нижчі значення змушують модулі, які потребують багато пам’яті, обробляти зображення зі збільшенням кількості плиток. Це число є часткою від загального обсягу системної пам’яті, поділеної на 1024. Наприклад, у системі з 16 ГБ загальної системної пам’яті кількість, призначена параметром resource_default (у ГБ), дорівнює 16 * 512 / 1024, або 8 ГБ системної оперативної пам’яті.
b. мінімальний розмір буфера тайлінгу: Мінімальний розмір одного буфера тайлінгу, аналогічно виражений як частка загальної системної пам’яті. Наприклад, у системі з 16 ГБ загальної системної пам’яті кількість, призначена параметром resource_default (у ГБ), становить 16 * 8 / 1024 або 0,125 ГБ системної оперативної пам’яті. Зауважте, що цей параметр є значною мірою історичним і більше не має особливої практичної користі – радимо залишити його значення за замовчуванням.
c. кеш-пам’ять мініатюр: Обсяг пам’яті, який потрібно використовувати для кешу мініатюр. Знову ж таки, це виражається як частка загальної системної пам’яті, і в системі з 16 ГБ кількість, призначена параметром resource_default, становить 16 * 128 / 1024, або 2 ГБ системної пам’яті.
d. Пам’ять OpenCL (GPU).: Максимальний обсяг пам’яті графічного процесора, доступної для обробки модуля. Як і у випадку з системною пам’яттю, нижчі значення змусять модулі, які потребують багато пам’яті, обробляти зображення зі збільшенням кількості тайлів. Ваша пам’ять графічного процесора, ймовірно, також використовуватиметься іншими програмами у вашій системі. Однак, на відміну від системної пам’яті, ваш графічний процесор не може скористатися перевагами файлів свопінгу, і darktable може бути важко точно знати, скільки пам’яті доступно в певний момент. Якщо цей параметр встановлено занадто високо, darktable може бути змушений повернутися до обробки центральним процесором (яка буде значно повільнішою). З цієї причини частка параметра пам’яті графічного процесора також включає додаткові 400 МБ запасу, щоб уникнути надмірного виділення пам’яті. Наприклад, на графічному процесорі з 6 ГБ пам’яті darktable використовуватиме приблизно (6 - 0,4) * 700 / 1024 або 3,8 ГБ оперативної пам’яті графічного процесора при використанні рівня resource_default.

На додаток до рівнів ресурсів, представлених в інтерфейсі користувача, за допомогою командного рядка можна встановити наступні параметри (наприклад, darktable --conf resourcelevel="notebook"). Ці режими призначені для зневадження проблем із тайлінгом та тестування продуктивності звичайних систем на потужніших машинах розробки. Надаються такі варіанти:

“mini” (1 ГБ оперативної пам’яті, 2 МБ буфер, 128 МБ кешу мініатюр, 200 МБ пам’яті OpenCL)
“notebook” (4 ГБ оперативної пам’яті, 32 МБ буфер, 512 МБ кешу мініатюр, 1 ГБ пам’яті OpenCL)
“reference” (8 ГБ оперативної пам’яті, 32 МБ буфер, 512 МБ кешу мініатюр, 2 ГБ пам’яті OpenCL)

🔗налаштування використання пам’яті GPU

Якщо ви хочете максимально використовувати пам’ять GPU для OpenCL, у вас є три варіанти:

Виберіть “великий” рівень ресурсів. Для карти з обсягом пам’яті 6 ГБ буде використовуватися приблизно 5 ГБ пам’яті графічного процесора, залишаючи 1 ГБ для решти вашої системи.
Відредагуйте darktablerc, щоб збільшити останнє число (частка пам’яті OpenCL) для вибраного рівня ресурсу. Наприклад, збільшення частки пам’яті OpenCL до 950 збільшить доступну пам’ять на GPU з 6 ГБ пам’яті приблизно до 5,3 ГБ.
Установіть налаштування > обробка > cpu / gpu / пам’ять > налаштування продуктивності OpenCL на “розмір пам’яті”, що використовуватиме всю пам’ять вашого пристрою за вирахуванням 400 МБ запасу. Перегляньте розділ нижче, щоб дізнатися про інші опції, пов’язані з цим параметром.

🔗balanced OpenCL versus CPU tiling

In most cases, running a processing module on a high-powered GPU (the OpenCL codepath) is significantly faster than running the same module using the CPU codepath. However, many users have fast multi-core CPUs with a large amount of system RAM, but a GPU with significantly lower capabilities (typically, integrated graphics with small amounts of dedicated memory). Use of OpenCL code in these cases can lead to excessive tiling, and it is often better to run a module without tiling using the CPU codepath than to attempt to use OpenCL with heavy tiling.

While processing the pipeline, darktable attempts to determine which mode will be best for a given module by estimating the expected workloads for both OpenCL and CPU codepaths. In most cases it will prefer the OpenCL codepath even if that would mean tiling the image, since OpenCL is typically much faster than running the CPU code (often as much as 10 times faster if it is a dedicated card).

If the ratio of estimated workloads (CPU vs GPU) is larger than the advantage hint (see below), darktable will use the CPU for processing that module, else it will use the GPU.

🔗конфігурація OpenCL для конкретного пристрою

Налаштування darktable за замовчуванням мають забезпечувати розумну продуктивність графічного процесора в більшості систем. Однак, якщо ви хочете спробувати оптимізувати речі далі, цей розділ описує відповідні параметри конфігурації (усі вони встановлені у вашому файлі darktablerc).

Починаючи з darktable 4.0, більшість опцій, пов’язаних з OpenCL, керуються окремо для кожного пристрою. Параметр конфігурації для кожного пристрою виглядає так:

cldevice_v4_quadrortx4000=0 250 0 16 16 1024 0 0 0.017853 20.000

або, більш загально

cldevice_version_canonicalname=a b c d e f g h i j

В darktablerc буде автоматично створено запис для кожного нововиявленого пристрою під час першого запуску darktable з правильним канонічним ім’ям пристрою та номером версії. Параметри a - i визначаються таким чином, і їх можна редагувати вручну:

a. уникати atomics: 1 = уникати atomics; 0 = використовувати atomics; Атомні операції в OpenCL – це особливий метод синхронізації даних і використовуються лише в кількох модулях. На жаль, деякі старі пристрої AMD/ATI надзвичайно повільно обробляють атомні операції і на цих картах краще обробити постраждалі від цього модулі на центральному процесорі, а не приймати надзвичайно повільний шлях виконання на GPU. Встановіть для цього параметра значення 1, якщо у вас повільна обробка в таких модулях, як тіні та світлі тони, монохром, локальний контраст, глобальне тональне відображення (застарілий) або якщо у вас періодично зависає система. Зауважте, що це не повинно вплинути на пристрої, випущені з 2015 року.
b. мікро-пауза: за замовчуванням 250; В ідеальному випадку ви будете тримати графічний процесор зайнятим на 100% під час обробки конвеєра. Однак, якщо ваш графічний процесор також потрібен для оновлення екрана, а darktable використовує його на 100%, на виконання цього завдання може не залишитися достатньо часу. Зазвичай це проявляється як уривчасті оновлення графічного інтерфейсу під час панорамування, масштабування або переміщення повзунків. Щоб вирішити цю проблему, darktable може додати невеликі паузи у свою обробку конвеєра, щоб графічний процесор міг “перевести дух” і виконати дії, пов’язані з графічним інтерфейсом. Параметр “мікро-пауза” контролює тривалість цих пауз в мікросекундах. У сучасних системах ви в достатній безпеці зі значенням за замовчуванням, навіть для вбудованих GPU. Якщо ви використовуєте кілька пристроїв, це значення можна встановити на 0 для пристрою, який не обробляє оновлення екрана.
c. закріплена пам’ять: 0 = використовувати GUI для вибору режиму; 1 = увімкнути “закріплену пам’ять”; 2 = вимкнути “закріплену пам’ять”; Під час тайлінгу між хостом і пристроєм потрібно передавати величезні обсяги пам’яті. На деяких пристроях пряме переміщення до та з довільної області пам’яті хоста може призвести до значного зниження продуктивності. Це особливо помітно під час експорту великих зображень на менш потужних графічних картах або під час використання нових модулів, таких як дифузія / різкість або режим керованих лапласіанів у модулі відновлення переекспонованих ділянок.; Немає безпечного методу чи загального правила, щоб передбачити, чи забезпечить цей параметр перевагу продуктивності, тому вам доведеться експериментувати самостійно. Цей режим також можна встановити глобально, встановивши для параметра “налаштування продуктивності OpenCL” значення “переміщення в пам’яті” (в налаштування > обробка > cpu / gpu / пам’ять), тоді цей параметр має бути встановлений на 0. В іншому випадку ви можете ввімкнути/вимкнути його на рівні пристрою за допомогою цього параметра.
d. clroundup wh / e. clroundup ht: Ці параметри слід залишити на значенні за замовчуванням – тестування не показало жодної переваги від використання інших значень.
f. кількість дескрипторів подій: Дескриптори подій використовуються darktable для моніторингу успіху/збою ядер та отримання інформації профілювання, навіть якщо конвеєр виконується асинхронно. Кількість дескрипторів подій є обмеженим ресурсом вашого драйвера OpenCL – хоча їх можна повторно використовувати, але існує обмежена кількість, яку можна використовувати одночасно. На жаль, неможливо дізнатись, якими є обмеження ресурсів для даного пристрою, тому darktable використовує дуже консервативне припущення 128 за замовчуванням. На більшості сучасних пристроїв і драйверів можна очікувати, що число до 1024 буде безпечним і призведе до трохи кращої продуктивності OpenCL. Якщо у вашого драйвера закінчуються вільні дескриптори, ви зіткнетеся зі збоєм ядер OpenCL з повідомленням про помилку (CL_OUT_OF_RESOURCES) або навіть падінням програми або зависанням системи.; Значення 0 блокує darktable від використання будь-яких дескрипторів подій. Це не дозволить darktable належним чином відстежувати успіх ваших ядер OpenCL, але заощадить деякі накладні витрати драйверів, що призведе до кращої продуктивності. Наслідком цього є те, що будь-які збої, ймовірно, призведуть до спотвореного результату, але darktable цього не помітить. Це рекомендовано лише в тому випадку, якщо ви точно знаєте, що ваша система працює надійно.
g. асинхронний режим: 1 = використовувати асинхронний режим; 0 = не використовувати; Цей прапорець визначає, як часто darktable блокує конвеєр OpenCL, щоб отримати статус про успіх/збій запущених ядер. Для оптимальної затримки встановіть значення 1, тоді darktable запускає конвеєр асинхронно та намагається використовувати якомога менше переривань/подій. Якщо у вас виникають помилки OpenCL, як-от збій ядер, скиньте параметр до 0 (це значення за замовчуванням). Це змусить darktable перериватися після кожного модуля, щоб ви могли легше ізолювати будь-які проблеми. Повідомлялося про проблеми з деякими старими картами AMD/ATI (такими як HD57xx), які можуть видавати спотворені результати, якщо для цього параметра встановлено значення 1. Якщо ви сумніваєтеся, залиште його за замовчуванням в 0.
h. вимкнути пристрій: 0 = увімкнути пристрій; 1 = вимкнути пристрій; Якщо darktable виявить несправний пристрій, він автоматично позначить його як такий, встановивши цей параметр на 1. Якщо у вас є пристрій, який повідомляє про багато помилок, ви можете вручну вимкнути його, встановивши для цього поля значення 1.
i. тест продуктивності: Коли darktable виявить новий пристрій у вашій системі, він виконає невеликий тест продуктивності й збереже результат тут. Ви можете повернути це значення на 0, щоб змусити darktable перезапустити тест, але в більшості випадків не слід редагувати це налаштування.
j. advantage hint: This defines the advantage hint described in the balanced OpenCL versus CPU tiling section. If you have a fast graphics card with plenty of memory you can safely leave this at its default value of 0.000. However, if you want to adapt this number to your own system, you should use the following process:

Start darktable with the tiling debug option (darktable -d tiling) and start editing an image in the darkroom. Open the highlight reconstruction module and use the “guided laplacians” method, setting the “diameter of reconstruction” to a high value, while ensuring that tiling does not occur (check the debug information in your terminal session while adjusting the slider).
Check the execution times of this module with OpenCL on and off (by running darktable -d perf to examine the performance).
Set the “advantage hint option” to approximately (CPU execution time / GPU execution time).

Примітка: якщо darktable виявить “помилковий” ключ конфігурації пристрою, він буде перезаписаний до значень за замовчуванням.

🔗конфігурація OpenCL для конкретного id пристрою

A second device-specific configuration key is also provided, which takes into account both the device name and the device id (just in case you have two identical devices). In this case, the usual key name cldevice_version_canonicalname is followed by _idX with X being the device id. For example, if the above example device was referred to as device 0, the second configuration setting would (by default) be cldevice_v4_quadrortx4000_id0=400.

Цей ключ конфігурації наразі має лише один визначений параметр:

примусовий запас (за замовчуванням 400): Обсяг пам’яті (у МБ), який не використовуватиме darktable під час обробки OpenCL. Цей параметр дійсний, лише якщо ви встановили налаштування > обробка > налаштування продуктивності OpenCL на “розмір пам’яті”.; якщо встановити цей параметр на нуль (0), тоді під час першого запуску піксельного конвеєра darktable спробує визначити, скільки пам’яті графічного процесора фактично доступно, і використає це (із запасом безпеки 100 МБ) як максимальний обсяг пам’яті, який використовуватиме darktable до кінця сеансу. Зазвичай це безпечно, якщо ви не запускаєте інші програми (які використовують помітний обсяг пам’яті GPU) під час роботи darktable. Інакше використання цієї опції може призвести до помилок нестачі пам’яті, які змусять darktable повернутися до обробки на центральному процесорі, що значно знизить продуктивність. Ви можете вимкнути та знову ввімкнути цю опцію, щоб спонукати darktable виконати обчислення пам’яті ще раз (на початку наступного запуску конвеєра). Зауважте, що існують відомі проблеми з автоматичним виявленням пам’яті в новіших драйверах Nvidia, тож автоматичне виявлення слід використовувати обережно, тому воно вимкнено за замовчуванням.; Якщо ви впевнені, що жодна програма (або ваша ОС) не використовує певний пристрій, ви можете встановити цей параметр на 1 для такого пристрою, тоді darktable використовуватиме всю пам’ять цього пристрою.; Значення за замовчуванням у 400 МБ підійде для більшості систем. Якщо ви помітили, що у вас виникли проблеми з продуктивністю через те, що darktable повертається до обробки на центральному процесорі, спробуйте змінити значення на 600 або вимкнути налаштування “розмір пам’яті”.

🔗інші ключі конфігурації

Наступні додаткові ключі конфігурації також доступні в darktablerc:

cldevice_version_canonicalname_building: Ця опція використовується під час компіляції ядер OpenCL і може бути надана для налаштування продуктивності або для обходу помилок. Ви повинні видалити всі наявні ядра, щоб перекомпілювати їх з новими опціями. Надайте порожній рядок для перекомпіляції без будь-яких опцій. Видаліть налаштування повністю, щоб перекомпілювати з опціями за замовчуванням: -cl-fast-relaxed-math
opencl_synch_cache: Якщо встановлено значення “true”, цей параметр змусить darktable отримувати буфери зображень з вашого графічного процесора після кожного модуля та зберігати їх у своєму кеші конвеєра. Це операція, яка вимагає ресурсів, але може мати сенс залежно від вашого графічного процесора (зокрема, якщо графічний процесор досить повільний). У цьому випадку darktable може насправді заощадити деякий час, коли параметри модуля змінилися, оскільки він може повернутися до деякого кешованого проміжного стану і переробити лише частину конвеєра. У багатьох випадках для цього параметра слід встановити значення “active module” (за замовчуванням), при якому буде кешуватися лише вхід поточно сфокусованого модуля.