Change Depth Store Default to Don't Care

[ahcox]

Using the Gears example app to experiment with ARM's new Frame Advisor performance tool for their Mali GPUs I noticed that the depth buffer was being written out:

With this one-line change to the base class, the depth isn't being written:

If this base class change will have negative impacts on other examples, I could make a slightly more complex PR which allows derived examples to specify the depth buffer storage operation to the base class before it sets up its main renderpass in VulkanExample::setupRenderPass().

[SaschaWillems]

Can you elaborate a bit? Is this a vendor specific optimization?

As this touches the base class I would have to check with all samples to make sure this doesn't break anything. Will probably take some time to review this.

[ahcox]

Can you elaborate a bit? Is this a vendor specific optimization?

In the tile-based GPUs typical of mobile devices like phones, tablets, and watches, the depth buffer exists in a small area of static RAM alongside colour buffers. This normally represents a rectangle of up to ~64x64 pixels depending on pixel formats and levels of MSAA. In rendering the main view of a game, while a colour buffer does need to be written from tile memory to external RAM for post processing and scan out to a display, the depth buffer does not need to be written to memory at all, and not doing so is a large bandwidth saving. By setting the flag the way it is before this PR, the code explicitly instructs the Vulkan implementation to write the depth buffer to external memory. By setting the flag used in this PR the code is telling the implementation that the depth buffer may be safely discarded without being written to RAM. This is a cross-vendor feature in Vulkan that definitely helps Imagination PowerVR and ARM Mali tile based mobile GPUs, and probably Adrenos, Apple Silicon via MoltenVK, and less well-known ones too. In addition, a desktop GPU vendor should at least be able to use it to invalidate cachelines covering the depth buffer rather than letting them write back over time uselessly.

As this touches the base class I would have to check with all samples to make sure this doesn't break anything. Will probably take some time to review this.

I was putting this in speculatively in hopes you'd know it was safe off the top of your head. I don't want to make work for you more than reviewing the PR already did so I will close it.