It looks like none of the depth formats support linear tiling on my system, only optimal tiling, so I can’t read the values from a depth image directly. (Need to do this for debugging purposes.)
Copying or blitting images doesn’t seem to work between depth formats and other formats according to the specification.
Do I have to write a shader to copy it to an image with a different format (With linear tiling support), or is there a direct way?
That’s odd. Spec allows that, but there is no reason I can see to disable linear tiling format (as a purely memory type with TRANSFER_USAGE flag). What HW do you have? Did you query that capability with vkGetPhysicalDevice!!Image!!FormatProperties?
But yes, the copy to Buffer seems to be the prefered way in spec (has nicely defined conversion from depth/stencil formats).
PS: Does anyone know why the D32_SFLOAT format is mandated to have BLIT_SRC feature by the spec?
PS2: Is cmdCopyImage supposed to convert tiling? Because it does on my implementation. That would simplify lot of things, including this one.
That did the trick, thanks.
Yeah, none of them support linear tiling:
D16Unorm:
Buffer:
Linear Tiling:
Optimal Tiling: SampledImage | DepthStencilAttachment | BlitSrc
X8D24UnormPack32:
Buffer:
Linear Tiling:
Optimal Tiling:
D32Sfloat:
Buffer:
Linear Tiling:
Optimal Tiling: SampledImage | DepthStencilAttachment | BlitSrc
S8Uint:
Buffer:
Linear Tiling:
Optimal Tiling: SampledImage | DepthStencilAttachment | BlitSrc
D16UnormS8Uint:
Buffer:
Linear Tiling:
Optimal Tiling: SampledImage | DepthStencilAttachment | BlitSrc
D24UnormS8Uint:
Buffer:
Linear Tiling:
Optimal Tiling:
D32SfloatS8Uint:
Buffer:
Linear Tiling:
Optimal Tiling: SampledImage | DepthStencilAttachment | BlitSrc
I have an AMD Radeon R9 280, latest Vulkan drivers and SDK version.
According to the specs, “The VkFormat of each of srcImage and dstImage must be compatible, as defined below”:
I’m not sure if that just means just the size has to match for depth formats, or the actual format.
I have R9 280X 
.What you list is format capabilities, not support (vkGetPhysicalDeviceFormatProperties vs vkGetPhysicalDeviceImageFormatProperties). Even if it has no features listed, it can still be supported (and used with USAGE_TRANSFER - in vkCmdCopyImage, but not blit).
The format compatibility is well-defined. There is even a table. It means only the VK_FORMAT_X. Any of the depth formats is compatible only with itself. For copy, the size doesn’t matter (you are unable to pass differing ranges to the API).
If I use vkCmdCopyImage, it does convert the tiling from optimal to linear for me (tried that for Color aspect). The spec says it is “like memcpy”, which would mean that is not supposed to happen. Then again, then it lists the conversions it does NOT do and tiling is not among them.
Anyone here knows for sure? Just wondering. The copy to buffer is clearly the intended and more compatible way.
If I use vkCmdCopyImage, it does convert the tiling from optimal to linear for me (tried that for Color aspect). The spec says it is “like memcpy”, which would mean that is not supposed to happen.
The spec doesn’t say “like memcpy”. It says “in a similar manner to a host memcpy”. It then goes on to clarify what that means (no scaling, blending, color-space nonsense), which as you yourself pointed out, does not list tiling as a forbidden difference.
The spec seems pretty clear on this to me.
Anyone here knows for sure? Just wondering. The copy to buffer is clearly the intended and more compatible way.
Different needs for different uses.
Copying image data to/from a buffer has its uses.
Copying between images has its uses. That you could use copying between images to copy tiling is one of them, but that’s far from its only use. I see no reason why they would want to explicitly forbid it.
What there needs to be is something suggesting that people not use linear images as staging buffers for tiled ones, using raw memory buffers and a good buffer-to-image copy command instead. That’s not really what linear image format support is for.
Like=in similar manner, where I learned english, but never mind my laziness and misquoting. 
Isn’t clear to me. Quote me the part that without doubt makes it MUST or SHOULD or MAY or MUST NOT convert tiling and is not immediately contradicted by the next sentence. It does not list tiling conversion as permited difference either.
I mean, it makes sense if I think about it. It is probably handled more as a addressing mode and “conversion” have to happen even between optimaly tiled images. But where is it black on white?
Different needs for different uses.
What I ment is for the use of the OP. They made special care to define Depth formats to buffer conversion explicitely. Besides AFAI can tell, the spec does not even guarantee support of linear tiling, so the former being the more compatible way.
I see no reason why they would want to explicitly forbid it.
I assume you mean the tiling conversion (not image copying in general - duh, why would they?). Well, if that is so, how do I query if the conversion will happen, then?
That’s not really what linear image format support is for.
What is it for, then? Only other purpose I can think of is to make things simpler for debugging tools.
Quote me the part that without doubt makes it MUST or SHOULD or MAY or MUST NOT convert tiling and is not immediately contradicted by the next sentence.
It exhaustively lists the things that it cannot alter. The function has an entire section who’s sole purpose is to list every single thing that the function cannot do.
Everything not in that section is, by definition, fair game.
What is it for, then?
Linear image formats are for people who want to be able to access the pixels in an image from the host without staging, while still being able to use it as a texture (sampling it from a shader, using it as an output attachment, or whatever). This would mainly be for things like frequently modified images and the like. If you’ve ever felt the desire to map a texture, then linear formats are what you want.
Where? You mean the “such as”(=for example/not exhaustively) sentence?
To clarify, you are saying the behavior is undefined/platform dependent? That is, a MAY case?
Of course. But VkImage may not support sampling and/or being output attachment and yet be linear. It begs to be used for staging in that case (especialy if the tiling conversion happens on copy).
No, I mean the section called “Valid Usage”. If the copying of textures with different tilings were forbidden, that is where it would be stated. Since it is not stated there, it is therefore allowed.
No, I’m saying that, because it is not forbidden, it is allowed. There is no wiggle room in the specification for an implementation to forbid it.
And many people believe that the API clearly suggests that it’s a good idea to give each independent object a static secondary command buffer too.
Vulkan exists to expose you to the hardware. The API forbidding you from doing something the hardware can do works against that. If the hardware can copy between images with tilings, why should it be prevented? Because someone might think that linear images are meant to be used for staging?
Indeed, if linear images were meant for staging, why would vkCmdCopyBufferToImage exist? Doesn’t that seem more like what would be used for staging?
I know, I can pass Images with differing tiling to the function (without crash). My concern was with behavior/result of that function if I do so.
Nevermind though, I thought it through, and am now 90 % certain it is ment to do the conversion - simply because it is impossible NOT to do it(it has to be read in the tiled order anyway).
Doesn’t that seem more like what would be used for staging?
Just try to stop me from using Image object to store/push image data!!
But yeah, for pushing raw bytes, I would use Buffer.
Speaking strictly on esthetical level.
Thanks for discussing with me at lenght!