[Mesa-dev] [PATCH] anv: GetDeviceImageFormatProperties: fix transfer destination formats

[Jason Ekstrand]

On Aug 5, 2016 2:30 AM, "Lionel Landwerlin" <lionel.g.landwerlin at intel.com>
wrote:
>
> On 03/08/16 16:01, Jason Ekstrand wrote:
>>
>> On Aug 3, 2016 5:53 AM, "Lionel Landwerlin" <
lionel.g.landwerlin at intel.com> wrote:
>> >
>> > We let the user believe we support some transfer destination formats
>> > which we don't. This can lead to crashes when actually trying to use
>> > those formats for example on
>> > dEQP-VK.api.copy_and_blit.image_to_image.* tests.
>> >
>> > Allow formats we can render to as meta implements transfers using
>> > attachments.
>>
>> Sadly, it's not quite that simple... Nanley and I had a long chat about
this in the office last week.  I'll try and summarize here.  Let's take one
particular format as an example: R9G9B9E5.  This format is required to be
supported for sampling with VK_TILING_OPTIMAL but has no requirements on
rendering.  We can sample from it but cannot render to it.  Since it's
required to be supported in a tilled configuration, the only way the user
can get data into it is through vkCopy* commands. This means it has to be
supported as a transfer destination.  This means we have to support
vkClearColorImage on it as well.
>>
>> This implies two things: First, the correct criterion for supporting
transfer operations is render, depth-stencil, *or* sampling.  Second, we
really need to come up with a better clearing sorry than just "bind as a
render target and draw".  While this works for most formats, there are a
few where we have to bind as a different format and manually convert the
data.
>>
>> Make sense?
>>
>> --Jason
>
>
> Make sense.
>
> If I follow, then it seems the source transfer condition is wrong as well
(since they only check against sampling)?

That's correct.  In practice, checking for sampling is provably the same as
checking all of them but the correct thing to do is say " if it's supported
for anything then it's supported for transfer."

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160805/b3b77690/attachment-0001.html>