[RFC 0/9] nuclear pageflip

[Rob Clark]

On Fri, Sep 14, 2012 at 1:23 PM, Ville Syrjälä <syrjala at sci.fi> wrote:
> On Fri, Sep 14, 2012 at 12:34:59PM -0500, Rob Clark wrote:
>> On Fri, Sep 14, 2012 at 12:02 PM, Ville Syrjälä
>> <ville.syrjala at linux.intel.com> wrote:
>> > On Fri, Sep 14, 2012 at 11:29:04AM -0500, Rob Clark wrote:
>> >> On Fri, Sep 14, 2012 at 10:48 AM, Ville Syrjälä
>> >> <ville.syrjala at linux.intel.com> wrote:
>> >> > On Fri, Sep 14, 2012 at 09:45:18AM -0500, Rob Clark wrote:
>> >> >> On Fri, Sep 14, 2012 at 8:58 AM, Ville Syrjälä
>> >> >> <ville.syrjala at linux.intel.com> wrote:
>> >> >> > On Fri, Sep 14, 2012 at 08:25:53AM -0500, Rob Clark wrote:
>> >> >> >> On Fri, Sep 14, 2012 at 7:50 AM, Ville Syrjälä
>> >> >> >> <ville.syrjala at linux.intel.com> wrote:
>> >> >> >> > On Thu, Sep 13, 2012 at 11:35:59AM -0500, Rob Clark wrote:
>> >> >> >> >> On Thu, Sep 13, 2012 at 9:29 AM, Ville Syrjälä
>> >> >> >> >> <ville.syrjala at linux.intel.com> wrote:
>> >> >> >> >> > That's a bit of an open question. I was considering several options:
>> >> >> >> >>
>> >> >> >> >> the thing I like about one ioctl per crtc is that it avoids this whole
>> >> >> >> >> question..
>> >> >> >> >>
>> >> >> >> >> And, I think as long as you have to update multiple different scanout
>> >> >> >> >> address registers, there is always going to be a race in multi-crtc
>> >> >> >> >> flipping.  Having a single ioctl does make the race smaller.  I'm not
>> >> >> >> >> sure how important that point is.
>> >> >> >> >
>> >> >> >> > Which race?
>> >> >> >>
>> >> >> >> ie. if you set REG_CRTC1_ADDR just immediately before vblank and
>> >> >> >> REG_CRTC2_ADDR just after
>> >> >> >
>> >> >> > Well, with unsynced crtcs I wouldn't call that any kind of meaningful race.
>> >> >> > The same problem after all exists even with a single crtc. You either make
>> >> >> > the deadline and write the register before vblank, or you don't make it
>> >> >> > and end up with a repeated frame.
>> >> >>
>> >> >> I meant w/ sync'd crtc's, there is still no 100% guarantee that the
>> >> >> two flip at the same time.
>> >> >
>> >> > Sure there is. That's what the vblank evade stuff gives you. I just
>> >> > happen to need it even when using just one crtc because the hardware
>> >> > doesn't have the necessary mechanism to flip several planes atomically.
>> >>
>> >> hmm, I guess I don't quite follow then.  But I guess I don't know the
>> >> intel hw well enough.  It seemed like you weren't atomically updating
>> >> scanout registers.
>> >
>> > I guarantee the atomicity by making sure I'm not too close to the start
>> > of vblank when I write the registers. It's a very generic solution that
>> > will work on any hardware with double buffered registers that get
>> > flipped on vblank. Even if some of the registers would get flipped at
>> > slightly different times (eg. plane A flips at vbl_start+1, plane B at
>> > vbl_start+10) you could still use this method by extending the range of
>> > scanlines to be avoided.
>>
>> ahh, ok, double-buffered..  well, if they are double buffered you
>> should be able to tolerate two ioctl() calls, because you have a
>> relatively large window to update all the registers ;-)
>
> Hey, if "should" would be good enough, there would be no need for an
> atomic page flip ioctl.

Well, true.. but there is a bit of a difference of scale.. I mean
flipping multiple layers on a single CRTC that is not vblank sync'd
with another CRTC should be a common case, and you can get incorrect
results on the screen, so an "it *should* work" solution is less
acceptable.

vsync locked crtc's seem like it would be less common, and less likely
to be noticed if once in a while the flip is off by a frame.  So it
seems like a less urgent issue to solve.

Just playing devil's advocate here ;-)

BR,
-R

> And somehwat ironically, if I didn't have double buffered registers,
> I'd just write the lot of them from the vblank irq handler, which would
> be simpler in some sense. Well, to tell the truth, not all registers in
> Intel HW are double buffered. Gamma tables/ramps for example are single
> buffered, and if we actually start to care about accurate color
> reproduction we may need to mix the two approaches. The other approach
> would be to reject changes to features backed by single buffered registers
> while the relevant piece of hardware is enabled.
>
> --
> Ville Syrjälä
> syrjala at sci.fi
> http://www.sci.fi/~syrjala/
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel