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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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. 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@xxxxxx http://www.sci.fi/~syrjala/ _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
