From patchwork Mon Nov 4 10:31:26 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maarten Lankhorst X-Patchwork-Id: 21323 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-oa0-f71.google.com (mail-oa0-f71.google.com [209.85.219.71]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 3DEFC25B39 for ; Mon, 4 Nov 2013 10:31:39 +0000 (UTC) Received: by mail-oa0-f71.google.com with SMTP id j6sf22512480oag.10 for ; Mon, 04 Nov 2013 02:31:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:message-id:date:from:user-agent :mime-version:to:references:in-reply-to:cc:subject:precedence :list-id:list-unsubscribe:list-archive:list-post:list-help :list-subscribe:errors-to:sender:x-original-sender :x-original-authentication-results:mailing-list:content-type :content-transfer-encoding; bh=DLk4CIXNm/be4/LX0/WhsiQInf96Bh+bX6OuBvVxoLA=; b=BpQ7EiDkg5egEXXfTVkj5dEOVi9fvrsa4+fdpdPw6joeK5wz5dLrw8YjWq5XeRBmH8 TQlAbnAIoqwY0Baf0CYA7YMHFVUHVsKkv4IZAG2ZokVOcZbDr+JrwgA0tXm/llWWkej/ 8AKGVUesp3ZIxZ46HodwBxAOOIYrVr58oe6pWG7Qm/n0lPr6MlbO/LaRb0JOc4+idJbP hIpeJ0VXLVEnutSgNhWeiOVqlEz2GTvi6bN73+zaIhhCKEOsZ5tz6CVe7O/hOehqKpOR EsNZsNcZkrx82M75awp696Ee4nA0DHHEuqnOT8TThQ8UkAyeJ/6wnllpm+XCbkKfduhs hUJw== X-Gm-Message-State: ALoCoQmbYOE0J9PawYD6ITL3LSoq8TK+i5JzR82uYLKkcKL9SGD/xkNLX3m1Wm91J4lC8EuDGorP X-Received: by 10.182.111.227 with SMTP id il3mr425001obb.41.1383561098319; Mon, 04 Nov 2013 02:31:38 -0800 (PST) X-BeenThere: patchwork-forward@linaro.org Received: by 10.49.116.43 with SMTP id jt11ls1223442qeb.24.gmail; Mon, 04 Nov 2013 02:31:38 -0800 (PST) X-Received: by 10.220.253.66 with SMTP id mz2mr2681205vcb.10.1383561098148; Mon, 04 Nov 2013 02:31:38 -0800 (PST) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by mx.google.com with ESMTPS id wp10si4944942vdb.136.2013.11.04.02.31.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 02:31:38 -0800 (PST) Received-SPF: neutral (google.com: 209.85.128.178 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) client-ip=209.85.128.178; Received: by mail-ve0-f178.google.com with SMTP id db12so1283340veb.37 for ; Mon, 04 Nov 2013 02:31:38 -0800 (PST) X-Received: by 10.220.164.202 with SMTP id f10mr1119225vcy.25.1383561098045; Mon, 04 Nov 2013 02:31:38 -0800 (PST) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patches@linaro.org Received: by 10.220.174.196 with SMTP id u4csp123324vcz; Mon, 4 Nov 2013 02:31:37 -0800 (PST) X-Received: by 10.180.13.13 with SMTP id d13mr11751789wic.34.1383561096970; Mon, 04 Nov 2013 02:31:36 -0800 (PST) Received: from ip-10-141-164-156.ec2.internal (lists.linaro.org. [54.225.227.206]) by mx.google.com with ESMTPS id hk4si359780wib.81.2013.11.04.02.31.36 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 Nov 2013 02:31:36 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linaro-mm-sig-bounces@lists.linaro.org designates 54.225.227.206 as permitted sender) client-ip=54.225.227.206; Received: from localhost ([127.0.0.1] helo=ip-10-141-164-156.ec2.internal) by ip-10-141-164-156.ec2.internal with esmtp (Exim 4.76) (envelope-from ) id 1VdHPD-0002Jw-BN; Mon, 04 Nov 2013 10:29:11 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by ip-10-141-164-156.ec2.internal with esmtp (Exim 4.76) (envelope-from ) id 1VdHP7-0002Jo-CD for linaro-mm-sig@lists.linaro.org; Mon, 04 Nov 2013 10:29:05 +0000 Received: from 5ed49945.cm-7-5c.dynamic.ziggo.nl ([94.212.153.69] helo=[192.168.1.128]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1VdHRO-0006xD-VP; Mon, 04 Nov 2013 10:31:27 +0000 Message-ID: <5277777E.5060904@canonical.com> Date: Mon, 04 Nov 2013 11:31:26 +0100 From: Maarten Lankhorst User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Colin Cross References: <524BCCD0.90002@canonical.com> <52556ABE.2090201@canonical.com> <52690EEC.5000501@canonical.com> <5270F8D7.4040406@canonical.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Cc: "linaro-mm-sig@lists.linaro.org" , Android Kernel Team , John Stultz , "dri-devel@lists.freedesktop.org" Subject: Re: [Linaro-mm-sig] thoughts of looking at android fences X-BeenThere: linaro-mm-sig@lists.linaro.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: , List-Help: , List-Subscribe: , Errors-To: linaro-mm-sig-bounces@lists.linaro.org Sender: linaro-mm-sig-bounces@lists.linaro.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: maarten.lankhorst@canonical.com X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.128.178 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 op 02-11-13 22:36, Colin Cross schreef: > On Wed, Oct 30, 2013 at 5:17 AM, Maarten Lankhorst > wrote: >> op 24-10-13 14:13, Maarten Lankhorst schreef: >>> So I actually tried to implement it now. I killed all the deprecated members and assumed a linear timeline. >>> This means that syncpoints can only be added at the end, not in between. In particular it means sw_sync >>> might be slightly broken. >>> >>> I only tested it with a simple program I wrote called ufence.c, it's in drivers/staging/android/ufence.c in the following tree: >>> >>> http://cgit.freedesktop.org/~mlankhorst/linux >>> >>> the "rfc: convert android to fence api" has all the changes from my dma-fence proposal to what android would need, >>> it also converts the userspace fence api to use the dma-fence api. >>> >>> sync_pt is implemented as fence too. This meant not having to convert all of android right away, though I did make some changes. >>> I killed the deprecated members and made all the fence calls forward to the sync_timeline_ops. dup and compare are no longer used. >>> >>> I haven't given this a spin on a full android kernel, only with the components that are in mainline kernel under staging and my dumb test program. >>> >>> ~Maarten >>> >>> PS: The nomenclature is very confusing. I want to rename dma-fence to syncpoint, but I want some feedback from the android devs first. :) >>> >> Come on, any feedback? I want to move the discussion forward. >> >> ~Maarten > I experimented with it a little on a device that uses sync and came > across a few bugs: > 1. sync_timeline_signal needs to call __fence_signal on all signaled > points on the timeline, not just the first > 2. fence_add_callback doesn't always initialize cb.node > 3. sync_fence_wait should take ms > 4. sync_print_pt status printing was incorrect > 5. there is a deadlock: > sync_print_obj takes obj->child_list_lock > sync_print_pt > fence_is_signaled > fence_signal takes fence->lock == obj->child_list_lock > 6. freeing a timeline before all the fences holding points on that > timeline have timed out results in a crash > > With the attached patch to fix these issues, our libsync and sync_test > give the same results as with our sync code. I haven't tested against > the full Android framework yet. > > The compare op and timeline ordering is critical to the efficiency of > sync points on Android. The compare op is used when merging fences to > drop all but the latest point on the same timeline. This is necessary > for example when the same buffer is submitted to the display on > multiple frames, like when there is a live wallpaper in the background > updating at 60 fps and a static screen of widgets on top of it. The > static widget buffer is submitted on every frame, returning a new > fence each time. The compositor merges the new fence with the fence > for the previous buffer, and because they are on the same timeline it > merges down to a single point. I experimented with disabling the > merge optimization on a Nexus 10, and found that leaving the screen on > running a live wallpaper eventually resulted in 100k outstanding sync > points. Well, here I did the same for dma-fence, can you take a look? diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c index 2c7fd3f2ab23..d1d89f1f8553 100644 --- a/drivers/staging/android/sync.c +++ b/drivers/staging/android/sync.c @@ -232,39 +232,62 @@ void sync_fence_install(struct sync_fence *fence, int fd) } EXPORT_SYMBOL(sync_fence_install); +static void sync_fence_add_pt(struct sync_fence *fence, int *i, struct fence *pt) { + fence->cbs[*i].sync_pt = pt; + fence->cbs[*i].fence = fence; + + if (!fence_add_callback(pt, &fence->cbs[*i].cb, fence_check_cb_func)) { + fence_get(pt); + (*i)++; + } +} + struct sync_fence *sync_fence_merge(const char *name, struct sync_fence *a, struct sync_fence *b) { int num_fences = a->num_fences + b->num_fences; struct sync_fence *fence; - int i; + int i, i_a, i_b; fence = sync_fence_alloc(offsetof(struct sync_fence, cbs[num_fences]), name); if (fence == NULL) return NULL; - fence->num_fences = num_fences; atomic_set(&fence->status, num_fences); - for (i = 0; i < a->num_fences; ++i) { - struct fence *pt = a->cbs[i].sync_pt; - - fence_get(pt); - fence->cbs[i].sync_pt = pt; - fence->cbs[i].fence = fence; - if (fence_add_callback(pt, &fence->cbs[i].cb, fence_check_cb_func)) - atomic_dec(&fence->status); + /* + * Assume sync_fence a and b are both ordered and have no + * duplicates with the same context. + * + * If a sync_fence can only be created with sync_fence_merge + * and sync_fence_create, this is a reasonable assumption. + */ + for (i = i_a = i_b = 0; i_a < a->num_fences || i_b < b->num_fences; ) { + struct fence *pt_a = i_a < a->num_fences ? a->cbs[i_a].sync_pt : NULL; + struct fence *pt_b = i_b < b->num_fences ? b->cbs[i_b].sync_pt : NULL; + + if (!pt_b || pt_a->context < pt_b->context) { + sync_fence_add_pt(fence, &i, pt_a); + + i_a++; + } else if (!pt_a || pt_a->context > pt_b->context) { + sync_fence_add_pt(fence, &i, pt_b); + + i_b++; + } else { + if (pt_a->seqno - pt_b->seqno <= INT_MAX) + sync_fence_add_pt(fence, &i, pt_a); + else + sync_fence_add_pt(fence, &i, pt_b); + + i_a++; + i_b++; + } } - for (i = 0; i < b->num_fences; ++i) { - struct fence *pt = b->cbs[i].sync_pt; - - fence_get(pt); - fence->cbs[a->num_fences + i].sync_pt = pt; - fence->cbs[a->num_fences + i].fence = fence; - if (fence_add_callback(pt, &fence->cbs[a->num_fences + i].cb, fence_check_cb_func)) - atomic_dec(&fence->status); - } + if (num_fences > i) + atomic_sub(num_fences - i, &fence->status); + fence->num_fences = i; sync_fence_debug_add(fence); return fence;