Created attachment 136863 [details]
gpu crash dump
Early on in the game (GOG, ver. 2.6.0) you enter a cave. A short moment later the GPU will hang, and from thereon the hang is fully reproducible simply by restarting the game. Changing options (resolution, details, windowed/fullscreen) does not make a difference.
Linux t460s 4.14.12-1-ARCH #1 SMP PREEMPT Fri Jan 5 18:19:34 UTC 2018 x86_64 GNU/Linux
Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz
X.Org X Server 1.19.6
Release Date: 2017-12-20
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2) (0x1916)
Video memory: 3072MB
Unified memory: yes
Attachment includes gzipped crash dump from /sys/class/drm/card0/error
Created attachment 136864 [details]
I upgraded the kernel (to 4.14.13) and mesa (to 17.3.2), unfortunately this makes no difference.
As this is a Unity game, please try running also with following environment variable set:
Another 'shot in the dark', does setting this make difference:
This one makes no difference.
> Another 'shot in the dark', does setting this make difference:
Yep, it does. I can't reproduce the hang with this setting.
(In reply to Henri Kemppainen from comment #4)
> > UNITY_DISABLE_GRAPHICS_DRIVER_WORKAROUNDS=yes
> This one makes no difference.
> > Another 'shot in the dark', does setting this make difference:
> > INTEL_DEBUG=norbc
> Yep, it does. I can't reproduce the hang with this setting.
Thanks for testing this, FYI Jason.
There are now patches on the list for this:
This is fixed by the following commit in master:
Author: Jason Ekstrand <email@example.com>
Date: Mon Jan 22 23:40:48 2018 -0800
i965/miptree: Add an aux_disabled parameter to render_aux_usage
Only one of the callers of intel_miptree_render_aux_usage actually took
brw->draw_aux_buffer_disabled into account. This was causing us to
ignore draw_aux_buffer_disabled for the intel_miptree_prepare_render.
This isn't a problem because the draw_aux_buffer_disabled entry was set
during texture preparation and we already did the resolve at that time.
However, this also meant that the aux_usage we were passing to
brw_cache_flush_for_render and brw_render_cache_add_bo was wrong so our
automatic cache flushing around aux_usage changes wasn't happening.
This was causing GPU hangs in Oxenfree.
Reviewed-by: Iago Toral Quiroga <firstname.lastname@example.org>
Reviewed-by: Kenneth Graunke <email@example.com>