From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755947AbaGVPf2 (ORCPT ); Tue, 22 Jul 2014 11:35:28 -0400 Received: from mail-bn1blp0183.outbound.protection.outlook.com ([207.46.163.183]:46076 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753793AbaGVPf0 convert rfc822-to-8bit (ORCPT ); Tue, 22 Jul 2014 11:35:26 -0400 X-WSS-ID: 0N94DYN-07-FIQ-02 X-M-MSG: Message-ID: <53CE84AA.9030703@amd.com> Date: Tue, 22 Jul 2014 17:35:06 +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: Daniel Vetter , =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5p?= =?UTF-8?B?Zw==?= CC: Dave Airlie , Maarten Lankhorst , 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> <20140709122953.11354.46381.stgit@patser> <53CE2421.5040906@amd.com> <20140722114607.GL15237@phenom.ffwll.local> <20140722115737.GN15237@phenom.ffwll.local> <53CE56ED.4040109@vodafone.de> <20140722132652.GO15237@phenom.ffwll.local> <53CE6AFA.1060807@vodafone.de> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed X-Originating-IP: [10.224.155.194] Content-Transfer-Encoding: 8BIT X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:165.204.84.221;CTRY:US;IPV:NLI;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(6009001)(428002)(24454002)(377454003)(199002)(189002)(51704005)(47776003)(85182001)(74502001)(97736001)(68736004)(64126003)(92566001)(107046002)(33656002)(65806001)(31966008)(80022001)(81342001)(20776003)(105586002)(102836001)(64706001)(85852003)(65956001)(19580395003)(92726001)(561944003)(99396002)(93886003)(50466002)(81542001)(83322001)(4396001)(65816999)(36756003)(87266999)(85306003)(86362001)(76482001)(77982001)(76176999)(85202003)(80316001)(87936001)(106466001)(19580405001)(46102001)(54356999)(74662001)(83072002)(79102001)(95666004)(83506001)(44976005)(84676001)(23676002)(21056001)(101416001)(59896001)(50986999);DIR:OUT;SFP:;SCL:1;SRVR:BN1PR02MB037;H:atltwp01.amd.com;FPR:;MLV:sfv;PTR:InfoDomainNonexistent;MX:1;LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02801ACE41 Authentication-Results: spf=none (sender IP is 165.204.84.221) 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 22.07.2014 17:17, schrieb Daniel Vetter: > On Tue, Jul 22, 2014 at 3:45 PM, Christian König > wrote: >>> Would that be something you can agree to? >> >> No, the whole enable_signaling stuff should go away. No callback from the >> driver into the fence code, only the other way around. >> >> fence->signaled as well as fence->wait should become mandatory and only >> called from process context without holding any locks, neither atomic nor >> any mutex/semaphore (rcu might be ok). > So for the enable_signaling, that's optional already. It's only for > drivers that don't want to keep interrupts enabled all the time. You > can opt out of that easily. > > Wrt holding no locks at all while calling into any fence functions, > that's just not going to work out. The point here is to make different > drivers work together and we can rework all the ttm and i915 code to > work locklessly in all cases where they need to wait for someone to > complete rendering. Or at least I don't think that's feasible. So if > you insist that no one might call into radeon code then we simply need > to exclude radeon from participating in any shared fencing. But that's > a bit pointless. > >>> Like I've said I think restricting the insanity other people are willing >>> to live with just because you don't like it isn't right. But it is >>> certainly right for you to insist on not being forced into any such >>> design. I think the above would achieve this. >> >> I don't think so. If it's just me I would say that I'm just to cautious and >> the idea is still save to apply to the whole kernel. >> >> But since Dave, Jerome and Ben seems to have similar concerns I think we >> need to agree to a minimum and save interface for all drivers. > Well I haven't yet seen a proposal that actually works. How about this: Drivers exporting fences need to provide a fence->signaled and a fence->wait function, everything else like fence->enable_signaling or calling fence_signaled() from the driver is optional. Drivers wanting to use exported fences don't call fence->signaled or fence->wait in atomic or interrupt context, and not with holding any global locking primitives (like mmap_sem etc...). Holding locking primitives local to the driver is ok, as long as they don't conflict with anything possible used by their own fence implementation. Christian. > From an intel > pov I don't care that much since we don't care about desktop prime, so > if radeon/nouveau don't want to do that, meh. Imo the design as-is is > fairly sound, and as simple as it can get given the requirements. I > haven't heard an argument convincing me otherwise, so I guess we > won't have prime support on linux that actually works, ever. > -Daniel From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= Subject: Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences Date: Tue, 22 Jul 2014 17:35:06 +0200 Message-ID: <53CE84AA.9030703@amd.com> References: <20140709093124.11354.3774.stgit@patser> <20140709122953.11354.46381.stgit@patser> <53CE2421.5040906@amd.com> <20140722114607.GL15237@phenom.ffwll.local> <20140722115737.GN15237@phenom.ffwll.local> <53CE56ED.4040109@vodafone.de> <20140722132652.GO15237@phenom.ffwll.local> <53CE6AFA.1060807@vodafone.de> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter , =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5p?= =?UTF-8?B?Zw==?= Cc: Thomas Hellstrom , nouveau , LKML , dri-devel , "Deucher, Alexander" , Ben Skeggs List-Id: nouveau.vger.kernel.org QW0gMjIuMDcuMjAxNCAxNzoxNywgc2NocmllYiBEYW5pZWwgVmV0dGVyOgo+IE9uIFR1ZSwgSnVs IDIyLCAyMDE0IGF0IDM6NDUgUE0sIENocmlzdGlhbiBLw7ZuaWcKPiA8ZGVhdGhzaW1wbGVAdm9k YWZvbmUuZGU+IHdyb3RlOgo+Pj4gV291bGQgdGhhdCBiZSBzb21ldGhpbmcgeW91IGNhbiBhZ3Jl ZSB0bz8KPj4KPj4gTm8sIHRoZSB3aG9sZSBlbmFibGVfc2lnbmFsaW5nIHN0dWZmIHNob3VsZCBn byBhd2F5LiBObyBjYWxsYmFjayBmcm9tIHRoZQo+PiBkcml2ZXIgaW50byB0aGUgZmVuY2UgY29k ZSwgb25seSB0aGUgb3RoZXIgd2F5IGFyb3VuZC4KPj4KPj4gZmVuY2UtPnNpZ25hbGVkIGFzIHdl bGwgYXMgZmVuY2UtPndhaXQgc2hvdWxkIGJlY29tZSBtYW5kYXRvcnkgYW5kIG9ubHkKPj4gY2Fs bGVkIGZyb20gcHJvY2VzcyBjb250ZXh0IHdpdGhvdXQgaG9sZGluZyBhbnkgbG9ja3MsIG5laXRo ZXIgYXRvbWljIG5vcgo+PiBhbnkgbXV0ZXgvc2VtYXBob3JlIChyY3UgbWlnaHQgYmUgb2spLgo+ IFNvIGZvciB0aGUgZW5hYmxlX3NpZ25hbGluZywgdGhhdCdzIG9wdGlvbmFsIGFscmVhZHkuIEl0 J3Mgb25seSBmb3IKPiBkcml2ZXJzIHRoYXQgZG9uJ3Qgd2FudCB0byBrZWVwIGludGVycnVwdHMg ZW5hYmxlZCBhbGwgdGhlIHRpbWUuIFlvdQo+IGNhbiBvcHQgb3V0IG9mIHRoYXQgZWFzaWx5Lgo+ Cj4gV3J0IGhvbGRpbmcgbm8gbG9ja3MgYXQgYWxsIHdoaWxlIGNhbGxpbmcgaW50byBhbnkgZmVu Y2UgZnVuY3Rpb25zLAo+IHRoYXQncyBqdXN0IG5vdCBnb2luZyB0byB3b3JrIG91dC4gVGhlIHBv aW50IGhlcmUgaXMgdG8gbWFrZSBkaWZmZXJlbnQKPiBkcml2ZXJzIHdvcmsgdG9nZXRoZXIgYW5k IHdlIGNhbiByZXdvcmsgYWxsIHRoZSB0dG0gYW5kIGk5MTUgY29kZSB0bwo+IHdvcmsgbG9ja2xl c3NseSBpbiBhbGwgY2FzZXMgd2hlcmUgdGhleSBuZWVkIHRvIHdhaXQgZm9yIHNvbWVvbmUgdG8K PiBjb21wbGV0ZSByZW5kZXJpbmcuIE9yIGF0IGxlYXN0IEkgZG9uJ3QgdGhpbmsgdGhhdCdzIGZl YXNpYmxlLiBTbyBpZgo+IHlvdSBpbnNpc3QgdGhhdCBubyBvbmUgbWlnaHQgY2FsbCBpbnRvIHJh ZGVvbiBjb2RlIHRoZW4gd2Ugc2ltcGx5IG5lZWQKPiB0byBleGNsdWRlIHJhZGVvbiBmcm9tIHBh cnRpY2lwYXRpbmcgaW4gYW55IHNoYXJlZCBmZW5jaW5nLiBCdXQgdGhhdCdzCj4gYSBiaXQgcG9p bnRsZXNzLgo+Cj4+PiBMaWtlIEkndmUgc2FpZCBJIHRoaW5rIHJlc3RyaWN0aW5nIHRoZSBpbnNh bml0eSBvdGhlciBwZW9wbGUgYXJlIHdpbGxpbmcKPj4+IHRvIGxpdmUgd2l0aCBqdXN0IGJlY2F1 c2UgeW91IGRvbid0IGxpa2UgaXQgaXNuJ3QgcmlnaHQuIEJ1dCBpdCBpcwo+Pj4gY2VydGFpbmx5 IHJpZ2h0IGZvciB5b3UgdG8gaW5zaXN0IG9uIG5vdCBiZWluZyBmb3JjZWQgaW50byBhbnkgc3Vj aAo+Pj4gZGVzaWduLiBJIHRoaW5rIHRoZSBhYm92ZSB3b3VsZCBhY2hpZXZlIHRoaXMuCj4+Cj4+ IEkgZG9uJ3QgdGhpbmsgc28uIElmIGl0J3MganVzdCBtZSBJIHdvdWxkIHNheSB0aGF0IEknbSBq dXN0IHRvIGNhdXRpb3VzIGFuZAo+PiB0aGUgaWRlYSBpcyBzdGlsbCBzYXZlIHRvIGFwcGx5IHRv IHRoZSB3aG9sZSBrZXJuZWwuCj4+Cj4+IEJ1dCBzaW5jZSBEYXZlLCBKZXJvbWUgYW5kIEJlbiBz ZWVtcyB0byBoYXZlIHNpbWlsYXIgY29uY2VybnMgSSB0aGluayB3ZQo+PiBuZWVkIHRvIGFncmVl IHRvIGEgbWluaW11bSBhbmQgc2F2ZSBpbnRlcmZhY2UgZm9yIGFsbCBkcml2ZXJzLgo+IFdlbGwg SSBoYXZlbid0IHlldCBzZWVuIGEgcHJvcG9zYWwgdGhhdCBhY3R1YWxseSB3b3Jrcy4KCkhvdyBh Ym91dCB0aGlzOgoKRHJpdmVycyBleHBvcnRpbmcgZmVuY2VzIG5lZWQgdG8gcHJvdmlkZSBhIGZl bmNlLT5zaWduYWxlZCBhbmQgYSAKZmVuY2UtPndhaXQgZnVuY3Rpb24sIGV2ZXJ5dGhpbmcgZWxz ZSBsaWtlIGZlbmNlLT5lbmFibGVfc2lnbmFsaW5nIG9yIApjYWxsaW5nIGZlbmNlX3NpZ25hbGVk KCkgZnJvbSB0aGUgZHJpdmVyIGlzIG9wdGlvbmFsLgoKRHJpdmVycyB3YW50aW5nIHRvIHVzZSBl eHBvcnRlZCBmZW5jZXMgZG9uJ3QgY2FsbCBmZW5jZS0+c2lnbmFsZWQgb3IgCmZlbmNlLT53YWl0 IGluIGF0b21pYyBvciBpbnRlcnJ1cHQgY29udGV4dCwgYW5kIG5vdCB3aXRoIGhvbGRpbmcgYW55 IApnbG9iYWwgbG9ja2luZyBwcmltaXRpdmVzIChsaWtlIG1tYXBfc2VtIGV0Yy4uLikuIEhvbGRp bmcgbG9ja2luZyAKcHJpbWl0aXZlcyBsb2NhbCB0byB0aGUgZHJpdmVyIGlzIG9rLCBhcyBsb25n IGFzIHRoZXkgZG9uJ3QgY29uZmxpY3QgCndpdGggYW55dGhpbmcgcG9zc2libGUgdXNlZCBieSB0 aGVpciBvd24gZmVuY2UgaW1wbGVtZW50YXRpb24uCgpDaHJpc3RpYW4uCgo+ICAgRnJvbSBhbiBp bnRlbAo+IHBvdiBJIGRvbid0IGNhcmUgdGhhdCBtdWNoIHNpbmNlIHdlIGRvbid0IGNhcmUgYWJv dXQgZGVza3RvcCBwcmltZSwgc28KPiBpZiByYWRlb24vbm91dmVhdSBkb24ndCB3YW50IHRvIGRv IHRoYXQsIG1laC4gSW1vIHRoZSBkZXNpZ24gYXMtaXMgaXMKPiBmYWlybHkgc291bmQsIGFuZCBh cyBzaW1wbGUgYXMgaXQgY2FuIGdldCBnaXZlbiB0aGUgcmVxdWlyZW1lbnRzLiBJCj4gaGF2ZW4n dCBoZWFyZCBhbiAgYXJndW1lbnQgY29udmluY2luZyBtZSBvdGhlcndpc2UsIHNvIEkgZ3Vlc3Mg d2UKPiB3b24ndCBoYXZlIHByaW1lIHN1cHBvcnQgb24gbGludXggdGhhdCBhY3R1YWxseSB3b3Jr cywgZXZlci4KPiAtRGFuaWVsCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVz a3RvcC5vcmcKaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ry aS1kZXZlbAo=