[PATCH 02/11] dma-buf: add new dma_fence_chain container v4

[Koenig, Christian]

Am 15.02.19 um 19:16 schrieb Jason Ekstrand:
On Fri, Feb 15, 2019 at 11:51 AM Christian König <ckoenig.leichtzumerken at gmail.com<mailto:ckoenig.leichtzumerken at gmail.com>> wrote:
Am 15.02.19 um 17:49 schrieb Jason Ekstrand:
On Fri, Feb 15, 2019 at 9:52 AM Lionel Landwerlin via dri-devel <dri-devel at lists.freedesktop.org<mailto:dri-devel at lists.freedesktop.org>> wrote:
On 15/02/2019 14:32, Koenig, Christian wrote:
> Am 15.02.19 um 15:23 schrieb Lionel Landwerlin:
>> Hi Christian, David,
>>
>> For timeline semaphore we need points to signaled in order.
>> I'm struggling to understand how this fence-chain implementation
>> preserves ordering of the seqnos.
>>
>> One of the scenario I can see an issue happening is when you have a
>> timeline with points 1 & 2 and userspace submits for 2 different
>> engines :
>>      - first with let's say a blitter style engine on point 2
>>      - then a 3d style engine on point 1
> Yeah, and where exactly is the problem?
>
> Seqno 1 will signal when the 3d style engine finishes work.
>
> And seqno 2 will signal when both seqno 1 is signaled and the blitter
> style engine has finished its work.

That's an interesting interpretation of the spec.  I think it's legal and I could see that behavior may be desirable in some ways.

Well we actually had this discussion multiple times now, both internally as well as on the mailing list. Please also see the previous mails with Daniel on this topic.

I dug through dri-devel and read everything I could find with a search for "timeline semaphore"  I didn't find all that much but this did come up once.

Need to dig through my mails as well, that was back in November/December last year.


My initial suggestion was actually to exactly what Leonid suggested as well.

And following this I used a rather simple container for the implementation, e.g. just a ring buffer indexed by the sequence number. In this scenario userspace can specify on syncobj creation time how big the window for sequence numbers should be, e.g. in this implementation how big the ring buffer would be.

This was rejected by our guys who actually wrote a good part of the Vulkan specification. Daniel then has gone into the same direction during the public discussion.

I agree with whoever said that specifying a ringbuffer size is unacceptable.  I'm not really sure how that's relevant though.  Is a ringbuffer required to implement the behavior that is being suggested here?  Genuine question; I'm trying to get back up to speed.

Using a ring buffer was just an example how we could do it if we follow my and Lionel's suggestion.

Key point is that we could simplify the implementation massively if sequence numbers don't need to depend on each other.

In other words we just see the syncobj as container where fences are added and retrieved from instead of something actively involved in the signaling.

Main reason we didn't do it this way is because the AMD Vulkan team has rejected this approach.

Additional to that chaining sequence numbers together is really the more defensive approach, e.g. it is less likely that applications can shoot themselves in the foot.


 4. If you do get into a sticky situation, you can unblock an entire timeline by using the CPU signal ioctl to set it to a high value.

Well I think that this could be problematic as well. Keep in mind that main use case for this is sharing timelines between processes.

In other words you don't want applications to be able to mess with it to much.

Cross-process is exactly why you want it.  Suppose you're a compositor and you have a timeline shared with another application and you've submitted work which waits on it.  Then you get a notification somehow (SIGHUP?) that the client has died leaving you hanging.  What do you do?  You take the semaphore that's shared with you and the client and whack it to UINT64_MAX to unblock yourself.  Of course, this can be abused and that's always the risk you take with timelines.

My last status is that basically everybody agrees now that wait before signal in the kernel is forbidden.

So when you get a SIGHUB because your client is dead you just kill your thread waiting on it.

Regards,
Christian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20190215/5b951d92/attachment-0001.html>