From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Christian_K=c3=b6nig?= Subject: Re: [PATCH 0/9] drm/syncobj: Add full-featured wait support (v2) Date: Wed, 16 Aug 2017 18:53:42 +0200 Message-ID: References: <1502232369-19753-1-git-send-email-jason.ekstrand@intel.com> <1502491174-10913-1-git-send-email-jason.ekstrand@intel.com> <15ddc33d250.277a.c6988b7ea6112e3e892765a0d4287e0c@jlekstrand.net> <676f6b65-0ab5-e69e-19a5-ebcebd6754a3@amd.com> <15ddde0c6d0.277a.c6988b7ea6112e3e892765a0d4287e0c@jlekstrand.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0818880593==" Return-path: Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0089.outbound.protection.outlook.com [104.47.41.89]) by gabe.freedesktop.org (Postfix) with ESMTPS id 438D66E0E2 for ; Wed, 16 Aug 2017 16:53:58 +0000 (UTC) In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Jason Ekstrand Cc: Jason Ekstrand , Dave Airlie , Maling list - DRI developers List-Id: dri-devel@lists.freedesktop.org This is a multi-part message in MIME format. --===============0818880593== Content-Type: multipart/alternative; boundary="------------8296E13787849B6B5C7BA238" Content-Language: en-US This is a multi-part message in MIME format. --------------8296E13787849B6B5C7BA238 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit > [SNIP] > > See a wait_queue is a callback mechanism anyway, so you are > wrapping a callback mechanism inside another callback > mechanism and that makes not really much sense. > > > Fair enough. There is one little snag though: We need to wait on > sync objects and fences at the same time in order for WAIT_ANY | > WAIT_FOR_SUBMIT to work. I see two options here: > > 1) Convert dma-fence to use waitqueue instead of its callback > mechanism and add a wait_queue_any. A quick grep for > dma_fence_add_callback says that this would affect four drivers. > > > The more I think about it, the less sense using waitqueues makes. The > fundamental problem here is that the event we are waiting on is > actually the concatenation of two events: submit and signal. Since we > are waiting on several of these pairs of concatenated events > simultaneously, the only two options we have are to either combine > them into one event (the proxy approach) or to implement a wait which > is capable of handling both at the same time. I don't see a way to do > the latter with wait queues. Agree completely. Essentially we would need to enable wait_event_* to wait for multiple events and then convert all the fence callback stuff to wait_event structures. But that is certainly outside the scope of this patchset, so feel free to go ahead with the approach of waiting manually (but please without the bugs). Well if you got a student/interim with free time that would certainly be a nice cleanup task to start on kernel work. Regards, Christian. --------------8296E13787849B6B5C7BA238 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
[SNIP]
See a wait_queue is a callback mechanism anyway, so you are wrapping a callback mechanism inside another callback mechanism and that makes not really much sense.

Fair enough.  There is one little snag though:  We need to wait on sync objects and fences at the same time in order for WAIT_ANY | WAIT_FOR_SUBMIT to work.  I see two options here:

 1) Convert dma-fence to use waitqueue instead of its callback mechanism and add a wait_queue_any.  A quick grep for dma_fence_add_callback says that this would affect four drivers.

The more I think about it, the less sense using waitqueues makes.  The fundamental problem here is that the event we are waiting on is actually the concatenation of two events: submit and signal.  Since we are waiting on several of these pairs of concatenated events simultaneously, the only two options we have are to either combine them into one event (the proxy approach) or to implement a wait which is capable of handling both at the same time.  I don't see a way to do the latter with wait queues.

Agree completely.

Essentially we would need to enable wait_event_* to wait for multiple events and then convert all the fence callback stuff to wait_event structures.

But that is certainly outside the scope of this patchset, so feel free to go ahead with the approach of waiting manually (but please without the bugs).

Well if you got a student/interim with free time that would certainly be a nice cleanup task to start on kernel work.

Regards,
Christian.
--------------8296E13787849B6B5C7BA238-- --===============0818880593== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0818880593==--