From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: [PATCH] drm/i915: Android sync points for i915 v2 Date: Tue, 5 Aug 2014 10:52:36 -0700 Message-ID: <20140805105236.6f441592@jbarnes-desktop> References: <53DB3275.6010102@canonical.com> <1407194292-16218-1-git-send-email-jbarnes@virtuousgeek.org> <20140805075928.44d6a316@jbarnes-desktop> <20140805090504.417ac115@jbarnes-desktop> <20140805100908.0c90a67d@jbarnes-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by gabe.freedesktop.org (Postfix) with ESMTP id 60C256E008 for ; Tue, 5 Aug 2014 10:52:20 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id et14so1800433pad.9 for ; Tue, 05 Aug 2014 10:52:20 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: Maarten Lankhorst , Greg KH , intel-gfx , John Stultz List-Id: intel-gfx@lists.freedesktop.org On Tue, 5 Aug 2014 19:43:22 +0200 Daniel Vetter wrote: > On Tue, Aug 5, 2014 at 7:09 PM, Jesse Barnes wrote: > >> >> >> 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. > > Ah yeah, userspace needs to be adjusted of course to use fences as > flip completion events instead of drm events received through the drm > fd. But if we have a generic kms userspace (android hwc or wayland or > whatever) that part shouldn't have any driver-specific logic either. > And I've thought hwc expects fences for flip completion so that it > knows when it can start to reuse buffers and render into them again. > So at least on Android I think we need this, and I guess wayland > wouldn't mind if it could deal with fences exclusively. Yeah, Wayland doesn't currently use them, but it could for synchronizing client buffers against what it wants to draw for the next frame (i.e. if a client fence has passed when the compositor decides to draw its next frame, it gets included, otherwise the previous frame is included in the newly composed display buffer). I think they can probably be made generic, either by adding a new flag to mode sets/flips/vblank calls to return a fence, or by creating a separate display timeline to be passed in to a fence ioctl call. -- Jesse Barnes, Intel Open Source Technology Center