Lack of support for D24S8 textures on Vulkan.

[zlash]

Support for the texture format D24S8 is low on Vulkan. As Vulkan Hardware Database reports, most platforms have around ~68% support. (Windows shown here. Other platforms have similar percentages except Android)

This in contrast with D32FS8 which has almost complete support.

Being the only depth+stencil format supported by bgfx, this becomes quite a limitation on Vulkan for scenarios where it's required. For example, running sample 16-shadowmaps in any AMD GPU on Linux and switching to "Point Light" fails to create the framebuffer and crashes.

Blindly changing the mapping in renderer_vk.cpp for D24S8 from VK_FORMAT_D24_UNORM_S8_UINT to VK_FORMAT_D32_SFLOAT_S8_UINT makes it work as expected, but I'm not 100% sure that this is the best way to go. (However, vkd3d does this for its d3d to vulkan translation layer).

So what I'm looking for are ideas/thoughts on how to tackle this issue. My current ideas are:

• Add a D32FS8 texture type to bgfx. This way this "issue" can be handled by the application requesting the d32fs8 format if d24s8 is not available or vice versa.
• Transparently request a VK_FORMAT_D32_SFLOAT_S8_UINT when VK_FORMAT_D24_UNORM_S8_UINT is requested and not available. For most cases, having more precision shouldn't be a problem and on most modern platforms its supposed to be free (The depth buffer uses 32bits always, even when requesting a d24 format). I can imagine implementation differences for code that depends on the internal representation of the depth buffer, but I don't know if this is actually an issue except for limited cases. In the end, changing the internal representation to another one than the user requests might cause confusion but on the other hand the bgfx vulkan layer is now bumping 16F and 24F formats to 32F so it might be acceptable. I'd like some input/thoughts on what the stance is from a bgfx point of view on this.
• The previous idea but toggled with a runtime or compile time flag. All the same advantages/drawbacks except that having to turn it on or off explicitly might make the intent more clear for the users.

Ideas are welcome! Thanks!

[bkaradzic]

Blindly changing the mapping in renderer_vk.cpp for D24S8 from VK_FORMAT_D24_UNORM_S8_UINT to VK_FORMAT_D32_SFLOAT_S8_UINT makes it work as expected, but I'm not 100% sure that this is the best way to go. (However, vkd3d does this for its d3d to vulkan translation layer).

Actually this is totally fine. The only issue would arise if used in shaders as raw format, but I think no one would do that anyway.

[zlash]

Thanks! I'll make a PR.