[Mesa-dev] [PATCH 3/6] Add support for swrast to the DRM EGL platform
Emil Velikov
emil.l.velikov at gmail.com
Thu Jul 24 05:34:42 PDT 2014
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 ?
> 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.
> 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.
Cheers,
Emil
> Thanks,
> pq
>
More information about the mesa-dev
mailing list