Hi Samuel,
D16_UNORM support is mandatory on 2D images according to the spec
("Features, Limits and Formats" chapter).
Thanks,
Alex
On 3 November 2017 at 10:02, Samuel Pitoiset <samuel.pitoi...@gmail.com>
wrote:
> TC compatible HTILE only supports D32_SFLOAT on VI, while GFX9
> supports both. This is a recommandation for apps because HTILE
> decompressions are costly.
>
> This improves performance with Talos (73->76FPS) and Serious
> Sam 2017 (119->134FPS) because they no longer use any 16bpp
> depth surfaces and thus no HTILE decompressions are needed.
>
> Mad Max and DOW3 are not affected, but F1 2017 still uses one
> 16bpp depth surface even when the format is not advertised.
>
> Signed-off-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
> ---
> src/amd/vulkan/radv_formats.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_formats.c b/src/amd/vulkan/radv_formats.c
> index 5c79ea7406..21a05c4bbd 100644
> --- a/src/amd/vulkan/radv_formats.c
> +++ b/src/amd/vulkan/radv_formats.c
> @@ -1122,6 +1122,15 @@ static VkResult radv_get_image_format_properties(struct
> radv_physical_device *ph
> }
> }
>
> + if (physical_device->rad_info.chip_class == VI &&
> + info->format == VK_FORMAT_D16_UNORM) {
> + /* Do not advertise D16_UNORM on VI because TC compatible
> HTILE
> + * only supports D32_SFLOAT (GFX9 supports both), and HTILE
> + * decompressions are costly.
> + */
> + goto unsupported;
> + }
> +
> *pImageFormatProperties = (VkImageFormatProperties) {
> .maxExtent = maxExtent,
> .maxMipLevels = maxMipLevels,
> --
> 2.15.0
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
