Linux 7.3 краще працюватиме, коли відеопам'ять закінчується

Патчі ядра, що переробляють поведінку драйвера AMD під час вичерпання відеопам'яті, прийнято в upstream і поставлено в чергу до Linux 7.3 — про це йдеться в записі, опублікованому 17 серпня в блозі pixelcluster. Робота продовжує попередній проєкт з покращення керування VRAM для ігор.

Фізика вичерпання VRAM

Теоретично нестача VRAM мала б бити лише по продуктивності, а не по стабільності: драйвер дозволяє застосунку запросити більше пам'яті, ніж є на карті, а лишок переміщується в оперативну пам'ять. Саме це переміщення і є вузьким місцем. На з'єднанні PCIe 4.0 x16 шина передає трохи менше 32 GiB/с, тобто близько 32,2 MiB за мілісекунду. За 30 кадрів на секунду на кадр припадає 33,3 мс, отже, з витісненої пам'яті GPU встигає витягнути приблизно 1 075,5 MiB — трохи більше за 1 GiB. Якщо одному кадру потрібно більше, 30 FPS недосяжні.

Помилка стабільності: взаємне блокування

Вичерпання також ламає стабільність. RADV повідомляє "Not enough memory for command submission", коли ядро повертає -ENOMEM, хоча всі виділення пам'яті завершилися успішно. Причина — класичне ABBA-взаємоблокування: одне надсилання намагається витіснити виділення, яке вже заблокував інший процес, а тому процесу потрібна пам'ять, яку тримає перший. Ядро вміє виявляти такі ситуації та повторювати спробу, але помічник drm_exec не використовувався в TTM — спільному шарі керування пам'яттю GPU. Патчі 2024 року так і не увійшли, тож розробник переніс їх на актуальне ядро й виправив решту помилок: тиждень пішов на пошук зависань, що з'являлися за три хвилини інтенсивного навантаження на VRAM.

Буфери сканування та витіснення 4 GiB

Профілювання показало, що більшість втраченого часу припадає не на рендеринг, а на переміщення буферів через SDMA. Найгірший випадок — буфер, який виводиться на дисплей: апаратура дисплея обходить віртуальну пам'ять і потребує фізично неперервних сторінок, тоді як алгоритм витіснення — простий цикл за LRU, що не враховує фізичних обмежень. На практиці до 4 GiB VRAM витіснялося, щоб звільнити місце для зображень сканування приблизно по 32 MiB піксельних даних кожне; саме переміщення цих даних коштує щонайменше 130 мс. Нові фази жорсткого й м'якого обмеження мають зупинити це перекидання пам'яті.

Що це дає

З такими евристиками Indiana Jones: The Great Circle, яка на карті з 8 GiB просила 9 GiB, видавала в середньому 19,6 мс на кадр. Подвоєння надлишку помітно збільшило розкид часу кадру: сплески понад 33,3 мс і середнє близько 29,8 мс. Ядро також враховує розширення VK_EXT_pageable_device_local_memory і vkSetDeviceMemoryPriorityEXT — застосунок може сам позначити, яку пам'ять витісняти безпечніше; vkd3d-proton уже перекладає на цей механізм API резидентності D3D12. Робота вже доступна в каналах SteamOS Stable і Preview.