Bug 107728

Summary:	Wrong background in Sascha Willem's Multisampling Demo
Product:	Mesa	Reporter:	LunarG <johnz>
Component:	Drivers/Vulkan/intel	Assignee:	Jason Ekstrand <jason>
Status:	RESOLVED FIXED	QA Contact:	Intel 3D Bugs Mailing List <intel-3d-bugs>
Severity:	normal
Priority:	medium	CC:	david, jason
Version:	18.1	Keywords:	bisected, regression
Hardware:	x86-64 (AMD64)
OS:	All
Whiteboard:
i915 platform:		i915 features:

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.