On Thu, Nov 08, 2018 at 02:06:52PM -0800, Matt Roper wrote: > On Thu, Nov 01, 2018 at 05:05:58PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > The plane color correction registers are single buffered. So > > ideally we would write them at the start of vblank just after the > > double buffered plane registers have been latched. Since we have > > no convenient way to do that for now let's at least move the > > single buffered register writes to happen after the double > > buffered registers have been written. > > Should we move this all the way out of the vblank evasion? I realize > that vlv is only two registers total so it's not a big deal, but I know > Uma is working on the plane color management stuff for later platforms > where we have a bunch of registers to write, so maybe we should setup > the callsite now? I didn't want to pile on too much work in this series. For the plane color management we might need to think how to do this properly as otherwise it's may end up being too ugly to actually use. I also have a branch somewhere with fp16 scanout support, and on ivb that requires playing around with the plane gamma as well. So that could be another natural point when we might come up with a better mechanism for single buffered registers. Although I'm not sure we can land fp16 any time soon though since there is no userspace currently. I implemented it just so that I could test the higher precision pipe gamma modes. > > On a similar note, I notice our single-buffered pipe-level color > management registers are written before evasion right now...should we > move that to after the evasion as well? Yes. I have that actually implemented on a branch that reworks the pipe color management stuff quite a bit. I'm actually moving it to happen after the vblank waits in the sequence, but I didn't add any kind of proper vblank worker etc. so I expect it's still likely to tear :( But at least it's a bit closer to where it really should be. I'm planning to post that series after this stuff lands as there is a slight dependency on the update_planes stuff and whatnot. -- Ville Syrjälä Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
