[Mesa-dev] [PATCH v3 0/3] Software rendering in EGL-DRM

Giovanni Campagna scampa.giovanni at gmail.com
Mon Jun 16 08:15:47 PDT 2014


2014-06-16 7:47 GMT+02:00 Pekka Paalanen <ppaalanen at gmail.com>:
> On Sun, 15 Jun 2014 13:49:48 +0200
> Giovanni Campagna <scampa.giovanni at gmail.com> wrote:
>
>> Hello all,
>>
>> This is the third attempt at swrast/llvmpipe support for DRM
>> drivers that don't have userspace support (qxl, cirrus, simpledrm, etc.)
>>
>> I hope I addressed all of Emil's comments.
>
> Hi,
>
> this sounds cool work to me, sorry I can't really review it.
>
> Does this work also help in getting llvmpipe working with the egl_dri2
> loader?

If you mean in wayland, unfortunately no. Each egl platform has to
implement buffer uploading differently, so the code paths are
different. This patchset only tackles the DRM platform, which means
mutter, weston and other wayland compositors can run with llvmpipe,
but their clients will not have working egl.

> AFAIU, currently on EGL-Wayland the only way to use llvmpipe is to use
> egl_gallium.so as the loader, and I don't really know what it would
> take to make egl_dri2 work there, apart from the Wayland-specific bits,
> so I was kind of hoping your work would make that easier to implement.

In the end, the simple way is to implement swrastGetImage and
swrastPutImage for the wayland platform, using an shm backed buffer.
It would look similar to the platform_drm side (because the way drm
and wayland do double buffering is quite similar, and because both are
incapable of front-buffer rendering, single-buffer rendering or
rendering to foreign windows), but no real code sharing.
OTOH, in wayland buffer sharing exists, so it would be hugely
inefficient to implement swrast support this way (it incures one extra
copy, from the malloc backbuffer to the shm fake frontbuffer). It
should be possible to design an "swrast2" interface in terms of shm
FDs, similar to prime/dma-buf FDs, and with similar semantics, just
nobody is working on it right now.

Giovanni


More information about the mesa-dev mailing list