Vulkan: fix NaN in tanh.comp with AMD proprietary driver on Windows

[stduhpf]

I noticed when running test-backend-ops that the TANH op can sometimes output NaNs with Vulkan. I didn't experience any issues because of it, but it was a simple fix, that should hopefuly not cause any noticable slowdown.

Master:

> .\build\bin\Release\test-backend-ops.exe  | Select-String -Pattern "TANH"
ggml_vulkan: Found 1 Vulkan devices:
ggml_vulkan: 0 = AMD Radeon RX 5700 XT (AMD proprietary driver) | uma: 0 | fp16: 1 | warp size: 64 | matrix cores: none
ggml_vulkan: Compiling shaders..........................Done!

  TANH(type=f32,ne_a=[128,2,2,2],v=0): [TANH] NaN at index 0 (Vulkan0=-nan(ind) CPU=-1.000000) FAIL
  TANH(type=f32,ne_a=[5,7,11,13],v=0): [TANH] NaN at index 2 (Vulkan0=-nan(ind) CPU=1.000000) FAIL
  TANH(type=f32,ne_a=[128,2,2,2],v=1): not supported [Vulkan0]
  TANH(type=f32,ne_a=[5,7,11,13],v=1): not supported [Vulkan0]

PR:

>.\build\bin\Release\test-backend-ops.exe  | Select-String -Pattern "TANH"
ggml_vulkan: Found 1 Vulkan devices:
ggml_vulkan: 0 = AMD Radeon RX 5700 XT (AMD proprietary driver) | uma: 0 | fp16: 1 | warp size: 64 | matrix cores: none
ggml_vulkan: Compiling shaders..........................Done!

  TANH(type=f32,ne_a=[128,2,2,2],v=0): OK
  TANH(type=f32,ne_a=[5,7,11,13],v=0): OK
  TANH(type=f32,ne_a=[128,2,2,2],v=1): not supported [Vulkan0]
  TANH(type=f32,ne_a=[5,7,11,13],v=1): not supported [Vulkan0]

[0cc4m]

We've had this issue before (#5260), last time I fixed it by replacing tanh(x) with 1 - 2 / (e^(2x) + 1). Not sure which version is more performant.

[stduhpf]

It looks like doing 1 - 2 / (e^(2x) + 1) is faster, at least on my end: https://www.shadertoy.com/view/MfGBzR

Edit: Actually, it looks like it's even faster than built-in tanh? 🤔 Maybe webGLSL isn't such a good way to test performance....

[0cc4m]

It looks like doing 1 - 2 / (e^(2x) + 1) is faster, at least on my end: https://www.shadertoy.com/view/MfGBzR

Edit: Actually, it looks like it's even faster than built-in tanh? 🤔 Maybe webGLSL isn't such a good way to test performance....

I think it's unlikely that any of these versions is slow enough to cause an issue, looks good, thank you for the fix.

This just leaves the q2_k and q3_k MMV issue on Windows AMD, all the other unit test failures are barely above the threshold.