[Mesa-dev] [PATCH] anv: gen9 doesn't support fast clear on single-sampled SRGB buffers

[Lionel Landwerlin]

The problem is a bit more annoying than I initially thought :(

Here is what the vkd3d test does :

1. Create image format R8G8B8A8_UNORM
2. Create image view format R8G8B8A8_SRGB
3. Clear the view through a sub pass to a particular color
4. Barrier on the image to from color attachment to source transfer
5. Copy the image into a linear buffer to check the content

The problem happens at step 4 because that's where we resolve the image.
Because the barrier command operates on images, it'll do a resolve in 
the format of the image, not the view.
So we end up writing the clear color in the UNORM format hence the test 
failure.

I'm not quite sure how to deal with this. The spec says those format 
should be compatible, so no flags are required at image creation that 
could hint to disable the compression so we avoid the resolve and don't 
run into this issue...

Currently I'm thinking of storing an additional color field in the clear 
color information so that gets loaded into the blorp shader and then can 
apply some srgb conversion if needed.

Thoughts?

Thanks a lot,

-
Lionel

On 21/12/2018 13:13, Lionel Landwerlin wrote:
> Looking at this, I think the issue is more in anv_blorp.c.
> All of the mcs/ccs ops we're doing use the anv_image which can be a 
> different format from the anv_image_view we're dealing with.
> In this particular bug, the image is R8G8B8A8_UNORM while the view is 
> R8G8B8A8_SRGB.
>
> I think this might be the problem.
> Currently looking at adding 
> anv_image_view_mcs_op/anv_image_view_ccs_op and see if that breaks the 
> world.
>
> -
> Lionel
>
> On 21/12/2018 13:09, Jason Ekstrand wrote:
>> This isn't quite true. Fast-clear without CCS compression (also known 
>> as CCS_D) is supported on gen9. There is, however, a bug with 
>> blending and non-0/1 clear colors that we don't currently bother 
>> handling in anv. See also:
>>
>> https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/mesa/drivers/dri/i965/intel_mipmap_tree.c#L2672 
>>
>>
>> On December 21, 2018 06:26:31 Samuel Iglesias Gonsálvez 
>> <siglesias at igalia.com> wrote:
>>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108911
>>>
>>> Signed-off-by: Samuel Iglesias Gonsálvez <siglesias at igalia.com>
>>> ---
>>>
>>> Lionel, I have doubts if this is only for gen9 or it should be gen9+.
>>> Can you confirm on gen10 if the sRGB bug is happening there and if this
>>> fixes it? (You would need to adapt the GEN_GEN == 9 to >=).
>>>
>>> src/intel/vulkan/genX_cmd_buffer.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/src/intel/vulkan/genX_cmd_buffer.c 
>>> b/src/intel/vulkan/genX_cmd_buffer.c
>>> index 93b5269c6ba..cb08ef8df1e 100644
>>> --- a/src/intel/vulkan/genX_cmd_buffer.c
>>> +++ b/src/intel/vulkan/genX_cmd_buffer.c
>>> @@ -324,6 +324,10 @@ color_attachment_compute_aux_usage(struct 
>>> anv_device * device,
>>>          break;
>>>       }
>>>
>>> +      /* Gen9 doesn't support fast clear on single-sampled SRGB 
>>> buffers */
>>> +      if (GEN_GEN == 9 && 
>>> isl_format_is_srgb(iview->planes[0].isl.format) && 
>>> iview->image->samples == 1)
>>> +         att_state->fast_clear = false;
>>> +
>>>       /* Potentially, we could do partial fast-clears but doing so 
>>> has crazy
>>>        * alignment restrictions.  It's easier to just restrict to 
>>> full size
>>>        * fast clears for now.
>>> -- 
>>> 2.19.1
>>>
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>>
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev