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

[Jason Ekstrand]

For mutable format images, I don't think we can safely allow the clear 
color to escape the render pass. Otherwise we'd have to do annoying 
trickery to resolve with the correct format. We could do a bunch of 
predicated resolves or we could emit an MI command to whack the surface 
state. Neither of those sounds good. Sorry, that's not really a solution?

--Jason

On December 22, 2018 19:07:33 Lionel Landwerlin 
<lionel.g.landwerlin at intel.com> wrote:

> 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