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