Bug 109630 - vkQuake flickering geometry under Intel
Summary: vkQuake flickering geometry under Intel
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Vulkan/intel (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
: 111267 (view as bug list)
Depends on:
Reported: 2019-02-14 12:13 UTC by Ricardo Garcia
Modified: 2019-08-08 10:46 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Note You need to log in before you can comment on or make changes to this bug.
Description Ricardo Garcia 2019-02-14 12:13:19 UTC

I'm running vkQuake from git master (89f0979b1c86b7923b5ddeebde06791018fd3eea) and using mesa master (227df98fa63ae5cd0509399c030d74dc6f524226) under Fedora 29, with kernel 4.20.7-200.fc29.x86_64.

Hardware is the integrated graphics card on an Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, which is an Intel(R) UHD Graphics 620 (Kabylake GT2).

When running the game normally, I see flickering geometry almost constantly, like pieces of the level missing. Here's an example of a wrong frame:


Compared to a correct frame:


It doesn't happen running vkQuake on a different computer with Fedora 29 and the proprietary NVIDIA drivers.

I've recorded a few seconds with vktrace in which the problem is visible and reproducible with vkreplay in my system. Note the recording may need to be reproduced under X11 and not Wayland.


Instructions to replay:
xz -d vkquake-flicker-3.vktrace.xz
vkreplay -o vkquake-flicker-3.vktrace

vkQuake can be downloaded here:


And I was using the shareware version of the game data when reproducing the bug.

Please do not hesistate to ask for more information if you need it.
Comment 1 Denis 2019-02-14 14:02:12 UTC
hi Ricardo, thanks for the report. Question - it is flickering where any part of any texture can flick as "black" fast? If so, then looks like I reproduced it on my machine.
Comment 2 Ricardo Garcia 2019-02-14 15:21:39 UTC
Hi Denis,

Thanks for the quick reply. It's not only the textures apparently going black but also some geometry disappearing. I think I got a nice recording of the effect here:


Let me know if that's what you see.
Comment 3 Denis 2019-02-14 16:10:14 UTC
yes, great record which shows exactly the same what I meant. So to summarize:
1. this flickering exists in game since working with this issue https://bugs.freedesktop.org/show_bug.cgi?id=97229 (I mean that it is not regression in mesa, I checked late 17.* and most of 18 mesa versions)

2. Also on all my PC's I see weird green/black flickering during game starting, which can be reproduced only after launching game and only in the menu. Can't be reproduced in game (and possibly, doesn't relate to current issue)

3. I tested this game on 3 different GPU (HD 620, UHD 620 and UHD 630), and can say, that provided trace flickers more often exactly on U... gpu's. 

So we need developers opinion on this thing, game is quite old and maybe some time ago this issue was already raised or discussed
Comment 4 Ricardo Garcia 2019-02-14 17:25:35 UTC
Thanks for reproducing it and running all those tests!

I also see the menu flickering you mention. In fact, sometimes the flicker between green, black and the menu becomes so intense it's hard to look at the screen.
Comment 5 nagrigoriadis 2019-03-19 13:20:12 UTC
Seems to be the same as https://bugs.freedesktop.org/show_bug.cgi?id=109616

Some geometry intermittently disappearing for a frame.
Comment 6 Danylo 2019-03-29 16:57:12 UTC
Yes, after more investigation https://bugs.freedesktop.org/show_bug.cgi?id=109616 seems to have the same cause.

The issue is somewhere with push constants. If I upload push constants for vertex shader before every draw - the flickering is gone. 

And it also has some connection to compute workload since if I just disable dispatches in vkQuake - flickering is gone.
Comment 7 Danylo 2019-03-29 17:03:00 UTC
To have the minimum amount of vulkan calls one can comment out all draws in R_RenderScene of vkQuake and left only R_ShowTris.

To test that compute dispatch affects this comment out dispatch in R_ComputeWarpTexture
Comment 8 Jason Ekstrand 2019-03-29 17:21:58 UTC
A few more notes:

 1. Flagging dirty push constants on every draw makes the flicker go away.

 2. VkQuake uses actual Vulkan push constants which is a bit weird.  Witcher 3 via DXVK probably doesn't though so if they're related, it may not be push constants.

 3. Denis said it may have something to do with compute (if you disable compute dispatch in the driver, the flickering goes away).  This made me wonder if it had something to do with switching between 3D and compute.  Flushing push constants after PIPELINE_SELECT does nothing. :-(

 4. Disabling UBO pushing by commenting out brw_nir_analyze_ubo_ranges() in anv_pipeline.c does nothing.

 5. Flagging dirty descriptors also makes the flicker go away.  Dirty push constants always cause dirty descriptors but not the other way around so maybe it's actually something with binding tables?

I'm not really sure where to go next with this one.  It could also, I guess, be blorp related possibly though blorp usually causes pretty complete state flushing.
Comment 9 Danylo 2019-04-01 09:38:24 UTC
> 2. VkQuake uses actual Vulkan push constants which is a bit weird.  Witcher 3 
> via DXVK probably doesn't though so if they're related, it may not be push 
> constants.

From what I see DXVK uses push constants for some operations but not for actual rendering.

Also while it's easy to test that disabling compute helps vkQuake, The Witcher 3 doesn't show anything useful without compute.
Comment 10 Danylo 2019-04-01 12:56:16 UTC
Ok, one more update:
A part of the dispatch which seems to lead to the issue is MEDIA_INTERFACE_DESCRIPTOR_LOAD, commenting out everything unnecessary around doesn't make flickering disappear, the moment MEDIA_INTERFACE_DESCRIPTOR_LOAD is commented out - no flicker.

So the minimal reproduction will be commenting out the dispatch and adding this at the start of cmd_buffer_flush_state:

   if((cmd_buffer->state.gfx.dirty & ANV_CMD_DIRTY_PIPELINE) &&
      struct anv_pipeline *pipeline = cmd_buffer->state.compute.base.pipeline;
      cmd_buffer->state.pending_pipe_bits |= ANV_PIPE_CS_STALL_BIT;
      anv_batch_emit_batch(&cmd_buffer->batch, &pipeline->batch);

      struct anv_state state =
               GENX(INTERFACE_DESCRIPTOR_DATA_length), 64);

      uint32_t size = GENX(INTERFACE_DESCRIPTOR_DATA_length) * sizeof(uint32_t);
                     GENX(MEDIA_INTERFACE_DESCRIPTOR_LOAD), mid) {
         mid.InterfaceDescriptorTotalLength        = size;
         mid.InterfaceDescriptorDataStartAddress   = 0;

      // Just to be sure...
      cmd_buffer->state.gfx.dirty = ~0;
      cmd_buffer->state.gfx.vb_dirty = ~0;
      cmd_buffer->state.pending_pipe_bits = ~0;
      cmd_buffer->state.descriptors_dirty = ~0;
      cmd_buffer->state.push_constants_dirty = ~0;

Which produces the same issue.
Comment 11 Jason Ekstrand 2019-07-31 14:12:12 UTC
*** Bug 111267 has been marked as a duplicate of this bug. ***
Comment 12 Svenn-Arne Dragly 2019-07-31 14:56:13 UTC
Thanks for pointing out that this is a likely duplicate of Bug 111267!

I should probably add that the compute pass is strictly necessary to reproduce the bug in my case as well. Removing the empty compute pass also removes the flickering.

I am not sure if the following is related, but in a different application I am also experiencing that two subsequent compute passes are "overlapping" on this driver. This is even though barriers should have been properly inserted between them. Running this application on an older machine with Intel graphics or on an Nvidia card works fine. And by overlapping, I mean that if I am writing to the same buffer in both compute shaders, the output of the first shader sometimes ends up being stored in the buffer at the end of some frames. Kind of like a flicker.

Again, I am not sure if it is related or helps in any way. Let me know if I can provide any more details.
Comment 13 Jason Ekstrand 2019-07-31 15:48:10 UTC
Does this bug also exist on Broadwell or is it gen9-only?  My guess is gen9-only.  Also, does this fix witcher? https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1526  I've tested and it seems to fix vkQuake.
Comment 14 Svenn-Arne Dragly 2019-08-01 08:38:18 UTC
I have only tested on Haswell and gen-9. The bug is not present on Haswell.
Comment 15 Svenn-Arne Dragly 2019-08-01 12:32:52 UTC
Just tested your patch (https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1526) and it fixes the visual flickering bug for me. Thanks!

Also tested the issue I had with the "overlapping" compute shaders, but that was not fixed. I will see if I can create a minimal working example for that and file a separate bug report - unless the error should turn out to be in my code, of course.

By the way, I just realized that I have seen a couple of your talks when reading up on Vulkan, Jason. Thanks for those as well. I learned a lot!
Comment 16 Denis 2019-08-08 10:46:43 UTC
as this commit was merged to master and tested by Svenn-Arne Dragly and from our side, closing issue as fixed.

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>

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.