tht , vor 11 Tagen

@karolherbst @bashbaug should follow the specs in my opinion

oblomov , vor 10 Tagen

@karolherbst as a user (i.e. developer of OpenCL code), I'd ask you if possible to please go with the spec.

@bashbaug

bashbaug , vor 6 Tagen

@karolherbst Can you describe the failing case in more detail? I just did a few quick get_global_offset tests and everything is working as I'd expect.

Regardless, I agree we should have a CTS test for this. There is a get_global_offset test, but it's not currently testing out-of-range indices.

(Sorry for the slow reply, was on vacation and away from computers last week.)

karolherbst OP , vor 6 Tagen

@bashbaug we have some custom CL tests in piglit and this one seems to fail on my Intel one: https://gitlab.freedesktop.org/mesa/piglit/-/blob/main/tests/cl/program/execute/global-offset.cl?ref_type=heads#L97

It's the last "[test]" section in that file in case you want to adjust your local test program.

Here it returns "3" instead of "0" in the last line.

bashbaug , vor 6 Tagen

@karolherbst Thanks, I've reproduced the problem. Looks like no out-of-range checks are happening (oops). I filed https://github.com/KhronosGroup/SPIRV-LLVM-Translator/issues/2638, which I think is the best place to fix this.

Have you only seen this issue with get_global_offset?

karolherbst OP , vor 6 Tagen

@bashbaug I think this issue should exist with all builtins, but I'm wondering why the SPIRV-Translator is the best place, because I was seeing this with Intel-compute-runtime using OpenCL C as well.

Not saying that it won't make sense to fix it in the translator, but I think it depends on what's meant with "The mapping from an OpenCL C built-in function to the SPIR-V BuiltIn is informational and non-normative." in the env spec.

bashbaug , vor 6 Tagen

@karolherbst Our implementation compiles everything through SPIR-V, so the SPIR-V LLVM Translator is involved even when starting from OpenCL C.

Our OpenCL C flow currently goes OpenCL C -> LLVM IR (with calls to get_global_offset) -> SPIR-V (with vector BuiltIns and OpVectorExtractDynamic) -> our GPU compiler, so I think the only place where the fix could go is in the SPIR-V LLVM Translator, when the SPIR-V gets generated from the LLVM IR.

karolherbst OP , vor 6 Tagen

@bashbaug oh, I wasn't aware that you are also using SPIR-V internally. Is that an old change or something more recent?

bashbaug , vor 6 Tagen

@karolherbst We've been using SPIR-V internally for at least a couple of years, probably more like five years now. :)