On Thu, 24 Jul 2014 13:34:42 +0100
Emil Velikov <emil.l.veli...@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.veli...@gmail.com> wrote:
> >
> >> From: Giovanni Campagna <gcampa...@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.veli...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
