[RFC 0/2] Add fp16 formats

[Strasser, Kevin]

Pekka Paalanen wrote:
> 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. 

That is what I was trying to achieve, offering applications fp16 scan out 
buffers. I'm not aware of any explicit requirement for adding the wl_shm format
outside of Mesa's Walyand egl driver, which includes WL_SHM_FORMAT* for each
supported visual (I think just for the swrast path).

> 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?

I don't believe fp16 would be needed 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.

Ok, thanks for the detailed explanation.

Thanks,
Kevin