Add WaveGetLane* support for Metal and WGSL

[fairywreath]

Closes #6208, related to #6210.

Adds support for WaveGetLane* intrinsics for Metal and WGSL through the use of GLSL flavored in/out global vars.

These intrinsics require built-in values to be passed through the entry point parameters, but the intrinsics themselves are "global" functions. The implementation reuses the already existing code that handles glsl gl_* global builtin variables and adds them to the entry point parameter list. translateGLSLGlobalVar is renamed because it also handles non-glsl code.

[csyonghe]

Looks good!

[csyonghe]

Can name it translate-global-varying-var.

[csyonghe]

Can we just use a single RequireTargetExtension for all targets?

[fairywreath]

Not sure why the Metal glsl variant test fails while the HLSL variant passes - the produced code is similar and they both compile fine using the Metal compiler. I do not have an Apple device to test, hopefully my most recent change fixes it.

[fairywreath]

The glsl variant test still failed on Metal and I am not sure why. I loosened up the check requirements for the Metal case and added another test for the glsl syntax that is a copy of the hlsl syntax test(that passes just fine in Metal), so the new test should definitely pass.

[csyonghe]

Hmm, if it is a hardware problem, then the HLSL syntax should also fail?

Can you compare the metal shader output from both HLSL and GLSL syntax and see if there are any differences?

[fairywreath]

Yea somehow the new GLSL syntax test(that is a 1-1 copy of the passing HLSL syntax test) is failing. Here is a diff of the outputs of the HLSL and GLSL syntax. They are very similar(the difference in output type is a test case typo).

[csyonghe]

I noticed that the HLSL case, the compiler is able to fold the access to wave index directly as a use of _builtinWaveLaneIndex_0 parameter, where in the GLSL case, the parameter is first written into the kernel context and then loaded from the context.

Which should be fine, but I wonder if that's the reason that caused the wrong value.

[csyonghe]

Another suspicious thing is:

struct KernelContext_0
{
    uint device* outputBuffer_0;
    uint3 _S1;
    uint _S2;
    uint _S3;
};

note that _S2 is the wave index, and it is placed right after a uint3. It is unlikely, but I wonder if there are bugs that causes an assignment to _S1 overwrites _S2 due to mishandling of alignment/padding etc. in the metal driver.

[csyonghe]

We are currently generating:

#line 16
    (&kernelContext_0)->_S3 = _builtinWaveLaneCount_0;

#line 16
    (&kernelContext_0)->_S2 = _builtinWaveLaneIndex_0;

#line 16
    (&kernelContext_0)->_S1 = gl_GlobalInvocationID_0;

and this is in reverse order of the fields, might worth clean this up and make the assignment in the consistent order of the fields.

[fairywreath]

Thanks for the help. I have made changes so that the GLSL and HLSL outputs are exactly the same (diff). Can you run the test again?

[fairywreath]

It is surprising that the GLSL syntax variant still fails. Here is a diff of the hlsl and glsl tests and diff of the Metal output. The produced Metal code is exactly the same.

[csyonghe]

One test is using COMPARE_COMPUTE, and the other is using COMPARE_COMPUTE_EX, can we make both of them the same?

[csyonghe]

This is needing more debug. Let's disable the glsl test and get this PR merged first. We can leave it as future work.

[csyonghe]

Instead of disable test here, let’s run the test, but add the test name to expected-failure.txt so we can always use that file to track tests that we still need to work on.

[fairywreath]

Whoops I put the expected to fail tests in the wrong file, I have corrected them.

[fairywreath]

There were some merge conflicts - I corrected them