VK_FORMAT_E5B9G9R9_UFLOAT_PACK32 write masks and blending

[billhollings]

On non-Apple Silicon GPU's, VK_FORMAT_E5B9G9R9_UFLOAT_PACK32 is not supported as a color attachment format.

On Apple Silicon (iOS/tvOs/macOS M1), it is fully supported as a color attachment except that format components cannot be individually write-enabled. All components must either be write-enabled or write-disabled together.

This is causing several hundred CTS blending tests to fail on M1 (and presumably iOS & tvOS). For example:

dEQP-VK.pipeline.blend.format.e5b9g9r9_ufloat_pack32.states.color_dc_sas_rsub_alpha_1mdc_1msc_sub-color_1msa_1msc_add_alpha_ca_da_min-color_1msc_da_sub_alpha_1mca_ca_sub-color_o_1mda_max_alpha_sa_dc_min

This is the only format breaking any CTS blending tests.

Options identified so far:

• Disable VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT for VK_FORMAT_E5B9G9R9_UFLOAT_PACK32 until Apple fixes this. This causes the CTS tests to shift to Not Supported instead of Fail, but is definitely overkill, since everything around blending likely works except for disabling the blending of individual format components.

• Add to the portability extension the ability to be specific about write mask options when querying for image format properties. This means additional spec behavior for only one format.

• In a MoltenVK code comment, @cdavis5e has suggested that this could be worked around via framebuffer fetch. I assume this would mean forcing the MSL shader to perform programmable blending based on a SPIRV-Cross compilation options, even though the SPIR-V does not use programmable blending. At a gut level, this would appear to be programming heroics for just one edge case of one format.

[dgkoch]

Another option would be to just not expose VK_FORMAT_E5B9G9R9_UFLOAT_PACK32 as a color attachment format, since as you pointed out above, it's not supported on non-Apple Silicon GPUs, and therefor it isn't needed for any portability targets.

[billhollings]

@dgkoch Thanks for the feedback.

Another option would be to just not expose VK_FORMAT_E5B9G9R9_UFLOAT_PACK32 as a color attachment format

I did not include that in my list because I figured it was more restrictive than limiting blending alone.

it's not supported on non-Apple Silicon GPUs, and therefor it isn't needed for any portability targets

I assume it's part of Vulkan because it's widely supported elsewhere? Where is it supported in the Vulkan ecosystem outside of Apple platforms?

The Apple GPU platforms include iOS, which is a very large base. So, for example, refusing it as color attachment everywhere on Apple platforms limits someone taking a game from somewhere else in the ecosystem and porting it to iOS.

[dgkoch]

I assume it's part of Vulkan because it's widely supported elsewhere? Where is it supported in the Vulkan ecosystem outside of Apple platforms?

No - it's part of Vulkan for completeness.

I don't believe any of Intel / NVIDIA / AMD desktop GPUs expose E5B9G9R9 as a renderable texture format. In fact, I've never hear of any one supporting it as renderable before this. I tend to think of it as more like a compressed texture format. I also don't believe it's required to be renderable in any version of D3D.

refusing it as color attachment everywhere on Apple platforms limits someone taking a game from somewhere else in the ecosystem and porting it to iOS.

I don't think any widely supported game written for any other D3D or Vulkan platform could require that format, and therefore I don't see how it could be considered limiting under MVK.

[billhollings]

I don't believe any of Intel / NVIDIA / AMD desktop GPUs expose E5B9G9R9 as a renderable texture format. In fact, I've never hear of any one supporting it as renderable before this.

Thanks. Then I agree. Marking it as either not bendable, or entirely not renderable, would be a reasonable approach.

[jackohound]

QCOM recently published QCOM_render_shared_exponent, so you should expect future support for this format coming from QCOM. Still, I agree with @dgkoch that refusing E5B9G9R9 is unlikely to be limiting for MVK.

[lexaknyazev]

Just FYI, this format is also renderable with APPLE_color_buffer_packed_float.

[billhollings]

@dgkoch @jackohound @lexaknyazev

Thanks for all the input and feedback.

you should expect future support for this format coming from QCOM

this format is also renderable with APPLE_color_buffer_packed_float.

Given some Apple and Vulkan eco-system support for rending to this format, I've elected to make the least-intrusive reasonable change, and disable blending for this format on macOS Apple Silicon.

[DadSchoorse]

I assume it's part of Vulkan because it's widely supported elsewhere? Where is it supported in the Vulkan ecosystem outside of Apple platforms?

No - it's part of Vulkan for completeness.

I don't believe any of Intel / NVIDIA / AMD desktop GPUs expose E5B9G9R9 as a renderable texture format. In fact, I've never hear of any one supporting it as renderable before this. I tend to think of it as more like a compressed texture format. I also don't believe it's required to be renderable in any version of D3D.

@dgkoch FWIW AMD supports rendering to E5B9G9R9 since RDNA2: https://vulkan.gpuinfo.org/displayreport.php?id=11767#formats