Bug 110353 - weird colors seen in valley
Summary: weird colors seen in valley
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/Iris (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: bisected, regression
Depends on:
Blocks:
 
Reported: 2019-04-08 11:15 UTC by Tapani Pälli
Modified: 2019-04-19 04:53 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
camera shot (309.63 KB, image/jpeg)
2019-04-08 11:16 UTC, Tapani Pälli
Details
workaround (781 bytes, patch)
2019-04-09 06:58 UTC, Tapani Pälli
Details | Splinter Review

Description Tapani Pälli 2019-04-08 11:15:38 UTC
When running valley benchmark, sometimes weird colourful rectangles pop up.
Comment 1 Tapani Pälli 2019-04-08 11:16:16 UTC
Created attachment 143892 [details]
camera shot
Comment 2 Tapani Pälli 2019-04-08 11:38:23 UTC
bisected to:

--- 8< ---
commit 365886ebe1a54f893b688b457553eead6aa572ea
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Sat Mar 9 01:27:20 2019 -0800

    iris: Skip framebuffer resolve tracking if framebuffer isn't dirty
    
    Improves drawoverhead baseline score by 1.86x.
Comment 3 Kenneth Graunke 2019-04-08 21:37:59 UTC
Is this on Broadwell?  Rafael mentioned that it broke some Piglit tests there too, but we haven't turned it on in CI, so I failed to notice...
Comment 4 Tapani Pälli 2019-04-09 05:15:28 UTC
This is on Kabylake. Also wanted to rephrase a bit, by 'sometimes' I mean it happens always when running the benchmark but not all the time but only on some frames. I can also pause on such a frame and the rectangle-monster keeps changing it position and colours a bit but is constant.
Comment 5 Tapani Pälli 2019-04-09 05:34:11 UTC
I noticed that iris_predraw_resolve_drawbuffer does not flush the stencil bo because the condition checks only IRIS_DIRTY_DEPTH_BUFFER and not IRIS_DIRTY_WM_DEPTH_STENCIL. Adding the IRIS_DIRTY_WM_DEPTH_STENCIL to the check does not fix this issue though so I'm not sure if that's a problem.
Comment 6 Tapani Pälli 2019-04-09 06:58:08 UTC
Created attachment 143906 [details] [review]
workaround

This change removes the artifacts, so I guess (IRIS_DIRTY_BINDINGS_FS | IRIS_DIRTY_BLEND_STATE) is not being correctly set.
Comment 7 Tapani Pälli 2019-04-09 10:08:42 UTC
Some more findings .. I noticed that iris misses the Unigine workaround for dual src blending, not sure if that is related though as the workaround patches seemingly makes things work (?) but I did see that util_blend_state_is_dual() will return true sometimes during the benchmark.
Comment 8 Kenneth Graunke 2019-04-19 04:53:33 UTC
Fixed by

commit a913fbf124e201a8bf53fe8385619a71a6e9594b
Author: Kenneth Graunke <kenneth@whitecape.org>
Date:   Thu Apr 18 14:35:26 2019 -0700

    iris: Be less aggressive at postdraw work skipping
    
    We empty the cache sets when flushing the batch, at which point we need
    to add any framebuffer related BOs even though the bindings haven't
    changed.  So, we now do the cache set tracking unconditionally.
    
    For now, we continue skipping resolve work based on the same conditions
    in the predraw functions - the thinking is if we didn't trigger
    resolves, there's nothing to update here.  Time will tell if this works.
    
    Partly reverts commit 365886ebe1a54f893b688b457553eead6aa572ea, and
    fixes Unigine Valley rendering on Gen9+.  Drops drawoverhead scores
    by about 10-12%.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110353


We do still need to implement dual color blend by location.


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.