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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxx >>> <mailto:l.stach@xxxxxxxxxxxxxx>> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
