[PATCH 1/2] drm: Add DRM_CAP_PRIME_SCANOUT.
michel at daenzer.net
Mon Apr 17 06:41:10 UTC 2017
On 17/04/17 02:05 PM, Christopher James Halse Rogers wrote:
> On 10 April 2017 6:51:21 pm AEST, "Michel Dänzer" <michel at daenzer.net> wrote:
>> On 06/04/17 04:47 PM, Christopher James Halse Rogers wrote:
>>> On Wed, 5 Apr 2017 at 20:14 Lucas Stach <l.stach at pengutronix.de
>>> <mailto:l.stach at pengutronix.de>> wrote:
>>>> Drivers with separate VRAM and GTT are already doing a lot of migration
>>>> behind the userspaces back. The only issue with dma-buf migration to
>>>> VRAM is that you probably don't want to migrate the pages, but duplicate
>>>> them in VRAM, doubling memory consumption with possible OOM. But then
>>>> you could alloc the memory on addfb where you are able to return proper
>>> Hm. So, on a first inspection, this looks like something I could
>>> actually cook up.
>>> Looking at amdgpu it seems like the thing to do would be to associate a
>>> shadow-bo in VRAM for the imported dma-buf in the addfb call, then
>>> pin-and-copy-to the shadow bo in the places where the bo is currently
>>> Is this approach likely to be acceptable?
>> It would break e.g. with DRI2 flips, because they replace the screen
>> pixmap buffer with the buffer we're flipping to. If the app stops
>> flipping while such a shadow BO is being scanned out, later draws to
>> the screen pixmap won't become visible.
> This shadow BO would only ever be used for imported dma-bufs. This
> would change the behaviour from “addfb fails” to “you get a shadow
> BO”. (And, pre-patch, from “addfb succeeds but you never see any new
> I don't think any DRI2 implementation hits this, because of it did it
> would already be broken.
You're right, I got it backwards. I guess this could work.
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
More information about the dri-devel