[RFC 0/2] Add fp16 formats

[Pekka Paalanen]

On Fri,  1 Feb 2019 13:54:39 -0800
Kevin Strasser <kevin.strasser at intel.com> wrote:

> I'm sharing this as an RFC while the kernel [1] patches are still under review.
> On the Mesa mailing list some doubts [2] were raised as to whether we would be
> able to land these without fp16 support in Pixman, so I'd like some input from
> the wider Wayland community.
> 
> [1] https://patchwork.freedesktop.org/series/53213/
> [2] https://patchwork.freedesktop.org/patch/281553/
> 
> Kevin Strasser (2):
>   protocol: Add fp16 formats
>   tests: Add fp16 formats
> 
>  protocol/wayland.xml        | 2 ++
>  tests/data/example-client.h | 8 ++++++++
>  tests/data/example-server.h | 8 ++++++++
>  tests/data/example.xml      | 2 ++
>  4 files changed, 20 insertions(+)
> 

Hi Kevin,

is there a reason you need these in the wl_shm format list? That is,
essentially for software rendered stuff?

The zwp_linux_dmabuf extension which GL and Vulkan implementations are
using only says the format is a drm_fourcc format, so there is no need
to explicitly add the format there.

Wayland does not need to support a pixel format for a compositor to be
able to use that format on scanout/KMS. You only need the pixel format
through Wayland if you want to have client buffers be able to hit the
composite-bypass path and be scanned out directly on e.g. overlay or
primary planes. wl_shm buffers are never expected to be scanout-capable
because of the way their memory is allocated, so adding the format
there does not help. zwp_linux_dmabuf is where the format is needed.

Or do you need the formats for cursor planes?

Wayland and Pixman have no connection whatsoever. You don't need
support in Pixman to have these added into wl_shm set of formats.

Implementing compositor support for them may or may not need Pixman
support, depending on the compositor. Weston for example has two
renderers, and the GL-renderer could well support these formats without
Pixman supporting them. The Pixman renderer OTOH could not. Weston's
renderers are allowed to support different sets of formats, so Pixman
support is not necessary for Weston support.

As a small detail, patch 2 is ok, but not necessary. Those tests test
wayland-scanner, and adding this new format to example.xml does not
really add anything to the test.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190204/b5aaa99f/attachment.sig>