On Mon, 16 Jun 2014 17:15:47 +0200 Giovanni Campagna <scampa.giova...@gmail.com> wrote:
> 2014-06-16 7:47 GMT+02:00 Pekka Paalanen <ppaala...@gmail.com>: > > On Sun, 15 Jun 2014 13:49:48 +0200 > > Giovanni Campagna <scampa.giova...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
