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 Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
