Linux Virtualization - May 2019 - [PATCH v4 00/19] Share TTM code among DRM framebuffer drivers

Hi

Am 06.05.19 um 14:22 schrieb Gerd Hoffmann:
>> GEM VRAM could implement PRIME helpers, which would allow for using
>> the generic fbcon.
> 
> bochs_gem_prime_*() functions with this series applied look like you can
> just rename them & move over to vram helpers.
> 
> It's not a full prime implementation, specifically actual export/import
> isn't there.  But pin+vmap (needed by generic fbcon) is implemented.
I did have a patch to do this, but then I read that prime requires DMA
for buffer sharing and bochs works only because it's emulated. If bochs'
implementation is complete enough to be useful for other drivers, I'll
add it to the patch set.

Best regards
Thomas
> cheers,
>   Gerd
> 
-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imend?rffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG N?rnberg)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20190506/c6105a8a/attachment.sig>

On Mon, May 06, 2019 at 03:09:20PM +0200, Thomas Zimmermann
wrote:
> Hi
> 
> Am 06.05.19 um 14:22 schrieb Gerd Hoffmann:
> >> GEM VRAM could implement PRIME helpers, which would allow for
using
> >> the generic fbcon.
> > 
> > bochs_gem_prime_*() functions with this series applied look like you
can
> > just rename them & move over to vram helpers.
> > 
> > It's not a full prime implementation, specifically actual
export/import
> > isn't there.  But pin+vmap (needed by generic fbcon) is
implemented.
> 
> I did have a patch to do this, but then I read that prime requires DMA
> for buffer sharing and bochs works only because it's emulated.
For actual buffer sharing with other drivers yes because dma-bufs
typically are a bunch of pages (struct page**) and live in RAM.

Not sure whenever it is possible or useful to place the vram in
ZONE_DEVICE to get page structs for it, then export buffers located
in vram that way without copying them over to main memory.  I suspect
most importers would fail to properly setup PCI-PCI dma in that case.
> If bochs' implementation is complete enough to be useful for other
> drivers, I'll add it to the patch set.
It's good enough for generic fbcon.

cheers,
  Gerd

On Mon, May 06, 2019 at 04:20:34PM +0200, Gerd Hoffmann
wrote:
> On Mon, May 06, 2019 at 03:09:20PM +0200, Thomas Zimmermann wrote:
> > Hi
> > 
> > Am 06.05.19 um 14:22 schrieb Gerd Hoffmann:
> > >> GEM VRAM could implement PRIME helpers, which would allow for
using
> > >> the generic fbcon.
> > > 
> > > bochs_gem_prime_*() functions with this series applied look like
you can
> > > just rename them & move over to vram helpers.
> > > 
> > > It's not a full prime implementation, specifically actual
export/import
> > > isn't there.  But pin+vmap (needed by generic fbcon) is
implemented.
> > 
> > I did have a patch to do this, but then I read that prime requires DMA
> > for buffer sharing and bochs works only because it's emulated.
> 
> For actual buffer sharing with other drivers yes because dma-bufs
> typically are a bunch of pages (struct page**) and live in RAM.
> 
> Not sure whenever it is possible or useful to place the vram in
> ZONE_DEVICE to get page structs for it, then export buffers located
> in vram that way without copying them over to main memory.  I suspect
> most importers would fail to properly setup PCI-PCI dma in that case.
Christian K?nig is working on p2p dma-buf sharing. Not sure that's worth
it for virtual devices, but could be fun to wire up I guess.
-Daniel
> 
> > If bochs' implementation is complete enough to be useful for other
> > drivers, I'll add it to the patch set.
> 
> It's good enough for generic fbcon.
> 
> cheers,
>   Gerd
> 
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch