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

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

Обробка 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 так, щоб використовувати якомога більше вашої системної та графічної пам’яті.

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

There are a number of configuration parameters that can help you to fine-tune your system’s performance. Some of these parameters are available in preferences > processing > CPU / memory and others need to be modified directly in darktable’s configuration file (found in $HOME/.config/darktable/darktablerc).

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

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

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

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

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

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


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


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

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

🔗Ресурси Darktable

The “darktable resources” preference (in preferences > processing > CPU / memory) allows you to choose between four different approaches to allocating your system’s resources to darktable. Each of these options controls multiple individual parameters, which are defined independently in $HOME/.config/darktable/darktablerc. You can amend any of these directly within your darktablerc file to tweak values for your selected resource level, though you cannot add your own custom resource level to the preferences drop-down.


Примітка: Режим без обмежень справді “забирає все”. Це може здатися найкращим параметром для використання, але, особливо під час експорту великих зображень із високою якістю, необмежене використання пам’яті може спричинити використання підкачки, що може призвести до погіршення продуктивності або мовчазної зупинки Darktable вашою операційною системою.


Кожен із чотирьох параметрів “ресурсів 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 повернутися до обробки центральним процесором (яка буде значно повільнішою, але стабільною і з правильно обробленими даними) або Darktable може аварійно завершити роботу і навіть зробити вашу систему нестабільною або непридатною для використання. З цієї причини параметр частки пам’яті графічного процесора також включає додаткові 600 МБ запасу, щоб уникнути надмірного виділення пам’яті. Наприклад, на графічному процесорі з 6 ГБ пам’яті Darktable використовуватиме приблизно (6 - 0,6) * 700 / 1024 або 3,5 ГБ оперативної пам’яті графічного процесора при використанні рівня 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 ГБ. (категорично не рекомендується)

  • Set preferences > processing > OpenCL > use all device memory to “on”, which will use all of your device’s memory, less a 600MB headroom. Please see the section below for “per device setting” of headroom.

🔗balanced OpenCL versus CPU tiling

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

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

Якщо співвідношення очікуваних робочих навантажень (CPU проти GPU) більше, ніж підказка про перевагу (див. нижче), Darktable використовуватиме CPU для обробки цього модуля, інакше використовуватиме GPU.

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

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

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

cldevice_v5_nvidiacudaquadrortx4000=0 250 0 16 16 128 0 0 0.000 0.000 0.500

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

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

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

a. уникати atomics
1 = уникати atomics; 0 = використовувати atomics (за замовчуванням)
Атомні операції в OpenCL – це особливий метод синхронізації даних і використовуються лише в кількох модулях. На жаль, деякі старі пристрої AMD/ATI надзвичайно повільно обробляють атомні операції і на цих картах краще обробити постраждалі від цього модулі на центральному процесорі, а не приймати надзвичайно повільний шлях виконання на GPU. Встановіть для цього параметра значення 1, якщо у вас повільна обробка в таких модулях, як Тіні та світлі тони, Монохром, Локальний контраст, Глобальне тональне відображення (застарілий) або якщо у вас періодично зависає система. Зауважте, що це не повинно вплинути на пристрої, випущені з 2015 року.
b. мікро-пауза
за замовчуванням 250
В ідеальному випадку ви будете тримати графічний процесор зайнятим на 100% під час обробки конвеєра. Однак, якщо ваш графічний процесор також потрібен для оновлення екрана, а Darktable використовує його на 100%, на виконання цього завдання може не залишитися достатньо часу. Зазвичай це проявляється як уривчасті оновлення графічного інтерфейсу під час панорамування, масштабування або переміщення повзунків. Щоб вирішити цю проблему, Darktable може додати невеликі паузи у свою обробку конвеєра, щоб графічний процесор міг “перевести дух” і виконати дії, пов’язані з графічним інтерфейсом. Параметр “мікро-пауза” контролює тривалість цих пауз в мікросекундах.

У всіх поточних системах ви в безпеці зі значенням за замовчуванням. Якщо ви використовуєте кілька пристроїв або не використовуєте свій дискретний графічний процесор для малювання на екрані, це значення можна встановити на 0 для всіх не-десктопних пристроїв, що покращує продуктивність.

c. закріплена пам’ять
_0 = вимкнути “закріплену пам’ять” (за замовчуванням); 1 = увімкнути “закріплену пам’ять” _
Під час тайлінгу між хостом і пристроєм потрібно передавати величезні обсяги пам’яті. На деяких пристроях пряме переміщення до та з довільної області пам’яті хоста може призвести до значного зниження продуктивності. Це особливо помітно під час експорту великих зображень на менш потужних графічних картах або під час використання нових модулів, таких як Дифузія / різкість або режим керованих лапласіанів у модулі Відновлення переекспонованого.

Немає безпечного методу чи загального правила, щоб передбачити, чи забезпечить цей параметр перевагу продуктивності, тому вам доведеться експериментувати самостійно. Проте ймовірність того, що “закріплена пам’ять” призведе до покращення, досить низька, якщо вашу графічну карту було виготовлено після 2015 року.

d. clroundup wh / e. clroundup ht
Ці параметри слід залишити на значенні за замовчуванням – тестування не показало жодної переваги від використання інших значень.
f. кількість дескрипторів подій
за замовчуванням 128
Darktable використовує дескриптори подій для моніторингу успіху/збою ядер та отримання інформації профілювання, навіть якщо конвеєр виконується асинхронно. Кількість дескрипторів подій є обмеженим ресурсом вашого драйвера OpenCL – хоча їх можна повторно використовувати, але існує обмежена кількість, яку можна використовувати одночасно. На жаль, неможливо дізнатись, якими є обмеження ресурсів для даного пристрою (це пов’язано з тем, що Darktable використовує OpenCL V.1.2 API для підтримки всіх платформ), тому Darktable використовує консервативне припущення 128 за замовчуванням. На більшості сучасних пристроїв і драйверів можна очікувати, що число до 1024 буде безпечним (і це точно так, якщо ваш драйвер/карта повідомляє версію OpenCL V.2.0 або новішу), що призведе до трохи кращої продуктивності OpenCL. Якщо у вашого драйвера закінчуються вільні дескриптори, ви зіткнетеся зі збоєм ядер OpenCL з повідомленням про помилку (CL_OUT_OF_RESOURCES) або навіть падінням програми або зависанням системи.(Якщо ви зіткнулися з цим, відкрийте проблему на GitHub сторінці Darktable)

Значення 0 блокує Darktable від використання будь-яких дескрипторів подій. Це не дозволить Darktable належним чином відстежувати успіх ваших ядер OpenCL, але заощадить деякі накладні витрати драйверів, що призведе до дещо кращої продуктивності (менш як 5%). Наслідком цього є те, що всі збої призведуть до спотвореного результату, але Darktable цього не помітить. Це рекомендовано лише в тому випадку, якщо ви точно знаєте, що ваша система працює надійно.

g. асинхронний режим
1 = використовувати асинхронний режим; 0 = не використовувати (за замовчуванням)
Цей прапорець визначає, як часто Darktable блокує конвеєр OpenCL, щоб отримати інформацію про успіх/збій запущених ядер. Для оптимальної затримки встановіть значення 1, тоді Darktable запускає конвеєр асинхронно та намагається використовувати якомога менше переривань/подій. Якщо у вас виникають помилки OpenCL, як-от збій ядер, скиньте параметр до 0. Це змусить Darktable перериватися після кожного модуля, щоб ви могли легше ізолювати будь-які проблеми. Повідомлялося про проблеми з деякими старими картами AMD/ATI (такими як HD57xx), які можуть видавати спотворені результати, якщо для цього параметра встановлено значення 1. Якщо ви сумніваєтеся, залиште його за замовчуванням в 0.
h. вимкнути пристрій
0 = увімкнути пристрій; 1 = вимкнути пристрій
Якщо Darktable виявить несправний пристрій, він автоматично позначить його як такий, встановивши цей параметр на 1. Якщо у вас є пристрій, який повідомляє про багато помилок, ви можете вручну вимкнути його, встановивши для цього поля значення 1. Якщо Darktable вимкнув пристрій, але ви впевнені, що його потрібно використовувати, ви можете повторно ввімкнути його, встановивши для цього поля значення 0.

i. зарезервовано

j. підказка про перевагу
Це визначає підказку про перевагу, описану в розділі balanced OpenCL versus CPU tiling. Якщо у вас швидка графічна карта з великою кількістю пам’яті, ви можете сміливо залишити значення за замовчуванням 0,000. Однак, якщо ви хочете адаптувати це число до вашої власної системи, вам слід скористатися таким процесом:
  1. Запустіть Darktable із параметром налагодження тайлінгу (darktable -d tiling) і почніть редагувати зображення в темній кімнаті. Відкрийте модуль Відновлення переекспонованого і скористайтеся методом “керованих лапласіанів”, встановивши для “діаметра відновлення” високе значення, забезпечуючи при цьому відсутність тайлінгу (перевірте налагоджувальну інформацію у сеансі терміналу під час налаштування повзунка).
  2. Перевірте час виконання цього модуля з увімкненим і вимкненим OpenCL (запустивши darktable -d perf для перевірки продуктивності).
  3. Встановіть для параметра “підказка про перевагу” значення приблизно (час виконання CPU / час виконання GPU).
k. частка спільної пам’яті
Деякі пристрої OpenCL не мають виділеної пам’яті, але спільно використовують її з ЦП. Apple ARM silicon є одним із прикладів, а також інтегровані на платі пристрої від Intel, AMD або SOC ARM. Оскільки ми хочемо, щоб системна пам’ять залишалася доступною для кешування або шляхів виконання центральним процесором, ми обмежуємо обсяг усієї пам’яті, що використовується, заданою часткою. Таким чином, із значенням за замовчуванням 0,5 і комп’ютером Apple із 16 ГБ оперативної пам’яті OpenCL зможе використовувати 8 ГБ.

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


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

Також надається другий ключ конфігурації певного пристрою, який враховує назву пристрою та його ідентифікатор (на випадок, якщо у вас є два ідентичні пристрої). У цьому випадку за звичайною назвою ключа cldevice_version_canonicalname слідує _idX, де X є ідентифікатором пристрою. Наприклад, якщо наведений вище приклад пристрою було названо пристроєм 0, другий параметр конфігурації був би (за замовчуванням) cldevice_v5_quadrortx4000_id0=600.

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

forced headroom (default 600)
The amount of memory (in MB) that will not be used by darktable during OpenCL processing. This setting is only valid if you set preferences > processing > OpenCL > use all device memory to “on”.

Якщо ви впевнені, що жодна програма (або ваша ОС) не використовує певний пристрій, ви можете встановити цей параметр на 0 для такого пристрою, тоді Darktable використовуватиме всю пам’ять цього пристрою.

Значення за замовчуванням у 600 МБ підійде для більшості систем. Якщо ви помітили, що у вас виникли проблеми з продуктивністю через те, що Darktable повертається до обробки на центральному процесорі, спробуйте змінити значення на 800 або більше.

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

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

cldevice_version_canonicalname_building
Ця опція використовується під час компіляції ядер OpenCL і може бути надана для налаштування продуктивності або для обходу помилок. Ви повинні видалити всі наявні ядра, щоб перекомпілювати їх з новими опціями. Надайте порожній рядок для перекомпіляції без будь-яких опцій. Видаліть це налаштування повністю, щоб перекомпілювати з опціями за замовчуванням, де замовчування є -cl-fast-relaxed-mathдля драйверів nvidia, для всіх інших карт цей параметр компілятора не встановлено.
Опція -cl-fast-relaxed-math значно покращує продуктивність, але змінює математичні обчислення в коді обробки модуля, що може призвести до інших результатів. Для поточних реалізацій Intel цей прапорець компілятора призводить до явно неправильних результатів, на картах AMD результати непереконливі. Деякі комбінації карти/драйвера працюють нормально, а деякі ні. Оскільки драйвери AMD постійно змінюються, ми не рекомендуємо використовувати цю опцію для карт AMD.
opencl_synch_cache
Якщо встановлено значення “true”, цей параметр змусить Darktable отримувати буфери зображень з вашого графічного процесора після кожного модуля та зберігати їх у своєму кеші конвеєра. Це операція, яка вимагає ресурсів, але може мати сенс залежно від вашого графічного процесора (зокрема, якщо графічний процесор досить повільний). У цьому випадку Darktable може насправді заощадити деякий час, коли параметри модуля змінилися, оскільки програма може повернутися до деякого кешованого проміжного стану і переробити лише частину конвеєра. Починаючи з Darktable 4.4 ефективність кешу конвеєра значно покращилася, тож встановлення значення “active module” (за замовчуванням) для цього параметра є гарним варіантом у більшості випадків.
opencl_mandatory_timeout
:За замовчуванням 400
Якщо Darktable хоче використовувати будь-який пристрій OpenCL, він має зарезервувати його для подальшого використання. Якщо цей пристрій наразі використовується, Darktable чекатиме до opencl_mandatory_timeout * 5 мс, перш ніж здійснити відкат до центрального процесора. Збільште це значення, якщо ви віддаєте перевагу використанню OpenCL (оскільки ваша графічна карта дуже швидка, а ваш процесор — ні).

translations