Please ignore this full series here. I have a better one that let PSR on HSW in a better stage with only 1 idle frame and without changing the 100ms. Actually if we are brave we can reduce this to 24 or less. The new work is currently under http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=psr-3.18 However I'm not going to send yet because on BDW it got works. It seems BDW doesn't like to get PSR enabled immediatelly. So I'm justs sendint new series after I'm confortable that PSR is in a better stage for both HSW and BDW.
Thanks, Rodrigo. On Fri, Sep 5, 2014 at 1:37 AM, Daniel Vetter <dan...@ffwll.ch> wrote: > 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 > -- Rodrigo Vivi Blog: http://blog.vivi.eng.br
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
