On Wed, Jul 20, 2016 at 12:53 AM, Tomasz Figa <tf...@chromium.org> wrote:
> On Wed, Jul 20, 2016 at 7:40 AM, Rob Herring <r...@kernel.org> wrote:
>> On Fri, Jul 15, 2016 at 2:53 AM, Tomasz Figa <tf...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
