[RFC] drm: Allow DRM_IOCTL_MODE_MAP_DUMB for render nodes

[Emil Velikov]

Hi all,

Sharing some ideas on the topic. Personally I'm neither for, nor
against this patch.

On 24 July 2018 at 09:22, Robert Foss <robert.foss at collabora.com> wrote:
> From: Tomasz Figa <tfiga at chromium.org>
>
> There is no particular reason to prevent userspace for using this IOCTL,
> considering that it already has access to other, platform-specific
> IOCTLs. This patch makes is possible to have the same userspace code
> work regardless on the underlying platform, which significantly
> simplifies the stack.
>
> Signed-off-by: Tomasz Figa <tfiga at chromium.org>
> Reviewed-by: Zach Reizner <zachr at chromium.org>
> Signed-off-by: Nicolas Norvez <norvez at chromium.org>
> Reviewed-by: Tomasz Figa <tfiga at chromium.org>
> Signed-off-by: Robert Foss <robert.foss at collabora.com>
> ---
>
> I've been looking into enabling a kms_swrast based driver for mesa on
> the Android platform[1].
>
> But have come up against the issue of dumb buffer related ioctls below
> not being flagged with DRM_RENDER_ALLOW.
>
> DRM_IOCTL_MODE_CREATE_DUMB
> DRM_IOCTL_MODE_MAP_DUMB
>
> To be more precise, I've been seeing a failure due to DRM_IOCTL_MODE_MAP_DUMB
> not being allowed for /dev/dri/renderD* nodes, and used in mesa
> kms_sw_displaytarget_map().
>
>
> As I understand it the DRM_RENDER_ALLOW flag being unset is a very intentional
> restriction placed on dumb buffers in order to minimize its use.
> But as far as alternative solutions for software renderers there seems to only
> be VGEM and mmap()-ing DMABUFs.
>
> While it would be convenient from the point of view of software renderers if
> dumb buffers had more promiscuous permissions, it may be a hard sell upstream.
>
> If dumb buffers aren't the way forward, what is? VGEM? Or are there any other
> preferable ways?
>
The description of VGEM says "... as used by Mesa's software renderer
for enhanced performance."
Although that hasn't been the case really, since we're opening an
arbitrary GPU node with kms_swrast.

I think we should fix that.

On top of that we could also use the card node, which will remove the
need for this patch.
Yet again, there may be reasonable usecases where one needs the render
node to support the dumb buffer ioctls.

HTH
Emil