DMA-buf and uncached system memory
Thomas Zimmermann
tzimmermann at suse.de
Mon Feb 15 09:49:51 UTC 2021
Hi
Am 15.02.21 um 09:58 schrieb Christian König:
> Hi guys,
>
> we are currently working an Freesync and direct scan out from system
> memory on AMD APUs in A+A laptops.
>
> On problem we stumbled over is that our display hardware needs to scan
> out from uncached system memory and we currently don't have a way to
> communicate that through DMA-buf.
>
> For our specific use case at hand we are going to implement something
> driver specific, but the question is should we have something more
> generic for this?
For vmap operations, we return the address as struct dma_buf_map, which
contains additional information about the memory buffer. In vram
helpers, we have the interface drm_gem_vram_offset() that returns the
offset of the GPU device memory.
Would it be feasible to combine both concepts into a dma-buf interface
that returns the device-memory offset plus the additional caching flag?
There'd be a structure and a getter function returning the structure.
struct dma_buf_offset {
bool cached;
u64 address;
};
// return offset in *off
int dma_buf_offset(struct dma_buf *buf, struct dma_buf_off *off);
Whatever settings are returned by dma_buf_offset() are valid while the
dma_buf is pinned.
Best regards
Thomas
>
> After all the system memory access pattern is a PCIe extension and as
> such something generic.
>
> Regards,
> Christian.
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20210215/dd7e2a71/attachment.sig>
More information about the dri-devel
mailing list