I was investigating some potential mobile optimizations for one of my WebGPU apps and found many resources from the last decade citing that FP16 is used when performing rendering calculations, with many shader snippets using half types.

Examples:

• https://cdn2.unrealengine.com/Resources/files/GDC2014_Next_Generation_Mobile_Rendering-2033767592.pdf (Pg 14)
• https://medium.com/spaceapetech/physically-based-shading-on-mobile-d7d4e90bb4bd

Note that the Unreal deck is from 2014. This has been the defacto advice on mobile for over a decade!

As such I was somewhat surprised to see that the shader-f16 feature wasn't available on multiple Android devices that I attempted to test against. Digging into why, I found that, as discussed in #2512, to support shader-f16 on Vulkan both Chrome and Firefox require:

• The "VK_KHR_shader_float16_int8" extension with the shaderFloat16 feature.
• The "VK_KHR_16bit_storage" extension or Vulkan 1.1 with the storageBuffer16BitAccess and uniformAndStorageBuffer16BitAccess features.

Doing a query of gpuinfo.org for the availability of these features on Android shows

• shaderFloat16 support: 76.5%
• storageBuffer16BitAccess support: 64%
• uniformAndStorageBuffer16BitAccess support: 42%

Which means that lack of uniformAndStorageBuffer16BitAccess is the reason why most devices will miss out of f16 support. And unfortunately, something a notable about the list of devices that support the feature is that it contains exactly 0 Qualcomm devices.

So while f16 operations have been shown to be highly impactful on even older Qualcomm hardware, as evidences by the Unreal deck, as things are no Qualcomm devices can use 16-bit floats with WebGPU because they cannot surface 16-bit values in uniforms/storage.

Of course, how problematic that is depends on the type of work being done. For compute-based use cases like LLMs, which I recall factored heavily into the initial "shader-f16" discussions, being able to expose buffers of smaller data type is critical. For rendering it's less important, as it's typically the intermediate calculations that are being done at the lower precision while the outputs are cast back to full 32-bit values. It would be a shame if those rendering use cases are blocked on the majority of Android devices because we over-indexed on the needs of AI.

Recognizing that it's difficult to make large-scale changes to the existing feature given that it's already been shipped, I still think this is worth further discussion to see if there's any concessions that can be made to allow f16 operations to be exposed to a larger range of devices.