Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

On Fri, Sep 29, 2017 at 1:42 AM, Dave Airlie wrote: > On 29 September 2017 at 06:41, Marek Olšák wrote: >> Can I get Rb for this series? >> > > For the series, > > Reviewed-by: Dave Airlie > > Alex, please merge the two drm core precursor

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

On 29 September 2017 at 06:41, Marek Olšák wrote: > Can I get Rb for this series? > For the series, Reviewed-by: Dave Airlie Alex, please merge the two drm core precursor with patch 3. Dave. ___ amd-gfx mailing

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

Can I get Rb for this series? Thanks, Marek On Tue, Sep 12, 2017 at 10:42 PM, Marek Olšák wrote: > From: Marek Olšák > > for being able to convert an amdgpu fence into one of the handles. > Mesa will use this. > > Signed-off-by: Marek Olšák

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

On 2017年09月14日 10:33, Dave Airlie wrote: But think a bit more, if not by default, that isn't meaningful, we can continue to use seq_no base fence and Marek's syncfile fd approach. At least for radv I've no interest in every CS ioctl returning an fd that I have to close. OK, let's pend it

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

> > But think a bit more, if not by default, that isn't meaningful, we can > continue to use seq_no base fence and Marek's syncfile fd approach. > At least for radv I've no interest in every CS ioctl returning an fd that I have to close. Dave. ___

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

On 2017年09月14日 10:07, zhoucm1 wrote: On 2017年09月14日 09:52, Dave Airlie wrote: On 14 September 2017 at 00:16, Christian König wrote: Am 13.09.2017 um 16:06 schrieb Marek Olšák: On Wed, Sep 13, 2017 at 3:46 PM, Zhou, David(ChunMing) wrote: For

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

On 2017年09月14日 09:52, Dave Airlie wrote: On 14 September 2017 at 00:16, Christian König wrote: Am 13.09.2017 um 16:06 schrieb Marek Olšák: On Wed, Sep 13, 2017 at 3:46 PM, Zhou, David(ChunMing) wrote: For android using mesa instance, egl draw

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

On 14 September 2017 at 00:16, Christian König wrote: > Am 13.09.2017 um 16:06 schrieb Marek Olšák: >> >> On Wed, Sep 13, 2017 at 3:46 PM, Zhou, David(ChunMing) >> wrote: >>> >>> For android using mesa instance, egl draw will dequeue an android

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

Am 13.09.2017 um 16:06 schrieb Marek Olšák: On Wed, Sep 13, 2017 at 3:46 PM, Zhou, David(ChunMing) wrote: For android using mesa instance, egl draw will dequeue an android buffer, after egl draw, the buffer will back to android bufffer queue, but need append a syncfile fd.

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

On Wed, Sep 13, 2017 at 3:46 PM, Zhou, David(ChunMing) wrote: > For android using mesa instance, egl draw will dequeue an android buffer, > after egl draw, the buffer will back to android bufffer queue, but need > append a syncfile fd. If getting syncfile fd for every egl

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

For android using mesa instance, egl draw will dequeue an android buffer, after egl draw, the buffer will back to android bufffer queue, but need append a syncfile fd. If getting syncfile fd for every egl draw always needs several syncobj ioctls, the io overhead isn't small. But if we directly

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

syncfile indeed be a good way to pass fence for user space, which already is proved in Android and is upstreamed. Not really. syncfile needs a file descriptor for each handle it generates, that's quite a show stopper if you want to use it in general. Android syncfile are meant to be used for

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

Yes, to be comptibility, I kept both seq_no and syncfile fd in the patch set, you can take a look, which really is simpler and effective way. syncfile indeed be a good way to pass fence for user space, which already is proved in Android and is upstreamed. Regards, David Zhou 发自坚果 Pro Marek

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

On Wed, Sep 13, 2017 at 1:32 PM, Zhou, David(ChunMing) wrote: > Could you describe how difficult to directly use CS syncfile fd in Mesa > compared with concerting CS seq to syncfile fd via several syncobj ioctls? It just simplifies things. Mesa primarily uses seq_no-based

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

Could you describe how difficult to directly use CS syncfile fd in Mesa compared with concerting CS seq to syncfile fd via several syncobj ioctls? Regards, David Zhou 发自坚果 Pro Marek Ol?醟 于 2017年9月13日 下午6:11写道： On Wed, Sep 13, 2017 at 5:03 AM, zhoucm1

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

On Wed, Sep 13, 2017 at 5:03 AM, zhoucm1 wrote: > Hi Marek, > > You're doing same things with me, see my "introduce syncfile as fence > reuturn" patch set, which makes things more simple, we just need to directly > return syncfile fd to UMD when CS, then the fence UMD get

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

On 2017年09月13日 16:07, Christian König wrote: Am 13.09.2017 um 09:39 schrieb zhoucm1: On 2017年09月13日 15:09, Christian König wrote: syncfile is the older implementation, sync_obj is the replacement for it. Are you sure sync_obj is a replacement for syncfile? Anyone can clarify it?

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

Am 13.09.2017 um 09:39 schrieb zhoucm1: On 2017年09月13日 15:09, Christian König wrote: syncfile is the older implementation, sync_obj is the replacement for it. Are you sure sync_obj is a replacement for syncfile? Anyone can clarify it? sync_obj is mainly for semaphore usage, we can see

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

On 2017年09月13日 15:09, Christian König wrote: syncfile is the older implementation, sync_obj is the replacement for it. Are you sure sync_obj is a replacement for syncfile? Anyone can clarify it? sync_obj is mainly for semaphore usage, we can see sync_obj docs from Dave in drm_syncobj.c:

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

syncfile is the older implementation, sync_obj is the replacement for it. I don't think we should implement syncfile in the CS any more, sync_obj is already done and can be converted to/from syncfiles. Mareks IOCTL should cover the case when we need to create a syncfile or syncobj from a

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

I really very surprise that you prefer to expand sync_obj to get syncfile fd!!! Why not directly generate syncfile fd and use it? Which one is simple is so obvious. Regards, David Zhou On 2017年09月13日 14:57, Christian König wrote: Hi guys, Mareks IOCTL proposal looks really good to me.

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

Hi guys, Mareks IOCTL proposal looks really good to me. Please note that we already have sync_obj support for the CS IOCTL in the 4.13 branch and this work is based on top of that. UMD don't need to construct ip_type/ip_instance/ctx_id/ring Well the UMD does want to construct

Re: [PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

Hi Marek, You're doing same things with me, see my "introduce syncfile as fence reuturn" patch set, which makes things more simple, we just need to directly return syncfile fd to UMD when CS, then the fence UMD get will be always syncfile fd, UMD don't need to construct

[PATCH 3/3] drm/amdgpu: add FENCE_TO_HANDLE ioctl that returns syncobj or sync_file

From: Marek Olšák for being able to convert an amdgpu fence into one of the handles. Mesa will use this. Signed-off-by: Marek Olšák --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 61