I expect that shader libraries will make this a relative non-issue. Basically, FP16 fails when it has to deal with information of a specific type (like texture addresses), so it should be very easy for a robust shader library to properly-optimize for FP16 usage while being certain to always maintain optimal image quality.geo said:
The problem with implementing partial precision in games like FarCry or Half-Life 2 is simply that these games have thousands of shaders. It's just unfeasible to go through each of those shaders by hand and check for situations where FP16 will break. So the developers just turn FP16 on everywhere and suffer problems, or use full precision everywhere and lose performance (on architectures like the NV3x and NV4x).
Now, once shader libraries make it to the forefront (and they will because artists are not programmers, and you want artists to be able to make custom shaders), testing for situations where FP16 breaks will suddenly become much, much easier. First of all, the actual code pieces will be much shorter, making it easier for the programmers to just examine the code and find the bad spots. Secondly, one only needs to examine the pieces to see if FP16 will be a problem.
Side comment: yes, it is potentially possible that very long shaders will also cause issues, but I suspect that this won't be an issue, since very long shaders as they relate to games will likely result in the adding of incoherent data sets which will therefore not be prone to banding artifacts. This clearly won't be the case for recursive algorithms, but those again are simple pieces of code and would be taken care of within the shader library.
