We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
Three Goals:
At a high level, we have three cases:
device openmp serial
If you expand this out to include the underlying programing model, we expect to have:
cuda hip sycl openmp serial
If we enumerate the VTK-m specific options:
vtkm_cuda vtkm_kokkos_hip vtkm_kokkos_cuda vtkm_kokkos_sycl? vtkm_openmp vtkm_serial
(vtkm_cuda and kokkos_cuda are different implementations, and users may have a strong reason to choose one or the other)
vtkm_cuda
kokkos_cuda
I propose we support an option that accepts a union of these cases:
device cuda hip sycl vtkm_cuda vtkm_kokkos_hip vtkm_kokkos_cuda vtkm_kokkos_sycl? vtkm_openmp vtkm_serial openmp serial
Where device gives you general option that maps to either cuda | hip | sycl with some precedence in the rare case more than one exists.
device
cuda | hip | sycl
Additionally, we should support an input list that selects what should be tried and the precedence:
Examples:
execution: ["device","openmp","serial"]
Would try to use a device runtime (cuda or hip or sycl) first, then openmp, then serial
cuda
hip
sycl
openmp
serial
execution: ["cuda","openmp","serial"]
Would try to use cuda first, then openmp, then serial
execution: ["cuda","openmp"]
Would try to use cuda first, then openmp and would not try any others
execution: ["device"] or execution: "device"
Would only try to use a device runtime (cuda or hip or sycl) and no others.
The text was updated successfully, but these errors were encountered:
No branches or pull requests
Three Goals:
Naming of "backend" or execution strategies
At a high level, we have three cases:
If you expand this out to include the underlying programing model, we expect to have:
If we enumerate the VTK-m specific options:
(
vtkm_cuda
andkokkos_cuda
are different implementations, and users may have a strong reason to choose one or the other)I propose we support an option that accepts a union of these cases:
Where
device
gives you general option that maps to eithercuda | hip | sycl
with some precedence in the rare case more than one exists.Additionally, we should support an input list that selects what should be tried and the precedence:
Examples:
Would try to use a device runtime (
cuda
orhip
orsycl
) first, thenopenmp
, thenserial
Would try to use
cuda
first, thenopenmp
, thenserial
Would try to use
cuda
first, thenopenmp
and would not try any othersWould only try to use a device runtime (
cuda
orhip
orsycl
) and no others.The text was updated successfully, but these errors were encountered: