Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Все об Arch Linux
Arch Linux будет тем, что вы из него сделаете!
Если на Ryzen со встроенной графикой игра выдаёт вдвое меньше кадров, чем показывают чужие тесты на том же процессоре, почти всегда виновато не «слабое железо», а одно из трёх: узкая память, неверно выбранный драйвер или проваленный scheduler. Ниже — короткий маршрут, который помогает за десять минут понять, где именно теряются проценты, и что с этим делать. Сначала разберёмся с тем, откуда берётся низкая частота кадров, дальше — с проверками, а в конце с настройкой.
Встроенная графика не имеет собственной видеопамяти: она берёт системную DDR. Отсюда первая и самая частая причина — одноканальный режим памяти. Двухканальный контроллер даёт iGPU почти вдвое больше суммарной полосы, и в сценариях, где GPU упирается в пропускную способность (растеризация, текстуры, шейдеры без окклюзии), просадка легко превышает 30%.
Вторая причина — сама память. Стандартный JEDEC-профиль держит DDR4/DDR5 на низких частотах с высокой латентностью, пока не включён XMP (или EXPO для Ryzen). Пока профиль не активирован, iGPU получает и полосу, и отзывчивость ниже заявленных для платы значений. Подробнее про сам графический стек и драйвер — в статье AMD GPU: Radeon или amdgpu.
Третий фактор — CPU-bound сценарии. Когда узкое место не в памяти, а в логике игры, «разгон GPU» не даёт ничего: узко место в процессоре, и iGPU лишь отображает готовые кадры. Именно в таких сценариях помогают governor performance и отключение энергосбережения — об этом ниже.
Порядок примерно такой: сначала убедись, что игра вообще идёт через аппаратный рендерер, потом посмотри память, и только потом трогай настройки.
Смотри, какой рендерер и драйвер выбрала система:
glxinfo -B | grep -E "OpenGL renderer|OpenGL version"
glxinfo -B | grep "OpenGL core profile version"
В строке OpenGL renderer string должно быть AMD Radeon ... (radeonsi, ...), а не llvmpipe или softpipe. Если видишь llvmpipe — игра рисует на процессоре программно, и никакие настройки GPU не помогут. С Vulkan-путём похоже, только там нужен RADV:
vulkaninfo --summary | grep -E "deviceName|driverName|apiVersion"
В deviceName ищи RADV, в driverInfo — версию Mesa. Если в списке RADV нет, а есть llvmpipe или lavapipe, проблема снова в драйвере, а не в железе. Вторую половину проверки — как настроен Vulkan для игр — разбирали в гайде по настройке amdgpu, Vulkan и Mesa.
Проверь частоту и режим памяти:
lshw -short -C memory
dmidecode -t memory | grep -E "Locator|Size|Speed|Part Number"
Если в списке один модуль или все модули работают на одинаковой пониженной частоте, причина найдена: включи XMP/EXPO в UEFI.
Отдельно проверь прогреваемость монитора. В WSL и в виртуальных машинах, а иногда и на нестандартных разрешениях рабочий стол уходит на программный и с медленной вертикальной развёрткой. Сравни FPS в окне игры и на рабочем столе, а для контроля полной частоты:
xrandr | grep -E "\*|connected"
Потому что этот параметр управляет профилями энергопотребления и таблицами power play. В CPU-bound сцене кадры ограничены частотой процессора, и любые манипуляции с профилями GPU на неё не влияют — картинка уже готова, дольше её не показать.
С amdgpu.dc=0 (отключение Display Core) эксперименты спорные: на части конфигураций выигрыш есть, на части — артефакты и потеря производительности. Если решишь проверить, сначала зафиксируй исходные значения и откатывай через initramfs, а не через живой перезагрузкой ядра. Порядок такой: сначала amdgpu.ppfeaturemask и power_dpm_force_performance_level, и только потом отключение Display Core — иначе не поймёшь, что именно помогло.
У amdgpu есть собственный бюджет мощности и собственный governor поверх Linux governor. Текущий уровень читается так:
cat /sys/class/drm/card0/device/power_dpm_force_performance_level
Допустимые значения: low, auto, high, плюс варианты manual со сдвигом деления. Уровень low заставляет карту экономить и держать минимальные частоты, auto даёт драйверу решать, high фиксирует максимальные частоты и заметно поднимает FPS в GPU-bound сценариях.
sudo tee /sys/class/drm/card0/device/power_dpm_force_performance_level <<< "high"
sudo tee /sys/class/drm/card0/device/power_dpm_state <<< "performance"
Обрати внимание на имя устройства: если карт несколько, нужный cardN ищи через readlink -f /sys/class/drm/card*/device/driver или lspci -k | grep -A3 vga. Значения не переживают перезагрузку — их удобнее прописать в systemd-юнит, который выполняет tee до старта графической сессии, а не в rc.local.
Планировщик в ядре влияет на две вещи: как часто CPU будит iGPU для подачи команд и как быстро процессор уходит в максимальные частоты. Для Ryzen практичная связка — amd-pstate (или amd_pstate в новых ядрах), активный EPP и governor performance.
Проверить текущее состояние:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat /sys/devices/system/cpu/cpufreq/policy0/energy_performance_preference
cat /sys/devices/system/cpu/amd_pstate/status
Здесь стоит понимать разницу: amd_pstate=active — активный драйвер, он сам решает между энергосбережением и производительностью; amd_pstate=guided — гибридный, на десктопах он обычно полезнее, потому что учитывает нагрузку; passive отдаёт выбор на schedutil. Параметр amd_pstate_epp в active задаёт профиль качества (например, performance или balance_performance) — именно он заметно поднимает частоты в играх.
Переключить governor и профиль:
sudo cpupower frequency-set -g performance
echo amd_pstate_epp=performance | sudo tee /boot/loader/entries/*/conf
sudo update-grub # или grub-mkconfig -o /boot/grub/grub.cfg
Чтобы governor не слетал после перезагрузки, проще сделать его постоянным через udev-правило, а не через cpupower.service (тот переписывает настройки при старте и конфликтует с udev). Создай правило, которое выставляет performance на все политики CPU:
sudo tee /etc/udev/rules.d/50-cpufreq-performance.rules <<< 'ACTION=="add", KERNEL=="cpufreq", RUN+="/bin/sh -c \'/usr/bin/cpupower frequency-set -g performance\'"'
sudo udevadm control --reload-rules && sudo udevadm trigger
Если душа лежит к schedutil или powersave, меняй только performance в RUN на нужный governor — остальная логика не меняется. Полезно держать под рукой обе утилиты:
sudo pacman -S cpupower cpufrequtils
Отдельный слой настройки — выбор драйвера: под Vulkan-игры оставляй RADV, под OpenGL-движки можно переключиться на RadeonSI, если RADV даёт артефакты. Переключение делается переменными окружения или драйвер-файлами, без правки конфигов Mesa, и подробнее разобрано в разделе частых вопросов.
Для OpenGL-игр (старые движки, DXVK поверх Wine, нативные порты) берут RadeonSI, для Vulkan-игр — RADV. В твоём случае RADV почти всегда лучше: у него заметно выше производительность и свежее компиляторные трюки. Переключать глобально нужно только если конкретная игра глючит с RADV — тогда RADV_PERFTEST=gpl или VK_DRIVER_FILES помогают, а для нативного Wayland у Proton включают RADV принудительно.
amdgpu.ppfeaturemask в играх?В CPU-bound сценариях — нет, потому что он влияет на энергопотребление и таблицы power play, а не на частоту CPU. В GPU-bound — иногда да: в 0xffff есть полезные профили, но подбирать их стоит по конкретной модели, а не одним флагом на весь ноутбук.
Это не оверклок, а фиксация максимальных частот. На стоковом напряжении эффект безопасен, минус — рост нагрева и шума вентиляторов в ноутбуке. Разгон частот ядра через pp_od_clk_voltage возможен, но требует нагрузочного теста и даёт куда меньше, чем честные XMP-профили памяти.
Обычно это встроенный frame limiter или переменная частота кадров в самой игре, а не проблема драйвера. Проверь vblank в glxgears/ любом тесте и убедись, что вертикальная развёртка монитора не ниже частоты кадров в игре.
glxinfo -B нет строки renderer?Проверь, запущен ли ты в WSL или в виртуальной машине: там DRI может быть недоступен полностью, и ты вывод уходит в другой путь. На голом железе отсутствие строки означает, что не загрузился amdgpu-модуль — смотри dmesg | grep -i drm и lspci -k.
Встроенная графика Ryzen не конкурент дискретной карте, но в CPU-bound сценариях правильные настройки дают вполне реальные +20–30%. Порядок действий простой: двухканальная память на профиле XMP/EXPO, performance-профиль power_dpm_force_performance_level, governor performance с закреплённым amd_pstate_epp, и проверка того, что игра вообще идёт через RADV, а не через программный рендерер.
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии