[DRAFT] Allow GPU code path to be executed on CPU#299
Draft
samhatfield wants to merge 8 commits into
Draft
Conversation
Collaborator
Author
|
I forgot to mention why I'm doing this! The GPU code path has a number of data layout changes and general optimisations that we expect will improve also CPU performance. In the long term, we may therefore want to use this code path for operations instead of the "legacy" CPU version. But we need to do a proper side-by-side comparison first. Also, this will be useful for debugging the behaviour of the GPU version when it's actually running on GPU. |
Collaborator
Author
|
The latest commit seems to fix the above error. |
samhatfield
force-pushed
the
host_side_gpu
branch
2 times, most recently
from
160ec9a to
2f44473
Compare
samhatfield
force-pushed
the
host_side_gpu
branch
from
2f44473 to
1fb5410
Compare
samhatfield
force-pushed
the
host_side_gpu
branch
from
1fb5410 to
8c0cbee
Compare
No way we can have -DENABLE_OMPOFF=ON 😳
I don't think this works yet.
For some reason out-of-place FFTs give incorrect numbers but only for (consistently) random latitudes, like lat 14. Why? No idea.
This allows one to reenable OpenMP directives when building the GPU host backend. I am testing whether we can use the OpenMP target directives also to accelerate host-side loops.
samhatfield
force-pushed
the
host_side_gpu
branch
from
8c0cbee to
d594ac7
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR implements a "host backend" for the GPU code path. Essentially I have made some minor tweaks to the Fortran and implemented host-side C++ backends for the Fourier and Legendre transforms, using the existing LAPACK and FFTW functionality brought in by the CPU version.
Along the way I have tried to separate out "host OpenMP" and "accelerator OpenMP" functionalities into separate CMake features, as I didn't want to affect the CPU build when switching off OpenMP for the GPU (actually also running on CPU) build. When this PR is working we should properly scrutinise how all the various features and builds interact.
Right now the host GPU backend is not working numerically, hence why this is still a draft. I'm almost there though... see this screenshot of the transformed spherical harmonic used in the benchmark case:
It seems to be correct, except for some latitudes which have obvious error patterns. Really weird. Not sure what's going on there, but I will keep testing.