Introduce test plan for CUDA backend interop #207
Conversation
AerialMantis
requested review from
bader,
illuhad,
keryell and
ProGTX
as code owners
|
|
| is available and resolves to an alias of `CUevent`. | ||
| * Check that the `sycl::backend_input_t<sycl::backend::cuda, sycl::buffer>` | ||
| is available and resolves to an alias of | ||
| `struct { CUdeviceptr ptr; size_t size; }`. |
There was a problem hiding this comment.
This looks very much like an implementation detail for a given implementation.
There was a problem hiding this comment.
This has actually changed now in the CUDA backend specification, interop in this direction was removed as it was decided that it was too complicated to represent the complexities of the buffer class as an input for interop.
| * Check that the `sycl::backend_return_t<sycl::backend::cuda, sycl::event>` | ||
| is available and resolves to an alias of `CUevent`. | ||
| * Check that the `sycl::backend_return_t<sycl::backend::cuda, sycl::buffer>` | ||
| is available and resolves to an alias of `CUdeviceptr`. |
There was a problem hiding this comment.
At least it is interesting to see this as a Rosetta Stone for SYCL-CUDA translation. :-)
AerialMantis
force-pushed
the
gordon/cude-backend-interop-test-plan
branch
from
d33caac
to
309840d
Compare
|
I've updated the test plan to reflect changes in the CUDA backend spec and the tests in #336. |
| * `unsigned long int` | ||
| * `long long int` | ||
| * `unsigned long long int` | ||
| * `float` |
There was a problem hiding this comment.
Some NVIDIA GPUs support double data types. Can we add double to this list?
| * `vec<T, int dim>` where `T` is each of the scalar types listed above except | ||
| for `bool` and `dim` is `1`, `2`, `3`, `4`, `8`, and `16`. | ||
| * `marray<T, size_t dim>` where `T` is each of the scalar types listed above | ||
| and `dim` is `2`, `5`, and `10`. |
There was a problem hiding this comment.
Testing with 1 here too as a special array case.
|
LGTM after offline changes. |
|
@AerialMantis, I've applied code review suggestion in 3c3a06c. If you are okay with these changes, I suggest we merge this PR. @psalz, could you take a look at check-clang-format job, please? |
No idea what's going on there, looks like a GitHub issue:
I'd suggest to wait a few hours and try again. |
|
@bader thanks for applying those changes, this looks good to me, I think we can merge. |
Introduce the first draft of a test plan for CUDA backend interoperability as defined in the CUDA backend specification.
A pull request for introducing the CUDA backend specification to the SYCL 2020 specification is here - KhronosGroup/SYCL-Docs#197