float16 support for Polaris/Baffin ?

[allanmac]

Is the Baffin GPU capable of single-rate float16?

I don't see either the AMD "half" extension or float16=true in VK_KHR_float16_int8 in the AMDVLK driver.

[amdrexu]

float16 is supported only on GFX9 (or above) product, such as Vega. Baffin is GFX8 product, so the extension support is unavailable.

[allanmac]

Single-rate fp16 is supported by GCN3+, no?

This is supported by the nearly equivalent AMD_gpu_shader_half_float extension on many GCN3+ GPUs.

[amdrexu]

Yes, we could support single-rate fp16 on GFX8+. But we believe it is meaningless to performance. Thus, we discourage the use of it and expose the extension on GFX9+ which have better performance with double-rate fp16.

[allanmac]

• Use of fp16 may cut register pressure in half
  If there were spills caused by use of fp32 then this would improve performance.
• You can store twice as many fp16 values in the same register footprint
  More processing can be performed on-die, thus reducing off-multiprocessor memory traffic.
  The canonical use case is storing a "tile" of color channels (ARGB) entirely in registers.

Both impact performance.

I have plenty of compute shaders that benefit from fp16.

If support for single-rate fp16 is being dropped then performance will be reduced on AMD devices.

[amdrexu]

@Anteru Matthaeus is involved. Maybe he could comment on this.

We do plan to loosen restrictions and expose more fp16 properities to let developer choose whether to use it or not. Currently, just using extension string is too coarse. This is under discussion but is not finalized.

[linqun]

we have a panel option OnlyEnableFP16ForGfx9Plus = false to force enable fp16 on gfx8. it can work in most case, but I am not sure whether it can pass CTS. I hope it can help you.

[allanmac]

Setting OnlyEnableFP16ForGfx9Plus,false in the file ~/.config/amdPalSettings.cfg results in the VK_AMD_gpu_shader_half_float extension reappearing.

FWIW, the VK_KHR_shader_float16_int8 extension still reports .shaderFloat16=false.

I'll see how my shaders perform with and without this option.

Thanks!!!

[Anteru]

The only way you can get improvements through FP16 on GFX <9 is by increasing occupancy of highly occupancy constrained shaders. This is unfortunately very different from normal usage of FP16 code, which tries to exploit FP16 arithmetic. This kind of code does perform actually worse on hardware without double-rate FP16. Unfortunately, you can't discern between the two cases automatically (and applications can't know which one they're running into), so as @amdrexu pointed out, we decided to disable FP16 on pre-GFX9 parts.

I'd be curious to see how the shaders you have look like btw :) Are there available online somewhere?

[allanmac]

I don't fully understand the above comment though... are you saying fp16 throughput on GFX <9 is less than 1:1?

If fp16 throughput is less than fp32 I would definitely consider not using it on GFX <9.

For AMD GCN, my compute shader has a big slab of registers that represent 44 channels of color+alpha per lane in a 64-wide subgroup.

If each channel is an fp32, then that's at least 44 32-bit registers plus a number of other registers. That may push the shader into using more than 64 32-bit registers per lane.

If each channel is an fp16, then that's 22 32-bit registers leaving plenty of room for the rest of the shader.

I've benchmarked the shader with fp32 and it's very fast but using fp16 would likely significantly reduce register pressure.

The shader in question is forthcoming... I'll have to regenerate it for a GFX 9+ device as I only have an RX 560 in my workstation right now.

[Anteru]

On GFX <9, it is at most 1:1, but once you end up doing packing/unpacking/converting, then your effective ALU rate will be lower than running FP32 all the time. Certainly so if you're coming from code written for GFX9 which uses mixed precision math etc. (Hence my statement -- you can't make things go faster using FP16 math, you can only possibly go faster by reducing register pressure.)

If your shader is fully occupancy bound then you may see benefits, but it's very rare in practice.

[allanmac]

Ah, I see. Note that all math operations in the shader should remain in fp16. It's mostly fma, add/sub, min/max ops.

I was assuming that there was no overhead in packing/unpacking the single-rate fp16 on GFX<9.

I'll get you fp32 and fp16 shader variants as soon as I can.

[JaxLinAMD]

close it since it's an old ticket