оптимізація продуктивності
У файлі $HOME/.config/darktable/darktablerc є ряд параметрів конфігурації, які можуть допомогти покращити продуктивність OpenCL вашої системи. Продуктивність у цьому контексті здебільшого означає затримку darktable під час інтерактивної роботи (тобто скільки часу потрібно для повторної обробки конвеєра). Для комфортного робочого процесу важливо зберігати низьку затримку.
Для того, щоб отримати інформацію профілювання, вам потрібно запустити darktable з терміналу з командним рядком darktable -d opencl -d perf.
Після кожної повторної обробки конвеєра – спричиненої зміною параметрів модуля, масштабуванням, панорамуванням тощо – ви побачите загальний час витрачений в конвеєрі та час, проведений у кожному з ядер OpenCL. Найбільш надійним значенням є загальний час, проведений в конвеєрі. Зверніть увагу, що таймінги, вказані для кожного окремого модуля, є ненадійними при асинхронному запуску конвеєра OpenCL (див. opencl_async_pixelpipe нижче).
Щоб забезпечити швидку обробку конвеєра за допомогою OpenCL, важливо забезпечити зайнятість графічного процесора. Будь-які переривання або зупинений потік даних збільшить загальний час обробки. Це особливо важливо для невеликих буферів зображень, з якими нам потрібно мати справу під час інтерактивної роботи. Їх можна швидко обробити за допомогою швидкого графічного процесора. Однак навіть короткочасні зупинки конвеєра можуть легко стати вузьким місцем.
З іншого боку, продуктивність darktable під час експорту файлів більш-менш залежить лише від швидкості наших алгоритмів та потужності вашого графічного процесора. Короткотермінові затримки не матимуть помітного впливу на загальний час експорту.
darktable постачається із налаштуваннями за замовчуванням, які повинні забезпечити непогану продуктивність графічного процесора в більшості систем. Однак, якщо ви хочете трохи повозитися і спробувати оптимізувати речі далі, ось опис відповідних параметрів конфігурації.
- opencl_async_pixelpipe
- Цей прапорець визначає, як часто darktable блокує конвеєр OpenCL, щоб отримати статус про успіх/збій запущених ядер. Для оптимальної затримки встановіть значення TRUE, тоді darktable запускає конвеєр асинхронно та намагається використовувати якомога менше переривань. Якщо у вас виникають помилки OpenCL, як-от збій ядер, встановіть для параметра значення FALSE. Тоді darktable перериватиметься після кожного модуля, щоб ви могли легше виявити проблему. Повідомлялося про проблеми з деякими старими картами AMD/ATI, такими як HD57xx, які можуть видавати спотворені результати, якщо для цього параметра встановлено значення TRUE. Якщо ви сумніваєтеся, залиште його за замовчуванням в FALSE.
- opencl_number_event_handles
- Дескриптори подій дають можливість darktable моніторити успіх/збій ядер та інформацію про профілювання, навіть якщо конвеєр виконується асинхронно. Кількість дескрипторів подій – це обмежений ресурс вашого драйвера OpenCL. Звичайно, їх можна повторно використовувати, але існує обмежена кількість, яку можна використовувати одночасно. На жаль, неможливо дізнатись, якими є обмеження ресурсів, тому darktable має вгадати. Значення за замовчуванням 25 досить консервативне. Можливо, ви захочете побачити, чи вищі значення, такі як 100, покращують продуктивність OpenCL. Якщо у вашого драйвера закінчуються вільні дескриптори, ви зіткнетеся зі збоєм ядра OpenCL з кодом помилки
-5 (CL_OUT_OF_RESOURCES)або навіть падінням програми або зависанням системи. Якщо це трапиться, знову зменште число. Значення 0 заблокує використання будь-яких дескрипторів подій в darktable. Це не дозволить darktable належним чином моніторити успіх ваших ядер OpenCL, але заощадить деякі накладні витрати на драйвер. Наслідком є те, що будь-які збої, швидше за все, призведуть до спотвореного виводу і darktable не попереджатиме про проблеми. Це рекомендується лише у тому випадку, якщо ви точно знаєте, що ваша система працює надійно. Ви також можете встановити для цього параметра значення -1, яке означає, що darktable не передбачає обмеження кількості дескрипторів подій. Це не рекомендується. - opencl_synch_cache
- Цей параметр, якщо встановлено значення “true”, змусить darktable отримувати буфери зображень з вашого графічного процесора після кожного модуля та зберігати їх у своєму кеші конвеєра. Це операція, яка вимагає ресурсів, але може мати сенс залежно від вашого графічного процесора (зокрема, якщо графічний процесор досить повільний). У цьому випадку darktable може насправді заощадити деякий час, коли параметри модуля змінилися, оскільки він може повернутися до деякого кешованого проміжного стану і переробити лише частину конвеєра. У багатьох випадках для цього параметра слід встановити значення “active module” (за замовчуванням), при якому буде кешуватися лише вхід поточно сфокусованого модуля.
- opencl_micro_nap
- В ідеальному випадку ви будете тримати графічний процесор зайнятим на 100% при переробці конвеєра. Це добре. З іншого боку, ваш графічний процесор також може знадобитися для регулярного оновлення графічного інтерфейсу. Може статися так, що для цього завдання не залишається достатньо часу. Наслідком може стати уривчаста реакція вашого графічного інтерфейсу на панорамування, масштабування або переміщення повзунків. Щоб вирішити цю проблему, darktable може додати невеликі паузи у свою обробку конвеєра, щоб графічний процесор “перевів дух” і виконав дії, пов’язані з графічним інтерфейсом. Параметр opencl_micro_nap контролює тривалість цих пауз в мікросекундах. Вам потрібно буде експериментувати, щоб знайти оптимальне значення для вашої системи. Значення 0, 100, 500 та 1000 – це хороші відправні точки для спроб. За замовчуванням 1000.
- opencl_use_pinned_memory
- Під час “плиткової” обробки (тайлінгу) величезний обсяг пам’яті повинен передаватися між хостом і пристроєм. На деяких пристроях (як-от AMD) пряма передача пам’яті в довільну область хост-пам’яті може призвести до величезного зниження продуктивності. Це особливо помітно при експортуванні великих зображень. Встановлення для цього параметра конфігурації значення TRUE вказує darktable використовувати спеціальний вид проміжного буфера для передачі даних хост-пристрій. На деяких пристроях це може пришвидшити експорт великих файлів у 2–3 рази. Пристрої та драйвери NVIDIA, здається, мають більш ефективну техніку передачі пам’яті навіть для довільних областей пам’яті. Оскільки вони можуть не демонструвати жодного підвищення продуктивності і навіть можуть видавати спотворені результати, opencl_use_pinned_memory слід залишити зі значенням за замовчуванням FALSE для цих пристроїв.