From: Daniel Vetter <daniel@ffwll.ch>
To: "Michel Dänzer" <michel@daenzer.net>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 4/5] drm/amdgpu: Wait for end of last waited-for vblank before programming flip
Date: Thu, 16 Jun 2016 10:14:38 +0200 [thread overview]
Message-ID: <20160616081438.GR1338@phenom.ffwll.local> (raw)
In-Reply-To: <99c06535-36fe-9425-4cf2-65abca944f12@daenzer.net>
On Thu, Jun 16, 2016 at 11:15:14AM +0900, Michel Dänzer wrote:
> On 15.06.2016 18:23, Daniel Vetter wrote:
> > On Wed, Jun 15, 2016 at 05:03:41PM +0900, Michel Dänzer wrote:
> >> On 14.06.2016 17:06, Daniel Vetter wrote:
> > Yeah I think there's a bit of confusion going on here ;-) Of course I'm
> > not against fixing this, and I agree that fixing it by delaying the vblank
> > drm event (like I proposed at first) is not good. What I think would be
> > best to fix this:
> >
> > - For all current userspace (i.e. no flags or anything) force vrefresh to
> > to be fixed, and delay page flips which hit the vblank window to be
> > after that. This way amd drivers are consistent with every other kms
> > drivers, and work like current userspace seems to expect: Wait for
> > vblank, then assume any flips will only hit after the next vblank.
>
> This series preserves this behaviour. A flip is only allowed to complete
> during the current vertical blank period if userspace either:
>
> * expected it to complete in this vertical blank (or an earlier one).
> In other words, if the flip doesn't complete in this vertical blank,
> it is delayed (further) compared to userspace expectations.
>
> * hasn't called DRM_IOCTL_WAIT_VBLANK at all (so apparently it doesn't
> care about when the flip completes).
>
> It sounds like you're saying we aren't allowed to fix cases where flips
> are completing later than expected by userspace, because other drivers
> haven't fixed those cases yet. Quite frankly, that sucks. Nothing other
> than possible hardware restrictions prevents other drivers from fixing
> this as well.
I'm not objecting against fixing this. I'm objecting against fixing this
through clever inferring of what userspace wants, aka the above, instead
of an explicit flag or something. And without that flag the rule is that a
pageflip after vblank hits the next vblank and can't squeeze into the
current one.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2016-06-16 8:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-10 8:57 [PATCH 0/5] drm/amdgpu: Page flip improvement and related cleanups Michel Dänzer
2016-06-10 8:57 ` [PATCH 1/5] drm: Only handle _DRM_VBLANK_NEXTONMISS once Michel Dänzer
2016-06-10 8:57 ` [PATCH 2/5] drm: Keep track of last vblank sequence waited for per-file-descriptor Michel Dänzer
2016-06-10 8:57 ` [PATCH 3/5] drm/amdgpu: Unpin BO if we can't get fences in amdgpu_crtc_page_flip Michel Dänzer
2016-06-10 8:57 ` [PATCH 4/5] drm/amdgpu: Wait for end of last waited-for vblank before programming flip Michel Dänzer
2016-06-10 14:43 ` Daniel Vetter
2016-06-13 1:54 ` Michel Dänzer
2016-06-13 8:06 ` Daniel Vetter
2016-06-13 8:58 ` Michel Dänzer
2016-06-13 14:06 ` Daniel Vetter
2016-06-14 2:09 ` Michel Dänzer
2016-06-14 5:53 ` Daniel Vetter
2016-06-14 7:25 ` Michel Dänzer
2016-06-14 8:06 ` Daniel Vetter
2016-06-15 8:03 ` Michel Dänzer
2016-06-15 9:23 ` Daniel Vetter
2016-06-16 2:15 ` Michel Dänzer
2016-06-16 8:14 ` Daniel Vetter [this message]
2016-06-14 8:12 ` Chris Wilson
2016-06-10 8:57 ` [PATCH 5/5] drm/amdgpu: Set MASTER_UPDATE_MODE to 0 again Michel Dänzer
2016-06-10 9:01 ` [PATCH 0/5] drm/amdgpu: Page flip improvement and related cleanups Christian König
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=20160616081438.GR1338@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=michel@daenzer.net \
/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