-
Notifications
You must be signed in to change notification settings - Fork 797
[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
Changes from 10 commits
95977a6
512741d
c448c80
39a85a8
a07f0f7
0f9e310
8cc36a6
f18759d
6cfc9d9
174315e
944b660
e15d752
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -132,9 +132,16 @@ typedef enum { | |
// make the translation to OpenCL transparent. | ||
// | ||
typedef enum : pi_uint64 { | ||
PI_DEVICE_TYPE_CPU = CL_DEVICE_TYPE_CPU, | ||
PI_DEVICE_TYPE_GPU = CL_DEVICE_TYPE_GPU, | ||
PI_DEVICE_TYPE_ACC = CL_DEVICE_TYPE_ACCELERATOR | ||
PI_DEVICE_TYPE_DEFAULT = | ||
CL_DEVICE_TYPE_DEFAULT, ///< The default device available in the PI | ||
///< plugin. | ||
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. | ||
PI_DEVICE_TYPE_GPU = CL_DEVICE_TYPE_GPU, ///< A PI device that is a GPU. | ||
PI_DEVICE_TYPE_ACC = CL_DEVICE_TYPE_ACCELERATOR ///< A PI device that is a | ||
///< dedicated accelerator. | ||
} _pi_device_type; | ||
|
||
typedef enum { | ||
|
@@ -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 commentThe 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. |
||
char PiVersion[4]; | ||
// Plugin edits this. | ||
char PluginVersion[4] = _PI_H_VERSION_STRING; | ||
char PluginVersion[4]; | ||
char *Targets; | ||
struct FunctionPointers { | ||
#define _PI_API(api) decltype(::api) *api; | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -27,6 +27,11 @@ class plugin { | |
plugin(RT::PiPlugin Plugin, backend UseBackend) | ||
: MPlugin(Plugin), MBackend(UseBackend) {} | ||
|
||
plugin &operator=(const plugin &) = default; | ||
plugin(const plugin &) = default; | ||
plugin &operator=(plugin &&other) noexcept = default; | ||
plugin(plugin &&other) noexcept = default; | ||
Comment on lines
+30
to
+33
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 commentThe 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. |
||
|
||
~plugin() = default; | ||
|
||
const RT::PiPlugin &getPiPlugin() const { return MPlugin; } | ||
|
@@ -79,7 +84,7 @@ class plugin { | |
|
||
private: | ||
RT::PiPlugin MPlugin; | ||
const backend MBackend; | ||
backend MBackend; | ||
}; // class plugin | ||
} // namespace detail | ||
} // namespace sycl | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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 commentThe 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. |
||
// See https://llvm.org/LICENSE.txt for license information. | ||
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception | ||
|
||
#pragma once | ||
|
||
#include <detail/plugin.hpp> | ||
|
||
namespace pi { | ||
inline const char *GetBackendString(cl::sycl::backend backend) { | ||
switch (backend) { | ||
#define PI_BACKEND_STR(backend_name) \ | ||
case cl::sycl::backend::backend_name: \ | ||
return #backend_name | ||
PI_BACKEND_STR(cuda); | ||
PI_BACKEND_STR(host); | ||
PI_BACKEND_STR(opencl); | ||
#undef PI_BACKEND_STR | ||
default: | ||
return "Unknown Plugin"; | ||
} | ||
} | ||
} // namespace pi | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is screaming for a blank line. |
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.
Uh oh!
There was an error while loading. Please reload this page.
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.