• Pekka Paalanen's avatar
    rpi: add a Dispmanx renderer · d7265bc4
    Pekka Paalanen authored
    Dispmanx is the prorietary display API on the Raspberry Pi, which
    provides hardware compositing. Every visible surface is assigned a
    Dispmanx element, and the hardware or firmware will do all compositing
    onto screen. The API supports translation, scaling, flips, discrete
    rotations in 90-degree steps, alpha channel on the surfaces, and
    full-surface alpha on top.
    Previously, Dispmanx capabilities were used via the weston_plane
    mechanism, where surfaces were assigned to planes when possible, and
    otherwise transparently falling back to GLESv2 compositing. Because we
    have no way to use the same memory buffer as a GL texture and a Dispmanx
    resource, we had to prepare for both. In the worst case, that means one GL
    texture, and two (double-buffered case) Dispmanx resources, all the size
    of a whole surface, for all surfaces. This was eating memory fast. To
    make things worse (and less slow), the wl_shm buffer was kept around,
    since it was copied to either a texture or a resource as needed. This
    caused all clients to need two buffers. In a Dispmanx-only renderer, we
    can drop the GL texture, and we can release wl_shm buffer immediately
    after the first copy, so clients become effectively single-buffered. So
    from the worst case of 5 buffers per surface, we go down to 3 or just
    2 (single-buffered Dispmanx element, one wl_shm buffer in the client)
    buffers per surface.
    As this will replace the GL renderer on rpi, we cannot fall back to the
    GLESv2 compositing anymore. We lose arbitrary surface rotation, but we
    lose also the GL fallback, which caused glitches.
    This patch depends on new RaspberryPi firmware. Older firmware may not
    render ARGB surfaces correctly, solid color surfaces maybe cause a
    performance hit, and the output may completely fail in case the firmware
    does not fall back internal off-line compositing properly as needed.
    This new rpi-renderer support surface translation and scaling, but not
    rotation or transpose (not even in 90-deg steps). In theory, 90-deg step
    surface rotation is possible to support. Output transformations are
    supported, but flipped variants do not seem to work right.
    As a detail, menus and other surfaces that are simply translated with
    respect to another surface caused falling back to the GL renderer. The
    rpi-renderer handles them directly.
    This patch only adds the new renderer, but does not hook it up into use.
    Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
rpi-renderer.h 1.74 KB