Mhm, with that design there is only a minor difference any more to the sync_file implementation. Guys, what about the idea to change the behavior of the sync_file implementation with a flag so that it matches what Vulkan expect? As far as I can see the only difference is that when you can have a Vulkan semaphore object which isn't signaled, but at the moment you can't have a sync_file without any fence in it. Regards, Christian. Am 02.12.2016 um 02:41 schrieb zhoucm1: > Thanks Dave, got your suggestion. > > Regards, > David Zhou > > On 2016å¹´12æ??02æ?¥ 03:44, Dave Airlie wrote: >> Hi David, >> >> Some one major review suggestion, don't use file descriptors for >> semaphore, as fd's are a limited resource and we don't want to use >> them all up. >> >> You create semaphore objects and use them in a single process without >> them being fds, then when userspace wants to share with another >> process >> you convert the semaphore object to an fd, pass it to the other >> process and have it convert it back into a semaphore object. >> >> Dave. >> >> On 1 December 2016 at 16:11, zhoucm1 <david1.zhou at amd.com> wrote: >>> Hi Dave, >>> >>> As the attached, our Vulkan team is verifying it. >>> >>> Thanks, >>> David Zhou >>> >>> >>> On 2016å¹´12æ??01æ?¥ 13:44, Dave Airlie wrote: >>> >>> On 1 Dec. 2016 15:22, "zhoucm1" <david1.zhou at amd.com> wrote: >>>> Yes, the old implementation which is already in upstream libdrm is >>>> out of >>>> data, there isn't other user, so we want to drop it when new >>>> semaphore is >>>> verified OK. >>> Could you post some patches for the new one? Otherwise I'll have to >>> write >>> one for radv. >>> >>> Dave. >>>> Thanks, >>>> David Zhou >>>> >>>> >>>> On 2016å¹´12æ??01æ?¥ 10:36, Mao, David wrote: >>>>> Hi Dave, >>>>> i believe your first attempt is correct. >>>>> The export/import semaphore needs refine of the semaphore >>>>> implementation. >>>>> We are working on that. >>>>> >>>>> Thanks. >>>>> Best Regards, >>>>> David >>>>>> On 1 Dec 2016, at 10:12 AM, Dave Airlie <airlied at gmail.com> wrote: >>>>>> >>>>>> Hey all, >>>>>> >>>>>> So I've started adding semaphore support to radv but I'm not really >>>>>> sure what the API to the semaphore code is. >>>>>> >>>>>> the Vulkan API is you get a command submission of a number of submit >>>>>> units which have a 0-n wait semaphore, 0-n command buffers and 0-n >>>>>> signal semaphores. >>>>>> >>>>>> Now I'm not sure how I should use the APIs with those. >>>>>> >>>>>> My first attempt is >>>>>> >>>>>> call amdgpu_cs_wait_semaphore on all the wait ones, call the cs >>>>>> submit >>>>>> API, then call the amdgpu_cs_signal_semaphore on all the signal >>>>>> ones? >>>>>> >>>>>> or should I be up front calling wait/signal then submitting the >>>>>> command >>>>>> streams? >>>>>> >>>>>> Also upcoming work requires possibly sharing semaphores between >>>>>> processes, is there any indication how this might be made work with >>>>>> the libdrm_amdgpu semaphore implementation? >>>>>> >>>>>> Thanks, >>>>>> Dave. >>>>>> _______________________________________________ >>>>>> amd-gfx mailing list >>>>>> amd-gfx at lists.freedesktop.org >>>>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx >>>>> _______________________________________________ >>>>> amd-gfx mailing list >>>>> amd-gfx at lists.freedesktop.org >>>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx >>>> >>> > > _______________________________________________ > amd-gfx mailing list > amd-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
