[igt-dev] [PATCH i-g-t v3 4/4] tests/kms_frontbuffer_tracking: Remove redundant modesets during subtest start.

Daniel Vetter daniel.vetter at ffwll.ch
Thu Apr 5 19:44:58 UTC 2018


On Thu, Apr 5, 2018 at 9:30 PM, Paulo Zanoni <paulo.r.zanoni at intel.com> wrote:
> Em Qui, 2018-04-05 às 21:21 +0200, Maarten Lankhorst escreveu:
>> Op 05-04-18 om 18:31 schreef Paulo Zanoni:
>> > Em Qua, 2018-03-21 às 12:47 -0700, Paulo Zanoni escreveu:
>> > > Em Qui, 2018-03-01 às 16:33 +0100, Maarten Lankhorst escreveu:
>> > > > Hey,
>> > > >
>> > > > Op 27-02-18 om 09:52 schreef Maarten Lankhorst:
>> > > > > CRC capturing enables the display, then disables it again.
>> > > > > With
>> > > > > igt_display we can use igt_display_reset to restore the
>> > > > > original
>> > > > > state,
>> > > > > without committing it to the hw.
>> > > > >
>> > > > > All subtests first set their own state anyway, so we can save
>> > > > > up
>> > > > > on
>> > > > > the number of commits.
>> > > >
>> > > > I patched igt_kms to report the number of modesets..
>> > > >
>> > > > Without this patch running ./kms_frontbuffer_tracking on a 2
>> > > > output
>> > > > system (f2-snb-2600, forced VGA-1 enabled):
>> > > > Performed 382 modesets
>> > > >
>> > > > With this patch on a 2 output system:
>> > > > Performed 23 modesets
>> > > >
>> > > > On geminilake this means we save a lot of time, so could
>> > > > someone
>> > > > review this series?
>> > >
>> > > Is there an analysis on how reducing the amount of modesets will
>> > > *not*
>> > > invalidade the purpose of the tests? The modesets are there for a
>> > > reason.
>> >
>> > Ping?
>>
>> How will doing a modeset improve the test?
>>
>> We preserve the mode only if it makes sense, each subtest sets the
>> parameters it wants. It just happens that in most cases that's the
>> same mode, so we don't have to do a modeset.
>> That's all. :)
>
> But having or not having a modeset, having or not having a flip changes
> how the FBC code in the Kernel behaves. So changing from having a
> modeset to not having one will definitely have an impact on what code
> gets run. It would be good to have a detailed analysis on why this is
> not the case the specific points that changed.

Helps to also point at the regression report:

https://bugs.freedesktop.org/show_bug.cgi?id=105503

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the igt-dev mailing list