From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757824AbaGWKNR (ORCPT ); Wed, 23 Jul 2014 06:13:17 -0400 Received: from mail-by2lp0240.outbound.protection.outlook.com ([207.46.163.240]:52248 "EHLO na01-by2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1757588AbaGWKNP convert rfc822-to-8bit (ORCPT ); Wed, 23 Jul 2014 06:13:15 -0400 X-WSS-ID: 0N95TPW-08-3RR-02 X-M-MSG: Message-ID: <53CF8AB1.2000009@amd.com> Date: Wed, 23 Jul 2014 12:13:05 +0200 From: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Maarten Lankhorst , =?UTF-8?B?Q2hyaXM=?= =?UTF-8?B?dGlhbiBLw7ZuaWc=?= , Daniel Vetter CC: Thomas Hellstrom , nouveau , LKML , dri-devel , Ben Skeggs , "Deucher, Alexander" Subject: Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences References: <20140709093124.11354.3774.stgit@patser> <53CE8A57.2000803@vodafone.de> <53CF58FB.8070609@canonical.com> <53CF5B9F.1050800@amd.com> <53CF5EFE.6070307@canonical.com> <53CF63C2.7070407@vodafone.de> <53CF6622.6060803@amd.com> <53CF699D.9070902@canonical.com> <53CF6B18.5070107@vodafone.de> <53CF7035.2060808@amd.com> <53CF7191.2090008@canonical.com> <53CF765E.7020802@vodafone.de> <53CF8010.9060809@amd.com> <53CF822E.7050601@amd.com> <53CF84C7.2020507@vodafone.de> <53CF8693.1040006@canonical.com > In-Reply-To: <53CF8693.1040006@canonical.com> Content-Type: text/plain; charset="UTF-8"; format=flowed X-Originating-IP: [10.224.155.198] Content-Transfer-Encoding: 8BIT X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:165.204.84.222;CTRY:US;IPV:NLI;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(6009001)(428002)(51704005)(377454003)(199002)(24454002)(189002)(377424004)(44976005)(93886003)(85852003)(33656002)(101416001)(31966008)(47776003)(46102001)(84676001)(80022001)(86362001)(64126003)(76176999)(102836001)(79102001)(99396002)(68736004)(20776003)(74502001)(85306003)(50986999)(81542001)(85202003)(77982001)(92726001)(81342001)(19580395003)(106466001)(87936001)(76482001)(74662001)(80316001)(65816999)(21056001)(107046002)(97736001)(64706001)(19580405001)(65806001)(87266999)(83322001)(105586002)(50466002)(83072002)(95666004)(54356999)(85182001)(92566001)(23676002)(36756003)(65956001)(4396001)(83506001)(59896001);DIR:OUT;SFP:;SCL:1;SRVR:BY2PR02MB042;H:atltwp02.amd.com;FPR:;MLV:sfv;PTR:InfoDomainNonexistent;MX:1;LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 028166BF91 Authentication-Results: spf=none (sender IP is 165.204.84.222) smtp.mailfrom=Christian.Koenig@amd.com; X-OriginatorOrg: amd4.onmicrosoft.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 23.07.2014 11:55, schrieb Maarten Lankhorst: > op 23-07-14 11:47, Christian König schreef: >> Am 23.07.2014 11:44, schrieb Daniel Vetter: >>> On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter wrote: >>>> The scheduler needs to keep track of a lot of fences, so I think we'll >>>> have to register callbacks, not a simple wait function. We must keep >>>> track of all the non-i915 fences for all oustanding batches. Also, the >>>> scheduler doesn't eliminate the hw queue, only keep it much slower so >>>> that we can sneak in higher priority things. >>>> >>>> Really, scheduler or not is orthogonal. >>> Also see my other comment about interactions between wait_fence and >>> the i915 reset logic. We can't actually use it from within the >>> scheduler code since that would deadlock. >> Yeah, I see. You would need some way to abort the waiting on other devices fences in case of a lockup. >> >> What about an userspace thread to offload waiting and command submission to? > You would still need enable_signaling, else polling on the dma-buf wouldn't work. ;-) > Can't wait synchronously with multiple shared fences, need to poll for that. No you don't. Just make a list of fences you need to wait for and wait for each after another. But having an thread for each command submission context doesn't sounds like the best solution anyway. > And the dma-buf would still have fences belonging to both drivers, and it would still call from outside the driver. Calling from outside the driver is fine as long as the driver can do everything necessary to complete it's work and isn't forced into any ugly hacks and things that are not 100% reliable. So I don't see much other approach as integrating recovery code for not firing interrupts and some kind of lockup handling into the fence code as well. Christian. > > ~Maarten > From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= Subject: Re: [PATCH 09/17] drm/radeon: use common fence implementation for fences Date: Wed, 23 Jul 2014 12:13:05 +0200 Message-ID: <53CF8AB1.2000009@amd.com> References: <20140709093124.11354.3774.stgit@patser> <53CE8A57.2000803@vodafone.de> <53CF58FB.8070609@canonical.com> <53CF5B9F.1050800@amd.com> <53CF5EFE.6070307@canonical.com> <53CF63C2.7070407@vodafone.de> <53CF6622.6060803@amd.com> <53CF699D.9070902@canonical.com> <53CF6B18.5070107@vodafone.de> <53CF7035.2060808@amd.com> <53CF7191.2090008@canonical.com> <53CF765E.7020802@vodafone.de> <53CF8010.9060809@amd.com> <53CF822E.7050601@amd.com> <53CF84C7.2020507@vodafone.de> <53CF8693.1040006@canonical.com > Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <53CF8693.1040006-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nouveau-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org Sender: "Nouveau" To: Maarten Lankhorst , =?UTF-8?B?Q2hyaXM=?= =?UTF-8?B?dGlhbiBLw7ZuaWc=?= , Daniel Vetter Cc: Thomas Hellstrom , nouveau , LKML , dri-devel , Ben Skeggs , "Deucher, Alexander" List-Id: nouveau.vger.kernel.org QW0gMjMuMDcuMjAxNCAxMTo1NSwgc2NocmllYiBNYWFydGVuIExhbmtob3JzdDoKPiBvcCAyMy0w Ny0xNCAxMTo0NywgQ2hyaXN0aWFuIEvDtm5pZyBzY2hyZWVmOgo+PiBBbSAyMy4wNy4yMDE0IDEx OjQ0LCBzY2hyaWViIERhbmllbCBWZXR0ZXI6Cj4+PiBPbiBXZWQsIEp1bCAyMywgMjAxNCBhdCAx MTozOSBBTSwgRGFuaWVsIFZldHRlciA8ZGFuaWVsLnZldHRlckBmZndsbC5jaD4gd3JvdGU6Cj4+ Pj4gVGhlIHNjaGVkdWxlciBuZWVkcyB0byBrZWVwIHRyYWNrIG9mIGEgbG90IG9mIGZlbmNlcywg c28gSSB0aGluayB3ZSdsbAo+Pj4+IGhhdmUgdG8gcmVnaXN0ZXIgY2FsbGJhY2tzLCBub3QgYSBz aW1wbGUgd2FpdCBmdW5jdGlvbi4gV2UgbXVzdCBrZWVwCj4+Pj4gdHJhY2sgb2YgYWxsIHRoZSBu b24taTkxNSBmZW5jZXMgZm9yIGFsbCBvdXN0YW5kaW5nIGJhdGNoZXMuIEFsc28sIHRoZQo+Pj4+ IHNjaGVkdWxlciBkb2Vzbid0IGVsaW1pbmF0ZSB0aGUgaHcgcXVldWUsIG9ubHkga2VlcCBpdCBt dWNoIHNsb3dlciBzbwo+Pj4+IHRoYXQgd2UgY2FuIHNuZWFrIGluIGhpZ2hlciBwcmlvcml0eSB0 aGluZ3MuCj4+Pj4KPj4+PiBSZWFsbHksIHNjaGVkdWxlciBvciBub3QgaXMgb3J0aG9nb25hbC4K Pj4+IEFsc28gc2VlIG15IG90aGVyIGNvbW1lbnQgYWJvdXQgaW50ZXJhY3Rpb25zIGJldHdlZW4g d2FpdF9mZW5jZSBhbmQKPj4+IHRoZSBpOTE1IHJlc2V0IGxvZ2ljLiBXZSBjYW4ndCBhY3R1YWxs eSB1c2UgaXQgZnJvbSB3aXRoaW4gdGhlCj4+PiBzY2hlZHVsZXIgY29kZSBzaW5jZSB0aGF0IHdv dWxkIGRlYWRsb2NrLgo+PiBZZWFoLCBJIHNlZS4gWW91IHdvdWxkIG5lZWQgc29tZSB3YXkgdG8g YWJvcnQgdGhlIHdhaXRpbmcgb24gb3RoZXIgZGV2aWNlcyBmZW5jZXMgaW4gY2FzZSBvZiBhIGxv Y2t1cC4KPj4KPj4gV2hhdCBhYm91dCBhbiB1c2Vyc3BhY2UgdGhyZWFkIHRvIG9mZmxvYWQgd2Fp dGluZyBhbmQgY29tbWFuZCBzdWJtaXNzaW9uIHRvPwo+IFlvdSB3b3VsZCBzdGlsbCBuZWVkIGVu YWJsZV9zaWduYWxpbmcsIGVsc2UgcG9sbGluZyBvbiB0aGUgZG1hLWJ1ZiB3b3VsZG4ndCB3b3Jr LiA7LSkKPiBDYW4ndCB3YWl0IHN5bmNocm9ub3VzbHkgd2l0aCBtdWx0aXBsZSBzaGFyZWQgZmVu Y2VzLCBuZWVkIHRvIHBvbGwgZm9yIHRoYXQuCgpObyB5b3UgZG9uJ3QuIEp1c3QgbWFrZSBhIGxp c3Qgb2YgZmVuY2VzIHlvdSBuZWVkIHRvIHdhaXQgZm9yIGFuZCB3YWl0IApmb3IgZWFjaCBhZnRl ciBhbm90aGVyLiBCdXQgaGF2aW5nIGFuIHRocmVhZCBmb3IgZWFjaCBjb21tYW5kIHN1Ym1pc3Np b24gCmNvbnRleHQgZG9lc24ndCBzb3VuZHMgbGlrZSB0aGUgYmVzdCBzb2x1dGlvbiBhbnl3YXku Cgo+IEFuZCB0aGUgZG1hLWJ1ZiB3b3VsZCBzdGlsbCBoYXZlIGZlbmNlcyBiZWxvbmdpbmcgdG8g Ym90aCBkcml2ZXJzLCBhbmQgaXQgd291bGQgc3RpbGwgY2FsbCBmcm9tIG91dHNpZGUgdGhlIGRy aXZlci4KCkNhbGxpbmcgZnJvbSBvdXRzaWRlIHRoZSBkcml2ZXIgaXMgZmluZSBhcyBsb25nIGFz IHRoZSBkcml2ZXIgY2FuIGRvIApldmVyeXRoaW5nIG5lY2Vzc2FyeSB0byBjb21wbGV0ZSBpdCdz IHdvcmsgYW5kIGlzbid0IGZvcmNlZCBpbnRvIGFueSAKdWdseSBoYWNrcyBhbmQgdGhpbmdzIHRo YXQgYXJlIG5vdCAxMDAlIHJlbGlhYmxlLgoKU28gSSBkb24ndCBzZWUgbXVjaCBvdGhlciBhcHBy b2FjaCBhcyBpbnRlZ3JhdGluZyByZWNvdmVyeSBjb2RlIGZvciBub3QgCmZpcmluZyBpbnRlcnJ1 cHRzIGFuZCBzb21lIGtpbmQgb2YgbG9ja3VwIGhhbmRsaW5nIGludG8gdGhlIGZlbmNlIGNvZGUg CmFzIHdlbGwuCgpDaHJpc3RpYW4uCgo+Cj4gfk1hYXJ0ZW4KPgoKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTm91dmVhdSBtYWlsaW5nIGxpc3QKTm91dmVh dUBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWls bWFuL2xpc3RpbmZvL25vdXZlYXUK