Тестовое окружение: реальная система, MSI MAG H670 TOMAHAWK, Intel Core i5-12600K, встроенная Intel UHD Graphics 770 [8086:4680] (монитор подключён к ней), в системе также Intel Arc B580 [8086:e20b]. ALT Workstation 11.2, обновлённая до Sisyphus, GNOME 51 (Wayland/XWayland). Версии (Sisyphus): mesa-dri-drivers-26.2.4-alt1, xorg-dri-intel-26.2.4-alt1, i586-xorg-dri-intel-26.2.4-alt1 kernel-image-6.12-6.12.112-alt1 (также проверено на 6.12.94-alt1 — результат тот же) Шаги воспроизведения: 1. Скачать Unigine Heaven 4.0 для Linux: https://assets.unigine.com/d/Unigine_Heaven-4.0.run (sha256 52db2e5dedd5621d7c2bfa936b482c0a7cc69b30616278ef199513d494d8e397), распаковать. 2. Из каталога bin запустить OpenGL-режим на встроенной графике: LD_LIBRARY_PATH=./ ./heaven_x64 -project_name Heaven -data_path ../ -engine_config ../data/heaven_4.0.cfg -system_script heaven/unigine.cpp -sound_app openal -video_app opengl -video_multisample 0 -video_fullscreen 1 -video_mode -1 -video_width 1024 -video_height 768 -extern_define RELEASE,LANGUAGE_EN,QUALITY_HIGH,TESSELLATION_DISABLED -extern_plugin GPUMonitor (то же происходит с Windows-версией Heaven под wine-vanilla 11.19 с API = OpenGL) 3. Смотреть journalctl -k. Ожидаемый результат: сцена загружается и отображается. Фактический результат: экран остаётся на загрузке/чёрным, процесс не завершается; в журнале ядра повторяется каждые ~13 с: i915 0000:00:02.0: [drm] Resetting rcs0 for preemption time out i915 0000:00:02.0: [drm] heaven_x64[4116] context reset due to GPU hang i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:859f7c3b, in heaven_x64 [4116] Воспроизводится стабильно (wine-версия 4 раза из 4, нативная 1 из 1). A/B: - p11 на той же машине (mesa 26.1.8-alt1, kernel 6.12.110): OpenGL-режим Heaven под wine рисует сцену 3 раза из 3, GPU HANG нет; нативная версия — GPU HANG нет. - Sisyphus, тот же бенчмарк на дискретной Intel Arc B580 (DRI_PRIME=1): работает (~205 FPS). - Sisyphus с ядром 6.12.94 вместо 6.12.112: GPU HANG сохраняется — ядро не влияет. - Sisyphus, DirectX 11 через dxvk (Vulkan) на той же UHD 770: работает. Похоже на регрессию в Mesa 26.2.x (драйвер iris) для ADL-S GT1. Близкий по симптомам (GPU HANG, rcs0 preemption timeout), но на другом железе и приложении — bug 55112. Вложение: i915-gpu-hang-sisyphus.tar.gz (480 КБ) — дампы /sys/class/drm/card2/error для запуска под wine (ядро 6.12.112) и нативного запуска (ядро 6.12.94), журнал ядра i915/drm, лог Heaven.
Created attachment 22366 [details] Дампы ошибки i915 (wine и нативный запуск), журнал ядра i915/drm, лог Heaven
Проверила с ядром 6.18 на той же машине (MSI MAG H670 TOMAHAWK, i5-12600K, UHD 770 [8086:4680] + Arc B580), система обновлена до Sisyphus, GNOME 51 (Wayland/XWayland). Версии: mesa-dri-drivers-26.2.4-alt1, xorg-dri-intel-26.2.4-alt1 kernel-image-6.18-6.18.55-alt1 (рендер по умолчанию — UHD 770: glxinfo -B → "Mesa Intel(R) UHD Graphics 770 (ADL-S GT1)", OpenGL 4.6 Mesa 26.2.4) Нативный Heaven 4.0, OpenGL, команда из описания: - ядро 6.18.55: воспроизводится 2 раза из 2, сцена не отрисовывается, в journalctl -k каждые ~13 с: i915 0000:00:02.0: [drm] Resetting rcs0 for preemption time out i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:859f7c3b, in heaven_x64 [3921] i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:859f7c3b, in heaven_x:gdrv0 [3968] (/sys/class/drm/card1/error: "Kernel: 6.18.55-6.18-alt1", Platform: ALDERLAKE_S, PCI ID 0x4680) - контроль в том же окружении на ядре 6.12.112: тот же GPU HANG, ecode 12:1:859f7c3b (1 из 1). Итог: с ядром 6.18 воспроизводится так же, ecode совпадает, ядро на проблему не влияет. Это ещё раз указывает на Mesa 26.2.x (iris) — на p11 с Mesa 26.1.8 сбоя нет (см. описание).
Created attachment 22373 [details] iris: refresh shader info after forcing dual-source blending Воспроизведено на Intel Core i5-12600K / UHD Graphics 770 (ADL-S GT1, PCI ID 8086:4680), драйвер ядра i915, ядро 6.18.55-6.18-alt1, Mesa 26.2.4. Проверка исправления выполнена с нативным Heaven 4.0 под Xorg, с параметрами из описания бага и отключённым shader cache. Причина найдена в iris_force_dual_color_blend() (src/gallium/drivers/iris/iris_program.c). Совместимость с Heaven обеспечивается опцией dual_color_blend_by_location: второй цветовой выход FRAG_RESULT_DATA1 преобразуется в FRAG_RESULT_DATA0 с index = 1. После этого преобразования информация о шейдере не обновлялась, в частности nir->info.fs.color_is_dual_source оставался неактуальным. В src/intel/compiler/brw/brw_compile_fs.cpp этот флаг используется для ограничения dispatch до SIMD8 на Gfx11/12: dual-source RT writes при более широком dispatch могут приводить к GPU hang. Из-за устаревшего флага соответствующее аппаратное обходное решение не применялось. Прилагаемый патч добавляет nir_shader_gather_info(nir, nir_shader_get_entrypoint(nir)) после изменения location/index. Это обновляет флаг dual-source и маски выходов, не отключая расширение и не ограничивая все фрагментные шейдеры режимом SIMD8. Проверка: - Системная Mesa и отдельно собранная исходная Mesa без патча воспроизводят GPU HANG: ecode 12:1:859f7c3b. - Обе локальные сборки сделаны из 134e0fea09e; различие — только прилагаемая строка. - С патчем сцена загружается и отрисовывается без MESA_EXTENSION_OVERRIDE и INTEL_SIMD_DEBUG. Прогоны 180 и 60 секунд прошли без GPU hangs/resets. - В промежуточном 90-секундном прогоне сцена тоже отрисовывалась, но через 8 секунд после переключения с зависшей исходной сборки в журнале появился один reset. Его принадлежность к предыдущему или новому запуску однозначно не установлена; далее сбросов не было. Последующий отдельный 60-секундный прогон прошёл без сбросов. - Выбор нужной libgallium проверен по /proc/<pid>/maps; сборки запускались из отдельных каталогов без замены системной Mesa. Shader cache отключён через MESA_SHADER_CACHE_DISABLE=true, для обеих сборок использованы одни и те же системные drirc-настройки. - Все 71 тест из настроенной сборки Mesa проходят. - Дополнительный небольшой OpenGL-тест проверяет результат dual-source blending и проходит на обеих сборках; сам GPU hang он не воспроизводит. Регрессионный сценарий здесь — Heaven. Патч предлагается для проверки и включения в пакет. Исправленную сборку под Wine, на Meteor Lake и других GPU не проверял; длительного прогона и сборки RPM пока не было.
Intel Corporation Alder Lake-N [UHD Graphics] [8086:46d1] если запустить ./heaven не из каталога bin и нажать run, все работает и в dmesg все чисто. если запустить LD_LIBRARY_PATH=./ ./heaven_x64 итд из каталога bin - доходит до Loading "heaven/heaven.world", GPU HANG в dmesg и все зависает
Вероятно это из-за того, что в разных случаях запуска используется разные библиотеки. зависает только с системной
(Ответ для Anton Farygin на комментарий #5) > зависает только с системной других у меня нет
Перепроверил на наших стендах. На UHD 770 (i5-12600K, 8086:4680) проблема стабильно воспроизводится и при запуске через ./heaven с кнопкой Run, и прямой командой из описания: в обоих случаях GPU HANG 12:1:859f7c3b. Настройки одинаковые: OpenGL, High, tessellation disabled, fullscreen 1024x768. На UHD 730 (i5-11400, 8086:4c8b) Mesa 26.2.4 без патча тоже зависает, ecode 12:1:859f7c07. Моё предположение про разные библиотеки пока не подтвердилось: в проверенном дистрибутиве Heaven своей Mesa/libGL нет, а на UHD 770 оба способа запуска действительно загружают системную /usr/lib64/libgallium-26.2.4.so — проверил по /proc/PID/maps. Можешь выложить данные именно процесса heaven_x64 на твоём Alder Lake-N для обоих вариантов: работающего после Run и зависшего при прямом запуске? Нужны полная командная строка, загруженные библиотеки и относящееся к графике окружение. Пока процесс запущен, подставь его PID: tr '\0' ' ' < /proc/PID/cmdline; echo awk '$6 ~ /^\// {print $6}' /proc/PID/maps | sort -u tr '\0' '\n' < /proc/PID/environ | grep -E '^(LD_|LIBGL_|MESA_|INTEL_|DRI_|DRIRC_|__GL|DISPLAY=|WAYLAND_DISPLAY=|XDG_CACHE_HOME=)' И приложи для каждого запуска строки OpenGL vendor/renderer/version из лога Heaven, выбранные настройки launcher и уточни, отключал ли shader cache. Важно сравнить renderer самого Heaven, а не только glxinfo. Хочу понять, чем у тебя отличаются эти два запуска: на нашем UHD 770 различие не воспроизводится, зависают оба.
./heaven_x64 -project_name Heaven -data_path ../ -engine_config ../data/heaven_4.0.cfg -system_script heaven/unigine.cpp -sound_app openal -video_app opengl -video_multisample 3 -video_fullscreen 0 -video_mode 5 -extern_define ,RELEASE,LANGUAGE_EN,QUALITY_ULTRA,TESSELLATION_EXTREME -extern_plugin ,GPUMonitor если -video_multisample поменять на 0, все вешается и в dmesg GPU HANG
тобиш без сглаживания оно не работает
А с патчем работает.
а на всяких AMD/NVIDIA(nouveau)?
на Raptor Lake-P [UHD Graphics] [8086:a7a8] ситуация аналогичная
Перепроверил Heaven на полигоне с -video_multisample 0 и 3. Остальные параметры запуска heaven_x64 одинаковые, кеш шейдеров отключён. Фактический renderer и загруженные библиотеки Mesa проверял по выводу Heaven и /proc/PID/maps. На исходной Mesa 26.2.4: 1. Intel UHD 770, Alder Lake, i915. При multisample 0 стабильно воспроизводится GPU HANG 859f7c3b со сбросами GPU, подтверждено в трёх отдельных запусках. При multisample 3 сбросов нет: первоначальный прогон 60 секунд и повторный 120 секунд. 2. Intel UHD 730, Rocket Lake, i915. При multisample 0 стабильно воспроизводится GPU HANG 859f7c07 со сбросами GPU, также в трёх отдельных запусках. При multisample 3 сбросов нет: 60 секунд и повторный прогон 120 секунд. После проблемных запусков перезапускал Xorg перед длинной проверкой multisample 3, чтобы исключить последствия предыдущего зависания. 3. Intel Arc B580, xe. При multisample 0 и 3 сбросов GPU нет, по 60 секунд. На собранной Mesa 26.2.4 с обсуждаемым исправлением оба UHD проходят multisample 0 и 3 без сбросов: по 60 секунд, плюс повторные прогоны multisample 3 примерно по 120 секунд. Это отдельный Intel-only runtime, не установленный пакет Mesa. Проверка maps подтверждает, что использовалась именно выбранная библиотека. 4. AMD Radeon RX 7600 и встроенная Raphael (Ryzen 5 7600X), amdgpu/radeonsi. AMD-стенд переустановил, системные пакеты Mesa обновил до 26.2.4-alt1. Ядро 6.18.52-6.18-alt1. На каждой карте выполнил по два прогона, multisample 0 и 3, по 120 секунд. Сцены отображаются, ошибок шейдеров, таймаутов и сбросов GPU нет. Исправленный Intel-only runtime здесь не использовал. 5. GeForce GT 1030, GP108/NV138, Nouveau. Проверял native Nouveau OpenGL на исходной Mesa 26.2.4, не Zink и не llvmpipe; ядро 6.12.110-6.12-alt1. Mesa 26.2.4 использовалась из отдельного runtime, системная установка осталась на 26.1.8. При multisample 0 и 3 сцена отображается, но есть ошибки: nouveau: kernel rejected pushbuf: Device or resource busy gr: intr 00000040 nv50cal_space: -16 Каждый прогон длился 120 секунд. Multisample 3 повторил после выгрузки и повторной загрузки Nouveau: ошибки сохранились, при этом камера заметно перемещалась между снимками на 54-й и 115-й секундах. Поэтому чистым успешным тестом Nouveau это не считаю, но и отождествлять эти ошибки с зависанием Intel оснований пока нет. Разница multisample 0/3 из комментариев выше воспроизвелась на обоих UHD. В проверенном дистрибутиве Heaven собственной Mesa нет, фактически загружаемые библиотеки проверены. Результаты с исправленной библиотекой подтверждают устранение воспроизведения на этих двух UHD. Почему включение сглаживания обходит проблемный путь, отдельно не проверял. Alder Lake-N на полигоне нет. Стенд с Raptor Lake/A380 пока не проверен из-за Secure Boot Violation. Это ограниченные прогоны 60–120 секунд, а не проверка длительной стабильности.
Mesa-4:26.2.4-alt2 -> sisyphus: Mon Oct 12 2026 Valery Inozemtsev <shrek@altlinux.ru> 4:26.2.4-alt2 - iris: fixed GPU HANG on MSAA disabled (closes: #60874)
