[RFC PATCH 2/2] vc4: introduce DMA-BUF heap

[Maxime Ripard]

On Fri, Nov 10, 2023 at 02:17:45PM +0000, Simon Ser wrote:
> On Friday, November 10th, 2023 at 15:13, Maxime Ripard <mripard at kernel.org> wrote:
> 
> > > > > We've talked with Sima at XDC about adding a symlink pointing to the
> > > > > DMA heap and extra metadata files describing priorities and such.
> > > > > However we don't actually need that part for the purposes of v3d --
> > > > > I think I'd rather defer that until more DMA heaps are plumbed
> > > > > across the DRM drivers.
> > > > 
> > > > Honestly, I don't think we can afford to only consider vc4/v3d here. The
> > > > issue you described seem to affect any SoC with a split scanout/GPU,
> > > > which is pretty much all of them? And if they are all affected, we
> > > > should design something that fixes it once and for all.
> > > 
> > > We don't need any sysfs stuff to fix the primary node and DRM dumb buffer
> > > issues in Mesa's kmsro/renderonly. The sysfs stuff is only required for a fully
> > > generic buffer placement constraint/compatibility uAPI. Which would be super
> > > useful in compositors, but let's do one step at a time.
> > 
> > I don't think a solution that further fragments the ecosystem is worth
> > taking, sorry. What you're doing is valuable, we should totally fix the
> > issue you have, but not at the expense of making vc4 special on one of
> > the platforms it supports.
> 
> This does not fragment the ecosystem. It moves the ecosystem bit by bit
> towards the final solution.

You can rephrase that any way you want, it moves one driver towards the
final solution, thus making it deviate from the norm and leaving the
rest behind.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20231113/0756ecf2/attachment.sig>