Re: [PATCH 2/2] tests/kms_fbc_crc: Fill entire target framebuffer to adds crc FIXMES

[Daniel Vetter <daniel@ffwll.ch>]

On Wed, Mar 25, 2015 at 06:47:21PM -0300, Paulo Zanoni wrote:
> 2015-03-25 17:15 GMT-03:00 Daniel Vetter <daniel.vetter@ffwll.ch>:
> > And use the same colors for both flip and fills so that we can reuse
> > crcs. Some details:
> > - For the flip_and_foo tests flip twice so that we again start with
> >   the black framebuffer and hence have a real change when painting it
> >   white.
> 
> But you don't really check the CRC after the first flip, so if it's
> completely ignored by the display engine, we won't know. That still
> looks like a regression from the previous code we had.

The clean fix would be to set up the 2nd (white) fb in the flip tests
instead of my lazy solution of simply flipping. And we already have a
simple flip test which makes sure that flips themselves work, so imo it's
ok to only test the _and_foo part in those tests.

If you want I can rework the test to be crazy and select the right
starting fb depending upon testcase.

> > - The upload for the rendercopy source isn't fast, but hey I'm lazy.
> 
> You're also changing everything form single-pixel write to full-fb
> write, which is not necessarily a bad thing (although slower), but
> could at least be on the changelog. Rodrigo sent a patch a while ago
> to transform these into visible rectangles and add
> igt_debug_wait_for_keypress(). I also have in my plans to add a small
> library for these draw operations, so we don't need to reimplement
> "write a colored rectangle using blt/render/mmap/etc" in every test.
> I'll send some patches for you to take a look.

Yeah the rectangle is a lot bigger now than a single pixel, I'm not sure
whether it really matters - if the hw gtt tracking misses a line we'll
still spot it because the crc checksum looks at the entire frame. And if
we indeed discover issues where only a few pixels get lost (thus far I
haven't seen that happen with fbc) then we can add more subtests with
corresponding crc. But for now I'd go with simple and obvious, full-screen
black->white transitions is about the most massive we can get.

And yeah helpers to write rbgx32 rectangles into buffers would be awesome
indeed, especially since I wasted a few hours yesterday debugging the blt
issues.

btw while you're thinking of making the test more useful for interactive
debugging, I wonder whether we should have an igt_debug_wait_for_keypress
when an igt_assert fails. Then you could run with
--interactive-debug=failure and with most crc testcase we don't need to
add specific interactive debug points.

Another one is running the testcase without fbc checks. That's useful for
debugging the test itself since you can then run it with fbc disabled.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx