Re: [PATCH 1/4] drm/i915: Increase PSR Idle Frame to 2.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 04, 2014 at 05:40:05PM -0700, Rodrigo Vivi wrote:
> Here goes results on BDW  with pure today's nightly (with idle_frame=1)
> 
> # First run
> 
> IGT-Version: 1.7-gd4b43f0 (x86_64) (Linux: 3.17.0-rc2+ x86_64)
> Subtest primary_page_flip: SUCCESS
> Subtest primary_mmap_gtt: SUCCESS
> Test assertion failure function test_crc, file kms_psr_sink_crc.c:307:
> Failed assertion: strcmp(ref_crc, CRC_GREEN) != 0
> Subtest primary_mmap_gtt_waiting: FAIL
> Subtest primary_mmap_cpu: SUCCESS
> Subtest primary_blt: SUCCESS
> Subtest primary_render: SUCCESS
> Subtest sprite_mmap_gtt: SUCCESS
> Waiting 10s...
> Subtest sprite_mmap_gtt_waiting: SUCCESS
> Subtest sprite_mmap_cpu: SUCCESS
> Subtest sprite_blt: SUCCESS
> Subtest sprite_render: SUCCESS
> Subtest sprite_plane_move: SUCCESS
> Subtest sprite_plane_onoff: SUCCESS
> Subtest cursor_mmap_gtt: SUCCESS
> Waiting 10s...
> Subtest cursor_mmap_gtt_waiting: SUCCESS
> Subtest cursor_mmap_cpu: SUCCESS
> Subtest cursor_blt: SUCCESS
> Subtest cursor_render: SUCCESS
> Subtest cursor_plane_move: SUCCESS
> Subtest cursor_plane_onoff: SUCCESS
> 
> #second run:
> 
> IGT-Version: 1.7-gd4b43f0 (x86_64) (Linux: 3.17.0-rc2+ x86_64)
> Subtest primary_page_flip: SUCCESS
> Subtest primary_mmap_gtt: SUCCESS
> Waiting 10s...
> Subtest primary_mmap_gtt_waiting: SUCCESS
> Subtest primary_mmap_cpu: SUCCESS
> Subtest primary_blt: SUCCESS
> Subtest primary_render: SUCCESS
> Subtest sprite_mmap_gtt: SUCCESS
> Waiting 10s...
> Subtest sprite_mmap_gtt_waiting: SUCCESS
> Subtest sprite_mmap_cpu: SUCCESS
> Subtest sprite_blt: SUCCESS
> Test assertion failure function test_crc, file kms_psr_sink_crc.c:307:
> Failed assertion: strcmp(ref_crc, CRC_GREEN) != 0
> Subtest sprite_render: FAIL
> Subtest sprite_plane_move: SUCCESS
> Subtest sprite_plane_onoff: SUCCESS
> Subtest cursor_mmap_gtt: SUCCESS
> Waiting 10s...
> Subtest cursor_mmap_gtt_waiting: SUCCESS
> Subtest cursor_mmap_cpu: SUCCESS
> Subtest cursor_blt: SUCCESS
> Subtest cursor_render: SUCCESS
> Subtest cursor_plane_move: SUCCESS
> Subtest cursor_plane_onoff: SUCCESS
> 
> random failures! but better than hsw at least.

Ugh, this is painful :(

> However the hardcoded color is indeed a mistake... Green on this panel is
> different from the green on the other panel.
> But I'm also not sure about drawing the color with cairo... How can we be
> sure what is there is what we want anyway.

Yeah, the crc value is implementation defined, but otoh we don't really
depend upon that, as long as the same output results in the same crc.

> So maybe it is better to fall back to old scheme where we just check if
> changed when we want it changes... without checking for colors.
> What do you think?

You can't check for change with crc due to collisions, you really only (at
least reliably) can check for matching outputs. And as long as we don't
have any color correction enabled a given color on the sprite/cursor plane
should exactly match the same color on the primary plane.

For inspiration Ville's cursor crc testcase has all the ingredients I
think you'll need for the sprite/cursor move tests.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux