Am 24.08.2016 um 12:01 schrieb zhoucm1: > > > On 2016å¹´08æ??24æ?¥ 17:39, Christian König wrote: >> Am 24.08.2016 um 11:33 schrieb zhoucm1: >>> >>> >>> On 2016å¹´08æ??18æ?¥ 16:15, Christian König wrote: >>>> NAK to the whole approach. >>>> >>>> If we want to share dependencies in the form of fences between >>>> devices and especially processes we must use android fences and the >>>> sync file framework. >>> Then if we want to share semaphore between devices and processes, we >>> must re-implement semaphore and move it to kernel side from libdrm, >>> right? >>> then bind unused fd to semaphore object, and then export/import fd. >>> What do you think of it? >> >> That is basically what sync_file does. It just doesn't call it >> semaphore and doesn't use the signal/wait semantic. >> >> Instead fences can be added to a sync_file and waited for completion >> before a command submission is made. > I understand your mean, UMD don't want to touch command submission to > semaphore, which isn't what semaphore want to do. > semaphore does: > 1. create a semaphore > 2. signal semahore----append the last fence of that ctx to semaphore > in lidrm > 3. wait semaphore----add semaphore to ctx->semaphore_list in libdrm, > when next submission is comming, then semaphore will be dependency of it. > 4. destroy semaphore. > the umd totally doesn't know what semaphore does, they just know the > synchronization is completed after semaphore, then they can continue > to do cs. > > sync_file seems cannot provide what semaphore does. So with thinking > more, we seems have to move semaphore implementation to kernel, use > unused fd and install it to fd like sync file mechanism to share > semaphore between devices and processes, right? No, as far as I can see sync_file does exactly the same thing as semaphores in libdrm, they just use a fd as handle. E.g. same concept, but different name and slightly different approaches of handling things (actually much saner ones, cause sync_file can't deadlock). Regards, Christian. > > > Regards, > David Zhou >> >> Regards, >> Christian. >> >>> >>> Regards, >>> David Zhou >>>> >>>> Sharing numbers in the form of the IDR is a security nightmare we >>>> already ran into with the GEM flink design. >>>> >>>> Regards, >>>> Christian. >>>> >>>> Am 18.08.2016 um 09:50 schrieb Chunming Zhou: >>>>> If we want to share semaphore/dependency across process across >>>>> device, we >>>>> must make ctx id be global, so that we can index it everywhere. >>>>> >>>>> Chunming Zhou (6): >>>>> drm/amdgpu: use global ctx mgr instead of vm specified >>>>> drm/amdgpu: clean up for amdgpu ctx >>>>> drm/amdgpu: allocate progressively higher ids for ctx until idr >>>>> counter wraps >>>>> drm/amdgpu: ctx id should be removed when ctx is freed >>>>> drm/amdgpu: use fence-array for ctx release >>>>> drm/amdgpu: dependency is already signaled if ctx has been freed >>>>> >>>>> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 17 ++-- >>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 9 +- >>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 142 >>>>> ++++++++++++++++++-------------- >>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 + >>>>> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4 - >>>>> 5 files changed, 92 insertions(+), 83 deletions(-) >>>>> >>>> >>> >> >
