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

Add generic device; Initial support in portBLAS #552

Closed
wants to merge 2 commits into from

Conversation

hjabird
Copy link
Contributor

@hjabird hjabird commented Aug 8, 2024

Description

Checklist

All Submissions

  • [NO] Do all unit tests pass locally? Attach a log.
    • I do not have a non Intel/Nvidia/AMD device to test with.
    • Tests appeared to run successfully when the code to recognise Intel devices was modified such that they fell through to the new "generic_device".
  • Have you formatted the code using clang-format?

New features

  • Have you provided motivation for adding a new feature?
  • [N/A] Have you added relevant tests?
    • The generic device is clearly documented as an unsupported configuration.

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

hjabird commented Aug 8, 2024

@al3x-jp I hope that this PR enables oneMKL interfaces to run on the PowerVR GPU with portBLAS as detailed in #542. Could you try this out?

@al3x-jp
Copy link

al3x-jp commented Aug 8, 2024

Hi, I have tried this (thank you) but it now fails with this error:

libze_intel_vpu.so.1: cannot open shared object file: No such file or directory
[New Thread 0x7ffff309d640 (LWP 5829)]
Caught std::exception during GEMM:
oneMKL: Couldn't load selected backend

oneMKL (debug build) was built with the following command line:

cmake .. -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang -DENABLE_MKLGPU_BACKEND=False -DENABLE_MKLGPU_BACKEND=False -DENABLE_PORTBLAS_BACKEND=True -DENABLE_CUBLAS_BACKEND=False -DENABLE_ROCBLAS_BACKEND=False -DENABLE_NETLIB_BACKEND=False -DBUILD_FUNCTIONAL_TESTS=False -DBUILD_EXAMPLES=True -DENABLE_MKLCPU_BACKEND=False -DENABLE_GENERIC_DEVICE=True

@hjabird
Copy link
Contributor Author

hjabird commented Aug 8, 2024

libze_intel_vpu.so.1 is not part of oneMKL Interfaces. It sounds like the DPC++ runtime is failing to find/open an Intel level-zero VPU backend. I don't know how the DPC++ runtime normally works with PowerVR. Does it just work when you build portBLAS independently? Does sycl-ls work correctly?

@hjabird
Copy link
Contributor Author

hjabird commented Aug 14, 2024

Hi @al3x-jp . Did you manage to investigate your problem any further?

@@ -60,6 +60,9 @@ option(ENABLE_CUFFT_BACKEND "Enable the cuFFT backend for the DFT interface" OFF
option(ENABLE_ROCFFT_BACKEND "Enable the rocFFT backend for the DFT interface" OFF)
option(ENABLE_PORTFFT_BACKEND "Enable the portFFT DFT backend for the DFT interface. Cannot be used with other DFT backends." OFF)

# Generic devices
option(ENABLE_GENERIC_DEVICE "Enable generic devices. Requires the portBLAS backend." OFF)
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 keen on adding yet another user option. Could this be automatically enabled whenever portBLAS is enabled and the default tuning target is used?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We could.

Generic device really means an unsupported device. That means:

  • It may not be tested, so there is a change of getting the wrong result.
  • Errors are likely to come from somewhere other than oneMKL Interfaces.

Consequently, I think any of this functionality should explicitly be opt-in. Additionally, we currently attempt to auto-detect a tuning target if it isn't set. This behavour is probably useful, although admittedtly portBLAS is even more useful for targets that don't have a vendor library already part of oneMKL Interfaces.

Copy link
Contributor

Choose a reason for hiding this comment

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

admittedtly portBLAS is even more useful for targets that don't have a vendor library already part of oneMKL Interfaces.

Yes that was my main reason to avoid having this option.

Thinking some more about it, if portBLAS always uses the "generic device" even for supported devices then it wouldn't conflict with the other backends anymore. It would make it easier to have portBLAS used as a fallback. The fallback feature won't happen in this PR but I think we will likely want to remove this option in the future so might as well not add it.
I think we could have portBLAS always use the generic device as part of this PR as well.

@@ -59,11 +59,19 @@ inline oneapi::mkl::device get_device_id(sycl::queue &queue) {
else if (vendor_id == AMD_ID)
device_id = device::amdgpu;
else {
#ifdef ENABLE_GENERIC_DEVICE
Copy link
Contributor

Choose a reason for hiding this comment

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

It seems to me we could avoid these ifdef and always return a generic_device as a fallback. The table_initializer object should throw backend_not_found the generic_device is used with a backend that does not support it.

@Rbiessy
Copy link
Contributor

Rbiessy commented Sep 5, 2024

Closing in favor of #566

@Rbiessy Rbiessy closed this Sep 5, 2024
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.

3 participants