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

[Pekka Paalanen]

On Thu, 24 Jul 2014 17:16:39 +0100
Emil Velikov <emil.l.velikov at gmail.com> wrote:

> 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(-)

...

> >>> 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.

Sure, but GBM does no rendering at all, does it? It's strange, GBM needs
to load a driver but does not render, so forcing "software rendering"
sounds funny. But obviously you want to be able to tell GBM to load a
software "driver" instead of a hardware one. Certainly does not make
this any easier to understand.

Well, the same can be said about EGL...

So, this thing is about GBM the driver loader, not GBM the EGL
platform. Maybe that is where I got confused. (The subject does speak
explicitly about EGL platform.)

> 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 ?

You raise a good point there. GBM is initialized first, whether it is
used as an EGL platform or stand-alone (just for importing dmabufs, I
think... what about libva?). For example, Weston uses GBM as an EGL
platform for GL-based compositing, but also uses GBM to directly import
wl_buffers and dmabufs so they can be passed to KMS for scanout. While
wl_buffer import relies on EGL, dmabuf import could theoretically work
without EGL, but I find that case quite unlikely in practice.

I do expect we have users of libgbm outside of Mesa, and also non-Mesa
implementations of libgbm. I'm just not sure if GBM is ever useful
without EGL being used on the side, too. I think only buffer import
in GBM could be usable without using also EGL, so that again leads to
the question of "dumb import" with software-only driver.

Sorry, I don't have good suggestions. I was hoping someone else might
have. :-)


Thanks,
pq