Skip to content

[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

Merged
merged 12 commits into from
May 20, 2020

Conversation

nyalloc
Copy link
Contributor

@nyalloc nyalloc commented May 15, 2020

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]

@nyalloc nyalloc requested review from smaslov-intel and a team as code owners May 15, 2020 15:33
@nyalloc nyalloc requested a review from s-kanaev May 15, 2020 15:33
@nyalloc nyalloc changed the title [WIP][SYCL] Enable PI unit testing on multiple plugins. [WIP][DO-NOT-MERGE][SYCL] Enable PI unit testing on multiple plugins. May 15, 2020
@bader
Copy link
Contributor

bader commented May 15, 2020

Okay. The failure seems to be sporadic.
I see SYCL-Unit::CudaInteropGetNativeTests.interopTaskGetMem failed twice for the PRs, which can't impact test results on CUDA.

  1. http://ci.llvm.intel.com:8010/#/builders/37/builds/869 from [SYCL] Add dependency.conf with external dependencies for SYCL #1555.
  2. http://ci.llvm.intel.com:8010/#/builders/37/builds/859 from [SYCL] Add support for kernel name types templated using enums. #1675.

OTOH, I see a lot of successful runs.

@bader
Copy link
Contributor

bader commented May 15, 2020

@StuartDAdams, are you able to reproduce this failure in your environment?

@pvchupin
Copy link
Contributor

We should disable sporadic fails until it's resolved.

@nyalloc
Copy link
Contributor Author

nyalloc commented May 18, 2020

@StuartDAdams, are you able to reproduce this failure in your environment?

Nothing is failing for me yet. This is curious.

@@ -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;
Copy link
Contributor Author

@nyalloc nyalloc May 19, 2020

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() {
Copy link
Contributor Author

@nyalloc nyalloc May 19, 2020

Choose a reason for hiding this comment

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

@bader @smaslov-intel

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.

@nyalloc nyalloc requested a review from smaslov-intel May 20, 2020 10:53
@nyalloc nyalloc changed the title [WIP][DO-NOT-MERGE][SYCL] Enable PI unit testing on multiple plugins. [SYCL] Enable PI unit testing on multiple plugins. May 20, 2020
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.
Copy link
Contributor

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.

Copy link
Contributor Author

@nyalloc nyalloc May 20, 2020

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

@bader
Copy link
Contributor

bader commented May 20, 2020

@intel/llvm-reviewers-runtime, ping.

Copy link
Contributor

@alexbatashev alexbatashev left a 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
Copy link
Contributor

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.
Copy link
Contributor

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.

Comment on lines +30 to +33
plugin &operator=(const plugin &) = default;
plugin(const plugin &) = default;
plugin &operator=(plugin &&other) noexcept = default;
plugin(plugin &&other) noexcept = default;
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@bader
Copy link
Contributor

bader commented May 20, 2020

Let's address non-blocking comments in follow-up PR.

@bader bader merged commit a6381fe into intel:sycl May 20, 2020
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.

7 participants