Summary: | radv doesn't support VK_FORMAT_D24_UNORM_S8_UINT | ||
---|---|---|---|
Product: | Mesa | Reporter: | Józef Kucia <joseph.kucia> |
Component: | Drivers/Vulkan/radeon | Assignee: | mesa-dev |
Status: | RESOLVED WONTFIX | QA Contact: | mesa-dev |
Severity: | normal | ||
Priority: | medium | CC: | joseph.kucia |
Version: | git | ||
Hardware: | All | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | Test case |
Does it work with RADV_DEBUG=nohiz ? D24 isn't even supported on RADV: FORMAT_D24_UNORM_S8_UINT: linearTiling FormatFeatureFlags: None optimalTiling FormatFeatureFlags: None bufferFeatures FormatFeatureFlags: None (In reply to Alex Smith from comment #2) > D24 isn't even supported on RADV: > > FORMAT_D24_UNORM_S8_UINT: > linearTiling FormatFeatureFlags: > None > optimalTiling FormatFeatureFlags: > None > bufferFeatures FormatFeatureFlags: > None Thanks. Could D24_UNORM_S8_UINT support be added to RADV? Oh my bad, I misread D24_UNORM_S8_UINT vs D32_SFLOAT_S8_UINT. :) Yeah, that could be supported. FWIW, VK_FORMAT_D24_UNORM_S8_UINT is already handled in various functions in src/amd/vulkan/radv_formats.c. It confused me, and I assumed that the format is supported. We won't add support for VK_FORMAT_D24_UNORM_S8_UINT for the following reasons: - TC-compatible HTILE isn't supported (requires decompression passes) - it consumes as much as VRAM as the 32bit format - RadeonSI internally uses the 32bit format - AMDVLK doesn't support it - it's not required by the spec. AFAIK, this is a win on NVIDIA but not on AMD hardware. Please, use VK_FORMAT_D32_UNORM_S8_UINT instead. Thanks! FWIW (not talking specifically about vulkan here) not supporting d24unorm may not be much of a problem for ordinary apps as you can use d32f instead and adapt your code to it. But if you're translating from some other APIs and you have to emulate it, it's not actually all that easy to emulate faithfully if you have no idea what the app is actually doing, since depth bias works a bit differently for unorm vs float formats. As far as I know the only way to emulate this somewhat accurately (of course the results still won't be 100% identical due to different precision) is to apply the depth bias (the constant part, not the slope scale part) in the fragment shader manually, which is of course rather a pain and probably quite suboptimal from a performance point of view (even if the hw actually might allow configuring how depth bias works independently from the actual format, but if it isn't exposed that doesn't help). |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 139576 [details] Test case The attached test succeeds on Anvil. Also, other depth formats work fine on radv.