Re: [PATCH] mesa: potentially enable texture float for gallium

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2017-05-30 at 11:27 -0400, Trevor Woerner wrote:
> Here is the relevant part of Fedora's mesa.spec file for Fedora 25
> (with line
> numbers):
> 
> 	 400 %configure \
> 	 401     %{?asm_flags} \
> 	 402     --enable-libglvnd \
> 	 403     --enable-selinux \
> 	 404     --enable-gallium-osmesa \
> 	 405     --with-dri-driverdir=%{_libdir}/dri \
> 	 406     --enable-egl \
> 	 407     --disable-gles1 \
> 	 408     --enable-gles2 \
> 	 409     --disable-xvmc \
> 	 410     %{?with_vdpau:--enable-vdpau} \
> 	 411     %{?with_vaapi:--enable-va} \
> 	 412     --with-egl-
> platforms=x11,drm,surfaceless%{?with_wayland:,wayland} \
> 	 413     --enable-shared-glapi \
> 	 414     --enable-gbm \
> 	 415     %{?with_omx:--enable-omx} \
> 	 416     %{?with_opencl:--enable-opencl --enable-opencl-icd}
> %{!?with_opencl:--disable-opencl} \
> 	 417     --enable-glx-tls \
> 	 418     --enable-texture-float=yes \
> 	 419 %if %{with_vulkan}
> 	 420     %{?vulkan_drivers} \
> 	 421 %endif
> 	 422     %{?with_llvm:--enable-gallium-llvm} \
> 	 423     %{?with_llvm:--enable-llvm-shared-libs} \
> 	 424     --enable-dri \
> 	 425 %if %{with_hardware}
> 	 426     %{?with_xa:--enable-xa} \
> 	 427     %{?with_nine:--enable-nine} \
> 	 428     --with-gallium-
> drivers=%{?with_vmware:svga,}%{?with_radeonsi:radeonsi,}%{?with_llvm:
> swrast,r600,}%{?with_freedreno:freedreno,}%{?with_etnaviv:etnaviv,}%{
> ?with_vc4:vc4,}%{?with_ilo:ilo,}virgl,r300,nouveau \
> 	 429 %else
> 	 430     --with-gallium-drivers=%{?with_llvm:swrast,}virgl \
> 	 431 %endif
> 	 432     %{?dri_drivers}
> 
> --enable-texture-float (line 418) is always, unconditionally enabled.
> However,
> mesa itself is then patched (for Fedora) so that the --enable-
> texture-float
> configuration option doesn't have any effect on llvm and swrast. I.e.
> it is
> easier to do this optional check in code than on the ./configure
> line:
> 
> 	From 00bcd599310dc7fce4fe336ffd85902429051a0c Mon Sep 17
> 00:00:00 2001
> 	From: Igor Gnatenko <i.gnatenko.brain@gmail.com>
> 	Date: Sun, 20 Mar 2016 13:27:04 +0100
> 	Subject: [PATCH 2/4] hardware gloat
> 
> 	Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
> 	---
> 	 src/gallium/drivers/llvmpipe/lp_screen.c | 7 +++++++
> 	 src/gallium/drivers/softpipe/sp_screen.c | 7 +++++++
> 	 2 files changed, 14 insertions(+)
> 
> 	diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
> b/src/gallium/drivers/llvmpipe/lp_screen.c
> 	index 4f61de8..3b0ec77 100644
> 	--- a/src/gallium/drivers/llvmpipe/lp_screen.c
> 	+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
> 	@@ -411,6 +411,13 @@ llvmpipe_is_format_supported( struct
> pipe_screen *_screen,
> 	    if (!format_desc)
> 	       return FALSE;
> 	 
> 	+   if ((bind & PIPE_BIND_RENDER_TARGET) &&
> 	+       format != PIPE_FORMAT_R9G9B9E5_FLOAT &&
> 	+       format != PIPE_FORMAT_R11G11B10_FLOAT &&
> 	+       util_format_is_float(format)) {
> 	+      return FALSE;
> 	+   }
> 	+
> 	    assert(target == PIPE_BUFFER ||
> 		   target == PIPE_TEXTURE_1D ||
> 		   target == PIPE_TEXTURE_1D_ARRAY ||
> 	diff --git a/src/gallium/drivers/softpipe/sp_screen.c
> b/src/gallium/drivers/softpipe/sp_screen.c
> 	index 031602b..c279120 100644
> 	--- a/src/gallium/drivers/softpipe/sp_screen.c
> 	+++ b/src/gallium/drivers/softpipe/sp_screen.c
> 	@@ -358,6 +358,13 @@ softpipe_is_format_supported( struct
> pipe_screen *screen,
> 	    if (!format_desc)
> 	       return FALSE;
> 	 
> 	+   if ((bind & PIPE_BIND_RENDER_TARGET) &&
> 	+       format != PIPE_FORMAT_R9G9B9E5_FLOAT &&
> 	+       format != PIPE_FORMAT_R11G11B10_FLOAT &&
> 	+       util_format_is_float(format)) {
> 	+      return FALSE;
> 	+   }
> 	+
> 	    if (sample_count > 1)
> 	       return FALSE;
> 	 
> 	-- 
> 	2.7.4
> 
> 
> Maybe this would be a better way forward? Enable it, always, in
> ./configure,
> add the patch to check for it in the code itself, then you can build
> for all
> the gallium targets (including swrast) and know that the patented
> code will
> only kick in where it's supported in hardware (and thus patent-safe)?

That sounds like exactly what we need to do!

Cheers,

Richard