[Mesa-dev] [PATCH 10/10] egl/android: Add fallback to kms_swrast driver

[Rob Herring]

On Wed, Jul 20, 2016 at 12:53 AM, Tomasz Figa <tfiga at chromium.org> wrote:
> On Wed, Jul 20, 2016 at 7:40 AM, Rob Herring <robh at kernel.org> wrote:
>> On Fri, Jul 15, 2016 at 2:53 AM, Tomasz Figa <tfiga at chromium.org> wrote:
>>> If no hardware driver is present, it is possible to fall back to
>>> the kms_swrast driver with any DRI node that supports dumb GEM create
>>> and mmap IOCTLs with softpipe/llvmpipe drivers. This patch makes the
>>> Android EGL platform code retry probe with kms_swrast if hardware-only
>>> probe fails.
>>
>> Presumably, you need a gralloc that supports this too? It would be
>> nice to have access to it to reproduce this setup.
>
> Our use case is running the system in Qemu with vgem driver, so our
> gralloc has a backend for vgem. However it should work with any
> available card or render node (more about render nodes below), no
> special support in gralloc really needed. It's just using kms_swrast
> instead of the native driver.

Okay, interesting. I've not really looked at vgem. GBM also has a path
for allocating dumb buffers which I was intending to try and get
working with s/w rendering. Sadly, I've found s/w rendering harder to
get working than h/w rendering.

>> [...]
>>
>>>  #define DRM_RENDER_DEV_NAME  "%s/renderD%d"
>>>
>>>  static int
>>> -droid_open_device(_EGLDisplay *dpy)
>>> +droid_open_device(_EGLDisplay *dpy, int swrast)
>>>  {
>>>     struct dri2_egl_display *dri2_dpy = dpy->DriverData;
>>>     const int limit = 64;
>>> @@ -933,7 +936,7 @@ droid_open_device(_EGLDisplay *dpy)
>>>        if (fd < 0)
>>>           continue;
>>>
>>> -      if (!droid_probe_device(dpy, fd))
>>> +      if (!droid_probe_device(dpy, fd, swrast))
>>
>> This only gets here if a render node is present and successfully
>> opened.
>
> This is the case when HAS_GRALLOC_HEADERS is not defined, which means
> only render nodes are supported. If you look at the other case, it
> will use whatever FD was provided by gralloc using that private
> perform call.
>
>> I would think in the sw rendering case, we want this to work
>> when there's only a card node present. Furthermore, you can't do dumb
>> allocs on a render node, so I don't see how this can work at all.
>
> This is only because the dumb alloc ioctl is not allowed, but that's
> the only thing preventing it from working. We had similar restriction
> put on mmap, but now everyone can just mmap the PRIME FD directly. We
> actually have a patch allowing dumb alloc and mmap ioctls for render
> nodes in our tree, because it makes things like swrast fallback much,
> much easier and doesn't seem to be harmful at all. It might be worth
> discussing this again on dri-devel mailing list.

Yes, bypassing permissions is an easy hack, but I believe what's in
place is by design and you are unlikely to change that. The answer
always seems to be don't use dumb buffers...

Rob