-
Notifications
You must be signed in to change notification settings - Fork 796
[SYCL] Enable PI unit testing on multiple plugins. #1694
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
Conversation
Enable CUDA + OpenCL PI unit tests. Signed-off-by: Stuart Adams <[email protected]>
Signed-off-by: Stuart Adams <[email protected]>
Signed-off-by: Stuart Adams <[email protected]>
Signed-off-by: Stuart Adams <[email protected]>
Signed-off-by: Stuart Adams <[email protected]>
Okay. The failure seems to be sporadic.
OTOH, I see a lot of successful runs. |
@StuartDAdams, are you able to reproduce this failure in your environment? |
We should disable sporadic fails until it's resolved. |
Nothing is failing for me yet. This is curious. |
Signed-off-by: Stuart Adams <[email protected]>
@@ -1422,9 +1429,9 @@ struct _pi_plugin { | |||
// Some choices are: | |||
// - Use of integers to keep major and minor version. | |||
// - Keeping char* Versions. | |||
const char PiVersion[4] = _PI_H_VERSION_STRING; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This const member was causing issues, as the compiler was no longer able to generate a default copy assignment operator, making it difficult to pass a vector of plugins to the algorithms I use in this PR. I could write one by hand, but copy constructors and other C++ language features have no place in this C API header.
Additionally, these in-class member initialisers are a C++ language feature. If I'm not mistaken, it generates a default constructor where these two members are initalized. Because of this, I moved the initialisation of these members to pi::initialize function in pi.cpp. _pi_plugin is now a POD because of these changes. There are a few C++ features in pi.h that would fail to compile with C, but these are the only things relevant to this PR.
return *it; | ||
} | ||
|
||
inline std::vector<cl::sycl::detail::plugin> initializeAndRemoveInvalid() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took on your feeback from #1647, and came up with this. In the version of googletest that ships with LLVM, there is no way to skip tests at runtime (googletest would later introduce GTEST_SKIP
).
Instead I have written a wrapper around pi::initiaize
that removes plugins that will not behave well during unit testing. If the plugin cannot return any platforms or it returns an error code, it is dropped from the test. Using this wrapper, the parameterised tests will now run tests only for plugins that are able to return platforms. I plan on adding a log for this as well, so that any dropped plugins can be seen in test logs.
PI_DEVICE_TYPE_ALL = | ||
CL_DEVICE_TYPE_ALL, ///< All devices available in the PI plugin. | ||
PI_DEVICE_TYPE_CPU = | ||
CL_DEVICE_TYPE_CPU, ///< A PI device that is the host processor. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure it's a 100% accurate. I assume it's possible to have CPU device != host processor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the wording OpenCL uses for their equivalent enumerator. I guess what you're thinking of would be more along the lines of an accelerator?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is what I used as reference.
https://www.khronos.org/registry/OpenCL/sdk/1.0/docs/man/xhtml/clGetDeviceIDs.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting... I always thought that OpenCL spec doesn't force the implementation to use the host processor on multi-processor systems. I think it's possible to configure Intel OpenCL CPU implementation to run on a "non-host" processor.
This might be just an typo in the spec...
@mkinsner, @bashbaug, do you have any thoughts regarding this wording?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my view, PI API is very close to OpenCL by design so it makes sense to me to keep the language here similar to the original wording. If it turns out to be a typo in the OpenCL spec, I'll happily update it with a follow-up PR. It is important that we re-enable PI API testing ASAP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's very minor comment and it shouldn't block merging this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This same text is in the latest OpenCL spec also. It hasn't changed since v1.0:
https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_API.html#CL_DEVICE_TYPE_CPU
I'll get this tidied up in the spec. I agree it shouldn't hold up this PR.
@intel/llvm-reviewers-runtime, ping. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comments are stylistic, they should not block this PR.
return "Unknown Plugin"; | ||
} | ||
} | ||
} // namespace pi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is screaming for a blank line.
@@ -0,0 +1,23 @@ | |||
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The header seems to be a little different from what the rest of the project uses.
plugin &operator=(const plugin &) = default; | ||
plugin(const plugin &) = default; | ||
plugin &operator=(plugin &&other) noexcept = default; | ||
plugin(plugin &&other) noexcept = default; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting... What made you explicitly default these things?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The compiler was deleting a few of these implicitly because pi_plugin's constant members. I was trying to narrow in on the source of the error, as it prevented me from passing plugins to standard algorithms that required the type to be copy assignable. Because this type encapsulates pi_plugin object, the compiler decided to delete its copy assignment and copy constructor. Now that pi_plugin has been fixed, you could probably remove these explicit defaults to no ill effect, but I decided to leave them in. I prefer all special member functions to be explicitly defined if any of them are present, as I can reason about the class' behavior without having to guess at what the compiler will do.
Let's address non-blocking comments in follow-up PR. |
This PR re-enables all disabled PI API unit tests.
Backend-agnostic unit tests have been refactored using value-parameterized tests, allowing the same set of unit tests to be ran on a set of PI plugins.
Signed-off-by: Stuart Adams [email protected]