Danylo, can you take a look and figure out if it is an app bug?

hello Deve, Mark.
I tested this issue and found out that it was fixed in commit below. Bisect was maden between 18.3.4 and 19.0.0-rc7 tags.
Firstly it made me crazy, because I got different results even for the same mesa version (like, 18.3.4 first time may show issue, after re-launching application - not).
This was solved by adding MESA_GLSL_CACHE_DISABLE=1 before binary name.
I think, some shaders simply were cached, and that could lead to wrong results.

Latest master (if you run app like this MESA_GLSL_CACHE_DISABLE=1 ./supertuxcart) doesn't have this issue.



commit 5a9b7bce9cee5563e94e75c93fffe462405dfcb1 (HEAD, refs/bisect/good-5a9b7bce9cee5563e94e75c93fffe462405dfcb1)
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date:   Mon Feb 4 22:57:06 2019 -0500

    nv50,nvc0: use condition for occlusion queries when already complete
    
    For the NO_WAIT variants, we would jump into the ALWAYS case for both
    nested and inverted occlusion queries. However if the query had
    previously completed, the application could reasonably expect that the
    render condition would follow that result.
    
    To resolve this, we remove the nesting distinction which unnecessarily
    created an imbalance between the regular and inverted cases (since
    there's no "zero" condition mode). We also use the proper comparison if
    we know that the query has completed (which could happen as a result of
    an earlier get_query_result call).
    
    Fixes KHR-GL45.conditional_render_inverted.functional
    
    Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
    Cc: 19.0 <mesa-stable@lists.freedesktop.org>
    (cherry picked from commit e00799d3dc0595dc3998dbf199ceec8b1eece966)

I am sorry, attached commit - it is the last "with issue".

First commit which didn't have this issue, here:


commit d278b3c187d426fea5ded7e8d97022efc9e9d7e3 (HEAD, refs/bisect/bad)
Author: Ilia Mirkin <imirkin@alum.mit.edu>
Date:   Tue Feb 5 03:05:33 2019 -0500

    nvc0: stick zero values for the compute invocation counts
    
    Not quite perfect, but at least we don't end up with random values in
    the query buffer.
    
    Fixes KHR-GL45.pipeline_statistics_query_tests_ARB.functional_default_qo_values
    
    Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
    Cc: 19.0 <mesa-stable@lists.freedesktop.org>
    (cherry picked from commit 6adb9b38bfb1f6ee4c94596bf0744225aa8e967a)

and sorry one more time. Now it flickers even on 19.0.0-rc7. So it really looks like completely random. Continue investigations

The original bug report says
"If you set all graphics settings to the lowest possible value except Improved Graphics and shadow (low or high), the shadows flash like crazy."

so maybe it is more visible on lower settings and only shadows enabled. For me it was always reproducible on highest settings.

It also behaves a bit "funny" for me. If I increase the wind direction to much higher values in c++ side, then it flickers much less. But using higher/different values in shaders doesn't help. And if I move "uniform vec3 wind_direction;" to the first line in shader, then it works without issues.

right now I can reproduce issue on max settings (6) in Graphics tab.
And still it is random. One time flickers - after restarting - not. I tried to make apitrace... but it creates without everything except sky - so useless.

Are you sure that you fixed it with your "hack"? And it wasn't the case when issue simply didn't reproduce?

I just can't reproduce it after that modification. And it just gives me impression that it's related to uniform variables...

All of this tells me that the issue is not related to my commit because the commit fixes the issue with the dual source blending which itself isn't even used in the game. And looking at troubles Denis is going through - maybe a wrong commit was found during the bisect?

I'm not near a machine with the necessary gpu  at the moment so I'm not able to definitely tell what's wrong. However Denis will probably provide more information later.

you may want MESA_EXTENSION_OVERRIDE="-GL_ARB_buffer_storage" apitrace trace bin/supertuxkart to avoid buffer storage usage in stk because we used MAP_COHERENT_BIT

I see all kinds of STK flickering with 0.9.3 from debian testing.  I see the same behavior on mesa master and 18.1.

This is on my Intel skylake system (HD520).

Since the behavior is consistent on our driver, it seems likely to me that a change to STK is causing this.

Is anyone able to test on an older STK?

On my system, with Ubuntu 18.04 and Mesa 18.3.3 from http://ppa.launchpad.net/ubuntu-x-swat/updates/ubuntu, I have this issue.  It started recently, so I assumed it was a certain change in the code, but that change was then reverted, and the issue is still present.  It is especially noticeable in Black Forest due to the large amount of trees.

@Mark Janes I checked STK 0.9.2 and it behaves the same. For older versions it would need some fixes in code to make shadows working with mesa. Actually I was using laptop with intel hd4000 for a long time and I never saw this bug before.

And if it's random for others, then maybe the bisected commit is unrelated and it just exposed a bug that is somewhere else...

@Deve - 
>I can "fix" this by changing order of the "layer" and "wind_direction" uniform variables. Maybe it's just a case.

Does it fix bisected by you commit (from Danylo)?
I made bisection one more time (and now I think that it was the most correct), but I did what you suggested (first line in shader is "wind_dircection", second - "layer".

As I wrote before, this issue is completely random. It can be reproduced, like, 1/5, or even 1/10 launches. Sometimes - 1 time from 2 launches.

So, 17.3.6 was stable (I did about 50 launches or even more), and 18.3.4 - with an issue. Also issue existed in 19.0.0-rc7 (simply I had them compiled).

And result of bisection also lead me to Danylo's commit.
>you may want MESA_EXTENSION_OVERRIDE="-GL_ARB_buffer_storage" apitrace trace bin/supertuxkart

thanks a lot! It helped and I made an apitrace.
I will discuss my results with Danylo when he will be available.

>This is on my Intel skylake system (HD520).
Very interesting. I made an apitrace, and ran it on SKL (fedora 29) about 10 times. Didn't see flickerings.
Also I checked app (and apitrace) on my KBL - with 19.0 mesa version - also nothing.

Could you please check apitrace I did?
https://drive.google.com/open?id=1hTRS3tgBuSOSNiFGoy7JaLVKkVeNmwb0

UDP - everything I did, was maden on:
Fedora 29
HSW cpu

Mark, could you recheck if it flickers for you on skylake since neither I nor Denis are able to reproduce it on gen8+ ?

Ok, my commit indeed leads to flickering for a very strange reason.

Commenting blend state update on new fragment program mystically solves the issue (https://gitlab.freedesktop.org/mesa/mesa/commit/eca4a6548d07bbbb02a7768edb397bad7b72cfc2#a17c5c8577696d3d741e2bdb7e9ea61ca0356b89_3200_3219).

So something is not updated right. The closest thing in PRM I found was the HSW PRM, volume 2b, page 823 (3DSTATE_BLEND_STATE_POINTERS):

"When the BLEND_STATE pointer changes but not the CC_STATE pointer,
driver needs to force a CC_STATE pointer change to improve
blend performance in pixel backend."

And doing this fixed the issue for some unknown for me reason. However the same quote is present for gen8 but I didn't reproduce the flickering there...

Here is a patch - https://gitlab.freedesktop.org/mesa/mesa/merge_requests/660

Created attachment 143998 [details]
flickering on skl

Created attachment 143999 [details]
no flickering occurs during gnome screen record

I must be looking at a different bug.  When I run supertuxcart on skl, I see lots of flickering.  See attached video.  Curiously, I had to take a video of it with my phone, because the flickering *stops* when I enable gnome's screen recording (ctrl-alt-shift-r).

The non-flickering video is also attached for reference.

Danylo's patch has no affect on this behavior.

I tested the patch https://gitlab.freedesktop.org/mesa/mesa/merge_requests/660 with both first bad commit and current git version on my intel HD4000 and it solves the issue for me.

(In reply to Mark Janes from comment #17)
> I must be looking at a different bug.  When I run supertuxcart on skl, I see
> lots of flickering.  See attached video.  Curiously, I had to take a video
> of it with my phone, because the flickering *stops* when I enable gnome's
> screen recording (ctrl-alt-shift-r).
> 
> The non-flickering video is also attached for reference.
> 
> Danylo's patch has no affect on this behavior.

hi Mark. I rechecked again my SKL, and I couldn't reproduce this issue.
I have fedora 29 there.

I moved this issue to a separate bug => https://bugs.freedesktop.org/show_bug.cgi?id=110463
later I will setup debian testing and will try again.

I'm seeing STK 1.0 flickering similar to the attached video on a Skylake system (i7-6700HQ, Intel HD Graphics 530) with Ubuntu 19.04 (Mesa 19.0.2-1ubuntu1) as well.  The proposed patch (https://gitlab.freedesktop.org/GL/mesa/commit/ef9b640df2cd2e56186dd94edd72d48e4cb611b4.diff) applied to Ubuntu's Mesa 19.0.2-1ubuntu1 packages does *not* fix the issue for me; I still get flickering at graphics detail levels 4 and 5, while level 3 is OK before and after the patch.

Thanks for mentioning detail levels!

The flickering on SKL+ seems to be caused by the same issue as in Vulkan:
  https://bugs.freedesktop.org/show_bug.cgi?id=109630 - vkQuake
  https://bugs.freedesktop.org/show_bug.cgi?id=109616 - Witcher 3
  https://bugs.freedesktop.org/show_bug.cgi?id=110295 - Dirt 4
Which I attempted to fix in https://gitlab.freedesktop.org/mesa/mesa/merge_requests/621

In short something goes wrong with binding tables of 3D workload after compute workload.

Why I think it is the same issue:
- STK uses compute shaders on these detail levels.
- Commenting out dispatch helps.
- Always uploading push constants helps.

(In reply to Deve from comment #18)
> I tested the patch
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/660 with both first
> bad commit and current git version on my intel HD4000 and it solves the
> issue for me.

I would put update related to this bug, because there were a lot of flood higher.
Mentioned commit should fix current issue on Gen8 and lower CPU models.
So waiting for patch review and merge (if it is ok)

Any updates on this, especially since a patch already exists?  Would love to get this in Mesa master, and preferably ported to 19.2 and 19.1 also.

*** This bug has been marked as a duplicate of bug 110463 ***

I just built latest mesa on a bdw system (gen8) and could not repro any flickering, using the repro case described in the STK bug.  Reopen if you can find a way to make it happen on master.

I don't like such issues... I also tried to reproduce it, and couldn't. I couldn't reproduce it even using bisected commit. Tried apitrace and latest game version (for about 20 runs for both, because issue wasn't stable). Shadows look great now

hi Mark, did you reproduce it again on BRW? We tried a lot, but without success (and, in fact, we didn't find, why it started working correctly even on previously found "bad" commits).
Based on Danylo's findings and proposed patch, I assumed that same bug was left only on HSW, and created a new ticket for it https://bugs.freedesktop.org/show_bug.cgi?id=111631
And possibly it should be added to blockers instead current one.

Denis: you are right, I reopened this bug because of confusion around what platforms were still broken.  The HSW specific bug is the one that should block the release.

*** This bug has been marked as a duplicate of bug 110463 ***

Definitely not a dupe of https://bugs.freedesktop.org/show_bug.cgi?id=110463, even though that bug also got reported in these comments (but was then split into its own bug, as it should be).  The other bug is for texture flickering, this is for shadow flickering.  If shadows are confirmed fine, then it should be resolved as fixed, not dupe.

I agree with @QwertyChouskie. That's not a duplicate, because in case with skylake - there was a patch, fixed it. Current issue was fixed "somehow", so lets don't reopen it again :) and move our discussions into HSW issue.