-
Notifications
You must be signed in to change notification settings - Fork 160
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
Add generic device and initial support in portBLAS #566
Conversation
* oneMKL Interfaces currently only supports known targets: Intel CPU/GPU, AMD GPU, Nvidia GPU * This PR: * Enables a new generic target * Enables the generic target to use the portBLAS backend * Adds documentation
possible devices. This commit remove the option ENABLE_GENERIC_DEVICE and instead add generic_device to the backends_table. The check for unsupported_device exception is moved to table_initializer and to keep it as informative as it is, it is required a change to the function_tables operator[]. This change allows to use portBLAS (and in a possible future) all "port" libraries with any device supported.
This patch enables the possibility to run tests with generic_device for devices that have an OpenCL backend.
Moved pragma and simplified if-statement to increase code readability
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.
That looks good to me, thanks!
@oneapi-src/onemkl-maintain Hi all, in this PR I am adding a new generic device to allow portable libraries such as portBLAS and portFFT to be compiled and run on devices that are not known to us right now, but that have an OpenCL backend available. Changes are few and simple, but since I am making an important one to |
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 a useful change, I have just a couple questions.
"OpenCL") != std::string::npos) | ||
unsigned int vendor_id = | ||
static_cast<unsigned int>(dev.get_info<sycl::info::device::vendor_id>()); | ||
/* Do not test for OpenCL backend on Intel GPU */ |
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.
Does this logic continue to do what we want on AMD and nVidia GPUs?
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.
Thank you for your review @andrewtbarker
As far as I know NVIDIA and AMD GPUs don't use OpenCL backends, so I expect they continue to work as intended. In any case, I am happy to add a condition to check if the vendor is one of the currently known one and skip the OpenCL backend.
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.
Does this logic continue to do what we want on AMD and nVidia GPUs?
What is the behavior that we want on AMD and Nvidia exactly? We've been wondering whether we should remove this check entirely since it's not clear why would we want to skip OpenCL backends. To me users should use ONEAPI_DEVICE_SELECTOR
instead.
@@ -59,14 +59,20 @@ class table_initializer { | |||
using dlhandle = std::unique_ptr<LIB_TYPE, handle_deleter>; | |||
|
|||
public: | |||
function_table_t &operator[](oneapi::mkl::device key) { | |||
auto lib = tables.find(key); | |||
function_table_t &operator[](std::pair<oneapi::mkl::device, sycl::queue> device_queue_pair) { |
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 not clear to me why this change is necessary. Where do we need the sycl::queue
in the lookup tables?
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.
Since I moved the unsupported_device
exception in the table initializer, I need the queue to query the device name. This is the only reason why I need the sycl::queue
here.
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.
That makes sense. It seems like a large change for just the exception - I would support reverting the function table and throwing a more generic exception (or maybe implement mkl::unsupported_device
with no device argument?). But it is also okay as is.
Previously if some specific backend where enabled the test suite always added a cpu to the device to run test on, even if another if condition already added them. This behaviour cause linking time issue if a cpu device is not available. This commit removes it and it adds missing pragma to the other device selection, fixing the linking issue.
Hi, I got the following error when trying to build this checkout: [ 51%] Linking CXX executable ../../bin/test_main_blas_ct
Call Stack (most recent call first): gmake[2]: *** [tests/unit_tests/CMakeFiles/test_main_blas_ct.dir/build.make:388: bin/test_main_blas_ct] Error 1 Does the build require a SYCL CPU target being available? |
Hi @al3x-jp, thank you for highlighting this issue here. |
Co-authored-by: Maria Kraynyuk <[email protected]>
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.
LGTM, thanks!
Description
Checklist
All Submissions
generic_device
path.Following logs show that all domains still work properly:
arc_mkl_BLAS_log.txt
arc_mkl_DFT_log.txt
arc_mkl_lapack_log.txt
arc_mkl_rng_log.txt
New features
The generic device doesn't requires new tests.