[xen2]

PR Details

Vulkan does not guarantee any specific depth+stencil format, only that one of D24_UNORM_S8_UINT or D32_SFLOAT_S8_UINT works as a depth-stencil attachment. Texture creation already substituted a supported one, but only in NativeFormat. Texture.Format kept the format that was requested, so the description did not describe the image.

Anything reading Texture.Format could then disagree with the device. The multisample feature table was one case, fixed separately in #3382.

Changes

• GraphicsDevice.GetSupportedDepthStencilFormat: resolves the format once per device and caches it. It only depends on the physical device.
• New AdjustDescriptionForDevice hook, called before the description is stored, so Format, ViewFormat, RowStride, SizeInBytes and the mipmap descriptions all describe the image that exists. No-op on Direct3D.
• Removed the late NativeFormat patch in InitializeFromImpl and the old Texture.GetFallbackDepthStencilFormat, which was recomputed at every texture and pipeline state creation.

This is what SwapChainGraphicsPresenter already does for back buffer formats: it writes the surface format it really got back into Description.BackBufferFormat.

Behaviour change: on a device without D24_UNORM_S8_UINT (AMD, most mobile), a depth buffer requested as D24_UNorm_S8_UInt now reports D32_Float_S8X24_UInt.

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My change requires a change to the documentation.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have built and run the editor to try this change out.

Builds clean on Direct3D11, Direct3D12 and Vulkan. Not run on a device lacking D24_UNORM_S8_UINT, so the substitution path itself is untested: on hardware that supports the format, nothing changes.