Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[UR] Support fetch adapter source individually #12907

Merged
merged 1 commit into from
Mar 18, 2024

Conversation

kbenzie
Copy link
Contributor

@kbenzie kbenzie commented Mar 5, 2024

This patch and its counterpart in oneapi-src/unified-runtime#1410 add CMake support for fetching an individual Unified Runtime adapter's source code from a different repo/tag combination using the new fetch_adapter_source() CMake function. Only the source is cloned, it is not added to the build directly.

Instead, the path to the adapter source is passed into Unified Runtime clone described by the UNIFIED_RUNTIME_REPO and UNIFIED_RUNTIME_TAG CMake variables. This clone is the source of truth for the Unified Runtime API and drives the build of the external adapter source.

Using fetch_adapter_source() is optional.

This patch and its counterpart in oneapi-src/unified-runtime#1410 add
CMake support for fetching an individual Unified Runtime adapter's
source code from a different repo/tag combination using the new
`fetch_adapter_source()` CMake function. Only the source is cloned, it
is not added to the build directly.

Instead, the path to the adapter source is passed into Unified Runtime
clone described by the `UNIFIED_RUNTIME_REPO` and `UNIFIED_RUNTIME_TAG`
CMake variables. This clone is the source of truth for the Unified
Runtime API and drives the build of the external adapter source.

Using `fetch_adapter_source()` is optional.
@kbenzie kbenzie marked this pull request as ready for review March 18, 2024 11:05
@kbenzie kbenzie requested a review from a team as a code owner March 18, 2024 11:05
@kbenzie
Copy link
Contributor Author

kbenzie commented Mar 18, 2024

@intel/llvm-gatekeepers please merge

@steffenlarsen steffenlarsen merged commit 7616785 into intel:sycl Mar 18, 2024
11 checks passed
ldrumm pushed a commit that referenced this pull request Mar 18, 2024
Implement `seq_cst` RC11/ptx6.0 memory consistency for CUDA backend.

See https://dl.acm.org/doi/pdf/10.1145/3297858.3304043 and
https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#memory-consistency-model
for full details. Requires sm_70 or above. With this PR there is now a
complete mapping between SYCL memory consistency model capabilities and
the official CUDA model, fully exploiting CUDA capabilities when
possible on supported arches.

This makes the SYCL-CTS atomic_ref tests fully pass for sm_70 on the
cuda backend.

Fixes #11208

Depends on #12907

---------

Signed-off-by: JackAKirk <jack.kirk@codeplay.com>
kbenzie pushed a commit to kbenzie/llvm that referenced this pull request Apr 15, 2024
Implement `seq_cst` RC11/ptx6.0 memory consistency for CUDA backend.

See https://dl.acm.org/doi/pdf/10.1145/3297858.3304043 and
https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#memory-consistency-model
for full details. Requires sm_70 or above. With this PR there is now a
complete mapping between SYCL memory consistency model capabilities and
the official CUDA model, fully exploiting CUDA capabilities when
possible on supported arches.

This makes the SYCL-CTS atomic_ref tests fully pass for sm_70 on the
cuda backend.

Fixes intel#11208

Depends on intel#12907

---------

Signed-off-by: JackAKirk <jack.kirk@codeplay.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants