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

[Pekka Paalanen]

On Mon, 16 Jun 2014 17:15:47 +0200
Giovanni Campagna <scampa.giovanni at gmail.com> wrote:

> 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.

Yes, that was clear to me.

> > 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.

Ookay... I maybe got half of that, but no worries. :-)

I was just under the impression, that some larger infrastructural
work was needed before egl_dri2 could work with software renderers,
and I was hoping your work do at least part of that infrastructure.

Doesn't matter, I was just curious. :-)


Thanks,
pq