On Fri, 25 Jul 2014 09:14:40 +0300
Pekka Paalanen ppaala...@gmail.com wrote:
On Thu, 24 Jul 2014 17:16:39 +0100
Emil Velikov emil.l.veli...@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.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(-)
...
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
