-
Notifications
You must be signed in to change notification settings - Fork 4
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
Backend structure #7
Conversation
3e9a7d9
to
67723b6
Compare
So as of now with the latest commit, the cuda backend that extends base backend also compiles (however extremely simplified and basically does nothing inside). Also, we have a time integrator that executes the algorithm within its subroutine called 'run'. All this is managed in the main file xcompact.f90, which is ultimately used for creating an executable. The issue I noticed at this level is that our allocator is not advanced enough to deal with different nx, ny, nz. To fix this I need to introduce a simple functionality in the allocator using the 'bounds remapping' introduced in fortran 2003. I have already used this 'bounds remapping' technique with the nvidia compiler and gfortran and haven't got any issues. |
4516a0a
to
0f9177b
Compare
I fixed the issue I mentioned on Monday about kernels not being executed. Now the transport equation runs in the backend structure. Next few days I'll work on separating a solver class from backend class and then the PR be ready to merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good overall. Just had a handful of very minor comments.
subroutine set_pprev_pnext(xprev, xnext, yprev, ynext, zprev, znext, & | ||
xnproc, ynproc, znproc, nrank) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure how you want to go about tests, but this function would be well suited to have one as it is easy to make a typo with sign/variables and it is isolated from the rest of the codebase.
src/xcompact.f90
Outdated
! GPU only | ||
!allocate(cuda_allocator_t :: allocator) | ||
!allocate(cuda_backend_t :: backend) | ||
|
||
!cuda_backend = cuda_backend_t(allocator, xdirps, ydirps, zdirps) | ||
|
||
!allocator = cuda_allocator_t([SZ, 512, 512*512/SZ]) | ||
!backend = cuda_backend_t(allocator, xdirps, ydirps, zdirps) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this be removed? as I understand there shouldn't be any implementation specifics calls in this part of the code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to make the main file a bit more elaborate so that it can handle both backends. The problem is if you're not on a GPU cluster you probably don't have the NVIDIA compiler and then all the CUDA Fortran extentions NVIDIA compiler supports are not recognized by standard Fortran compilers. Our Cmake file compiles the cuda backend only when the compiler is NVIDIA compiler. Other times cuda backend is not even compiled and I think we'll need to use 'ifdef' stuff just in a few places in the main file to sort this out.
First commit to showcase the backend structure in the new framework. It's possible that this won't compile, but it demonstrates the main idea.Subsequent commits added a lot of functionality to the codebase and we can run the transport equation on the CUDA backend now.