On Thu, Oct 15, 2015 at 04:00:48PM -0700, Kevin Strasser wrote: > On Thu, Oct 15, 2015 at 11:20:59AM +0300, Ville Syrjälä wrote: > > On Wed, Oct 14, 2015 at 01:33:57PM -0700, Kevin Strasser wrote: > > > On Wed, Oct 14, 2015 at 10:48:52PM +0300, Ville Syrjälä wrote: > > > > Does it? I just tried it on IVB, and behaves just like you said. So not > > > > sure how far back this goes. > > > > > > Ah, so this test case is failing on IVB too? > > > > I just poked at the registers. I don't think we have specific test cases > > for this, so any currently failing test case is just bad luck. > > > > It would be good to write a small tool that just frobs the registers in > > specific ways, and tells us if the test machine suffers from this issue. > > Would be easy to run on any machine then. > > Agreed, it is somewhat painful getting the whole test suite built and running in > some environments. > > > What I did manually was: > > intel_reg write 0x4a000 0x400000 > > intel_reg write 0x70180 0x0 > > <whatever> = intel_reg read 0x7019c > > intel_reg write 0x7019c <whatever> > > > > and as a second test I tried: > > intel_reg write 0x70180 <original value & ~(1<<31)) > > <whatever> = intel_reg read 0x7019c > > intel_reg write 0x7019c <whatever> > > > > And the result was black in the first test, dark red in > > the second. > > > > On SKL I additionally tried to resize the plane to be smaller, and then > > tried the same thing. But as stated the palette seems to misbehave > > somehow, so there was no change in the output from changing entry 0 even > > though most of the screen was supposed to be black. > > > > > Are there any reporting tools we > > > can look at to find out what tests are passing for each platform? > > > > > > > And now I'm really wondering about platforms where the primary > > > > plane need not be fullscreen (gen2/3 and chv). > > > > > > > > I tried this on SKL too, but that confused me even more. The data not > > > > going through any plane seems to be gamma corrected regardless of any > > > > plane control bits, so that's good. However the legacy palette seems > > > > all fubar. Black input apparently doesn't map to palette entry 0. > > > > I wonder if you're seeing this on HSW too, or is your palette entry 0 > > > > supposed to be non-black? > > > > > > I also tried on BDW and it is passing the test with and without my patch > > > applied. > > > > > > I'm not really sure what 'palette entry 0' you are looking for. Could you point > > > me to where in the code I can find out? > > > > Register 0x4a000, 0x4a800, 0x4b000, depending on which pipe you're > > using. > > I'm using pipe A, here is the output of 'intel_reg read 0x4a000': > (0x0004a000): 0x00000000 > > I suppose this means palette entry 0 is black for me. It means it's supposed to be black. But if you saw a difference between black when it went through the gamma and when it didn't, then I guess black is not hitting entry 0 on hsw either. So something seems fishy. > > > > > Looks like quite a bit more testing is needed to get to the bottom of > > > > this. > > > > > > Agreed, this does seem to extend beyond HSW. For now do you think my patch is > > > the right approach at least for HSW alone? > > > > Yeah, looks that way. But we do need to figure out which bits behave > > this way. Ie. is it just gamma, or pipe csc too, or perhaps even some > > other bits? > > I did some testing and it seems that gamma and pipe csc are both needed to pass > the test on HSW. v2 of the patch sets them explicitly. > > Thanks, > Kevin -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
