[PATCH libdrm 4/5] wrap syncobj timeline query/wait APIs for amdgpu v3

[Zhou, David(ChunMing)]

> -----Original Message-----
> From: Christian König <ckoenig.leichtzumerken at gmail.com>
> Sent: Friday, November 30, 2018 5:15 PM
> To: Zhou, David(ChunMing) <David1.Zhou at amd.com>; dri-
> devel at lists.freedesktop.org; amd-gfx at lists.freedesktop.org
> Subject: Re: [PATCH libdrm 4/5] wrap syncobj timeline query/wait APIs for
> amdgpu v3
> 
[snip]
> >> +drm_public int amdgpu_cs_syncobj_query(amdgpu_device_handle dev,
> >> +                       uint32_t *handles, uint64_t *points,
> > This interfaces is public to umd, I think they like "uint64_t
> > **points" for batch query, I've verified before, it works well and
> > more convenience.
> > If removing num_handles, that means only one syncobj to query, I agree
> > with "uint64_t *point".
> 
> "handles" as well as "points" are an array of objects. If the UMD wants to
> write the points to separate locations it can do so manually after calling the
> function.

Ok, it doesn't matter.

-David
> 
> It doesn't make any sense that libdrm or the kernel does the extra
> indirection, the transferred pointers are 64bit as well (even on a 32bit
> system) so the overhead is identical.
> 
> Adding another indirection just makes the implementation unnecessary
> complex.


> 
> Christian.
> 
> >
> > -David
> >> +                       unsigned num_handles) {
> >> +    if (NULL == dev)
> >> +        return -EINVAL;
> >> +
> >> +    return drmSyncobjQuery(dev->fd, handles, points, num_handles); }
> >> +
> >>   drm_public int amdgpu_cs_export_syncobj(amdgpu_device_handle dev,
> >>                       uint32_t handle,
> >>                       int *shared_fd)
> >