On Thu, 3 Jul 2014 15:46:14 +0300 Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Thu, 3 Jul 2014 14:15:34 +0200 > Boris BREZILLON <boris.brezil...@free-electrons.com> wrote: > > > On Thu, 3 Jul 2014 13:49:06 +0300 > > Pekka Paalanen <ppaala...@gmail.com> wrote: > > > > > On Thu, 3 Jul 2014 12:10:36 +0200 > > > Boris BREZILLON <boris.brezil...@free-electrons.com> wrote: > > > > > > > On Thu, 3 Jul 2014 12:24:44 +0300 > > > > Pekka Paalanen <ppaala...@gmail.com> wrote: > > > > > Weston's overlay planes code however totally depends on EGL to provide > > > > > hw-capable buffers from clients. A software renderer support in > > > > > EGL-DRM > > > > > won't help in that. > > > > > > > > Okay, if I understand correctly, this means I'll have to implement an > > > > atmel-hlcdc_dri.so module (as suggested by Giovanni), right ? > > > > > > Well, uhh, I suppose... > > > > > > That means you need to get clients actually rendering into hw-capable > > > buffers, so that usually means having a GL(ES) rendering working on > > > EGL Wayland platform, too. > > > > > > Or, clients could use something like libva(?) to fill the buffers and > > > use Mesa's internal wl_drm protocol to pass those to the compositor. If > > > the compositor is able to initialize EGL_WL_bind_wayland_display > > > extension, then with Mesa, the clients will have wl_drm available. > > > Still probably requires working GLESv2 rendering for the EGL DRM/GBM > > > platform, because the pixman renderer cannot handle anything else than > > > wl_shm buffers. > > > > > > Or, you migh hack Weston to copy pixels from wl_shm buffers into dumb > > > buffers, and put those into overlays (err, did dumb buffers support > > > going on overlays, or were they primary plane only?). But if you have > > > like less than 10 overlays in hw, that might be a net lose in > > > performance. > > > > I have, at most, 3 overlays (it depends on the HLCDC IP version), so > > this might be an acceptable solution. > > > > ITOH, I'd like to keep the implementation as clean as possible in order > > to be able to base future work on offical weston versions (and tell me > > if I'm wrong, but I'm not sure the proposed solution can ever make it to > > the official weston version). > > > > > > > > Or, you might go wild and have a hack on my hacky zlinux_dmabuf support > > > in weston: > > > http://cgit.collabora.com/git/user/pq/weston.git/log/?h=dmabuf-WIP > > > It is missing pixman-renderer integration, and the test client is > > > intel-only, but if you hack around those, you can have clients filling > > > dmabufs, sending those to Weston, and Weston using GBM to import them > > > to put them on overlays via DRM - unless the scenegraph forces them to > > > go through pixman-renderer in which case you are in a slight pickle. > > > > > > > That sounds interesting! > > I'll take a closer look at it. > > Note, that the protocol there does not address the problem of > compatibility at all, and the implementation does not even advertise any > pixel formats. It is all based on luck and clairvoyance, that the client > just happens to create exactly the right kind of dmabufs that the > compositor can use. If you fail that, the client gets kicked or you > get a mess on the screen. Obviously not upstreamable material. ;-) > > > > Warning: that weston branch may get rewritten or deleted without notice. > > > > > > I guess the take-away from this is that DRM overlay planes have not > > > really been considered for use with server nor client software rendering > > > in Weston. > > > > Yes, I kinda realize that know. > > > > My main goal here is to provide a video player demo application where > > the primary plane (or an overlay plane) is used to display video player > > controls (play, pause, ...) and another plane is used to display video > > content (using gstreamer or any other alternative). > > > > This needs to be done using overlays in order to get acceptable > > performances (avoid software rendering for plane composition), and > > thus should use drm overlay planes. > > Oh, a video player! How do you get the video frames? Do you have > hardware decoding? Can you perhaps decode straight into dmabufs? If > yes, then you could use zlinux_dmabuf to throw those video frames to > Weston zero-copy. Then the tricky part is to make Weston cope with those > video frame buffers, as if they even attempt to go through the > pixman-renderer, Weston will... hm, not sure what it does, but it won't > work. So you have to somehow guarantee, that the surface which those > buffers are targeting will *always* be assigned to an overlay. Some SoCs have an HW decoder and yes I had dmabuf in mind to provide zero copy from video decoder to DRM device ;-). But I'm not even sure this video decoder is supported in mainline and I'd like to get software decoding working first :-). > > That may be a fair amount of hacking. Good luck! :-) Yes that's what I'm realizing now. I thought the kernel driver would be the most complicated part, but now that I'm working on user space support I'd say developing the driver was quite easy :-). Thanks for your support. Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
