The 32_32_32_FLOAT format seems to be vertex-only, so it looks like there
can't be storage elements smaller than a single texel.
So, use a more precise name that can't be confused with "picture element"
(pixel) or "texture element" (texel) that represents a single logical pixel
rather than a storage block of pixels.
Switch between even and odd 16-byte element sequences along X by simply
flipping a bit rather than going to a different resolution-scaled group of
pixels, by increasing the size of the group within the constraints imposed
by tiling.
Use the _xe suffix instead of the xesl_ prefix for quicker visual
recognition of identifiers, also switch to snake_case for consistency.
Also add the f suffix to float32 literals because the Metal Shading
Language is based on C++.
For more optimal usage of exports and the parameter cache on the host regardless of how effective the optimizations in the host GPU driver are. Also reserve space for Vulkan/Metal/D3D11-specific HostVertexShaderTypes to use one more bit for the host vertex shader type in the shader modification bits, so that won't have to be done in the future as that would require invalidating shader storages (which are invalidated by this commit) again.
Ordering the descriptor sets by the change frequency on Vulkan, in increasing order (the opposite of D3D12 root signatures). The EDRAM binding never changes there (always one storage buffer), while the destination buffer binding may become changeable in the future (to split dispatches if exceeding `maxStorageBufferRange`, for example).
While the alpha of the texture data is not used at all (replaced with blue using the view swizzle), still make the shader code state the intention more explicitly if the format is decompressed for use as signed. Unsigned 1.0 is 0xFF, while signed 1.0 is 0x7F.
6fcf9d21fe made per-vertex diameter vs. constant radius consistent, and with that commit the shader works with direct pixel to NDC conversion, however, the NDC conversion factor was outdated in that commit (still included the 0.5 factor for diameter to radius conversion, resulting in all points being 50% narrower along each axis than needed). Now, the diameter to radius conversion factor is used there properly, and also the multiplication of the per-vertex diameter by 0.5 has been removed from the shader since the constant already includes it now (the constant diameter is passed via the system constants instead of the radius also).
