From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
intel-gfx@lists.freedesktop.org,
Maarten Lankhorst <maarten.lankhorst@canonical.com>
Subject: Re: [PATCH 3/3] drm/i915: add fences to the request struct
Date: Thu, 4 Dec 2014 12:05:34 +0100 [thread overview]
Message-ID: <20141204110534.GO32117@phenom.ffwll.local> (raw)
In-Reply-To: <20141204091321.GF25773@nuc-i3427.alporthouse.com>
On Thu, Dec 04, 2014 at 09:13:21AM +0000, Chris Wilson wrote:
> On Wed, Dec 03, 2014 at 11:49:07AM -0800, Jesse Barnes wrote:
> > This simplifies the sync code quite a bit. I don't think we'll be able
> > to get away with using the core fence code's seqno support, since we'll
> > be moving away from simple seqno comparisions with the scheduler and
> > preemption, but the additional code is pretty minimal anyway, and lets
> > us add additional debugging as needed, so it's probably fine to keep
> > either way.
> >
> > We still need to add support for other rings here; we ought to be able
> > to do that with the timeline field of the ioctl (which will include
> > other "rings" like the display flip queue for example).
>
> I am ambivalent about this. I don't think migrating i915_request over to
> use the heavyweight fence primitives is a good idea, so see little value
> in embedding the struct fence inside i915_request vs a small bookkeeping
> struct referencing i915_request.
Which part of struct fence is too heavyweight? And I guess we could always
add a slab or some cache if the allocation overhead is too much. I really
like this conceptually so if there's a concern with overhead I want solid
data for it.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2014-12-04 11:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-03 19:49 [RFC] Updated Android sync patches Jesse Barnes
2014-12-03 19:49 ` [PATCH 1/3] android: add sync_fence_create_dma Jesse Barnes
2015-01-14 14:09 ` Tvrtko Ursulin
2015-01-14 16:04 ` Maarten Lankhorst
2014-12-03 19:49 ` [PATCH 2/3] drm/i915: Android sync points for i915 v3 Jesse Barnes
2014-12-03 21:29 ` Maarten Lankhorst
2014-12-04 8:10 ` Chris Wilson
2014-12-04 9:03 ` Chris Wilson
2014-12-04 11:21 ` Daniel Vetter
2014-12-04 14:57 ` Jesse Barnes
2014-12-03 19:49 ` [PATCH 3/3] drm/i915: add fences to the request struct Jesse Barnes
2014-12-04 9:13 ` Chris Wilson
2014-12-04 11:05 ` Daniel Vetter [this message]
2014-12-04 11:29 ` Chris Wilson
2014-12-04 12:58 ` Daniel Vetter
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=20141204110534.GO32117@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jbarnes@virtuousgeek.org \
--cc=maarten.lankhorst@canonical.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