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

[Lionel Landwerlin]

On 03/08/16 16:01, Jason Ekstrand wrote:
>
> On Aug 3, 2016 5:53 AM, "Lionel Landwerlin" 
> <lionel.g.landwerlin at intel.com <mailto: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)?

Thanks a lot,

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