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

Brian Starkey brian.starkey at arm.com
Wed Apr 29 16:16:50 UTC 2020

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.

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.


More information about the dri-devel mailing list