On 22/09/16 12:21 AM, Christian König wrote: > Am 21.09.2016 um 17:13 schrieb Michel Dänzer: >> On 21/09/16 07:30 PM, Christian König wrote: >>> Am 21.09.2016 um 11:56 schrieb Michel Dänzer: >>>> FWIW, we seem to have the same issue with radeon vs. amdgpu: radeon >>>> only >>>> seems to wait for exclusive fences, so e.g. running Xorg on amdgpu and >>>> using PRIME slave scanout on radeon leaves artifacts. >>> Yeah, I know. See radeon_display.c radeon_flip_work_func(). >>> >>> We pretty much need the same patch here I've done for amdgpu as well. >> Actually, the PRIME slave can't scan out from the shared BOs directly >> (recall the recent discussion we had about that with Mario), but has to >> copy from the shared BO to a dedicated scanout BO. These copies need to >> be synchronized with the primary GPU's copies to the shared BO. > > Yeah, that thought came to my mind before as well. > > Buffer migrations by the kernel caused by a prime export actually set > the exclusive fence. > > So this shouldn't be an issue in practice when the displaying GPU needs > to copy from the BO again anyway. > > The only case I can see when this can happen is when the BO is composed > directly in system memory by the engines and not migrated there. There is no migration going on in the steady state, just the primary GPU writing to the shared BO and the slave GPU reading from it. If those operations aren't properly synchronized, there is at least intermittent tearing, but there can even be artifacts which stay until that area is updated again. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
