On Aug 5, 2016 2:30 AM, "Lionel Landwerlin" <<a href="mailto:lionel.g.landwerlin@intel.com">lionel.g.landwerlin@intel.com</a>> wrote: > > On 03/08/16 16:01, Jason Ekstrand wrote: >> >> On Aug 3, 2016 5:53 AM, "Lionel Landwerlin" <<a href="mailto:lionel.g.landwerlin@intel.com">lionel.g.landwerlin@intel.com</a>> 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