public inbox for intel-gfx@lists.freedesktop.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox