"Fixes" for page flipping under PRIME on AMD & nouveau
Christian König
deathsimple at vodafone.de
Thu Aug 18 08:20:21 UTC 2016
Am 18.08.2016 um 09:52 schrieb Michel Dänzer:
> On 18/08/16 04:41 PM, Christian König wrote:
>>> Afaiu the prime importing display gpu generates its own gem buffer
>>> handle (prime_fd_to_handle) from that dmabuf, importing scather-gather
>>> tables to access the dmabuf in system ram. As far as page flipping is
>>> concerned, so far those gem buffers / radeon_bo's aren't treated any
>>> different than native ones. During pageflip setup they get pinned into
>>> VRAM, which moves (=copies) their content from the RAM dmabuf backing
>>> store into VRAM.
>> Your understanding isn't correct. Buffers imported using prime always
>> stay in GTT, they can't be moved to VRAM.
> That's the theory, but based on Mario's description it's clear that
> there is at least one bug which either actually allows a shared buffer
> to be moved to VRAM, or at least doesn't propagate the error correctly,
> so the page flip operation "succeeds".
>
>
>> It's the DDX which copies the buffer content from the imported prime
>> handle into a native on which is enabled to scan out.
> There is no such code which could explain what Mario is seeing.
How should this work then otherwise?
I agree that I don't understand fully either what is happening here, but
I find it quite unlikely that we actually scan out from system memory
without the proper hardware setup.
On the other hand that we accidentally move a prime imported buffer to
VRAM could be possible, but this would clearly be a rather severe bug we
hopefully have noticed already.
Any other idea what actually happens here?
Regards,
Christian.
More information about the dri-devel
mailing list