Bug 107728 - Wrong background in Sascha Willem's Multisampling Demo
Summary: Wrong background in Sascha Willem's Multisampling Demo
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Vulkan/intel (show other bugs)
Version: 18.1
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Jason Ekstrand
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords: bisected, regression
Depends on:
Blocks:
 
Reported: 2018-08-28 16:23 UTC by LunarG
Modified: 2019-01-07 19:23 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description LunarG 2018-08-28 16:23:18 UTC
Introduced in the 18.1 branch (commit 92eb5bbc68d732463e9afb2373c9bd47e5ee0864), running Sascha Willem's Multisampling demo (https://github.com/SaschaWillems/Vulkan) will produce a black background where it should be white. 

Mesa versions from 18.0 produces the correct results. 

[Hardware]
Skylake CPU (530 graphics)

[Software]
Mesa 18.1, Ubuntu 16.04
Using Vkreplay from LunarG's SDK
Comment 1 Rafael Antognolli 2018-08-29 00:01:39 UTC
Quick update on this: in theory we should just revert that patch, because it's wrong, and even if we "fix" it by properly skipping the update of the clear color only during fast clears, we would only be saving a couple MI_MEM_COPY operations. It's probably better to just keep the code simpler and remove that logic.

However, while trying to revert it, I found that it regresses Haswell, so I'm debugging that now.
Comment 2 Jason Ekstrand 2018-08-29 00:58:19 UTC
Ugh... I reviewed that patch.  Now that I look at it in light of this, it's obviously wrong.  We also need inline clear colors for the source of MSAA resolves and maybe some other cases.  Rafael, do you remember why you did this?  Was it just to save some MI commands or did it have some deeper purpose?
Comment 3 Rafael Antognolli 2018-08-29 16:08:26 UTC
I don't remember for sure, but I think it was just to save the MI commands. That's the only thing I can remember now.
Comment 4 rukai 2018-12-04 20:10:26 UTC
Hi,
Looks like we hit this bug: https://github.com/vulkano-rs/vulkano/issues/1123
Has there been any progress?
Comment 5 mindtree 2019-01-04 03:20:00 UTC
It seems I'm also running into this via vulkano and I'm not yet sure of a workaround for MSAA. I'm also curious whether or not there has been any progress?
Comment 6 Jason Ekstrand 2019-01-04 19:15:52 UTC
Sorry for letting this one slip so long.  I've got a fix on the mailing list:

https://patchwork.freedesktop.org/patch/274598/

It would be awesome if someone could confirm this fixes vulkano.
Comment 7 Jason Ekstrand 2019-01-04 23:59:12 UTC
This is fixed by the following commit now in master:

commit 19c608fe43ae7e1578920326690a361ff1be9d88 (HEAD -> master, public/master)
Author: Jason Ekstrand <jason.ekstrand@intel.com>
Date:   Fri Jan 4 11:32:40 2019 -0600

    intel/blorp: Be more conservative about copying clear colors
    
    In 92eb5bbc68d7324 we attempted to avoid copying clear colors whenever
    we weren't doing a resolve.  However, this broke MSAA resolves because
    we need the clear color in the source.  This patch makes blorp much more
    conservative such that it only avoids the clear color copy if either
    aux_usage == NONE or it's explicitly doing a fast-clear.
    
    Fixes: 92eb5bbc68d7 "intel/blorp: Only copy clear color when doing..."
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107728
    Reviewed-by: Rafael Antognolli <rafael.antognolli@intel.com>

Sorry it took so long. :-(
Comment 8 Mark Janes 2019-01-07 19:23:08 UTC
the fix for this bug regresses the following crucible test on haswell:

func.renderpass.clear.color-render-area

Since haswell support is partial, this regression is not something that should block a mesa release.


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.