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)