This is the second part of the fp16 precision-through-pictures analysis. This time it was carried on a device with native fp16 support (i.e. register storage and ALUs), eliminating the need for temporary texture storage. The native fp16 support allows us to examine a practical shading scenario without much effort. The device in question is an ARM Midgard T628 with native support for fp16, fp32 and fp64 arithmetics.
First, how does the power gradient reconstruction look on this device?
register storage fp16 said:
It looks very much like the fp16 test on Kepler. But if you overlay the two images, you'll notice that the Midgard picture has a slightly smaller black rectangle in the lower left - i.e. the extreme-low-values area. Why is that? Without actually checking, I'd venture to guess that Midgard supports denormalized fp16 values, while Kepler does not (in textures). Denormals narrow down the gap of non-representativeness around zero in every FP format.
Ok, on to the practical shading scenario. It comprises of a Blinn shader with tangent-space bump mapping. For maximum clarity we'll use that shader on a sphere with a homogenous, non-perturbed bump map (i.e. all normals in the map are (0, 0, 1)). We'll also re-use our bump map as an albedo map (programmer's art, etc).
entirely fp32 said:
entirely fp16 said:
It doesn't take much effort to notice the artifacts in the specular sport. As mentioned earlier, specular spots are produced via power functions, and those have the very useful property of turning precision candidate-issues into real such.
So, can we mend that via mixed precision? Let's see. We can examine the critical-precision path in our shader, and tweak that accordingly (the version of the shader shown below is already tweaked, so we'll just explain the tweaks).
mixed precision Blinn fragment shader said:
All fp32 quantities are marked in red. The grey-background area is something which would not normally be found in a production-quality shader pipeline. But our experimental shader is used on meshes without bi-tangent attributes, so the grey-area code computes the tangent-space transformation (TBN matrix) from partial derivatives at the fragment stage instead. In a production-quality shader this would be carried in the vertex shader via bi-tangent attributes in the vertex stream. So let's focus on the non-grey area of the shader.
For every computation (either an operator or a basic math function) which takes at least one fp32 operand, the computation will be carried in fp32. The texture sampling function is an exception - its texture coord argument does not affect the precision of the result, just how exactly the texture will be addressed. So what did we effectively tweak to fp32 in this critical path? We made sure the dot product of the Blinn "half-direction" vector and the bump-map normal is carried at fp32 precision. That's all.
The final result:
mixed precision said:
.