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

[Pekka Paalanen]

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

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

GBM_ALWAYS_SOFTWARE sounds like a platform-specific variable, but
should forcing software rendering be platform-specific?

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