<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 03/08/16 16:01, Jason Ekstrand wrote: </div> <blockquote cite="mid:CAOFGe97UvY64rq87ku2NP3xXWcZ2eGJM=OvnJteFKiUqm+DMmw@mail.gmail.com" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> On Aug 3, 2016 5:53 AM, "Lionel Landwerlin" <<a moz-do-not-send="true" 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 </blockquote> 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 </body> </html>