Also, lets not forget that mobile gaming, whether on phones/tablets or laptops not necessarily plugged in, or as it grows in volume the Switch is ever increasing its share of rendered pixels. And, as pointed out, performance per Watt aren't making fantastic strides anywhere.
I agree that pure FP16 isn't good enough for most pixel/compute shaders. It is however enough for simple image processing shaders (such as blur kernels). But these shaders are generally bandwidth bound, so 2x ALU rate doesn't speed them up at all (but fp16 still saves power). Mixed FP16 & FP32 is the main use case, but it requires lots of knowledge and effort to pull off. You need to know your numeric ranges and FP specifics to understand the problem cases. And you need to avoid FP16<->FP32 conversions at any cost (conversion = ALU cost and temp register bloat). This is especially tricky to get right in HLSL, because HLSL doesn't support 16 bit constant buffer values and doesn't support 16 bit groupshared memory types. There are hacks around these limitations however, but writing good cross-platform 16 bit code in HLSL just isn't possible at the moment. Hopefully SM 6.1 fixes these issues. Vulkan has vendor extensions to fix these issues, but no generic solution either.
Has MS actually confirmed this, or is it just assumption at this point?
Confirmed, Digital Foundry's coverage said so.
Can you point to a post - just one post - in this forum that suggest FP16 alone is good enough for pixel shaders?
I hardly consider that a reason to postpone introduction of FP16. Also considering Pascal is for all intents "last gen", I'd assume they will consider FP16 development now for inclusion in future games. Frankly I don't see any frantic development efforts beyond Volta which to me indicates Nvidia already has something in mind (who knows maybe something to do with tensor cores).
Considering there is zero support currently for FP16*2 beyond Vega and no indication that the gaming development community is moving that direction for certain workloads (no console support), that Volta consumer versions would have been designed 2+ years ago, and the usual product segmentation that Nvidia pursue, there's a very good chance there will be no support for it in GV104 and lower.
What level of non-support exactly is confirmed? Even Tonga could support FP16, albeit with focus on more power and register efficiency:
Not necessarily depending on what was being rendered. Early culling passes that don't reuse the results could probably get away with FP16. Along with normals for the same purpose.
I believe it's an assumption. Possibly not exposed for backwards compatibility, but randomly appears following a future software/hardware release.
That was my thinking as well. We'd have seen a larger dev push otherwise as it would provide Nvidia with a means to encourage upgrades. Not to mention all the people pushing FP16 as exclusive to compute.
No packed math. It supports FP16 like Polaris does, being a Polaris based GPU.
Is there an interview or disclosure as to what was implemented for this support, or the Polaris feature set?
Can anyone confirm if those drivers are the same used on Vega FE or newer?
They are newer, Vega FE had 22.19.384.2, RX Vega has 22.19.640.2.
