Re: [RFC 0/2] Add fp16 formats
On Tue, 5 Feb 2019 21:57:40 + "Strasser, Kevin" wrote: > Pekka Paalanen wrote: > > On Mon, 4 Feb 2019 22:10:00 + "Strasser, Kevin" > > wrote: > > > 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. > > Ok, I *think* we are on the same page. Once the drm formats have landed in the > kernel we will add the equivalent to wl_shm (probably my first patch unless we > decide on some other fourcc definition). This will make fp16 visuals available > for hardware and software (swrast) paths in the egl driver. That should cover > the requirements for use in Weston's gl renderer. Hi, let me be more specific just in case. :-) The wl_shm format patch is only necessary if you want to have fp16 buffer format with software rendering. This is because the software rendering glue uses wl_shm Wayland buffers to send the content to a Wayland compositor. If you are happy to limit fp16 to hardware rendering on Wayland, you do not need to think of wl_shm at all. Hardware rendering uses zwp_linux_dmabuf (or the old wl_drm) Wayland buffers, which simply say "use the kernel DRM format definitions". Defining the formats is only for a common vocabulary. The formats a Wayland compositor will actually support are advertised explicitly at runtime, which I believe should affect things like what EGLConfigs an app sees available. Thanks, pq pgpYXEgTXAXfZ.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [RFC 0/2] Add fp16 formats
Pekka Paalanen wrote: > On Mon, 4 Feb 2019 22:10:00 + "Strasser, Kevin" > wrote: > > 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. Ok, I *think* we are on the same page. Once the drm formats have landed in the kernel we will add the equivalent to wl_shm (probably my first patch unless we decide on some other fourcc definition). This will make fp16 visuals available for hardware and software (swrast) paths in the egl driver. That should cover the requirements for use in Weston's gl renderer. Thanks, Kevin ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC 0/2] Add fp16 formats
On Mon, 4 Feb 2019 22:10:00 + "Strasser, Kevin" 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 pgpTy8uzJlDJa.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [RFC 0/2] Add fp16 formats
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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC 0/2] Add fp16 formats
On Fri, 1 Feb 2019 13:54:39 -0800 Kevin Strasser 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 pgpaNFo8WHD2E.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
