All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	John Stultz <john.stultz@linaro.org>
Subject: Re: [PATCH] drm/i915: Android sync points for i915 v2
Date: Tue, 5 Aug 2014 10:09:08 -0700	[thread overview]
Message-ID: <20140805100908.0c90a67d@jbarnes-desktop> (raw)
In-Reply-To: <CAKMK7uGbCbhT17cM2ZgN_3io2Up_-Kw_-k7h_B-8mGzojheCCg@mail.gmail.com>

On Tue, 5 Aug 2014 18:08:16 +0200
Daniel Vetter <daniel@ffwll.ch> wrote:

> On Tue, Aug 5, 2014 at 6:05 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > On Tue, 5 Aug 2014 17:08:22 +0200
> > Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> >> On Tue, Aug 5, 2014 at 4:59 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> >> >> This doesn't really look like the interface I'd expected. Imo we just
> >> >> need to add a flag to execbuf so that userspace can tell the kernel to
> >> >> create a fence for that execbuf, and switch one of the leftover rsvd
> >> >> fields to __s32 as an outparam for the fd.
> >> >
> >> > Given that I've got a new execbuf coming too, I just wanted to keep
> >> > them separate.  Any compelling reason to try to wedge it into execbuf?
> >>
> >> The new execbuf is for svm, and there we obviously need fences. But we
> >> also need proper fence support everywhere else (hence also the comment
> >> that we need support for fences in drm events).
> >>
> >> >> Then we need similar flags for vblank events and pageflips to do the
> >> >> same (obviously those are drm core patches) and it's all there. That
> >> >> should probably integrated as a special type of drm_event, so that
> >> >> drivers don't need to change a single line of code.
> >> >
> >> > Except for actually using the fences...
> >>
> >> Actually no, nothing needed - drivers already signal drm_events in all
> >> the right places, so we really only need to change
> >> drm_send_vblank_event. And ofc we need to rework the code in the
> >> pageflip/atomic/vblank_wait ioctl code in the drm core to create a
> >> fence (and return it to userspace) instead of a normal drm event.
> >
> > Actually yes.  You get back a fence object and want to do something
> > with it, right?  That means new code.  Plus modifying current execbuf
> > users that want fences to pass in a flag.
> 
> This comment was specifically about vblank and pageflips, _not_ about
> execbuf. At least that's been what I've thought while writing the
> original mail and reading your reply. Looks like we have a
> misunderstanding here. Since for vblank and pageflip we really can do
> it all in the drm core.

I was thinking of userspace drivers and userspace, not kernel
internals...  that's the disconnect.

  parent reply	other threads:[~2014-08-05 17:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-31 18:58 [RFC] Sync points/fences for i915 Jesse Barnes
2014-07-31 18:58 ` [PATCH] drm/i915: Android sync points " Jesse Barnes
2014-08-01  6:23   ` Maarten Lankhorst
2014-08-04 23:18     ` [PATCH] drm/i915: Android sync points for i915 v2 Jesse Barnes
2014-08-05  7:44       ` Daniel Vetter
2014-08-05 14:59         ` Jesse Barnes
2014-08-05 15:00           ` Maarten Lankhorst
2014-08-05 15:08           ` Daniel Vetter
2014-08-05 16:05             ` Jesse Barnes
2014-08-05 16:08               ` Daniel Vetter
2014-08-05 16:32                 ` Jesse Barnes
2014-08-05 17:09                 ` Jesse Barnes [this message]
2014-08-05 17:43                   ` Daniel Vetter
2014-08-05 17:52                     ` Jesse Barnes
2014-08-05  8:09       ` Maarten Lankhorst
2014-08-05 15:03         ` Jesse Barnes
2014-08-05 15:09           ` Daniel Vetter
2014-08-01  9:04   ` [PATCH] drm/i915: Android sync points for i915 Tvrtko Ursulin
2014-08-01 16:02     ` Jesse Barnes

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=20140805100908.0c90a67d@jbarnes-desktop \
    --to=jbarnes@virtuousgeek.org \
    --cc=daniel@ffwll.ch \
    --cc=gregkh@linuxfoundation.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=john.stultz@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.