[Mesa-dev] Env var for forcing sw driver (Re: [PATCH 3/6] Add support for swrast to the DRM EGL platform)

Thu Jul 24 23:34:29 PDT 2014

On Fri, 25 Jul 2014 09:14:40 +0300
Pekka Paalanen <ppaalanen at gmail.com> wrote:

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

Hm, reading Kenneth's comments about variable naming at
http://lists.freedesktop.org/archives/mesa-dev/2014-July/064103.html
I wonder, is there real benefit for different driver loaders in Mesa
each using a different env var for forcing loading a software
driver/renderer?

Is there a reason why we just couldn't make LIBGL_ALWAYS_SOFTWARE
actually always force the software driver or print a warning if the
loader cannot do that?

Can a single process be wanting to use different loaders to load
different software vs. hardware drivers at the same time?

Excuse me, this has nothing to do with the patch series anymore, I just
hijacked the topic for discussion. :-)

Thanks,
pq