Op 09-02-18 om 11:04 schreef Chris Wilson:
> Quoting Maarten Lankhorst (2018-02-09 09:53:59)
>> Some cleanups to move the uncore.lock around vblank evasion, so run
>> to completion without racing on uncore.lock. Hopefully this will reduce
>> the chance of underruns, and perhaps allows us to decrease
>> VBLANK_EVASION_TIME_US as well as a followup patch.
>> Tested on KBL and BSW.
> * shivers
> uncore.lock is a brutally contested lock. Ville's patches did work on
> splitting the uncore.lock into forcewake and display variants, which
> cuts down on the nasty side effects.
> Latency profiling, another item for the CI/QA wishlist.
Yeah, unfortunately this is not different from status quo. We already
require everything inside vblank evasion to run as fast as possible,
and it's down to a list of register writes and a few reads. Those
already need the uncore.lock, so all we do now is being more explicit
about when we take it and eliminate contention when we write out the
Intel-gfx mailing list