This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [gomp4.1 WIP] omp_target_* libgomp APIs
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Ilya Verbin <iverbin at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Kirill Yukhin <kirill dot yukhin at gmail dot com>
- Date: Mon, 13 Jul 2015 17:26:43 +0200
- Subject: Re: [gomp4.1 WIP] omp_target_* libgomp APIs
- Authentication-results: sourceware.org; auth=none
- References: <20150709140657 dot GR10247 at tucnak dot redhat dot com> <20150713131729 dot GP1788 at tucnak dot redhat dot com> <20150713133833 dot GA56059 at msticlxl57 dot ims dot intel dot com> <20150713140306 dot GR1788 at tucnak dot redhat dot com> <20150713151545 dot GD56059 at msticlxl57 dot ims dot intel dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Mon, Jul 13, 2015 at 06:15:45PM +0300, Ilya Verbin wrote:
> On Mon, Jul 13, 2015 at 16:03:06 +0200, Jakub Jelinek wrote:
> > On Mon, Jul 13, 2015 at 04:38:33PM +0300, Ilya Verbin wrote:
> > > On Mon, Jul 13, 2015 at 15:17:29 +0200, Jakub Jelinek wrote:
> > > > + k->refcount = INT_MAX;
> > >
> > > Shouldn't it be UINTPTR_MAX?
> >
> > Dunno if we can count on it being in stdint.h on all targets.
> > Perhaps
> > #define REFCOUNT_INFINITY (~(uintptr_t) 0)
> > ?
>
> Probably, I don't know.
Ok, I'll change this later.
>
> > > > + /* FIXME: Support device-to-device somehow? */
> > >
> > > Should libgomp copy data device-host-device if device-device is not supported by
> > > target? Current liboffloadmic doesn't support this. I'll find out if there are
> > > any plans.
> >
> > There is also the option to spawn an offloaded function that will just call
> > memcpy, or have such a function next to the main () of the program that we link
> > in.
>
> Do you mean the case when src_devicep == dst_devicep ? It's easy to support
> this by adding new func into plugin, whithout any changes in liboffloadmic.
> I thought about memcpy between different devices...
Well, even src_devicep == dst_devicep does not guarantee it is the same
device, that is the case only if also src_devicep->target_id ==
dst_devicep->target_id, right?
I wouldn't worry about that and just return EINVAL when copying in between
different devices.
> > Also, could you see if the 2 and 3 dimension memcpy_rect couldn't be handled
> > more efficiently by liboffloadmic too?
> > From what I can see, on the cuda side there is some cudaMemcpy2D and
> > cudaMemcpy3D, though I admit I haven't studied in detail what exactly they
> > do.
>
> I'll try to find out.
Thanks. I haven't looked exactly how the copying is implemented, but if it
is done by sending some control info plus (for copying to device) the data
itself, and for copying from device reading the data back, then if
the control data could be extended to pass in the device 2D or 3D
slice/offset/volume info and you could readv or writev the data...
Jakub