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(-)
>>>>
>>>
>>>> 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...
>
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.
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 ?
Cheers,
Emil
> 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
