[ur] Introduce virtual memory interfaces #525
Conversation
kbenzie
force-pushed
the
benie/virtual-memory
branch
from
98b7eea
to
36e04ce
Compare
kbenzie
force-pushed
the
benie/virtual-memory
branch
from
36e04ce
to
ca88f3d
Compare
|
The question just raised in my mind: For USM we are using Unified Memory Allocation Framework to organize pooling. In the future, we are considering this pooling framework as a common point for all allocations to improve interop with other runtimes. For example, MPI can benefit from it by using our pooling framework to get info about where memory (pointed by virtual address) resides. |
|
@vinser52 while porting the PI changes over to UR I was pondering how this might be more tightly integrated into the USM interfaces. I did wonder if it would be possible to use USM allocations as the backing for the virtual memory reservations but I think there are some complications with the need to track the adapter specific state lifetimes (e.g Would it make sense for ownership of adapter specific handles to be managed in a Then maybe we could be to include a I'm really not sure if this is feasible though, our hands are somewhat tied due to the CUDA interfaces. I'd like to hear @steffenlarsen's thoughts on this. |
kbenzie
force-pushed
the
benie/virtual-memory
branch
from
ca88f3d
to
7aa0462
Compare
|
I share @kbenzie's concern regarding this idea, given the relation between this and the CUDA interfaces. I am not sure we can always make the association at reservation time either, as I don't believe there is any guarantee about USM-like behavior of the reserved pointer until it is mapped to the physical memory. |
kbenzie
force-pushed
the
benie/virtual-memory
branch
2 times, most recently
from
59455ab
to
effd833
Compare
|
LGTM, I don't have any good idea for integrating that with the USM interfaces for now. We'll need to think about how to best expose UMF memory providers from UR - then we could implement the memory reservation using UMF providers and make them discoverable |
Fixes oneapi-src#357 by introducing a port of the PI changes from intel/llvm#8954 which add the ability to reserve virtual memory regions separately from physical memory backing allocations. * [x] Define interfaces in the spec & header * [ ] Add conformance tests exercising interfaces - tracked in oneapi-src#525
kbenzie
force-pushed
the
benie/virtual-memory
branch
from
effd833
to
e4b9735
Compare
| ############################################################################### | ||
| ## @brief Virtual memory access mode flags. | ||
| class ur_virtual_mem_access_flags_v(IntEnum): | ||
| READ_WRITE = UR_BIT(0) ## Virtual memory both read and write accessible |
There was a problem hiding this comment.
Sorry for the late reaction to this, but I just realized that we are losing the ability to set the access mode to "none" here by defining READ_WRITE as 0. CUDA considers an access mode of 0 as revoking access. @kbenzie - Could we either have a NONE value here or offset the existing ones?
There was a problem hiding this comment.
Missed that! Yeah, I'll add none.
There was a problem hiding this comment.
#638 will fix this.
Address [feedback](oneapi-src#525 (comment)) and add `UR_VIRTUAL_MEM_ACCESS_FLAG_NONE` to allow specifying a 0 value for the access flags.
Address [feedback](oneapi-src#525 (comment)) and add `UR_VIRTUAL_MEM_ACCESS_FLAG_NONE` to allow specifying a 0 value for the access flags.
Address [feedback](oneapi-src#525 (comment)) and add `UR_VIRTUAL_MEM_ACCESS_FLAG_NONE` to allow specifying no access.
|
@kbenzie - Sorry for the (very) late realization, but I cannot find any analogue for |
Fixes #357 by introducing a port of the PI changes from intel/llvm#8954
which add the ability to reserve virtual memory regions separately from
physical memory backing allocations.