[RFC 0/2] Add fp16 formats

[Pekka Paalanen]

On Mon, 4 Feb 2019 22:10:00 +0000
"Strasser, Kevin" <kevin.strasser at intel.com> wrote:

> 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).

That should really be only the software rendering paths and they use
wl_shm specifically.

The hardware rendering paths should use DRM formats (drm_fourcc),
everything is kind of standardising around those these days.

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

Right. Or maybe HDR cursors? Let's not go there yet. ;-)


Thanks,
pq

> > 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
-------------- 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/20190205/d0e2e6ad/attachment.sig>