-
Notifications
You must be signed in to change notification settings - Fork 188
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
Ensure that we treat cuda::mr::host_accessible
differently
#2452
Conversation
11532d4
to
150fee5
Compare
Currently we have an efficient and simple set of rules regarding properties. We simply match two sets of properties to find out whether A is a subset of B. However, that is not correct because we must treat `cuda::mr::host_accessible` differently because it is the implicit default, so `resource_ref<>` is equivalent to `resource_ref<cuda::mr::host_accessible>` This requires us to do some complex determination whether we need to actually extent the passed in set of types
This is news to me. Why is this the case? |
150fee5
to
5055aaa
Compare
🟨 CI finished in 56m 40s: Pass: 99%/364 | Total: 1d 12h | Avg: 6m 00s | Max: 56m 20s | Hits: 90%/20007
|
Project | |
---|---|
CCCL Infrastructure | |
+/- | libcu++ |
CUB | |
Thrust | |
+/- | CUDA Experimental |
pycuda | |
CUDA C Core Library |
Modifications in project or dependencies?
Project | |
---|---|
CCCL Infrastructure | |
+/- | libcu++ |
+/- | CUB |
+/- | Thrust |
+/- | CUDA Experimental |
+/- | pycuda |
+/- | CUDA C Core Library |
🏃 Runner counts (total jobs: 364)
# | Runner |
---|---|
297 | linux-amd64-cpu16 |
28 | linux-arm64-cpu16 |
24 | linux-amd64-gpu-v100-latest-1 |
15 | windows-amd64-cpu16 |
That was the default we settled on, otherwise we force the user to always pass in a property |
🟨 CI finished in 1h 28m: Pass: 99%/364 | Total: 1d 12h | Avg: 6m 00s | Max: 56m 20s | Hits: 90%/20007
|
Project | |
---|---|
CCCL Infrastructure | |
+/- | libcu++ |
CUB | |
Thrust | |
+/- | CUDA Experimental |
pycuda | |
CUDA C Core Library |
Modifications in project or dependencies?
Project | |
---|---|
CCCL Infrastructure | |
+/- | libcu++ |
+/- | CUB |
+/- | Thrust |
+/- | CUDA Experimental |
+/- | pycuda |
+/- | CUDA C Core Library |
🏃 Runner counts (total jobs: 364)
# | Runner |
---|---|
297 | linux-amd64-cpu16 |
28 | linux-arm64-cpu16 |
24 | linux-amd64-gpu-v100-latest-1 |
15 | windows-amd64-cpu16 |
Is that bad? |
It is not bad, but it is a choice. Effectively that means, that That could lead to issues moving forward when the user provides their own properties that do not exactly match ours. Furthermore, it will remove a bit of convenience. A user cannot write |
After internal discussion we decided that it is best to always require the user to provide an execution space property. All this implicit behavior is surpising at best and harmful in the other cases |
Currently we have an efficient and simple set of rules regarding properties.
We simply match two sets of properties to find out whether A is a subset of B.
However, that is not correct because we must treat
cuda::mr::host_accessible
differently because it is the implicit default, soresource_ref<>
is equivalent toresource_ref<cuda::mr::host_accessible>
This requires us to do some complex determination whether we need to actually extent the passed in set of types