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

Tomasz Figa tfiga at chromium.org
Wed Jul 20 05:53:07 UTC 2016

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.

> [...]
>>  #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.

In any case, this patch alone, even without any kernel changes should
work just fine with gralloc that returns a control node FD from the
GET_FD perform call.

Best regards,

More information about the mesa-dev mailing list