[PATCH 1/2] drm: Add DRM_CAP_PRIME_SCANOUT.

[Michel Dänzer]

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
>>>> errors.
>>>
>>> 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
>>> pinned.
>>>
>>> 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
> rendering”).
> 
> 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