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.
> -Chris

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
register values.

Intel-gfx mailing list

Reply via email to