Skip to content

Conversation

@fwyzard
Copy link
Contributor

@fwyzard fwyzard commented Mar 4, 2020

Rename the Intel oneAPI backend to SYCL.
Build a single binary with support for both CUDA and OpenCL backends.
Run on all devices by default, or restrict the choice with command line options.

Use the -Wno-unknown-cuda-version flag only if LLVM 11 is detected.
Look for libpi_cuda.so under the correct path.
Add the path to the oneAPI compiler to the PATH.
@makortel
Copy link
Owner

makortel commented Mar 4, 2020

I'm not sure about the rename to "SYCL" because of the use of the Intel extensions (or will they have a high chance to be accepted for the next SYCL version?). I would be perfectly fine with DPC++ (dpcpp even if the acronym is awful), or staying with oneAPI (even though to me DPC++ looks like the most precise term).

Makefile Outdated
ALPAKA_BASE := /usr/local/alpaka/alpaka
CUPLA_BASE := /usr/local/alpaka/cupla
ONEAPI_BASE := /opt/intel/inteloneapi/compiler/latest/linux
SYCL_BASE := /data/user/fwyzard/sycl/build
Copy link
Owner

Choose a reason for hiding this comment

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

Should this be something along /usr/local/sycl/build to stay more generic?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ops, that sneaked in... I'll change it to something more generic, like /opt/sycl/latest.

@fwyzard
Copy link
Contributor Author

fwyzard commented Mar 4, 2020

I'm not sure about the rename to "SYCL" because of the use of the Intel extensions (or will they have a high chance to be accepted for the next SYCL version?).

I think they have a good chance to be accepted, and some Intel people mentioned that the new specs could be released by the end of next month.

I can keep oneAPI if you prefer.

@makortel
Copy link
Owner

makortel commented Mar 4, 2020

On the other hand, I guess the probability of trying out SYCL 1.2.1 conforming implementation is low, so we could plan for "success (of new specs)" and go on with SYCL, and rename later if needed.

I'll merge after you change the path to something more generic.

@fwyzard
Copy link
Contributor Author

fwyzard commented Mar 4, 2020

If you are interested, I could also try to prepare an implementation for a conformant SYCL toolckain (like Codeplay's).
I think it should be doable, but I kept postponing it ...

@makortel
Copy link
Owner

makortel commented Mar 4, 2020

If you are interested, I could also try to prepare an implementation for a conformant SYCL toolckain (like Codeplay's).
I think it should be doable, but I kept postponing it ...

I think such an implementation would be interesting, but mostly in the academic sense, so I don't think it should have high (or even medium) priority.

@fwyzard
Copy link
Contributor Author

fwyzard commented Mar 4, 2020 via email

extensions, and Codeplay's CUDA backend is available on GitHub at
https://github.com/intel/llvm/ .
See [the instructions](https://patatrack.web.cern.ch/patatrack/wiki/SYCL/)
on the Patatrack Wiki for building the SYCL toolchain.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I will add the instructions there over the next days.

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
Owner

Choose a reason for hiding this comment

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

Thanks!

@makortel makortel merged commit 890a86c into makortel:master Mar 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants