From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757843AbaGWJkE (ORCPT ); Wed, 23 Jul 2014 05:40:04 -0400 Received: from mail-bn1blp0190.outbound.protection.outlook.com ([207.46.163.190]:30140 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1757824AbaGWJkA convert rfc822-to-8bit (ORCPT ); Wed, 23 Jul 2014 05:40:00 -0400 X-WSS-ID: 0N95S6J-07-KLG-02 X-M-MSG: Message-ID: <53CF82E7.2040102@amd.com> Date: Wed, 23 Jul 2014 11:39:51 +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 , Daniel Vetter CC: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= , "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> <53CE84AA.9030703@amd.com> <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> <53CF828E.5020201@canonical.com> In-Reply-To: <53CF828E.5020201@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.221;CTRY:US;IPV:NLI;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(6009001)(428002)(24454002)(377454003)(199002)(189002)(377424004)(51704005)(85182001)(65806001)(33656002)(68736004)(64126003)(107046002)(47776003)(85852003)(65956001)(80022001)(20776003)(81342001)(64706001)(102836001)(105586002)(19580395003)(92726001)(99396002)(93886003)(50466002)(80316001)(81542001)(84676001)(83322001)(4396001)(36756003)(65816999)(87266999)(86362001)(85306003)(76482001)(77982001)(76176999)(87936001)(106466001)(79102001)(54356999)(95666004)(97736001)(83072002)(85202003)(23676002)(21056001)(44976005)(101416001)(19580405001)(46102001)(83506001)(59896001)(50986999)(74662001);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: 028166BF91 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 23.07.2014 11:38, schrieb Maarten Lankhorst: > op 23-07-14 11:36, Christian König schreef: >> Am 23.07.2014 11:30, schrieb Daniel Vetter: >>> On Wed, Jul 23, 2014 at 11:27 AM, Christian König >>> wrote: >>>> You submit a job to the hardware and then block the job to wait for radeon >>>> to be finished? Well than this would indeed require a hardware reset, but >>>> wouldn't that make the whole problem even worse? >>>> >>>> I mean currently we block one userspace process to wait for other hardware >>>> to be finished with a buffer, but what you are describing here blocks the >>>> whole hardware to wait for other hardware which in the end blocks all >>>> userspace process accessing the hardware. >>> There is nothing new here with prime - if one context hangs the gpu it >>> blocks everyone else on i915. >>> >>>> Talking about alternative approaches wouldn't it be simpler to just offload >>>> the waiting to a different kernel or userspace thread? >>> Well this is exactly what we'll do once we have the scheduler. But >>> this is an orthogonal issue imo. >> Mhm, could have the scheduler first? >> >> Cause that sounds like reducing the necessary fence interface to just a fence->wait function. > You would also lose benefits like having a 'perf timechart' for gpu's. I can live with that, when it reduces the complexity of the fence interface. 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 11:39:51 +0200 Message-ID: <53CF82E7.2040102@amd.com> References: <20140709093124.11354.3774.stgit@patser> <53CE84AA.9030703@amd.com> <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> <53CF828E.5020201@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <53CF828E.5020201-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 , Daniel Vetter Cc: Thomas Hellstrom , nouveau , LKML , dri-devel , =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= , Ben Skeggs , "Deucher, Alexander" List-Id: nouveau.vger.kernel.org QW0gMjMuMDcuMjAxNCAxMTozOCwgc2NocmllYiBNYWFydGVuIExhbmtob3JzdDoKPiBvcCAyMy0w Ny0xNCAxMTozNiwgQ2hyaXN0aWFuIEvDtm5pZyBzY2hyZWVmOgo+PiBBbSAyMy4wNy4yMDE0IDEx OjMwLCBzY2hyaWViIERhbmllbCBWZXR0ZXI6Cj4+PiBPbiBXZWQsIEp1bCAyMywgMjAxNCBhdCAx MToyNyBBTSwgQ2hyaXN0aWFuIEvDtm5pZwo+Pj4gPGNocmlzdGlhbi5rb2VuaWdAYW1kLmNvbT4g d3JvdGU6Cj4+Pj4gWW91IHN1Ym1pdCBhIGpvYiB0byB0aGUgaGFyZHdhcmUgYW5kIHRoZW4gYmxv Y2sgdGhlIGpvYiB0byB3YWl0IGZvciByYWRlb24KPj4+PiB0byBiZSBmaW5pc2hlZD8gV2VsbCB0 aGFuIHRoaXMgd291bGQgaW5kZWVkIHJlcXVpcmUgYSBoYXJkd2FyZSByZXNldCwgYnV0Cj4+Pj4g d291bGRuJ3QgdGhhdCBtYWtlIHRoZSB3aG9sZSBwcm9ibGVtIGV2ZW4gd29yc2U/Cj4+Pj4KPj4+ PiBJIG1lYW4gY3VycmVudGx5IHdlIGJsb2NrIG9uZSB1c2Vyc3BhY2UgcHJvY2VzcyB0byB3YWl0 IGZvciBvdGhlciBoYXJkd2FyZQo+Pj4+IHRvIGJlIGZpbmlzaGVkIHdpdGggYSBidWZmZXIsIGJ1 dCB3aGF0IHlvdSBhcmUgZGVzY3JpYmluZyBoZXJlIGJsb2NrcyB0aGUKPj4+PiB3aG9sZSBoYXJk d2FyZSB0byB3YWl0IGZvciBvdGhlciBoYXJkd2FyZSB3aGljaCBpbiB0aGUgZW5kIGJsb2NrcyBh bGwKPj4+PiB1c2Vyc3BhY2UgcHJvY2VzcyBhY2Nlc3NpbmcgdGhlIGhhcmR3YXJlLgo+Pj4gVGhl cmUgaXMgbm90aGluZyBuZXcgaGVyZSB3aXRoIHByaW1lIC0gaWYgb25lIGNvbnRleHQgaGFuZ3Mg dGhlIGdwdSBpdAo+Pj4gYmxvY2tzIGV2ZXJ5b25lIGVsc2Ugb24gaTkxNS4KPj4+Cj4+Pj4gVGFs a2luZyBhYm91dCBhbHRlcm5hdGl2ZSBhcHByb2FjaGVzIHdvdWxkbid0IGl0IGJlIHNpbXBsZXIg dG8ganVzdCBvZmZsb2FkCj4+Pj4gdGhlIHdhaXRpbmcgdG8gYSBkaWZmZXJlbnQga2VybmVsIG9y IHVzZXJzcGFjZSB0aHJlYWQ/Cj4+PiBXZWxsIHRoaXMgaXMgZXhhY3RseSB3aGF0IHdlJ2xsIGRv IG9uY2Ugd2UgaGF2ZSB0aGUgc2NoZWR1bGVyLiBCdXQKPj4+IHRoaXMgaXMgYW4gb3J0aG9nb25h bCBpc3N1ZSBpbW8uCj4+IE1obSwgY291bGQgaGF2ZSB0aGUgc2NoZWR1bGVyIGZpcnN0Pwo+Pgo+ PiBDYXVzZSB0aGF0IHNvdW5kcyBsaWtlIHJlZHVjaW5nIHRoZSBuZWNlc3NhcnkgZmVuY2UgaW50 ZXJmYWNlIHRvIGp1c3QgYSBmZW5jZS0+d2FpdCBmdW5jdGlvbi4KPiBZb3Ugd291bGQgYWxzbyBs b3NlIGJlbmVmaXRzIGxpa2UgaGF2aW5nIGEgJ3BlcmYgdGltZWNoYXJ0JyBmb3IgZ3B1J3MuCgpJ IGNhbiBsaXZlIHdpdGggdGhhdCwgd2hlbiBpdCByZWR1Y2VzIHRoZSBjb21wbGV4aXR5IG9mIHRo ZSBmZW5jZSBpbnRlcmZhY2UuCgpDaHJpc3RpYW4uCgo+Cj4gfk1hYXJ0ZW4KPgoKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTm91dmVhdSBtYWlsaW5nIGxp c3QKTm91dmVhdUBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9w Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25vdXZlYXUK