vulkan : add fp16 support for the conv_2d kernel

[Green-Sky]

This enables you to run a fp16 sd1.x model with sd.cpp.

This is my first time touching the vulkan code, feedback appreciated.

Related discussions: leejet/stable-diffusion.cpp#739

[jeffbolznv]

LGTM. I haven't tested it locally, though.

[netrunnereve]

If we repeat the same test for different formats we typically loop through a ggml_type instead.

llama.cpp/tests/test-backend-ops.cpp

Lines 4989 to 4996 in 793c0d7

	// glu ops
	for (ggml_type type : {GGML_TYPE_F16, GGML_TYPE_F32}) {
	for (int v : {0, 1}) {
	for (int op = 0; op < GGML_GLU_OP_COUNT; op++) {
	for (bool swapped : {false, true}) {
	test_cases.emplace_back(new test_glu((ggml_glu_op) op, type, { 128, 2, 2, 2 }, v, swapped));
	test_cases.emplace_back(new test_glu((ggml_glu_op) op, type, { 5, 7, 11, 13 }, v, swapped));
	}

[Green-Sky]

Done. Also added the f16 tests to the normal tests, since they seem to run fast.

[Green-Sky]

Looks like the error in a few cases is just a little too much.

$ bin/test-backend-ops test -o CONV_2D
ggml_vulkan: Found 1 Vulkan devices:
ggml_vulkan: 0 = NVIDIA GeForce RTX 2070 (NVIDIA) | uma: 0 | fp16: 1 | bf16: 0 | warp size: 32 | shared memory: 49152 | int dot: 0 | matrix cores: KHR_coopmat
Testing 2 devices

Backend 1/2: Vulkan0
  Device description: NVIDIA GeForce RTX 2070
  Device memory: 8192 MB (8192 MB free)

[CONV_2D] NMSE = 0.000000127 > 0.000000100   CONV_2D(ne_input=[1,1,1,2],ne_kernel=[1,1,1,12],type_kernel=f16,stride0=1,stride1=5,padding0=5,padding1=5,dilation0=2,dilation1=4,cwhn=0): FAIL
[CONV_2D] NMSE = 0.000000115 > 0.000000100   CONV_2D(ne_input=[1,1,1,2],ne_kernel=[2,1,1,12],type_kernel=f16,stride0=1,stride1=5,padding0=5,padding1=5,dilation0=2,dilation1=4,cwhn=0): FAIL
[CONV_2D] NMSE = 0.000000243 > 0.000000100   CONV_2D(ne_input=[1,1,25,2],ne_kernel=[1,2,25,1],type_kernel=f16,stride0=1,stride1=5,padding0=5,padding1=5,dilation0=2,dilation1=4,cwhn=0): FAIL

...

  8129/8132 tests passed
  Backend Vulkan0: FAIL
Backend 2/2: CPU
  Skipping CPU backend
1/2 backends passed
FAIL

and here in ci:

 ggml_vulkan: Found 1 Vulkan devices:
 ggml_vulkan: 0 = llvmpipe (LLVM 15.0.7, 256 bits) (llvmpipe) | uma: 0 | fp16: 1 | bf16: 0 | warp size: 8 | shared memory: 32768 | int dot: 0 | matrix cores: none
 ggml_vulkan: Warning: Device type is CPU. This is probably not the device you want.
 Testing 2 devices
 
 Backend 1/2: Vulkan0
   Device description: llvmpipe (LLVM 15.0.7, 256 bits)
   Device memory: 15995 MB (15995 MB free)

[CONV_2D] NMSE = 0.000000193 > 0.000000100   CONV_2D(ne_input=[1,1,25,2],ne_kernel=[2,1,25,1],type_kernel=f16,stride0=1,stride1=5,padding0=5,padding1=5,dilation0=2,dilation1=4,cwhn=0): FAIL
[CONV_2D] NMSE = 0.000000294 > 0.000000100   CONV_2D(ne_input=[1,1,25,2],ne_kernel=[1,2,25,1],type_kernel=f16,stride0=1,stride1=5,padding0=5,padding1=5,dilation0=2,dilation1=4,cwhn=0): FAIL
[CONV_2D] NMSE = 0.000001574 > 0.000000100   CONV_2D(ne_input=[1,1,25,2],ne_kernel=[3,1,25,1],type_kernel=f16,stride0=3,stride1=5,padding0=5,padding1=5,dilation0=2,dilation1=4,cwhn=0): FAIL
[CONV_2D] NMSE = 0.000000101 > 0.000000100   CONV_2D(ne_input=[1,1,25,2],ne_kernel=[3,1,25,12],type_kernel=f16,stride0=3,stride1=5,padding0=5,padding1=5,dilation0=2,dilation1=4,cwhn=0): FAIL

   8128/8132 tests passed
   Backend Vulkan0: FAIL
 Backend 2/2: CPU
   Skipping CPU backend
 1/2 backends passed
 FAIL

[Green-Sky]

The error does not seem to be deterministic, is that expected?

(Just had only 2 cases surpass the error threshold)

[0cc4m]

Maybe another case of RTE?

Edit: No, just tried it, that does not resolve it.

[jeffbolznv]

The error does not seem to be deterministic, is that expected?

Yes, the test values are randomly generated.

IIUC the kernel just promotes the fp16 values to fp32, nothing is done with fp16 math, so there ought not be any precision issues (or at least, no worse than with fp32).

[etasnadi]

The error does not seem to be deterministic, is that expected?

(Just had only 2 cases surpass the error threshold)

I did not look into the cpu code but their f16 impl might use f16 for intermediate values - that could explain the divergence.

[jeffbolznv]

I think you're right. I see this:

                        if (kernel_type == GGML_TYPE_F32) {
                            *(float *) element_ptr = src_val;
                        } else if (kernel_type == GGML_TYPE_F16) {
                            *(ggml_fp16_t *) element_ptr = GGML_CPU_FP32_TO_FP16(src_val);
                        }

If we eventually want to accelerate these operations using tensor cores then having the sources both in fp16 is what we'll want. So I think we should change the shader to convert the source values to fp16.

[Green-Sky]

I hacked in the cat to kernel type, but it still errors. The error is smaller though.
edit: ci agrees

eg

[CONV_2D] NMSE = 0.000000130 > 0.000000100   CONV_2D(ne_input=[1,1,1,2],ne_kernel=[1,1,1,1],type_kernel=f16,stride0=1,stride1=5,padding0=5,padding1=5,dilation0=2,dilation1=4,cwhn=0): FAIL
[CONV_2D] NMSE = 0.000000105 > 0.000000100   CONV_2D(ne_input=[1,1,25,2],ne_kernel=[2,2,25,1],type_kernel=f16,stride0=1,stride1=5,padding0=5,padding1=5,dilation0=2,dilation1=4,cwhn=0): FAIL

[0cc4m]

That change means the shader no longer works without fp16 compute support.

If we eventually want to accelerate these operations using tensor cores then having the sources both in fp16 is what we'll want. So I think we should change the shader to convert the source values to fp16.

The usual assumption was that the CPU backend would do at least 32-bit precision, while GPU backends sacrifice precision for performance. This doesn't seem to be true here. I don't really see why better precision should cause failed tests, maybe the threshold should be increased slightly. We definitely need a 32-bit shader version just to support old devices.

[netrunnereve]

If you make the CPU implementation use FP32 only do the errors go away?

[etasnadi]

I hacked in the cat to kernel type, but it still errors. The error is smaller though. edit: ci agrees

eg

[CONV_2D] NMSE = 0.000000130 > 0.000000100   CONV_2D(ne_input=[1,1,1,2],ne_kernel=[1,1,1,1],type_kernel=f16,stride0=1,stride1=5,padding0=5,padding1=5,dilation0=2,dilation1=4,cwhn=0): FAIL
[CONV_2D] NMSE = 0.000000105 > 0.000000100   CONV_2D(ne_input=[1,1,25,2],ne_kernel=[2,2,25,1],type_kernel=f16,stride0=1,stride1=5,padding0=5,padding1=5,dilation0=2,dilation1=4,cwhn=0): FAIL

Maybe the NMSE threshold is too strict? Fp16 has ~4 significant digits, and I assume that the cpu/Vulkan code do not execute the same calculations in the same order. So it might be useful to define a threshold that respects the number format. E.g. the closest fp16 number to 1/3 is 0.33325195 according to Wikipedia. If the numbers differ from the 5th digit or more the test should be accepted.

[0cc4m]

@ggerganov @slaren Do you have an opinion on the test threshold? I don't want to reduce backend precision just to follow the CPU implementation.

[ggerganov]

I guess for test_conv_2d we can set the same max NMSE as for test_mul_mat: 5e-4.

[0cc4m]

LGTM