Ok - the change is Acked-by: Andrey Grodzovsky <andrey.grodzovsky@xxxxxxx> Andrey On 12/06/2018 10:59 AM, Nicholas Kazlauskas wrote: > On 2018-12-06 10:36 a.m., Grodzovsky, Andrey wrote: >> Not an expert on Freesync so maybe stupid question but from he comment >> looks like this pipe locking is only for the sake of Freesync mode there >> - why is it then called unconditionally w/o checking if you even run in >> Freesync mode ? >> >> Andrey > I don't think there's any sort of state tracking done in DC for FreeSync > state changes on a stream so it was probably easier to do this. Given > the age of the pipe lock addition I would be worried about other > behavior relying on it now if it was just conditionally done on that. > > In practice I think the worst case effect of guarding these calls with a > mutex is <100us of delay. That's for two separate threads issuing two > commits at the same time with the planes changed. > > Nicholas Kazlauskas > >> >> On 12/06/2018 08:42 AM, Kazlauskas, Nicholas wrote: >>> A reader/writer lock wouldn't help here, actually. >>> >>> Fast updates (and page flips in particular) need to lock the pipe as >>> well, see: commit_planes_for_stream. >>> >>> Nicholas Kazlauskas > _______________________________________________ > amd-gfx mailing list > amd-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/amd-gfx _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
