Re: [PATCH] drm: enable render nodes wherever buffer sharing is supported

From: Peter Collingbourne <pcc@google.com>
To: Brian Starkey <brian.starkey@arm.com>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>,
	nd@arm.com, Emil Velikov <emil.l.velikov@gmail.com>,
	ML dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] drm: enable render nodes wherever buffer sharing is supported
Date: Wed, 29 Apr 2020 09:51:19 -0700	[thread overview]
Message-ID: <CAMn1gO4ozMZQk3jN7iNGH5Cq-3jQd=d4vgVj-Zr35u3YRsMG0Q@mail.gmail.com> (raw)
In-Reply-To: <20200429161650.65m37srq3sucbsit@DESKTOP-E1NTVVP.localdomain>

On Wed, Apr 29, 2020 at 9:17 AM Brian Starkey <brian.starkey@arm.com> wrote:
>
> Hi Peter,
>
> On Mon, Apr 27, 2020 at 01:05:13PM -0700, Peter Collingbourne wrote:
> > Render nodes are not just useful for devices supporting GPU hardware
> > acceleration. Even on devices that only support dumb frame buffers,
> > they are useful in situations where composition (using software
> > rasterization) and KMS are done in different processes with buffer
> > sharing being used to send frame buffers between them. This is the
> > situation on Android, where surfaceflinger is the compositor and the
> > composer HAL uses KMS to display the buffers. Thus it is beneficial
> > to expose render nodes on all devices that support buffer sharing.
>
> If I understand your problem right, the issue is that you're getting
> your buffers in minigbm via pl111, which means you want a render node
> just for buffer allocation? Then HWComposer will import those on the
> primary node for displaying.

Correct.

> I'm not at all familiar with how minigbm sits in Android, but on our
> platforms where the Display and GPU devices are different, we allocate
> via ion in Gralloc, and import those into both the GPU and Display.
> I think that should work on pl111 too - if you can allocate contiguous
> memory from ion (or dma-buf heaps) in minigbm, then you don't need the
> render node.

Those contiguous memory regions would not necessarily be compatible
with the pl111 device as far as I know -- according to [1], on some
devices, a designated memory region must be used for the framebuffer
and therefore the memory region allocated in CMA would not be
compatible. That being said, FVP doesn't appear to be one of those
devices, so in principle that might work for FVP (provided that the
user provides a sufficiently large cma=X kernel command line
argument), but not for those other devices.

Peter

[1] https://www.kernel.org/doc/Documentation/devicetree/bindings/display/arm%2Cpl11x.txt
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel