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.

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:

https://people.igalia.com/rgarcia/vkquake-flicker.mp4

Let me know if that's what you see.

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

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.

Seems to be the same as https://bugs.freedesktop.org/show_bug.cgi?id=109616

Some geometry intermittently disappearing for a frame.

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.

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

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.

> 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.

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) &&
      cmd_buffer->state.compute.base.pipeline)
   {
      struct anv_pipeline *pipeline = cmd_buffer->state.compute.base.pipeline;
      genX(flush_pipeline_select_gpgpu)(cmd_buffer);
      cmd_buffer->state.pending_pipe_bits |= ANV_PIPE_CS_STALL_BIT;
      genX(cmd_buffer_apply_pipe_flushes)(cmd_buffer);
      anv_batch_emit_batch(&cmd_buffer->batch, &pipeline->batch);

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

      uint32_t size = GENX(INTERFACE_DESCRIPTOR_DATA_length) * sizeof(uint32_t);
      anv_batch_emit(&cmd_buffer->batch,
                     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.

*** Bug 111267 has been marked as a duplicate of this bug. ***

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.

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.

I have only tested on Haswell and gen-9. The bug is not present on Haswell.

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!

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>