Hi Tobias!
On 2024-02-27T13:29:33+0100, Tobias Burnus <tbur...@baylibre.com> wrote:
> Thomas Schwinge:
>>> @table @asis
>>> @item @emph{Description}
>>> -This function allocates @var{len} bytes of device memory. It returns
>>> +This function allocates @var{bytes} of device memory. It returns
>> Not '@var{bytes} {+bytes+}' or similar?
>
> I think either works – depending how one parses @var{<name>} mentally,
> one of the variants sounds smooth and the other very odd. But I can/will
> change it.
Yeah, I see. Not the strongest argument ("upstream vs. local" style),
but I see that while OpenACC 3.3 doesn't for 'acc_malloc', it does, for
example, for 'acc_copyin' talk about "'bytes' bytes" (or, avoiding the
issue: "'bytes' specifies the data size in bytes").
>>> --- a/libgomp/openacc.f90
>>> +++ b/libgomp/openacc.f90
>> Assuming that 'module openacc_internal' currently is sorted per
>> appearance in the OpenACC specification (?), I suggest we continue to do
>> so. (..., like in 'openacc_lib.h', too.)
> I will check – it looks only block-wise sorted but I might be wrong.
OK, but please don't sink too much time into that.
> I
> followed location of the comments, placing it before the routines that
> followed the comment, assuming that the comments were at the right spot.
>>> @@ -794,6 +881,9 @@ module openacc
>>> ...
>>> + public :: acc_malloc, acc_free, acc_map_data, acc_unmap_data,
>>> acc_deviceptr
>>> + public :: acc_hostptr, acc_memcpy_to_device, acc_memcpy_to_device_async
>>> + public :: acc_memcpy_from_device, acc_memcpy_from_device_async
>>> ...
>>> - ! acc_malloc: Only available in C/C++
>>> - ! acc_free: Only available in C/C++
>>> -
>>> ...
>>> interface acc_is_present
>>> procedure :: acc_is_present_32_h
>>> procedure :: acc_is_present_64_h
>>> procedure :: acc_is_present_array_h
>>> end interface
>> Is that now a different style that we're not listing the new interfaces
>> in 'module openacc' here?
>
> As there is no precedent for this type of interface, the style is by
> nature differently. But the question is which style is better. The
> current 'openacc' is very short – and contains not a single specific
> interface, but only generic interfaces. The actual specific-procedure
> declarations are only in 'openacc_internal'.
>
> Those new procedures are the first ones that do not have a generic
> interface and only a specific one. Thus, one can either put the specific
> one into 'openacc_internal' and refer it from 'openacc' (via 'use
> openacc_internal' + 'public :: acc_<routine-name>') – or place the
> interface directly into 'openacc' (and not touching 'openacc_internal'
> at all).
>
> During development, I had a accidentally a mixture between both - and
> then settled for the current variant. – Possibly, moving the interface
> to 'openacc' is clearer?
>
> Thoughts?
No, sorry. As I said: "I don't know much about Fortran interfaces". :-|
>>> --- /dev/null
>>> +++ b/libgomp/testsuite/libgomp.fortran/acc_host_device_ptr.f90
>>> + ! The following assumes sizeof(void*) being the same on host and device:
>> That's generally required anyway.
>
> I have to admit that I don't know OpenACC well enough to see whether
> that's the case or not.
My thinking, "simply", is that this follows implicitly from the fact that
data layout has to match between host and device, and if pointers have
different sizes, that breaks?
For example, OpenACC 3.3, 2.6.4 "Data Structures with Pointers":
| [...]
| When a data object is copied to device memory, the values are copied exactly.
If the data is a data
| structure that includes a pointer, or is just a pointer, the pointer value
copied to device memory
| will be the host pointer value. [...]
> And, while I am not very consistent, I do try to
> document stricter requirements / implementation-specific parts in a
> testcases.
ACK, that's always good practice.
> I know that OpenMP permits that the pointer size differs
Oh, really!?
> and 'void *p =
> omp_target_alloc (...);' might in this case not return the device
> pointer but a handle to the device ptr. (For instance, it could be a
> pointer to an uint128_t variable for a 128bit device pointer; I think
> such a hardware exists in real - and uses several bits for other
> purposes like flags.)
I do see in OpenMP 5.2, 1.2.6 "Data Terminology":
| *device address* An address of an object that may be referenced on a _target
device_.
| *device pointer* An _implementation-defined handle_ that refers to a _device
address_.
..., and I'm now -- at least vaguely -- curious how OpenMP handles
different-sized pointers for host vs. device in host/device-shared data
layout. ("Fortunately" ;-) I have too many higher-priority items to look
after, so not able to spend more time on that questions...)
> In that case, host-side pointer arithmetic won't work and
> 'is_device_ptr' clauses etc. need to do transfer work.
>
> But, admittedly, in GCC there it is assumed at many places that both
> sides use the same pointer size* and also during specification
> development, everyone implicitly assumes that routines and clauses yield
> bare device pointers and not some opaque pointer to the actual data (a
> handle); hence, one has to keep remind oneself that the spec permits
> system where that's not the case.
> (* There are a few spots which handle a smaller device pointer than the
> host pointer or consider a different size but that's not done very
> consistently and largely lacking.)
Yeah, I guess.
Grüße
Thomas
