> I do wonder if we need the separate sem signal/wait interface, I think > we should just add > semaphore chunks to the CS interface. Yeah, that's what I've said as well from the very first beginning. Another question is if we should really create another implementation to share semaphores between processes. In other words putting the current fences inside the semaphore into a sync_file with the signal_on_any bit set would have pretty much the same effect, except that the resulting object then had the sync_file semantics for adding new fences and can be used in the atomic IOCTLs as well. Regards, Christian. Am 09.03.2017 um 08:00 schrieb zhoucm1: > Hi Dave, > > We have already completed implementation as the attached for both > kernel and libdrm. We discuss it on top of this. > > > Thanks, > David Zhou > > On 2017å¹´03æ??09æ?¥ 12:24, Dave Airlie wrote: >> I've attached two patches for RFC at the moment, I haven't finished >> the userspace for these yet, but just wanted to get some >> ideas/feedback. >> >> Dave. >> >> On 9 March 2017 at 13:52, Dave Airlie <airlied at gmail.com> wrote: >>> On 28 February 2017 at 11:46, zhoucm1 <david1.zhou at amd.com> wrote: >>>> Hi Dave, >>>> >>>> The attached is our semaphore implementation, amdgpu_cs.c is drm >>>> file, the >>>> others are kernel file. >>>> Any suggestion? >>> Thanks, >>> >>> I've built a tree with all these in it, and started looking into the >>> interface. >>> >>> I do wonder if we need the separate sem signal/wait interface, I think >>> we should just add >>> semaphore chunks to the CS interface. >>> >>> I'm just playing around with this now. >>> >>> Dave. >
