On 2017年09月12日 19:00, Christian König wrote:
NAK for the CS part (but I think that was just as prove of concept
anyway).
Dave's sync object implementation is already done for this, the
problem is that isn't merged yet into amd-staging-4.12 (but should be
in 4-13).
Yeah, I already realized it before, if only vm part, I agree syncobj can
satisfy the synchronization between SDMA and other engine.
But from your old dependency perspective, we also should cover
wait_ioctl and wait_any/all_ioctl, which should also can wait fence from
syncfile, so it makes sense that cs_ioctl and va_ioctl return syncfile
fd to UMD.
Compared with only retuning fence seq number, UMD can be convenience to
pass fd to any where it needs to sync and as dependency or to semaphore,
and they don't need to construct ip_type/ip_instance/ctx_id/ring any
more, even the caching fences in ctx becomes no meanless if don't
consider compatibility.
Regards,
David Zhou
The VM part looks similar to what I had in mind, but we should base
this on Dave's sync_obj stuff as well.
Regards,
Christian.
Am 12.09.2017 um 12:23 schrieb Chunming Zhou:
*** BLURB HERE ***
Chunming Zhou (5):
drm/amdgpu: introduce sync file for CS returning fence
drm/amdgpu: add syncfile chunk support
drm/amdgpu: add syncfile support to wait ioctl
drm/amdgpu: add syncfile fence support to wait_any/all ioctl
drm/amdgpu: expand mapping ioctl to return fence to UMD by using
syncfile
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 90
++++++++++++++++++++++++---------
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 24 +++++++--
include/uapi/drm/amdgpu_drm.h | 13 ++++-
3 files changed, 96 insertions(+), 31 deletions(-)
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
