On Fri, Sep 14, 2012 at 1:23 PM, Ville Syrjälä <syrjala@xxxxxx> 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@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. 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@xxxxxx > http://www.sci.fi/~syrjala/ > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
