From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
To: Rom Lemarchand <romlem@google.com>
Cc: "linaro-mm-sig@lists.linaro.org" <linaro-mm-sig@lists.linaro.org>,
Android Kernel Team <kernel-team@android.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
Colin Cross <ccross@google.com>
Subject: Re: [Linaro-mm-sig] thoughts of looking at android fences
Date: Fri, 08 Nov 2013 11:43:41 +0100 [thread overview]
Message-ID: <527CC05D.9010400@canonical.com> (raw)
In-Reply-To: <CAABpnA-85QdwoYO5Ldz52bxw1_dWaQz541MjgEGZhwdu+Bhtvw@mail.gmail.com>
op 07-11-13 22:11, Rom Lemarchand schreef:
> Hi Maarten, I tested your changes and needed the attached patch: behavior
> now seems equivalent as android sync. I haven't tested performance.
>
> The issue resolved by this patch happens when i_b < b->num_fences and
> i_a >= a->num_fences (or vice versa). Then, pt_a is invalid and so
> dereferencing pt_a->context causes a crash.
Oops, thinko. :) Originally I had it correct by doing this:
+ /*
+ * 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 = a->cbs[i_a].sync_pt;
+ struct fence *pt_b = b->cbs[i_b].sync_pt;
+
+ if (pt_a->context < pt_b->context) {
+ sync_fence_add_pt(fence, &i, pt_a);
+
+ i_a++;
+ } else if (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++;
+ }
+ }
+
+ /* Add remaining fences from a or b*/
+ for (; i_a < a->num_fences; i_a++)
+ sync_fence_add_pt(fence, &i, a->cbs[i_a].sync_pt);
+
+ for (; i_b < b->num_fences; i_b++)
+ sync_fence_add_pt(fence, &i, b->cbs[i_b].sync_pt);
Then I thought I could clean it up by merging it, but that ended up being
more unreadable and crashing... so I guess I'll revert back to this version. :)
next prev parent reply other threads:[~2013-11-08 10:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-02 7:35 thoughts of looking at android fences Maarten Lankhorst
2013-10-02 18:13 ` [Linaro-mm-sig] " Erik Gilling
2013-10-08 17:37 ` John Stultz
2013-10-08 18:56 ` Rob Clark
2013-10-09 14:39 ` Maarten Lankhorst
2013-10-24 12:13 ` Maarten Lankhorst
2013-10-30 12:17 ` Maarten Lankhorst
2013-11-01 21:03 ` Rom Lemarchand
2013-11-02 21:36 ` Colin Cross
2013-11-03 6:31 ` Maarten Lankhorst
2013-11-04 9:36 ` Maarten Lankhorst
2013-11-04 10:31 ` Maarten Lankhorst
2013-11-07 21:11 ` Rom Lemarchand
2013-11-08 10:43 ` Maarten Lankhorst [this message]
2013-11-08 11:43 ` Maarten Lankhorst
2013-11-08 14:35 ` Rom Lemarchand
2013-11-12 1:53 ` Rom Lemarchand
2013-10-08 18:47 ` Rob Clark
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=527CC05D.9010400@canonical.com \
--to=maarten.lankhorst@canonical.com \
--cc=ccross@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kernel-team@android.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=romlem@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).