-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
An alpaka module with an explicit cpu backend fails to run in a job with a list of accelerators that does not include the cpu #43780
Comments
cms-bot internal usage |
A new Issue was created by @fwyzard Andrea Bocci. @Dr15Jones, @makortel, @rappoccio, @smuzaffar, @antoniovilela, @sextonkennedy can you please review it and eventually sign/assign? Thanks. cms-bot commands are listed here |
assign core, heterogeneous |
New categories assigned: core,heterogeneous @Dr15Jones,@fwyzard,@makortel,@makortel,@smuzaffar you have been requested to review this Pull request/Issue and eventually sign? Thanks |
This comment is mostly to just think out loud. I want to find out if The The Currently, the In a way CPU is a special "accelerator" as it is always (assumed to be) present. And non-Alpaka code will use the CPU anyway. So perhaps just allowing explicitly-set host backends irrespective of the contents of If the previous case would be allowed, what about setting the backend explicitly to anything? For example, |
I agree that I think this should fail. What about the case where a job uses |
Actually, that fails because
|
I'm glad |
An
@alpaka
module with an explicit CPU backend such aswill fail to run if the
process
is configured to exclude the CPU from the accelerators:with the message:
Currently, the workaround is to use the
alpaka_serial_sync::
variant explicitly:The text was updated successfully, but these errors were encountered: