[igt-dev] [PATCH i-g-t v2 4/4] lib/igt_fb: Generalize the slow read from gtt mmap handling

[Ville Syrjälä]

On Mon, Nov 05, 2018 at 04:41:22PM +0100, Maxime Ripard wrote:
> On Mon, Nov 05, 2018 at 04:33:28PM +0100, Maarten Lankhorst wrote:
> > Op 05-11-18 om 16:19 schreef Maxime Ripard:
> > > On Fri, Nov 02, 2018 at 09:37:31PM +0200, Ville Syrjala wrote:
> > >> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > >>
> > >> Make the handling of slow gtt mmap reads generic, and extend it to
> > >> the pixman converter. Makes the pixman path a bit faster.
> > >>
> > >> With testing just XRGB8888 and XBGR8888 on KBL:
> > >> $ time kms_plane --r pixel-format-pipe-A-planes
> > >> - real	0m18,757s
> > >> + real	0m2,635s
> > >>
> > >> v2: Use the original src buffer if the malloc fails (Chris)
> > >>     Drop the duplicated comment about things being slow
> > >>
> > >> Cc: Chris Wilson <chris at chris-wilson.co.uk>
> > >> Cc: Maxime Ripard <maxime.ripard at bootlin.com>
> > >> Cc: Arkadiusz Hiler <arkadiusz.hiler at intel.com>
> > >> Cc: Juha-Pekka Heikkila <juhapekka.heikkila at gmail.com>
> > >> Cc: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> > >> Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > For the 4 patches,
> > > Reviewed-by: Maxime Ripard <maxime.ripard at bootlin.com>
> > >
> > > Thanks!
> > > Maxime
> > >
> > Reviewed-by: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
> > 
> > I already had a similar fix to 1/4 in my tree but didn't send it out yet. :)
> 
> I'm curious, how did you find that issue in the first place?
> 
> It went through CI and I could run the kms_plane tests on my test
> laptop, so I'm confused.

XBGR8888 fb contents were gibberish. Since you disabled that
format in kms_plane we don't normally see the problem at all.

Unfortunately this doesn't fix the XBGR8888 crc fail. That one looks to
be some odd hardware issue as it still fails even if I change the LUT
programming to keep only the single msb. The colors on the screen do
look reasonably correct, and the fb data looked correct (apart from
0 vs. 0xff alpha, but manually changing that didn't make a different
either). So for now this remains a mystery :(

-- 
Ville Syrjälä
Intel