[Mesa-dev] [PATCH 3/6] Add support for swrast to the DRM EGL platform

[Emil Velikov]

On 24/07/14 14:30, Pekka Paalanen wrote:
> On Thu, 24 Jul 2014 13:34:42 +0100
> Emil Velikov <emil.l.velikov at gmail.com> wrote:
> 
>> On 24/07/14 07:23, Pekka Paalanen wrote:
>>> On Thu, 24 Jul 2014 01:43:35 +0100
>>> Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>
>>>> From: Giovanni Campagna <gcampagna at src.gnome.org>
>>>>
>>>> Turn GBM into a swrast loader (providing putimage/getimage backed
>>>> by a dumb KMS buffer). This allows to run KMS+DRM GL applications
>>>> (such as weston or mutter-wayland) unmodified on cards that don't
>>>> have any client side HW acceleration component but that can do
>>>> modeset (examples include simpledrm and qxl)
>>>>
>>>> [Emil Velikov]
>>>>  - Fix make check.
>>>>  - Split dri_open_driver() from dri_load_driver().
>>>>  - Don't try to bind the swrast extensions when using dri.
>>>>  - Handle swrast->CreateNewScreen() failure.
>>>>  - strdup the driver_name, as it's free'd at destruction.
>>>>  - s/LIBGL_ALWAYS_SOFTWARE/GBM_ALWAYS_SOFTWARE/
>>>>  - Move gbm_dri_bo_map/unmap to gbm_driiint.h.
>>>>  - Correct swrast fallback logic.
>>>>
>>>> Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com>
>>>> ---
>>>>  src/egl/drivers/dri2/platform_drm.c | 153 +++++++++++++++++++++++----
>>>>  src/gbm/backends/dri/gbm_dri.c      | 203 +++++++++++++++++++++++++++++++-----
>>>>  src/gbm/backends/dri/gbm_driint.h   |  57 +++++++++-
>>>>  src/gbm/gbm-symbols-check           |   1 +
>>>>  src/gbm/main/gbm.h                  |   3 +
>>>>  5 files changed, 369 insertions(+), 48 deletions(-)
>>>>
>>>
>>>> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
>>>> index 347bc99..1aca506 100644
>>>> --- a/src/gbm/backends/dri/gbm_dri.c
>>>> +++ b/src/gbm/backends/dri/gbm_dri.c
>>>
>>>> @@ -743,7 +886,7 @@ static struct gbm_device *
>>>>  dri_device_create(int fd)
>>>>  {
>>>>     struct gbm_dri_device *dri;
>>>> -   int ret;
>>>> +   int ret, force_sw;
>>>>  
>>>>     dri = calloc(1, sizeof *dri);
>>>>     if (!dri)
>>>> @@ -763,7 +906,15 @@ dri_device_create(int fd)
>>>>     dri->base.type = GBM_DRM_DRIVER_TYPE_DRI;
>>>>     dri->base.base.name = "drm";
>>>>  
>>>> -   ret = dri_screen_create(dri);
>>>> +   force_sw = getenv("GBM_ALWAYS_SOFTWARE") != NULL;
>>>> +   if (!force_sw) {
>>>> +      ret = dri_screen_create(dri);
>>>> +      if (ret)
>>>> +         ret = dri_screen_create_swrast(dri);
>>>> +   } else {
>>>> +      ret = dri_screen_create_swrast(dri);
>>>> +   }
>>>> +
>>>>     if (ret)
>>>>        goto err_dri;
>>>
>>> Hi,
>>>
>>> is GBM_ALWAYS_SOFTWARE a new env var?
>>> Is it documented somewhere?
>> None of the GBM env variables are. In a matter of fact there isn't even a
>> single reference of gbm in the docs - env vars or otherwise. It's like gbm
>> does not exist :'(
>>
>> Will need to get a new document out there similar to egl.html.
>> Any objections if we do that as a follow up patch ?
> 
> I would be happy to see any documentation at some point. :-)
> 
>>> How does it interact with EGL_SOFTWARE?
>>> Does GBM_ALWAYS_SOFTWARE affect GBM's ability to import dmabufs
>>> somehow, or only the surfaces that will be passed to EGL?
>>> (Importing dmabufs to be passed directly to KMS for scanout.)
>>>
>> Considering it's a variable that needs to be explicitly set, the behaviour
>> depends on the current state of the software backend.
>>
>> AFAICS current swrast/kms_swrast does not allow/use dmabufs.
> 
> Maybe that was a stupid question on my part, as I don't know
> whether generic DRM API even has a way to import dmabufs at all.
> Something like dumb buffer import...
> 
AFAICS one needs to use a device driver capable of handling dmabufs, otherwise
the core drm will return EINVAL/ENOSYS.

I don't see any "software" implementation (dumb buffer) that can be used here.

IMHO all the above should be mentioned somewhere/documented rather than
expecting everything to magically work exactly as you expected it to.

>>> I'm terribly confused with all the *SOFTWARE* variables, and it seems
>>> I'm not alone as someone just recently filed a bunch of Weston bug
>>> reports while trying to get software GL rendering with
>>> LIBGL_ALWAYS_SOFTWARE on DRM/KMS.
>>>
>>>
>> I have the sneaking suspicion that most people see LIBGL_ALWAYS_SOFTWARE as
>> the magic variable that reads your mind and makes things work as you would
>> imagine them. Would be great to move from that to read the documentation and
>> amend propose improvements of it when needed.
> 
> Right. What about EGL_SOFTWARE? Why not use that on GBM platform too? A
> quick grep implies that X11 and Wayland platforms use it (but only with
> egl_gallium.so?)?
> 
A bit of history - when Chia-I was doing all the EGL work, he was considerable
enough to make individual switches for people to toggle when needed. He also
documented all of these :)

> GBM_ALWAYS_SOFTWARE sounds like a platform-specific variable, but
> should forcing software rendering be platform-specific?
> 
GBM is not EGL I fear. Also EGL is not the only user of GBM.

If we were to have zero users of libgbm outside of mesa(libegl) and then we
can happily go with EGL_SOFTWARE and be gone with it. Perhaps the most
reasonable compromise is to use the GBM env var and fallback to the EGL one.
How does that sound ?

Cheers,
Emil

> Btw. how do you force software rendering if using egl_dri2 driver on
> any platform? And not using libGL but, say, GLESv2? Uhh... :-)
> 
> 
> Thanks,
> pq
>