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

[SYCL] Rewrite tests that fail when usm_shared_allocations not supported #2 #12655

Merged
merged 23 commits into from
Feb 12, 2024

Conversation

lbushi25
Copy link
Contributor

@lbushi25 lbushi25 commented Feb 7, 2024

Continuation of #12636.
Refer to it for a description.

Copy link
Contributor

github-actions bot commented Feb 7, 2024

✅ With the latest revision this PR passed the C/C++ code formatter.

@lbushi25 lbushi25 changed the title Rewrite tests that fail when usm_shared_allocations not supported #2 [SYCL] Rewrite tests that fail when usm_shared_allocations not supported #2 Feb 8, 2024
@lbushi25
Copy link
Contributor Author

lbushi25 commented Feb 9, 2024

@intel/llvm-reviewers-runtime

Copy link
Contributor

@sommerlukas sommerlukas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes to kernel fusion tests LGTM.

@@ -24,7 +24,7 @@
// the tests, please check if they pass without the discard_events property, if
// they don't pass then it's most likely a general issue unrelated to
// discard_events.

// REQUIRES: aspect-usm_shared_allocations
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Am I right that we can't rewrite discard event test cases to use buffer & accessor instead because the latter introduces dependencies in the execution graph that this test case doesn't want?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That could be a reason but for me what convinced me to not do it is that many functions in this test have the USM string in their names. Therefore, with limited knowledge of how this test is supposed to work, I decided to leave it as is.

@@ -76,44 +78,45 @@ void testRootGroupFunctions() {
sycl::ext::oneapi::experimental::use_root_sync};

constexpr int testCount = 10;
bool *testResults = sycl::malloc_shared<bool>(testCount, q);
sycl::buffer<bool> testResults_buf{sycl::range{testCount}};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest using a consistent naming scheme. Since the code around this change uses camelCase, you could as well use that.

@@ -15,20 +15,26 @@ int main() {
sycl::queue Q1{Ctx, Dev, {sycl::property::queue::in_order{}}};
sycl::queue Q2{Ctx, Dev, {sycl::property::queue::in_order{}}};

int *DevData = sycl::malloc_shared<int>(N, Dev, Ctx);
sycl::buffer<int> DevDatabuf{sycl::range{N}};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT: 'DevDatabuf' -> 'DevDataBuf'

@@ -47,8 +53,5 @@ int main() {
}
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIUC, we should keep the 'free(HostData)' as it is still being malloc'd.

@@ -6,6 +6,7 @@
// RUN: | FileCheck %s
// RUN: env ZE_DEBUG=-6 SYCL_PI_TRACE=-1 %{run} %t.out \
// RUN: | FileCheck %s --check-prefixes=CHECK-CACHE
// REQUIRES: aspect-usm_shared_allocations
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we rewite this test case to use buffer/accessors instead? I don't see how that change will alter the caching/eviction of kernels/programs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've changed it to use malloc_device because with buffer/accessor the test was failing due to some PI calls not showing up as expected.

@@ -80,24 +80,22 @@ static void test(RedStorage &Storage, RangeTy Range) {
cgh, Range, ext::oneapi::experimental::empty_properties_t{}, RedSycl,
[=](auto Item, auto &Red) { Red.combine(T{1}); });
}).wait();

auto *Result = malloc_shared<T>(1, q);
sycl::buffer<T> Result_buf{sycl::range{1}};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same suggestion of using a consistent naming scheme.

@@ -3,7 +3,7 @@

// Windows doesn't yet have full shutdown().
// UNSUPPORTED: ze_debug && windows

// REQUIRES: aspect-usm_shared_allocations
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we rewite this test using buffers intead?

@@ -3,7 +3,7 @@

// Windows doesn't yet have full shutdown().
// UNSUPPORTED: ze_debug && windows

// REQUIRES: aspect-usm_shared_allocations
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here. Can we rewrite it using buffers instead?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we do need some USM allocation for the span version of the reduction. However, using device allocations might make this test supported on a broader range of devices.

@@ -6,7 +6,7 @@

// Windows doesn't yet have full shutdown().
// UNSUPPORTED: ze_debug && windows

// REQUIRES: aspect-usm_shared_allocations
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same

Copy link
Contributor Author

@lbushi25 lbushi25 Feb 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These tests that involve spans seem unfriendly to buffers/accessor as there are no span constructors that accept accessors as arguments. I could probably use the get_ptr method on an accessor and pass that pointer to the span but I've got a feeling that's probably undefined behavior, feel free to correct me though! I'll see if i can make them work instead with @aelovikov-intel's suggestion to use malloc_device instead.

@lbushi25
Copy link
Contributor Author

lbushi25 commented Feb 9, 2024

@uditagarwal97 Will change the names to camel case as you suggested.
Regarding the request to write some tests using buffer/accessors, I have tried implementing all the tests that you singled out using buffers/accessors but they were failing with very vague error reporting so I just decided to play it safe. I will try again to see if I've missed some test that should be doable with buffers/accessors but if a simple approach doesn't work, I won't try again since I don't want to potentially change what the test is trying to verify.

@uditagarwal97
Copy link
Contributor

@uditagarwal97 Will change the names to camel case as you suggested. Regarding the request to write some tests using buffer/accessors, I have tried implementing all the tests that you singled out using buffers/accessors but they were failing with very vague error reporting so I just decided to play it safe. I will try again to see if I've missed some test that should be doable with buffers/accessors but if a simple approach doesn't work, I won't try again since I don't want to potentially change what the test is trying to verify.

Sure. You can share with me the test case implementation with buffer/accessors that causes errors.

@lbushi25
Copy link
Contributor Author

lbushi25 commented Feb 9, 2024

@uditagarwal97 Will change the names to camel case as you suggested. Regarding the request to write some tests using buffer/accessors, I have tried implementing all the tests that you singled out using buffers/accessors but they were failing with very vague error reporting so I just decided to play it safe. I will try again to see if I've missed some test that should be doable with buffers/accessors but if a simple approach doesn't work, I won't try again since I don't want to potentially change what the test is trying to verify.

Sure. You can share with me the test case implementation with buffer/accessors that causes errors.

Have a look at my changes, with Andrei's suggestion of using malloc_device we get 100% test coverage just like buffers/accessors except that the test itself is simpler than buffer/accessor so I recommend we stick to this instead.

Copy link
Contributor

@cperkinsintel cperkinsintel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Any thoughts about what to do moving forward as more tests get written? malloc_shared and friends are popular, seems likely to be reintroduced without the aspect check. I guess "constant vigilance" ?

@lbushi25
Copy link
Contributor Author

LGTM

Any thoughts about what to do moving forward as more tests get written? malloc_shared and friends are popular, seems likely to be reintroduced without the aspect check. I guess "constant vigilance" ?

From what I've seen so far, malloc_shared seems to be the only problematic one and hopefully people will steer away of this after facing these errors. I also think we should not have e2e tests run on devices that do not support malloc_shared. If we want to test for malloc_shared failure specifically, we can have some unit tests on mock devices.

@lbushi25
Copy link
Contributor Author

@uditagarwal97 Have a look when you have some time please!

Copy link
Contributor

@uditagarwal97 uditagarwal97 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@aelovikov-intel aelovikov-intel merged commit 6639e78 into intel:sycl Feb 12, 2024
12 checks passed
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.

5 participants