Re: [PATCH] drm: enable render nodes wherever buffer sharing is supported
On Thu, Apr 30, 2020 at 12:57:40PM -0700, Eric Anholt wrote: > On Thu, Apr 30, 2020 at 3:44 AM Daniel Vetter wrote: > > > > On Tue, Apr 28, 2020 at 2:46 PM 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. > > > > > > Because all drivers that currently support render nodes also support > > > buffer sharing, the DRIVER_RENDER flag is no longer necessary to mark > > > devices as supporting render nodes, so remove it and just rely on > > > the presence of a prime_handle_to_fd function pointer to determine > > > whether buffer sharing is supported. > > > > The idea behind render nodes is that you can freely pass these to > > unpriviledged users, and nothing bad happens. That's why we have gpu > > reset code in drivers, proper pagetables, and also (in at least the > > solid drivers) ban code so that repeat offenders from userspace who > > constantly submit endless batch buffers and funny stuff like that > > can't DOS the gpu. > > > > Ofc in practice there's hw issues and fun stuff like that sometimes, > > and driver bugs, and all that. But that's the aspiration. > > > > Now many of these display-only drivers need contiguous buffers, and > > there's not endless amounts of that around. So if you allow random > > clients to allocate buffers, they can easily exhaust that, and not > > just upset the render side of the gpu, but essentially make it > > impossible for a compositor to allocate more framebuffers. I don't > > think that's a good idea. > > > > I know there's hw like vc4 which needs contiguous buffers for > > everything, but that's kinda the places where aspiration falls a bit > > short. > > > > So from that pov I'm a rather worried with handing out render rights > > to everyone for these display-only buffers. It's not entirely > > harmless. > > This doesn't feel like a contiguous-mem-specific concern to me. We > don't have resource limits on renderer GPU nodes today, you can > allocate memory there to fill up and DOS the system, and unless > something changed since last time I was looking, we don't even tell > the OOM killer about our allocations so they can kill the right app! > (my compositor always got picked, in my experience) > > And, keep in mind what we're fixing at a system level here: the > current workaround is you either get your compositor to hand you a GPU > fd, at which point you can DOS the system, or you open the master node > yourself and try to drop master before the compositor comes up, then > DOS the system. "But there are access controls for the compositor or > the card node!" you say: yes, but there are for render nodes too. I > know my distro doesn't default to open access to /dev/dri/render* Hm indeed, I thought we've limited dumb buffer creation to master only on the primary device. But that kinda leaves me wondering, how do you allocate buffers on these then? Exposing dumb on render nodes gets the Dave "it's not for rendering" Airlie nack, at least for drivers which do have real userspace sitting on the same drm driver. And exposing dumb only for these display-only devices feels somewhat silly and inconsistent too. So not sure. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: enable render nodes wherever buffer sharing is supported
On Thu, Apr 30, 2020 at 3:44 AM Daniel Vetter wrote: > > On Tue, Apr 28, 2020 at 2:46 PM 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. > > > > Because all drivers that currently support render nodes also support > > buffer sharing, the DRIVER_RENDER flag is no longer necessary to mark > > devices as supporting render nodes, so remove it and just rely on > > the presence of a prime_handle_to_fd function pointer to determine > > whether buffer sharing is supported. > > The idea behind render nodes is that you can freely pass these to > unpriviledged users, and nothing bad happens. That's why we have gpu > reset code in drivers, proper pagetables, and also (in at least the > solid drivers) ban code so that repeat offenders from userspace who > constantly submit endless batch buffers and funny stuff like that > can't DOS the gpu. > > Ofc in practice there's hw issues and fun stuff like that sometimes, > and driver bugs, and all that. But that's the aspiration. > > Now many of these display-only drivers need contiguous buffers, and > there's not endless amounts of that around. So if you allow random > clients to allocate buffers, they can easily exhaust that, and not > just upset the render side of the gpu, but essentially make it > impossible for a compositor to allocate more framebuffers. I don't > think that's a good idea. > > I know there's hw like vc4 which needs contiguous buffers for > everything, but that's kinda the places where aspiration falls a bit > short. > > So from that pov I'm a rather worried with handing out render rights > to everyone for these display-only buffers. It's not entirely > harmless. This doesn't feel like a contiguous-mem-specific concern to me. We don't have resource limits on renderer GPU nodes today, you can allocate memory there to fill up and DOS the system, and unless something changed since last time I was looking, we don't even tell the OOM killer about our allocations so they can kill the right app! (my compositor always got picked, in my experience) And, keep in mind what we're fixing at a system level here: the current workaround is you either get your compositor to hand you a GPU fd, at which point you can DOS the system, or you open the master node yourself and try to drop master before the compositor comes up, then DOS the system. "But there are access controls for the compositor or the card node!" you say: yes, but there are for render nodes too. I know my distro doesn't default to open access to /dev/dri/render* ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: enable render nodes wherever buffer sharing is supported
On Tue, Apr 28, 2020 at 2:46 PM 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.
>
> Because all drivers that currently support render nodes also support
> buffer sharing, the DRIVER_RENDER flag is no longer necessary to mark
> devices as supporting render nodes, so remove it and just rely on
> the presence of a prime_handle_to_fd function pointer to determine
> whether buffer sharing is supported.
The idea behind render nodes is that you can freely pass these to
unpriviledged users, and nothing bad happens. That's why we have gpu
reset code in drivers, proper pagetables, and also (in at least the
solid drivers) ban code so that repeat offenders from userspace who
constantly submit endless batch buffers and funny stuff like that
can't DOS the gpu.
Ofc in practice there's hw issues and fun stuff like that sometimes,
and driver bugs, and all that. But that's the aspiration.
Now many of these display-only drivers need contiguous buffers, and
there's not endless amounts of that around. So if you allow random
clients to allocate buffers, they can easily exhaust that, and not
just upset the render side of the gpu, but essentially make it
impossible for a compositor to allocate more framebuffers. I don't
think that's a good idea.
I know there's hw like vc4 which needs contiguous buffers for
everything, but that's kinda the places where aspiration falls a bit
short.
So from that pov I'm a rather worried with handing out render rights
to everyone for these display-only buffers. It's not entirely
harmless.
-Daniel
>
> Signed-off-by: Peter Collingbourne
> ---
> Documentation/gpu/drm-uapi.rst | 9 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
> drivers/gpu/drm/drm_drv.c | 2 +-
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.c | 2 +-
> drivers/gpu/drm/lima/lima_drv.c | 2 +-
> drivers/gpu/drm/msm/msm_drv.c | 1 -
> drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
> drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +-
> drivers/gpu/drm/radeon/radeon_drv.c | 3 +--
> drivers/gpu/drm/tegra/drm.c | 2 +-
> drivers/gpu/drm/v3d/v3d_drv.c | 1 -
> drivers/gpu/drm/vc4/vc4_drv.c | 8
> drivers/gpu/drm/vgem/vgem_drv.c | 2 +-
> drivers/gpu/drm/virtio/virtgpu_drv.c| 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
> include/drm/drm_drv.h | 7 ---
> 19 files changed, 19 insertions(+), 36 deletions(-)
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 56fec6ed1ad8..2769714ae75a 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -129,10 +129,11 @@ authenticate to a DRM-Master prior to getting GPU
> access. To avoid this
> step and to grant clients GPU access without authenticating, render
> nodes were introduced. Render nodes solely serve render clients, that
> is, no modesetting or privileged ioctls can be issued on render nodes.
> -Only non-global rendering commands are allowed. If a driver supports
> -render nodes, it must advertise it via the DRIVER_RENDER DRM driver
> -capability. If not supported, the primary node must be used for render
> -clients together with the legacy drmAuth authentication procedure.
> +Only non-global rendering commands are allowed. Drivers that support
> +:ref:`PRIME buffer sharing ` automatically
> +support render nodes. If a driver does not support render nodes,
> +the primary node must be used for render clients together with the
> +legacy drmAuth authentication procedure.
>
> If a driver advertises render node support, DRM core will create a
> separate render node called renderD. There will be one render node
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 8ea86ffdea0d..46460620bc37 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1426,7 +1426,7 @@ static struct drm_driver kms_driver = {
> .driver_features =
> DRIVER_ATOMIC |
> DRIVER_GEM |
> - DRIVER_RENDER | DRIVER_MODESET | DRIVER_SYNCOBJ |
> + DRIVER_MODESET | DRIVER_SYNCOBJ |
> DRIVER_SYNCOBJ_TIMELINE,
> .open = amdgpu_driver_open_kms,
> .postclose =
Re: [PATCH] drm: enable render nodes wherever buffer sharing is supported
On Thu, Apr 30, 2020 at 12:30 PM Brian Starkey wrote: > > On Wed, Apr 29, 2020 at 06:31:01PM +0100, Liviu Dudau wrote: > > On Wed, Apr 29, 2020 at 09:51:19AM -0700, Peter Collingbourne wrote: > > > On Wed, Apr 29, 2020 at 9:17 AM Brian Starkey > > > 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. > > Yeah I'd be surprised if FVP cares about anything other than it being > contiguous. > > My understanding of how "most" Android devices implement this is to > have ion heaps representing whatever dedicated memory regions there > are. Gralloc can then pick the appropriate one based on the gralloc > usage flags. So allocations wouldn't go via the DRM driver. > > It looks like the checks in pl111 can't support that usage model if > use_device_memory is set (though that wouldn't matter on FVP). > > > > > We have been doing that with mali-dp drivers for years. Because most of > > our dev environments are on FPGAs, we needed to use the local RAM on > > those boards so we've had to assign a memory region to the driver that > > in turn was using CMA. We've made heavy use of 'reserved-memory' and > > 'memory-region' nodes in the DT to link the two together, but things > > worked out quite well. Because the 'reserved-memory' sub-node was marked > > as 'compatible="shared-dma-pool"', gralloc and ION could be used to > > allocate memory from it. > > This is a little imperfect because ion doesn't have a way to access > the `dev` pointer needed to allocate from device-attached CMA regions, > so some hackery is required. > > I think dma-heaps would let you expose device-specific CMA regions. The plan was that each device in sysfs which needs special dma memory would have a pointer to the corresponding dma-heap. That way userspace knows where to allocate. Just need some userspace to use these, and kernel patch to expose those links. I think it's defacto already there through the dma pointers of struct device. -Daniel > > Even if you did that and allocated from the right place, the check > in pl111 would reject any attempt to import it if it's set to > use_device_memory. > > I don't know if there's a better way to tell if the memory is > compatible, but that check seems like a bit of a sledgehammer. It > looks like it not only forces the memory to be from the right place, > it also forces it to have been allocated via pl111. > > On FVP though, I reckon any old CMA memory should be fine. > > Cheers, > -Brian > > > > > Best regards, > > Liviu > > > > > > > > Peter > > > > > > [1] > > > https://www.kernel.org/doc/Documentation/devicetree/bindings/display/arm%2Cpl11x.txt > > > > -- > > > > | I would like to | > > | fix the world, | > > | but they're not | > > | giving me the | > > \ source code! / > > --- > > ¯\_(ツ)_/¯ > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365
Re: [PATCH] drm: enable render nodes wherever buffer sharing is supported
On Wed, Apr 29, 2020 at 06:31:01PM +0100, Liviu Dudau wrote: > On Wed, Apr 29, 2020 at 09:51:19AM -0700, Peter Collingbourne wrote: > > On Wed, Apr 29, 2020 at 9:17 AM Brian Starkey 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. Yeah I'd be surprised if FVP cares about anything other than it being contiguous. My understanding of how "most" Android devices implement this is to have ion heaps representing whatever dedicated memory regions there are. Gralloc can then pick the appropriate one based on the gralloc usage flags. So allocations wouldn't go via the DRM driver. It looks like the checks in pl111 can't support that usage model if use_device_memory is set (though that wouldn't matter on FVP). > > We have been doing that with mali-dp drivers for years. Because most of > our dev environments are on FPGAs, we needed to use the local RAM on > those boards so we've had to assign a memory region to the driver that > in turn was using CMA. We've made heavy use of 'reserved-memory' and > 'memory-region' nodes in the DT to link the two together, but things > worked out quite well. Because the 'reserved-memory' sub-node was marked > as 'compatible="shared-dma-pool"', gralloc and ION could be used to > allocate memory from it. This is a little imperfect because ion doesn't have a way to access the `dev` pointer needed to allocate from device-attached CMA regions, so some hackery is required. I think dma-heaps would let you expose device-specific CMA regions. Even if you did that and allocated from the right place, the check in pl111 would reject any attempt to import it if it's set to use_device_memory. I don't know if there's a better way to tell if the memory is compatible, but that check seems like a bit of a sledgehammer. It looks like it not only forces the memory to be from the right place, it also forces it to have been allocated via pl111. On FVP though, I reckon any old CMA memory should be fine. Cheers, -Brian > > Best regards, > Liviu > > > > > Peter > > > > [1] > > https://www.kernel.org/doc/Documentation/devicetree/bindings/display/arm%2Cpl11x.txt > > -- > > | I would like to | > | fix the world, | > | but they're not | > | giving me the | > \ source code! / > --- > ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: enable render nodes wherever buffer sharing is supported
On Wed, Apr 29, 2020 at 09:51:19AM -0700, Peter Collingbourne wrote: > On Wed, Apr 29, 2020 at 9:17 AM Brian Starkey 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. We have been doing that with mali-dp drivers for years. Because most of our dev environments are on FPGAs, we needed to use the local RAM on those boards so we've had to assign a memory region to the driver that in turn was using CMA. We've made heavy use of 'reserved-memory' and 'memory-region' nodes in the DT to link the two together, but things worked out quite well. Because the 'reserved-memory' sub-node was marked as 'compatible="shared-dma-pool"', gralloc and ION could be used to allocate memory from it. Best regards, Liviu > > Peter > > [1] > https://www.kernel.org/doc/Documentation/devicetree/bindings/display/arm%2Cpl11x.txt -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: enable render nodes wherever buffer sharing is supported
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. Cheers, -Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: enable render nodes wherever buffer sharing is supported
On Tue, Apr 28, 2020 at 4:48 AM Liviu Dudau wrote: > > On Mon, Apr 27, 2020 at 07:22:02PM -0700, Peter Collingbourne wrote: > > On Mon, Apr 27, 2020 at 1:47 PM Eric Anholt wrote: > > > > > > On Mon, Apr 27, 2020 at 1:05 PM 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. > > > > > > > > Because all drivers that currently support render nodes also support > > > > buffer sharing, the DRIVER_RENDER flag is no longer necessary to mark > > > > devices as supporting render nodes, so remove it and just rely on > > > > the presence of a prime_handle_to_fd function pointer to determine > > > > whether buffer sharing is supported. > > > > > > I'm definitely interested in seeing a patch like this land, as I think > > > the current state is an ugly historical artifact. We just have to be > > > careful. > > > > > > Were there any instances of drivers with render engines exposing PRIME > > > but not RENDER? We should be careful to make sure that we're not > > > exposing new privileges for those through adding render nodes. > > > > These are the drivers that we'd be adding render nodes for with this change: > > > > $ git grep -l prime_handle_to_fd (git grep -L DRIVER_RENDER (git grep > > -l '\.driver_features')) > > drivers/gpu/drm/arc/arcpgu_drv.c > > drivers/gpu/drm/arm/display/komeda/komeda_kms.c > > drivers/gpu/drm/arm/hdlcd_drv.c > > drivers/gpu/drm/arm/malidp_drv.c > > drivers/gpu/drm/armada/armada_drv.c > > drivers/gpu/drm/aspeed/aspeed_gfx_drv.c > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > > drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c > > drivers/gpu/drm/imx/imx-drm-core.c > > drivers/gpu/drm/ingenic/ingenic-drm.c > > drivers/gpu/drm/mcde/mcde_drv.c > > drivers/gpu/drm/mediatek/mtk_drm_drv.c > > drivers/gpu/drm/meson/meson_drv.c > > drivers/gpu/drm/mxsfb/mxsfb_drv.c > > drivers/gpu/drm/pl111/pl111_drv.c > > drivers/gpu/drm/qxl/qxl_drv.c > > drivers/gpu/drm/rcar-du/rcar_du_drv.c > > drivers/gpu/drm/rockchip/rockchip_drm_drv.c > > drivers/gpu/drm/shmobile/shmob_drm_drv.c > > drivers/gpu/drm/sti/sti_drv.c > > drivers/gpu/drm/stm/drv.c > > drivers/gpu/drm/tilcdc/tilcdc_drv.c > > drivers/gpu/drm/tve200/tve200_drv.c > > drivers/gpu/drm/xen/xen_drm_front.c > > drivers/gpu/drm/zte/zx_drm_drv.c > > > > Some of the drivers provide custom ioctls but they are already > > protected from render nodes by not setting DRM_RENDER_ALLOW. Another > > thing to check for is drivers providing custom fops that might expose > > something undesirable in the render node: > > > > $ git grep -L 'DEFINE_DRM_GEM_CMA_FOPS\|DEFINE_DRM_GEM_FOPS' (git grep > > -l prime_handle_to_fd (git grep -L DRIVER_RENDER (git grep -l > > '\.driver_features'))) > > drivers/gpu/drm/mediatek/mtk_drm_drv.c > > drivers/gpu/drm/rockchip/rockchip_drm_drv.c > > drivers/gpu/drm/xen/xen_drm_front.c > > > > But looking at those drivers in detail, I see that each of them is > > using the standard DRM fops handlers (which presumably already handle > > render nodes correctly) with the exception of mmap, which they provide > > wrappers for that mostly just wrap drm_gem_mmap. > > > > So unless I'm missing something significant (which seems likely -- I'm > > not a DRM expert), I don't see a problem so far. > > > > > There's a UAPI risk I see here. Right now, on a system with a single > > > renderer GPU, we can just open /dev/dri/renderD128 and get the GPU for > > > rendering, and various things are relying on that (such as libwaffle, > > > used in piglit among other things) Adding render nodes for kms-only > > > drivers could displace the actual GPU to 129, and the question is > > > whether this will be disruptive. For Mesa, I think this works out, > > > because kmsro should load on the kms device's node and then share > > > buffers over to the real GPU that it digs around to find at init time. > > > Just saying, I'm not sure I know all of the userspace well enough to > > > say "this should be safe despite that" > > > > > > (And, maybe, if we decide that it's not safe enough, we could punt > > > kms-only drivers to a higher starting number?) > > > > Android (minigbm) similarly tries to open /dev/dri/renderD$N in a loop > > with 128 <= N < 192 and assumes that the first non-blacklisted (i.e. > > not vgem) one that it can open corresponds to the real GPU [1]. I > > think that the risk of breaking something on Android is low since
Re: [PATCH] drm: enable render nodes wherever buffer sharing is supported
On Mon, Apr 27, 2020 at 1:47 PM Eric Anholt wrote: > > On Mon, Apr 27, 2020 at 1:05 PM 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. > > > > Because all drivers that currently support render nodes also support > > buffer sharing, the DRIVER_RENDER flag is no longer necessary to mark > > devices as supporting render nodes, so remove it and just rely on > > the presence of a prime_handle_to_fd function pointer to determine > > whether buffer sharing is supported. > > I'm definitely interested in seeing a patch like this land, as I think > the current state is an ugly historical artifact. We just have to be > careful. > > Were there any instances of drivers with render engines exposing PRIME > but not RENDER? We should be careful to make sure that we're not > exposing new privileges for those through adding render nodes. These are the drivers that we'd be adding render nodes for with this change: $ git grep -l prime_handle_to_fd (git grep -L DRIVER_RENDER (git grep -l '\.driver_features')) drivers/gpu/drm/arc/arcpgu_drv.c drivers/gpu/drm/arm/display/komeda/komeda_kms.c drivers/gpu/drm/arm/hdlcd_drv.c drivers/gpu/drm/arm/malidp_drv.c drivers/gpu/drm/armada/armada_drv.c drivers/gpu/drm/aspeed/aspeed_gfx_drv.c drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c drivers/gpu/drm/imx/imx-drm-core.c drivers/gpu/drm/ingenic/ingenic-drm.c drivers/gpu/drm/mcde/mcde_drv.c drivers/gpu/drm/mediatek/mtk_drm_drv.c drivers/gpu/drm/meson/meson_drv.c drivers/gpu/drm/mxsfb/mxsfb_drv.c drivers/gpu/drm/pl111/pl111_drv.c drivers/gpu/drm/qxl/qxl_drv.c drivers/gpu/drm/rcar-du/rcar_du_drv.c drivers/gpu/drm/rockchip/rockchip_drm_drv.c drivers/gpu/drm/shmobile/shmob_drm_drv.c drivers/gpu/drm/sti/sti_drv.c drivers/gpu/drm/stm/drv.c drivers/gpu/drm/tilcdc/tilcdc_drv.c drivers/gpu/drm/tve200/tve200_drv.c drivers/gpu/drm/xen/xen_drm_front.c drivers/gpu/drm/zte/zx_drm_drv.c Some of the drivers provide custom ioctls but they are already protected from render nodes by not setting DRM_RENDER_ALLOW. Another thing to check for is drivers providing custom fops that might expose something undesirable in the render node: $ git grep -L 'DEFINE_DRM_GEM_CMA_FOPS\|DEFINE_DRM_GEM_FOPS' (git grep -l prime_handle_to_fd (git grep -L DRIVER_RENDER (git grep -l '\.driver_features'))) drivers/gpu/drm/mediatek/mtk_drm_drv.c drivers/gpu/drm/rockchip/rockchip_drm_drv.c drivers/gpu/drm/xen/xen_drm_front.c But looking at those drivers in detail, I see that each of them is using the standard DRM fops handlers (which presumably already handle render nodes correctly) with the exception of mmap, which they provide wrappers for that mostly just wrap drm_gem_mmap. So unless I'm missing something significant (which seems likely -- I'm not a DRM expert), I don't see a problem so far. > There's a UAPI risk I see here. Right now, on a system with a single > renderer GPU, we can just open /dev/dri/renderD128 and get the GPU for > rendering, and various things are relying on that (such as libwaffle, > used in piglit among other things) Adding render nodes for kms-only > drivers could displace the actual GPU to 129, and the question is > whether this will be disruptive. For Mesa, I think this works out, > because kmsro should load on the kms device's node and then share > buffers over to the real GPU that it digs around to find at init time. > Just saying, I'm not sure I know all of the userspace well enough to > say "this should be safe despite that" > > (And, maybe, if we decide that it's not safe enough, we could punt > kms-only drivers to a higher starting number?) Android (minigbm) similarly tries to open /dev/dri/renderD$N in a loop with 128 <= N < 192 and assumes that the first non-blacklisted (i.e. not vgem) one that it can open corresponds to the real GPU [1]. I think that the risk of breaking something on Android is low since Android's architecture basically already depends on there being a render node, and it seems unlikely for a device to have more than one GPU, one of which would be non-functional. It's also worth bearing in mind that render nodes were added to vgem in commit 3a6eb795 from 2018. To the extent that exposing additional render nodes would lead to widespread breakage, this would seem to me to be a likely way in which it could have happened (since I would expect that it could cause many machines to go from
Re: [PATCH] drm: enable render nodes wherever buffer sharing is supported
On Mon, Apr 27, 2020 at 07:22:02PM -0700, Peter Collingbourne wrote: > On Mon, Apr 27, 2020 at 1:47 PM Eric Anholt wrote: > > > > On Mon, Apr 27, 2020 at 1:05 PM 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. > > > > > > Because all drivers that currently support render nodes also support > > > buffer sharing, the DRIVER_RENDER flag is no longer necessary to mark > > > devices as supporting render nodes, so remove it and just rely on > > > the presence of a prime_handle_to_fd function pointer to determine > > > whether buffer sharing is supported. > > > > I'm definitely interested in seeing a patch like this land, as I think > > the current state is an ugly historical artifact. We just have to be > > careful. > > > > Were there any instances of drivers with render engines exposing PRIME > > but not RENDER? We should be careful to make sure that we're not > > exposing new privileges for those through adding render nodes. > > These are the drivers that we'd be adding render nodes for with this change: > > $ git grep -l prime_handle_to_fd (git grep -L DRIVER_RENDER (git grep > -l '\.driver_features')) > drivers/gpu/drm/arc/arcpgu_drv.c > drivers/gpu/drm/arm/display/komeda/komeda_kms.c > drivers/gpu/drm/arm/hdlcd_drv.c > drivers/gpu/drm/arm/malidp_drv.c > drivers/gpu/drm/armada/armada_drv.c > drivers/gpu/drm/aspeed/aspeed_gfx_drv.c > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c > drivers/gpu/drm/imx/imx-drm-core.c > drivers/gpu/drm/ingenic/ingenic-drm.c > drivers/gpu/drm/mcde/mcde_drv.c > drivers/gpu/drm/mediatek/mtk_drm_drv.c > drivers/gpu/drm/meson/meson_drv.c > drivers/gpu/drm/mxsfb/mxsfb_drv.c > drivers/gpu/drm/pl111/pl111_drv.c > drivers/gpu/drm/qxl/qxl_drv.c > drivers/gpu/drm/rcar-du/rcar_du_drv.c > drivers/gpu/drm/rockchip/rockchip_drm_drv.c > drivers/gpu/drm/shmobile/shmob_drm_drv.c > drivers/gpu/drm/sti/sti_drv.c > drivers/gpu/drm/stm/drv.c > drivers/gpu/drm/tilcdc/tilcdc_drv.c > drivers/gpu/drm/tve200/tve200_drv.c > drivers/gpu/drm/xen/xen_drm_front.c > drivers/gpu/drm/zte/zx_drm_drv.c > > Some of the drivers provide custom ioctls but they are already > protected from render nodes by not setting DRM_RENDER_ALLOW. Another > thing to check for is drivers providing custom fops that might expose > something undesirable in the render node: > > $ git grep -L 'DEFINE_DRM_GEM_CMA_FOPS\|DEFINE_DRM_GEM_FOPS' (git grep > -l prime_handle_to_fd (git grep -L DRIVER_RENDER (git grep -l > '\.driver_features'))) > drivers/gpu/drm/mediatek/mtk_drm_drv.c > drivers/gpu/drm/rockchip/rockchip_drm_drv.c > drivers/gpu/drm/xen/xen_drm_front.c > > But looking at those drivers in detail, I see that each of them is > using the standard DRM fops handlers (which presumably already handle > render nodes correctly) with the exception of mmap, which they provide > wrappers for that mostly just wrap drm_gem_mmap. > > So unless I'm missing something significant (which seems likely -- I'm > not a DRM expert), I don't see a problem so far. > > > There's a UAPI risk I see here. Right now, on a system with a single > > renderer GPU, we can just open /dev/dri/renderD128 and get the GPU for > > rendering, and various things are relying on that (such as libwaffle, > > used in piglit among other things) Adding render nodes for kms-only > > drivers could displace the actual GPU to 129, and the question is > > whether this will be disruptive. For Mesa, I think this works out, > > because kmsro should load on the kms device's node and then share > > buffers over to the real GPU that it digs around to find at init time. > > Just saying, I'm not sure I know all of the userspace well enough to > > say "this should be safe despite that" > > > > (And, maybe, if we decide that it's not safe enough, we could punt > > kms-only drivers to a higher starting number?) > > Android (minigbm) similarly tries to open /dev/dri/renderD$N in a loop > with 128 <= N < 192 and assumes that the first non-blacklisted (i.e. > not vgem) one that it can open corresponds to the real GPU [1]. I > think that the risk of breaking something on Android is low since > Android's architecture basically already depends on there being a > render node, and it seems unlikely for a device to have more than one > GPU, one of which would be non-functional. Would Juno suffer from this issue? It has 2 HDLCD drivers
Re: [PATCH] drm: enable render nodes wherever buffer sharing is supported
On Mon, Apr 27, 2020 at 1:05 PM 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. > > Because all drivers that currently support render nodes also support > buffer sharing, the DRIVER_RENDER flag is no longer necessary to mark > devices as supporting render nodes, so remove it and just rely on > the presence of a prime_handle_to_fd function pointer to determine > whether buffer sharing is supported. I'm definitely interested in seeing a patch like this land, as I think the current state is an ugly historical artifact. We just have to be careful. Were there any instances of drivers with render engines exposing PRIME but not RENDER? We should be careful to make sure that we're not exposing new privileges for those through adding render nodes. There's a UAPI risk I see here. Right now, on a system with a single renderer GPU, we can just open /dev/dri/renderD128 and get the GPU for rendering, and various things are relying on that (such as libwaffle, used in piglit among other things) Adding render nodes for kms-only drivers could displace the actual GPU to 129, and the question is whether this will be disruptive. For Mesa, I think this works out, because kmsro should load on the kms device's node and then share buffers over to the real GPU that it digs around to find at init time. Just saying, I'm not sure I know all of the userspace well enough to say "this should be safe despite that" (And, maybe, if we decide that it's not safe enough, we could punt kms-only drivers to a higher starting number?) > @@ -260,12 +258,6 @@ static int vc4_drm_bind(struct device *dev) > if (!vc4) > return -ENOMEM; > > - /* If VC4 V3D is missing, don't advertise render nodes. */ > - node = of_find_matching_node_and_match(NULL, vc4_v3d_dt_match, NULL); > - if (!node || !of_device_is_available(node)) > - vc4_drm_driver.driver_features &= ~DRIVER_RENDER; > - of_node_put(node); > - > drm = drm_dev_alloc(_drm_driver, dev); > if (IS_ERR(drm)) > return PTR_ERR(drm); Looks like dropping this code from vc4 should be fine -- kmsro looks for a render node from each driver name it supports in turn, so even if v3d moves from renderD128 to renderD129, things should still work. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
