Andrew Stubbs wrote:
For dev == omp_initial_device (on a Linux host):
* default device == an nvidia device
→ managed memory is used (honoring the alignment)
* default device != nvidia device (e.g. the host)
→ fall back is used → ABORT
(with default_fb, 'malloc' would be used but
without the 265-bit alignment).
For dev == any non-host device
* default mem space is used ('malloc'), honoring
the alignment.
Well, that wasn't intentional. I see the default definition of the
MEMSPACE_ALLOC macros was the problem, so I've updated those, along
with the other backend routines.
I've now coded in the logic that non-standard "ompx_gnu" memory spaces
don't have a silent fall-back-to-malloc if they're not available. I
think there's an expectation that the standard-defined memory spaces
are always available (if not actually distinct), but we don't need any
such expectation for the ompx_gnu ones (of which
ompx_gnu_managed_mem_space is the first).
This can be adjusted in future, if needed, of course, but is probably
a good default for new examples of such memspaces.
Yes, it make more sense like that.
My v5 patch is attached.
OK now?
LGTM.
Thanks for the patch!
Tobias
