Skip to content
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

Potential misuse of host_allocator #97

Open
semi-h opened this issue May 22, 2024 · 0 comments
Open

Potential misuse of host_allocator #97

semi-h opened this issue May 22, 2024 · 0 comments

Comments

@semi-h
Copy link
Member

semi-h commented May 22, 2024

#89 introduced a host_allocator concept. It is a way to make sure that we can get a field that lives in host memory when we need. Currently, its used for setting the initial conditions, but I anticipate it'll soon be used for other purposes too.

The open matter on this is that one can accidentally mix and use get_block and release_block from backend%allocator and solver%host_allocator. In OpenMP backend this won't cause any immediate issues, because both allocators point to the same object, but this isn't the case in CUDA backend.

So lets discuss the best strategy to prevent such misuses if we can.

One thing I tried was having field pointers a type type(field_t) instead of class(field_t) so that a get_field from CUDA allocator will raise an error, it was okay with nvfortran but the gcc compiler didn't like this.

One thing I have in mind is implementing a get_host_field function in allocator, and using this instead with host_allocator. But this can still cause problems when we test things on OpenMP and try to run on CUDA. In the meeting we had a few recommendations but I'm not sure if I understand these, so could you explain here please?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant