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

Tests for [[device_has]] attribute from optional kernel features #287

Conversation

andreyromanof
Copy link
Contributor

@andreyromanof andreyromanof commented Feb 17, 2022

This PR provides tests for optional kernel features.
Test decorates kernel or function invoked by the kernel with the attribute [[sycl::device_has(aspect)]] and expected exception if a device doesn't support aspect, otherwise expect no throw.

Depends on:

* Added cmake for deivce_has tests

* Added common code for device_has tests

* Added tests for device_has attribute

* Tests added to filter for computecpp and hipsycl
@andreyromanof andreyromanof force-pushed the optional_kernel_features/device_has_exception branch from a50e287 to 5cb9077 Compare February 17, 2022 02:20
@andreyromanof andreyromanof marked this pull request as ready for review February 17, 2022 07:15
@@ -28,3 +28,4 @@ usm
vector_api
vector_constructors
vector_swizzles
optional_kernel_features
Copy link
Contributor

Choose a reason for hiding this comment

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

Same naming question as in #285

Romanov AndreyX added 4 commits February 18, 2022 10:17
According to spec SYCL_EXTERNAL is optional and can be unsupported by some
implemetations. If implementation doesn't define SYCL_EXTERNAL then
tests with external functions will be disabled
Copy link
Contributor

@bader bader left a comment

Choose a reason for hiding this comment

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

@andreyromanof, could you extend the description of the PR with the information about what prevent the compilation of this test with computcpp/dpcpp/hipsycl?

@andreyromanof
Copy link
Contributor Author

@andreyromanof, could you extend the description of the PR with the information about what prevent the compilation of this test with computcpp/dpcpp/hipsycl?

Done

Copy link
Member

@keryell keryell left a comment

Choose a reason for hiding this comment

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

You could remove some useless ()

Also changed `device_has()` to `get_device().has()`
Copy link
Contributor

@bader bader left a comment

Choose a reason for hiding this comment

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

  • Build fails on computecpp due to linkage error, which I was unable to solve.

@andreyromanof, the link points to the log for a different PR. According to @psalz, there are at least two issues with compiling this PR with computecpp:

  • tests use unnamed lambda
  • tests use "device_has"

I expected you to list both in the description.

I suggest we remove optional_kernel_features from all the filters and disable specific test cases with the macro introduced by #293.

@andreyromanof
Copy link
Contributor Author

I suggest we remove optional_kernel_features from all the filters and disable specific test cases with the macro introduced by #293.

That makes sense. I'm going to patch this test and tests from other PRs.

@andreyromanof
Copy link
Contributor Author

I added compile time disable of the test and removed this test from the filter.
I also noticed, that for some reason I should pass implementation names in strict order. For example

  • DISABLED_FOR_TEMPLATE_TEST_CASE_SIG(ComputeCpp, DPCPP, hipSYCL) build fails due strange errors
  • DISABLED_FOR_TEMPLATE_TEST_CASE_SIG(ComputeCpp, hipSYCL, DPCPP) build finishes with no errors

@psalz could you please verify is this a bug or not.

@andreyromanof
Copy link
Contributor Author

andreyromanof commented Feb 28, 2022

Build still fails on hipSYCL because there is no sycl::errc definition.

@psalz
Copy link
Member

psalz commented Feb 28, 2022

I added compile time disable of the test and removed this test from the filter. I also noticed, that for some reason I should pass implementation names in strict order. For example

* `DISABLED_FOR_TEMPLATE_TEST_CASE_SIG(ComputeCpp, DPCPP, hipSYCL)` build fails due strange errors

* `DISABLED_FOR_TEMPLATE_TEST_CASE_SIG(ComputeCpp, hipSYCL, DPCPP)` build finishes with no errors

@psalz could you please verify is this a bug or not.

Yes same bug as in #289, fixed in #295.

Copy link
Contributor

@bader bader left a comment

Choose a reason for hiding this comment

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

Will this work?

ci/hipsycl.filter Outdated Show resolved Hide resolved
Romanov AndreyX added 2 commits March 1, 2022 09:12
@bader bader mentioned this pull request Mar 1, 2022
@bader
Copy link
Contributor

bader commented Mar 1, 2022

@andreyromanof, does merging #299 and #296 fix pre-commit?

@andreyromanof
Copy link
Contributor Author

Can't say for sure.
#296 should fix build for computecpp which I can't test locally. Also, Philip mentioned a bug with linkage even after with fix. So probably we will need to update computecpp version too.
#299 Should fix ci build for dpcpp.

…into optional_kernel_features/device_has_exception
/**
* @brief Macro for generating code that will use TYPE
*/
#define USE_FEATURE(TYPE) \
Copy link
Member

Choose a reason for hiding this comment

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

Not clear why you are using a macro instead of a generic function or lambda.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This macro should help to test cases, when user try to use feature function directly in kernel body, wihout functions or lambda. For example:

// using feature directly from kernel
queue.submit([&](sycl::handler &cgh) {
    cgh.single_task([] {
      dobule d = 0;
      d += 42;
    });
  });

// using feature in function call
queue.submit([&](sycl::handler &cgh) {
    cgh.single_task([] {
      some_function_use_double();
    });
  });

The goal was test separately cases with functions, that use some feature and test cases, when feature is used by kernel directly.

} \
CHECK(is_exception_thrown == IS_EXCEPTION_EXPECTED); \
check_async_exception(QUEUE, false); \
} \
Copy link
Member

Choose a reason for hiding this comment

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

Why such a huge macro instead of a function/class/lambda? Is this to pass the attribute with the preprocessor?
Also a lot of copy-paste inside the macro itself.

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 used macro because in some cases kernel should be sent as a submission call (without storing it in separate lambda or class functor for example). To achieve that I wrote this huge macro, that should paste code with submission call.

This macro also refactored in this commit: 2fb2d5e

}
}
CHECK(is_exception_thrown == is_exception_expected);
check_async_exception(queue, false);
Copy link
Member

Choose a reason for hiding this comment

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

I have the feeling to mostly see 3 times the same code.
Factorize in a function/lambda called 3 times and taking a lambda for executing the different code?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You're right, it looks like I can optimize these places. I tried to refactor these functions in this commit: 2fb2d5e

}
}
CHECK(is_exception_thrown == is_exception_expected);
check_async_exception(queue, false);
Copy link
Member

Choose a reason for hiding this comment

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

Idem: mostly 3 copy-pastes.

Romanov AndreyX added 2 commits March 5, 2022 09:46
…into optional_kernel_features/device_has_exception
Change try/catch blocks to CHECK_THROW_MATCHES and CHECK_NOTHROW
Moved exception check to separate function
@andreyromanof
Copy link
Contributor Author

andreyromanof commented Mar 5, 2022

@bader Right now computecpp build fails, because there are using unnamed kernels in the code. Spec says that it's allowed. Should we use a workaround with the named kernel to avoid this build issue, or these tests can just wait in the filter(disabled by macro DISABLED_FOR_TEMPLATE_TEST_CASE_SIG) until feature with automatic kernel names will be implemented in computecpp? Please note, that unnamed kernels are also used in these PRs: #292, #294, #289.

Also, computecpp will not compile even with named kernels due to a linkage error that looks like an implementation bug. (This error occurs in other PR where named kernels are used. Link to linkage error in other PR)

@andreyromanof
Copy link
Contributor Author

andreyromanof commented Mar 5, 2022

@psalz I don't understand why code in kernel_features_device_has_exceptions.cpp still compiling on computecpp, despite the fact that I disable implementation in every test with DISABLED_FOR_TEMPLATE_TEST_CASE_SIG(ComputeCpp, hipSYCL). Can you, please, suggest to me what I doing wrong? :)

@psalz
Copy link
Member

psalz commented Mar 7, 2022

@psalz I don't understand why code in kernel_features_device_has_exceptions.cpp still compiling on computecpp, despite the fact that I disable implementation in every test with DISABLED_FOR_TEMPLATE_TEST_CASE_SIG(ComputeCpp, hipSYCL). Can you, please, suggest to me what I doing wrong? :)

Fixed in #303.

…into optional_kernel_features/device_has_exception
@andreyromanof
Copy link
Contributor Author

Fixed in #303.

Thanks.

@bader bader merged commit 2ba9972 into KhronosGroup:SYCL-2020 Mar 9, 2022
@andreyromanof andreyromanof deleted the optional_kernel_features/device_has_exception branch April 7, 2022 08:02
steffenlarsen pushed a commit to steffenlarsen/SYCL-CTS that referenced this pull request Dec 6, 2022
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.

None yet

5 participants