| commit | 726a885cae86bd7598f9abdbccce02948435ed2f | |
| author | Szilard Pall <pall.szilard@gmail.com> | |
| Fri, 4 Oct 2013 00:01:44 +0000 (4 02:01 +0200) | ||
| committer | Berk Hess <hess@kth.se> | |
| Wed, 6 Nov 2013 09:59:40 +0000 (6 10:59 +0100) | ||
| tree | 6b3a33c585e26a3a54cc447ddde04d77d88c1c3e | treesnapshot (tar.gz zip) |
| parent | 823410572cc32505541f72ce7801d7dc31fe9f3f | commitdiff |
enable GPU sharing among tMPI ranks
It turns out that the only issue preventing sharing GPUs among thread-MPI
threads was that when the thread arriving to free_gpu() first destroys
the context, it is highly likely that the other thread(s) sharing a GPU
with this are still freeing their resources - operation which fails as
soon as the context is destroyed by the "fast" thread.
Simply placing a barrier between the GPU resource freeing and context
destruction solves the issue. However, there is still a very unlikely
concurrency hazard after CUDA texture reference updates (non-bonded
parameter table and coulomb force table initialization). To be on the
safe side, with tMPI a barrier is placed after these operations.
Change-Id: Iac7a39f841ca31a32ab979ee0012cfc18a811d76
It turns out that the only issue preventing sharing GPUs among thread-MPI
threads was that when the thread arriving to free_gpu() first destroys
the context, it is highly likely that the other thread(s) sharing a GPU
with this are still freeing their resources - operation which fails as
soon as the context is destroyed by the "fast" thread.
Simply placing a barrier between the GPU resource freeing and context
destruction solves the issue. However, there is still a very unlikely
concurrency hazard after CUDA texture reference updates (non-bonded
parameter table and coulomb force table initialization). To be on the
safe side, with tMPI a barrier is placed after these operations.
Change-Id: Iac7a39f841ca31a32ab979ee0012cfc18a811d76