Additional pixel formats for wl_shm

[Pekka Paalanen]

On Sun, 28 Apr 2013 15:48:09 +0900
Cedric BAIL <cedric.bail at free.fr> wrote:

> Hello,
> 
> On Fri, Apr 26, 2013 at 10:13 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > I'm working on Raspberry Pi, where the VideoCore can deal directly with
> > a large number of pixel formats. However, wl_shm only exposes ARGB and
> > XRGB 32-bit per pixel formats, which on such tiny devices are very
> > wasteful.
> >
> > Would it be acceptable to add more formats to the wl_shm formats enum?
> > I have happily forgot all the previous discussions about the topic, and
> > a quick search into the mailing list archives didn't turn up much.
> >
> > We are especially interested in 16-bit per pixel formats to save memory
> > and bandwidth, and if I am reading the GLESv2 specification right,
> > RGB565, RGBA4444 and RGBA5551 should be directly supported, so at least
> > those could be uploaded into textures without manual conversion. Of
> > course, the new rpi-renderer I am working on does not use GL for
> > compositing anymore, but it should be able to use those formats
> > directly, too.
> 
> I do have a question here. Is it really worth it ? do you have any
> benchmark ? I am asking, because in EFL we did have a 16bits software
> backend a few years ago. We removed it, because it lacked support and
> the 32bits engine was getting closer and closer to the speed of the
> 16bits version. At the end it was not worth it to keep it around for a
> 10% win (disabling our safety check would give the same speedup).
>   At least in our case, that path was not used enough to get people
> interested and get as much optimized as the 32bits path is.
> 
>   As for memory usage, how big is the difference between using 32bits
> vs 16bits in the compositor and in the application in your case. Quick
> check on the application I have to test with and it will be around a
> 10% win (QT and EFL) and they are small application, I expect that for
> bigger application it get even lower. I think a bigger win would have
> been to share most of those resource across applications.
> 
> Overall is it worth it in contrast to any complexity/maintenance
> burden it could create in the long term ? I don't know enough about
> Weston code to know about it.

It is more about the tiny memory. On Raspbian right now by default,
we have a 25 MB tmpfs for allocating wl_shm buffers from. The
amount of host RAM and VideoCore memory are both quite limited,
too, and the total memory (IIRC 256 MB on my device model) is
hard-split between these two.

I have also been said by someone who really knows the hardware,
that cutting the scanout memory bandwidth requirement by half for a
surface will be a significant win, in that we can support more
stuff on screen. It's not about rendering performance, but
the hardware scanout performance, as we are using tons of overlays
(every at least partially visible wl_surface gets its own overlay).

The complexity and maintenance burden on Weston should be
negligible. Other than the RPI backend do not necessarily need to
expose these formats. I would only want them specified in the
protocol. Supported pixel formats are explicitly advertised at
runtime on wl_shm.

Even if we did make other weston backends support them, the
mentioned 16-bit formats should be directly supported by GLESv2, so
it is simply a question of passing the format through. I didn't
look at Pixman's supported formats, but I would be surprised if it
didn't support these, too. Weston itself does not do any pixel
manipulation on the wl_buffer path.

I would say it is worth it, yes.


Thanks,
pq