SYCL support #914

rhoarau · 2019-06-16T11:58:18Z

I added some modifications to be able to use glm inside SYCL's kernel.

https://www.khronos.org/sycl/:

SYCL (pronounced ‘sickle’) is a royalty-free, cross-platform abstraction layer that builds on the underlying concepts, portability and efficiency of OpenCL that enables code for heterogeneous processors to be written in a “single-source” style using completely standard C++

The core and ext functions should work out-of-box as long as they don't use the SYCL kernel's limitations (RTTI, dynamic allocation, recursion, function pointer).

The core and some ext functions should work.

Fix typos and code style (space to tab).

rhoarau · 2019-06-23T09:33:03Z

@Groovounet
In order to give more visibility to the SYCL's user, can you add "sycl" to the glm topic tags?
There is also a web site for the SYCL ecosystem (http://sycl.tech/#projects), can I add glm here?

zjin-lcf · 2022-03-26T17:03:59Z

@rhoarau

When compiling a program with Intel LLVM SYCL compiler, the following error is shown. Is this expected ? Thanks.

include/glm/detail/_vectorize.hpp:71:24: error: SYCL kernel cannot call through a function pointer
return vec<3, T, Q>(Func(a.x, b.x), Func(a.y, b.y), Func(a.z, b.z));

rhoarau · 2022-04-07T12:52:06Z

@zjin-lcf
Yes it was expected since SYCL don't support function pointer in device code and GLM use this feature to apply a function on each component of a vector. Here is some workarounds:

Don't use these functions and write your own function (min, max, ...).
A better workaround would be to modify glm to use lambda function instead function pointer. If I remember, lambda is legal in device code.

This reverts PR g-truc#914 which introduced a hacky way to replace all std namespace maths function calls with sycl namespace ones. Presumably the original intention was to use GLM functions in SYCL device code (e.g. on GPUs) and force it to use the maths implementations optimised for the target device. However, this has been very limited in scope since the start because GLM relies heavily on function pointers which are illegal to use inside SYCL device code. The hacky solution shadowing std namespace with glm::std is problematic in many ways. One was that it required re-introducing all std symbols used across GLM codebase back to glm::std. The list of these symbols is difficult to maintain over time without extensive CI testing and unsurprisingly it got broken. Any code just including (some of) GLM headers now no longer compiles with SYCL compilers even if GLM is only used on the host side (CPU code). Remove this hack to allow SYCL programs using GLM on the host side to compile. The original hack was tested against the ComputeCpp compiler which is now phased out in favour of Intel's DPC++. Remove also the mention of ComputeCpp from README. The statement about "any C++11 compiler" still covers the host code compilation with DPC++.

This reverts PR #914 which introduced a hacky way to replace all std namespace maths function calls with sycl namespace ones. Presumably the original intention was to use GLM functions in SYCL device code (e.g. on GPUs) and force it to use the maths implementations optimised for the target device. However, this has been very limited in scope since the start because GLM relies heavily on function pointers which are illegal to use inside SYCL device code. The hacky solution shadowing std namespace with glm::std is problematic in many ways. One was that it required re-introducing all std symbols used across GLM codebase back to glm::std. The list of these symbols is difficult to maintain over time without extensive CI testing and unsurprisingly it got broken. Any code just including (some of) GLM headers now no longer compiles with SYCL compilers even if GLM is only used on the host side (CPU code). Remove this hack to allow SYCL programs using GLM on the host side to compile. The original hack was tested against the ComputeCpp compiler which is now phased out in favour of Intel's DPC++. Remove also the mention of ComputeCpp from README. The statement about "any C++11 compiler" still covers the host code compilation with DPC++.

This reverts PR g-truc#914 which introduced a hacky way to replace all std namespace maths function calls with sycl namespace ones. Presumably the original intention was to use GLM functions in SYCL device code (e.g. on GPUs) and force it to use the maths implementations optimised for the target device. However, this has been very limited in scope since the start because GLM relies heavily on function pointers which are illegal to use inside SYCL device code. The hacky solution shadowing std namespace with glm::std is problematic in many ways. One was that it required re-introducing all std symbols used across GLM codebase back to glm::std. The list of these symbols is difficult to maintain over time without extensive CI testing and unsurprisingly it got broken. Any code just including (some of) GLM headers now no longer compiles with SYCL compilers even if GLM is only used on the host side (CPU code). Remove this hack to allow SYCL programs using GLM on the host side to compile. The original hack was tested against the ComputeCpp compiler which is now phased out in favour of Intel's DPC++. Remove also the mention of ComputeCpp from README. The statement about "any C++11 compiler" still covers the host code compilation with DPC++.

rhoarau added 3 commits June 9, 2019 16:05

Initial SYCL support:

8fb71ff

The core and some ext functions should work.

Remove a preprocessor debug message and correct the readme

1079444

2a88228

Fix typos and code style (space to tab).

Groovounet self-assigned this Jun 21, 2019

Groovounet merged commit 6cd38b9 into g-truc:master Jun 21, 2019

rafbiels mentioned this pull request Oct 10, 2023

Remove the SYCL hacks #1160

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SYCL support #914

SYCL support #914

SYCL support #914

SYCL support #914

Conversation