Bug 105139

Summary: Assertion in Dying Light
Product: Mesa Reporter: Grazvydas Ignotas <notasas>
Component: Mesa coreAssignee: mesa-dev
Status: NEW --- QA Contact: mesa-dev
Severity: normal    
Priority: medium CC: mike
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Grazvydas Ignotas 2018-02-16 23:52:15 UTC
Dying Light triggers an assertion when switching from fullscreen to windowed mode:

DyingLightGame: state_tracker/st_atom_framebuffer.c:201: st_update_framebuffer_state: Assertion `!framebuffer.cbufs[i] || framebuffer.cbufs[i]->texture->bind & PIPE_BIND_RENDER_TARGET' failed.

(gdb) p i
$1 = 0
(gdb) p framebuffer.nr_cbufs 
$2 = 1 '\001'
(gdb) p framebuffer.cbufs[i]
$3 = (struct pipe_surface *) 0x1a132450
(gdb) p framebuffer.cbufs[i]->texture->bind
$4 = 9

The assert wants PIPE_BIND_RENDER_TARGET but PIPE_BIND_DEPTH_STENCIL|PIPE_BIND_SAMPLER_VIEW is set.
Comment 1 Ilia Mirkin 2018-02-17 00:19:38 UTC
They're managing to attach a depth texture to a GL_COLOR_ATTACHMENT0? That shouldn't be possible... but I don't see any logic blocking it in framebuffer_texture_with_dims.
Comment 2 Ilia Mirkin 2018-02-17 00:28:33 UTC
OK, looks like the literal attach is legal, but then the framebuffer isn't complete. From OpenGL 4.6:

"""
The framebuffer attachment point attachment is said to be framebuffer attachment
complete if the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE for
attachment is NONE (i.e., no image is attached), or if all of the following conditions are true:

...

If attachment is COLOR_ATTACHMENTi, then image must have a color-renderable
internal format.
"""

This should be handled in fbobject.c:test_attachment_completeness . Needs more investigation as to what's going wrong.
Comment 3 vadym 2018-03-09 15:02:28 UTC
Tried to run DyingLight on Ubuntu 16.04 but got an error that detected opengl version is 3.0 but needed is 3.3. But in glxinfo I can see 4.5 version of opengl. After this game is loaded and some audio is played but nothing on the screen. 

My setup info:

My setup info:
OS: Ubuntu 16.04 LTS 64 bit
Firefox: 58.0.2 (64-bit)
Mesa: 18.1.0-devel (git-33633690aa) 
CPU: Intel® Core™ i7-8550U CPU @ 1.80GHz × 8 
GPU: Intel® UHD Graphics 620 (Kabylake GT2)
Comment 4 Denis 2018-06-27 10:10:13 UTC
hi. Is this issue still actual?
I tried to run game on debug mesa, and didn't see any assertion errors.

There were 2 things I did for this:
1. added "override" for GL version
2. launched on earlier mesa versions, because latest one has stable crash (https://bugs.freedesktop.org/show_bug.cgi?id=106997)
Comment 5 Grazvydas Ignotas 2018-06-27 22:08:08 UTC
Yes the issue is still there on latest mesa git, at least with radeonsi.

Note that you need to change some video setting for the assert to trigger (from in main menu). For me it's enough to toggle vsync, for example.
Comment 6 Mike Lothian 2018-06-27 22:41:24 UTC
If you're running radeonsi, can you try the patches from https://gitlab.freedesktop.org/tarceri/mesa/commits/ARB_gpu_shader_fp64 or https://github.com/FireBurn/PortageStuff/tree/master/patches/media-libs/mesa-9999

I used to see the issue where Dying Light used to crash on changes made to the graphical settings, however since bumping the compat version properly rather than forcing it, it seems to have fixed the issue
Comment 7 Grazvydas Ignotas 2018-07-04 09:04:14 UTC
It seems the patches have landed, and while GL version overrides are no longer needed, the assert still triggers for me. Perhaps you've built a non-debug version when you tested?
Comment 8 Mike Lothian 2018-07-04 09:19:31 UTC
Correct, I've only ever used debug builds when debugging issues

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.