Bug 110295 - DiRT 4 has rendering problems
Summary: DiRT 4 has rendering problems
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Vulkan/intel (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: mesa-19.2
  Show dependency treegraph
 
Reported: 2019-04-01 00:27 UTC by leozinho29_eu
Modified: 2019-09-17 07:10 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Video showing the problems and file with the game settings (19.35 MB, application/x-tar)
2019-04-01 00:27 UTC, leozinho29_eu
Details
fix_flicker_workaround (643 bytes, patch)
2019-04-01 16:10 UTC, Denis
Details | Splinter Review
workaround_patch_CORRECT (643 bytes, patch)
2019-04-01 16:13 UTC, Denis
Details | Splinter Review
Backtrace (2.35 MB, text/plain)
2019-08-08 23:25 UTC, leozinho29_eu
Details

Description leozinho29_eu 2019-04-01 00:27:12 UTC
Created attachment 143826 [details]
Video showing the problems and file with the game settings

On the game DiRT 4, which recently got a native version for Linux and uses Vulkan, it were observed some problems on rendering:

-The track may start to blink until it becomes completely black, this entire effect can last for up to 3 seconds;
-Some apparent white/black "holes" can appear on parts of the scenario very briefly;
-Some interface elements blink on the load menu, the most distinctive one is the element on bottom left which has a report related to the stage (19 seconds on the video);
-Some elements may blink similarly on the track, which are most noticeable on race start;
-The interior of the car may appear in random places and appear with no textures sometimes, this one can be pretty negative as it may cover the entire vision.

It seems that certain stages trigger specific problems more often than others. As it's a Vulkan game there is no apitrace to obtain, unfortunately.

The file attached has a video showing a part of a stage. The video and audio aren't synchronized and video cuts in the middle of the race because the computer couldn't keep recording, even encoding with half of the resolution and 12 FPS. DiRT 4 uses everything the computer has, which is enough to get consistent 30 FPS with settings on Ultralow. The other file is the preferences file.

System specifications:

Processor: Intel Core i3-6100U;
Video: Intel HD Graphics 520;
Architecture: amd64;
RAM memory: 8 GB;
Mesa: 19.1.0-devel (git-e4e6a3deaf);
Kernel version: 4.18.0-16-lowlatency;
Distribution: Xubuntu 18.04.2 amd64.
Comment 1 Denis 2019-04-01 16:10:15 UTC
Created attachment 143835 [details] [review]
fix_flicker_workaround

hi. Could you please do few things for me please?
I found out, that flickering disappear, if I turn off Vsync. I confirmed this behaviour for system 18.3.5 and built from source 19.1.0 mesa versions.

I can say that ultra-low settings and minimum resolution leads to quite playable game.

My configuration:
OS Fedora 29
Mesa (18.3.5, 19.1.0)
Kernel 4.20.16
gpu Skylake (HD 520)

Also, if I apply this patch (attached to issue) - problem disappears for me (in both cases, with Vsync and without).
So this leads me to idea that it is the same problem with 
https://bugs.freedesktop.org/show_bug.cgi?id=109630
https://bugs.freedesktop.org/show_bug.cgi?id=109616

One more thing - in case if I exchange driver (applying compiled manually instead of system) - game needs about 5-10 minutes to start (loading screen displays).
In case of system mesa version - game starts fast.
Comment 2 Denis 2019-04-01 16:11:47 UTC
Comment on attachment 143835 [details] [review]
fix_flicker_workaround

>diff --git a/src/intel/vulkan/genX_cmd_buffer.c b/src/intel/vulkan/genX_cmd_buffer.c
>index e5daf8b037d..2fc73435161 100644
>--- a/src/intel/vulkan/genX_cmd_buffer.c
>+++ b/src/intel/vulkan/genX_cmd_buffer.c
>@@ -2771,6 +2771,7 @@ genX(cmd_buffer_flush_state)(struct anv_cmd_buffer *cmd_buffer)
>    if (cmd_buffer->state.descriptors_dirty)
>       dirty = flush_descriptor_sets(cmd_buffer);
> 
>+   cmd_buffer->state.push_constants_dirty |= VK_SHADER_STAGE_ALL_GRAPHICS;
>    if (dirty || cmd_buffer->state.push_constants_dirty) {
>       /* Because we're pushing UBOs, we have to push whenever either
>        * descriptors or push constants is dirty.
Comment 3 Denis 2019-04-01 16:13:17 UTC
Created attachment 143836 [details] [review]
workaround_patch_CORRECT

I am sorry, first patch was sent with mistake. Added correct one:
workaround_patch_CORRECT
Comment 4 leozinho29_eu 2019-04-01 19:13:35 UTC
I did the test with disabling vsync but it did not fix the problems to me, they were still happening, but with Mesa with this patch applied, then the game worked correctly without the blinking elements. I have seen no graphical problem anywhere in the game with this patch applied.

Here, the 10 minutes loading only happens when I use a certain Mesa version for the first time, the second time using the same Mesa version is used the game opens fast.
Comment 5 Denis 2019-04-02 11:53:42 UTC
hm, interesting (about vsync). But in total - if patch helped, I think, this may mean that it has same or similar root of problem with Witcher3 and VKQuake
Comment 6 Denis 2019-08-08 11:44:04 UTC
Hey Leozinho, could you please check this issue in the game on latest master mesa?

I checked Witcher and vkQuake, both were fixed with:

commit bc612536eb2f0f77725103e53077ad5a28036ac3 (HEAD -> master, origin/master, origin/HEAD)
Author: Jason Ekstrand <jason@jlekstrand.net>
Date:   Wed Jul 31 10:42:24 2019 -0500

    anv: Emit a dummy MEDIA_VFE_STATE before switching from GPGPU to 3D
    
    There is an object-level  preemption workaround which requires this.
    However, even without object-level preemption, we seem to have issues
    with geometry flickering when 3D and compute are combined in the same
    batch and this appears to fix it.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109630
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111267
    Cc: mesa-stable@lists.freedesktop.org
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Comment 7 leozinho29_eu 2019-08-08 23:25:53 UTC
Created attachment 144988 [details]
Backtrace

I tried testing DiRT 4 and I got the most strange crash I've ever seen. Using Mesa 19.2.0-devel (git-5a898e2a65), on Steam logs, a bit before the crash, the following appeared:

SPIR-V WARNING:
    In file ../src/compiler/spirv/spirv_to_nir.c:826
    Decoration not allowed on struct members: SpvDecorationRestrict
    1388 bytes into the SPIR-V binary
SPIR-V WARNING:
    In file ../src/compiler/spirv/spirv_to_nir.c:826
    Decoration not allowed on struct members: SpvDecorationRestrict
    2500 bytes into the SPIR-V binary
SPIR-V WARNING:
    In file ../src/compiler/spirv/spirv_to_nir.c:826
    Decoration not allowed on struct members: SpvDecorationRestrict
    2588 bytes into the SPIR-V binary
SPIR-V WARNING:
    In file ../src/compiler/spirv/spirv_to_nir.c:826
    Decoration not allowed on struct members: SpvDecorationRestrict
    2676 bytes into the SPIR-V binary
SPIR-V WARNING:
    In file ../src/compiler/spirv/spirv_to_nir.c:826
    Decoration not allowed on struct members: SpvDecorationRestrict
    2800 bytes into the SPIR-V binary
SPIR-V WARNING:
    In file ../src/compiler/spirv/spirv_to_nir.c:826
    Decoration not allowed on struct members: SpvDecorationRestrict
    2856 bytes into the SPIR-V binary

And then the game crashed with a segmentation fault. The backtrace, which is really strange, is attached. As the game is crashing when trying to start a stage, I can't test if this bug was fixed.
Comment 8 leozinho29_eu 2019-08-08 23:28:11 UTC
Also, there is the following in dmesg:

[368518.106893] traps: IdxD3D11_1[25466] general protection ip:7f4dbb871b10 sp:7f4d2e7d64b0 error:0 in libvulkan_intel.so[7f4dbb5c1000+541000]
[368760.788230] traps: IdxD3D11_1[30128] general protection ip:7fffafa99b10 sp:7fff23fd94b0 error:0 in libvulkan_intel.so[7fffaf7e9000+541000]
[368980.314952] traps: IdxD3D11_1[2320] general protection ip:7fffafa99b10 sp:7fff25fdd4b0 error:0 in libvulkan_intel.so[7fffaf7e9000+541000]
Comment 9 leozinho29_eu 2019-08-09 00:44:35 UTC
As this blinking elements bug was present on Elite Dangerous too, I tested Mesa 19.2.0-devel (git-5a898e2a65) with Elite Dangerous. In that game, there were no blinking elements, so it seems this bug is fixed.

Regarding DiRT 4, should I report this DiRT 4 crash as a new bug? The backtrace is really unhelpful.
Comment 10 Denis 2019-08-09 08:38:43 UTC
>Regarding DiRT 4, should I report this DiRT 4 crash as a new bug? The backtrace is really unhelpful.

thank you for feedback! Let me then find the game one more time (one friend had it on steam acc :) and reproduce.

I think it would be correct to open a new one, as it doesn't relate to artifacts in this bug report.
Comment 11 Denis 2019-08-09 11:49:55 UTC
good news. Game is crashing only on Debug mesa.

Built release one on this commit - 

commit 5e38db0c47ca57c6e904f44d0d0e9ef299d14f3c (HEAD -> master, origin/master, origin/HEAD)
Author: Tapani Pälli <tapani.palli@intel.com>
Date:   Thu Aug 8 14:57:14 2019 +0300

Game works fine, and flickering wasn't observed. I checked on max screen settings with and without vSync.
I created new ticket => https://bugs.freedesktop.org/show_bug.cgi?id=111339

Leozinho, you may try "release" flag for mesa. From my side confirming the fix.
Comment 12 leozinho29_eu 2019-09-17 01:27:07 UTC
I have tested Mesa 19.3.0-devel (git-eea6f21cbd) and, while the loading is longer, now it no longer crashes. The flickering also no longer exists, the game is working correctly.
Comment 13 Denis 2019-09-17 07:10:31 UTC
so, the final message is:

fixed with

commit bc612536eb2f0f77725103e53077ad5a28036ac3 (HEAD -> master, origin/master, origin/HEAD)
Author: Jason Ekstrand <jason@jlekstrand.net>
Date:   Wed Jul 31 10:42:24 2019 -0500

    anv: Emit a dummy MEDIA_VFE_STATE before switching from GPGPU to 3D


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.