From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maarten Lankhorst Subject: Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences Date: Wed, 23 Jul 2014 09:32:09 +0200 Message-ID: <53CF64F9.7020701@canonical.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> <53CE84AA.9030703@amd.com> <53CE8A57.2000803@vodafone.de> <53CF58FB.8070609@canonical.com> <53CF5B9F.1050800@amd.com> <53CF5EFE.6070307@canonical.com> <53CF6128.6010703@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <53CF6128.6010703@amd.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= , Daniel Vetter Cc: Thomas Hellstrom , nouveau , LKML , dri-devel , Ben Skeggs , "Deucher, Alexander" List-Id: nouveau.vger.kernel.org b3AgMjMtMDctMTQgMDk6MTUsIENocmlzdGlhbiBLw7ZuaWcgc2NocmVlZjoKPiBBbSAyMy4wNy4y MDE0IDA5OjA5LCBzY2hyaWViIERhbmllbCBWZXR0ZXI6Cj4+IE9uIFdlZCwgSnVsIDIzLCAyMDE0 IGF0IDk6MDYgQU0sIE1hYXJ0ZW4gTGFua2hvcnN0Cj4+IDxtYWFydGVuLmxhbmtob3JzdEBjYW5v bmljYWwuY29tPiB3cm90ZToKPj4+PiBDYW4gd2Ugc29tZWhvdyBhdm9pZCB0aGUgbmVlZCB0byBj YWxsIGZlbmNlX3NpZ25hbCgpIGF0IGFsbD8gVGhlIGludGVycnVwdHMgYXQgbGVhc3Qgb24gcmFk ZW9uIGFyZSB3YXkgdG8gdW5yZWxpYWJsZSBmb3Igc3VjaCBhIHRoaW5nLiBDYW4gZW5hYmxlX3Np Z25hbGxpbmcgZmFpbD8gV2hhdCdzIHRoZSByZWFzb24gZm9yIGZlbmNlX3NpZ25hbGVkKCkgaW4g dGhlIGZpcnN0IHBsYWNlPwo+Pj4gSXQgZG9lc24ndCBuZWVkIHRvIGJlIGNvbXBsZXRlbHkgcmVs aWFibGUsIG9yIGZpbmlzaCBpbW1lZGlhdGVseS4KPj4+Cj4+PiBBbmQgYW55IHRpbWUgd2FrZV91 cF9hbGwoJnJkZXYtPmZlbmNlX3F1ZXVlKSBpcyBjYWxsZWQgYWxsIHRoZSBmZW5jZXMgdGhhdCB3 ZXJlIGVuYWJsZWQgd2lsbCBiZSByZWNoZWNrZWQuCj4+IEkgcmFpc2VkIHRoaXMgYWxyZWFkeSBz b21ld2hlcmUgZWxzZSwgYnV0IHNob3VsZCB3ZSBoYXZlIHNvbWUgY29tbW9uCj4+IGluZnJhc3Ry dWN0dXJlIGluIHRoZSBjb3JlIGZlbmNlIGNvZGUgdG8gcmVjaGVjayBmZW5jZXMgcGVyaW9kaWNh bGx5Pwo+PiByYWRlb24gZG9lc24ndCBzZWVtIHRvIGJlIHRoZSBvbmx5IGh3IHdoZXJlIHRoaXMg aXNuJ3QgcmVsaWFibGUKPj4gZW5vdWdoLiBPZiBjb3Vyc2UgdGltZXItYmFzZWQgcmVjaGVja2lu ZyB3b3VsZCBvbmx5IHdvcmsgaWYgdGhlIGRyaXZlcgo+PiBwcm92aWRlcyB0aGUgZmVuY2UtPnNp Z25hbGxlZCBjYWxsYmFjayB0byByZWNoZWNrIGFjdHVhbCBmZW5jZSBzdGF0ZS4KPgo+IFllYWgs IGFncmVlLiBUaGUgcHJvcG9zYWwgd29uJ3Qgd29yayByZWxpYWJsZSBhdCBhbGwgd2l0aCByYWRl b24uCj4KPiBJbnRlcnJ1cHRzIGFyZSBhY2N1bXVsYXRlZCBiZWZvcmUgc2VuZGluZyB0aGVtIHRv IHRoZSBDUFUsIGUuZy4geW91IGNhbiBnZXQgb25lIGludGVycnVwdCBmb3IgbXVsdGlwbGUgZmVu Y2VzIGZpbmlzaGVkLiBJZiBpdCdzIGp1c3QgdGhlIGludGVycnVwdCBmb3IgdGhlIGxhc3QgZmVu Y2Ugc3VibWl0dGVkIHRoYXQgZ2V0cyBsb3N0IHlvdSBhcmUgY29tcGxldGVseSBzY3Jld2VkIHVw IGJlY2F1c2UgeW91IHdvbid0IGdldCBhbm90aGVyIGludGVycnVwdC4KPgo+IEkgaGFkIHRoYXQg cHJvYmxlbSBtdWx0aXBsZSB0aW1lcyB3aGlsZSB3b3JraW5nIG9uIFVWRCBzdXBwb3J0LCByZXN1 bHRpbmcgaW4gdGhlIGRyaXZlciB0aGlua2luZyB0aGF0IGl0IGNhbid0IHN1Ym1pdCBtb3JlIGpv YnMgYmVjYXVzZSBub24gb2YgdGhlIGludGVycnVwdHMgZm9yIHRoZSBhbHJlYWR5IHN1Ym1pdHRl ZCBmZW5jZSBjYW0gdGhyb3VnaC4KWWVhaCBidXQgYWxsIHRoZSBmZW5jZXMgdGhhdCBoYXZlIC5l bmFibGVfc2lnbmFsaW5nIHdpbGwgZ2V0IHNpZ25hbGVkIGZyb20gYSBzaW5nbGUgaW50ZXJydXB0 LCBvciB3aGVuIGFueSB3YWl0ZXIgY2FsbHMgcmFkZW9uX2ZlbmNlX3Byb2Nlc3MuCgo+IEFwYXJ0 IGZyb20gdGhhdCBpbnRlcnJ1cHRzIG9uIE1hY3MgdXN1YWxseSBkb24ndCB3b3JrIGF0IGFsbCwg c28gd2UgcmVhbGx5IG5lZWQgYSBzb2x1dGlvbiB3aGVyZSBjYWxsaW5nIGZlbmNlX3NpZ25hbGVk KCkgaXMgY29tcGxldGVseSBvcHRpb25hbC4KSSBoYXZlbid0IGhhZCBhIHByb2JsZW0gd2l0aCBp bnRlcnJ1cHRzIG9uIG15IG1icCBhZnRlciBkMWY5ODA5ZWQxMzE1YzRjZGM1NzYwY2YyZjU5NjI2 ZmQzMjc2OTUyLCBidXQgaXQgc2hvdWxkIGJlIHRyaXZpYWwgdG8gc3RhcnQgYSB0aW1lciB0aGF0 IHBlcmlvZGljYWxseSBkb2VzIHdha2VfdXBfYWxsLCBhbmQgZ2V0cyBpdHMgdGltZW91dCByZXNl dCBpbiBhIGNhbGwgdG8gcmFkZW9uX2ZlbmNlX3Byb2Nlc3MuIEl0IGNvdWxkIGVpdGhlciBiZSBh ZGRlZCBhcyBhIHdvcmsgaXRlbSwgb3IgYXMgYSBub3JtYWwgdGltZXIgKGRpc2FibGVkIGR1cmlu ZyBncHUgbG9ja3VwIHJlY292ZXJ5IHRvIHByZXZlbnQgY2hlY2tzIGZyb20gZmlkZGxpbmcgd2l0 aCB0aGluZ3MgaXQgc2hvdWxkbid0KS4KCn5NYWFydGVuCgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZl bEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756895AbaGWHc3 (ORCPT ); Wed, 23 Jul 2014 03:32:29 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:47216 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755935AbaGWHc2 (ORCPT ); Wed, 23 Jul 2014 03:32:28 -0400 Message-ID: <53CF64F9.7020701@canonical.com> Date: Wed, 23 Jul 2014 09:32:09 +0200 From: Maarten Lankhorst User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= , Daniel Vetter CC: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= , Dave Airlie , 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> <53CE84AA.9030703@amd.com> <53CE8A57.2000803@vodafone.de> <53CF58FB.8070609@canonical.com> <53CF5B9F.1050800@amd.com> <53CF5EFE.6070307@canonical.com> <53CF6128.6010703@amd.com> In-Reply-To: <53CF6128.6010703@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org op 23-07-14 09:15, Christian König schreef: > Am 23.07.2014 09:09, schrieb Daniel Vetter: >> On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst >> wrote: >>>> Can we somehow avoid the need to call fence_signal() at all? The interrupts at least on radeon are way to unreliable for such a thing. Can enable_signalling fail? What's the reason for fence_signaled() in the first place? >>> It doesn't need to be completely reliable, or finish immediately. >>> >>> And any time wake_up_all(&rdev->fence_queue) is called all the fences that were enabled will be rechecked. >> I raised this already somewhere else, but should we have some common >> infrastructure in the core fence code to recheck fences periodically? >> radeon doesn't seem to be the only hw where this isn't reliable >> enough. Of course timer-based rechecking would only work if the driver >> provides the fence->signalled callback to recheck actual fence state. > > Yeah, agree. The proposal won't work reliable at all with radeon. > > Interrupts are accumulated before sending them to the CPU, e.g. you can get one interrupt for multiple fences finished. If it's just the interrupt for the last fence submitted that gets lost you are completely screwed up because you won't get another interrupt. > > I had that problem multiple times while working on UVD support, resulting in the driver thinking that it can't submit more jobs because non of the interrupts for the already submitted fence cam through. Yeah but all the fences that have .enable_signaling will get signaled from a single interrupt, or when any waiter calls radeon_fence_process. > Apart from that interrupts on Macs usually don't work at all, so we really need a solution where calling fence_signaled() is completely optional. I haven't had a problem with interrupts on my mbp after d1f9809ed1315c4cdc5760cf2f59626fd3276952, but it should be trivial to start a timer that periodically does wake_up_all, and gets its timeout reset in a call to radeon_fence_process. It could either be added as a work item, or as a normal timer (disabled during gpu lockup recovery to prevent checks from fiddling with things it shouldn't). ~Maarten