[SYCL][CUDA] Adds PI CUDA support for reqd_work_group_size attribute

[steffenlarsen]

This commit adds support for reqd_work_group_size in the PI CUDA backend
by extracting the attribute as program metadata. The program metadata
accompanies the binary when passed to the backend and it is up to the
backend if they extract any useful metadata. This adds two additional
parameters to piProgramCreateWithBinary for passing the program
metadata.

Program metadata is transported as a properties created by
sycl-post-link, so this commit also changes the behaviour of the NVPTX
path for linkage actions leading to the offload wrapper. These changes
uses file tables for the NVPTX path as well to allow generation and
preservation of properties. This assumes that the file table only ever
contains a single row if taking the NVPTX path and will fail otherwise.

[steffenlarsen]

Fixes test SYCL/Basic/reqd_work_group_size.cpp in test suite for CUDA. (PR: intel/llvm-test-suite#278)

[steffenlarsen]

Looks like I missed a clang driver test. Should be fixed now.

[AlexeySachkov]

Code review for PropertySetIO, file-table-tform and sycl-post-link: overall changes look good to me, just a few (mostly minor) comments

[mdtoguchi]

Documentation (device link and wrap image) should be updated as well. https://github.com/intel/llvm/blob/sycl/sycl/doc/images/DeviceLinkAndWrap.svg

[steffenlarsen]

Documentation (device link and wrap image) should be updated as well. https://github.com/intel/llvm/blob/sycl/sycl/doc/images/DeviceLinkAndWrap.svg

Definitely! I have updated the documentation. Hopefully I found all the relevant sections.

[pvchupin]

LGTM. @kbobrovs please take a look as well.

[smaslov-intel]

This commit adds support for reqd_work_group_size in the PI CUDA backend
by extracting the attribute as program metadata. The program metadata
accompanies the binary when passed to the backend and it is up to the
backend if they extract any useful metadata. This adds two additional
parameters to piProgramCreateWithBinary for passing the program
metadata.

How is this attribute supported when program is created with SPIR-V?

[steffenlarsen]

How is this attribute supported when program is created with SPIR-V?

I have not checked with L0, but OpenCL can both query information about reqd_work_group_size of a kernel using the PI_KERNEL_GROUP_INFO_COMPILE_WORK_GROUP_SIZE descriptor and will explicitly fail with CL_INVALID_WORK_GROUP_SIZE if the attribute restrictions are not met during launch.

PTX has reqntid (which reqd_work_group_size is mapped to with #3755), but the documentation is vague about the specific error behavior when it is not met. Likewise, the CUDA driver API does not expose a way of querying this information. This is the motivation for carrying metadata to the runtime, more or less.

In case either OpenCL or L0 may be in need of any similar program metadata, it should be as simple as just making sycl-post-link generate the information, append it to PropSet[llvm::util::PropertySetRegistry::SYCL_PROGRAM_METADATA] and flip the switch so that it is generated for their path. Then it should reach the backend through piProgramCreateWithBinary.

[smaslov-intel]

How is this attribute supported when program is created with SPIR-V?

I have not checked with L0, but OpenCL can both query information about reqd_work_group_size of a kernel using the PI_KERNEL_GROUP_INFO_COMPILE_WORK_GROUP_SIZE descriptor and will explicitly fail with CL_INVALID_WORK_GROUP_SIZE if the attribute restrictions are not met during launch.

PTX has reqntid (which reqd_work_group_size is mapped to with #3755), but the documentation is vague about the specific error behavior when it is not met. Likewise, the CUDA driver API does not expose a way of querying this information. This is the motivation for carrying metadata to the runtime, more or less.

Thanks, this is helpful! Both Level-Zero and OpenCL can query this information from a kernel, so we shouldn't need anything there. Since CUDA RT does not expose this information, how do you know it in JIT mode where program is created from SPIR-V, not from binary (where you add this metadata)?

This adds two additional parameters to piProgramCreateWithBinary for passing the program metadata.

Here, could we change the interface to take existing pi_device_binary instead of just native binary, and add metadata to that structure instead?

[vladimirlaz]

"

@vladimirlaz @smaslov-intel I cannot inspect the Precommit details. Can you tell if this is caused by this patch or if it is unrelated?

The failures are unrelated: CI issue on WIndows.

[pvchupin]

@steffenlarsen, could you please resolve conflicts. I think everybody required reviewed and approved at least once.
@mdtoguchi, @AlexeySachkov, @kbobrovs, please comment if anything left.

[steffenlarsen]

Thanks @pvchupin . Sorry for the double rebase. New conflicts snuck in while I was doing the first rebase. It should be ready now.

[bader]

Ouch... @steffenlarsen, sorry, I seem to introduce another merge conflict. Could you take a look, please?

[steffenlarsen]

Ouch... @steffenlarsen, sorry, I seem to introduce another merge conflict. Could you take a look, please?

Haha, no worries! It has been taken care of. Thanks for letting me know.

[kbobrovs]

driver, doc, file-table-tform LGTM