On 03/08/16 16:01, Jason Ekstrand wrote:
On Aug 3, 2016 5:53 AM, "Lionel Landwerlin"
<[email protected] <mailto:[email protected]>>
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
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
