mesa: potentially enable texture float for gallium

Somewhere along the path from OpenGL ES 2.0 to OpenGL ES 3.0 are some algorithms that are encumbered by patents. These algorithms are enabled with
mesa's --enable-texture-float configure flag. However, if hardware acceleration is being used and the hardware supports --enable- texture-float,
it means the hardware vendor has paid for the patents.

This patch will add --enable-texture-float for any hardware-backed gallium
mesa driver. In other words, if you are only using the software backup
(swrast) you'll need to enable this flag if you know what you're doing (which
assumes you are complying with the patent). Otherwise we enable this flag so
the software can take full advantage of the hardware.

Quoted 8 lines · Trevor Woerner

Somewhere along the path from OpenGL ES 2.0 to OpenGL ES 3.0 are some algorithms that are encumbered by patents. These algorithms are enabled with
mesa's --enable-texture-float configure flag. However, if hardware acceleration is being used and the hardware supports --enable- texture-float,
it means the hardware vendor has paid for the patents.

Quoted 9 lines

This patch will add --enable-texture-float for any hardware-backed gallium
mesa driver. In other words, if you are only using the software backup
(swrast) you'll need to enable this flag if you know what you're doing (which
assumes you are complying with the patent). Otherwise we enable this flag so
the software can take full advantage of the hardware.

Does this handle the case where the driver may or may not run on a platform with the relevant hardware?

Some platforms add swrast as well
as hardware acceleration which based on what I read above, may breach patents depending on which hardware its run on?

Quoted 24 lines · Richard Purdie

Quoted 11 lines · Trevor Woerner

Somewhere along the path from OpenGL ES 2.0 to OpenGL ES 3.0 are some
algorithms that are encumbered by patents. These algorithms are enabled with
mesa's --enable-texture-float configure flag. However, if hardware
acceleration is being used and the hardware supports --enable- texture-float,
it means the hardware vendor has paid for the patents.

Quoted 11 lines

This patch will add --enable-texture-float for any hardware- backed
gallium
mesa driver. In other words, if you are only using the software backup
(swrast) you'll need to enable this flag if you know what you're doing (which
assumes you are complying with the patent). Otherwise we enable this
flag so
the software can take full advantage of the hardware.

Quoted 2 lines

Does this handle the case where the driver may or may not run on a platform with the relevant hardware?

The choice of gallium driver should be set based on the MACHINE setting, so hopefully this is being set correctly from the BSP. Presumably the user isn't building gallium with "swrast,imx,etnaviv" then trying to run that on intel hardware! In which case, you are
right: the imx/etnaviv code will not be able to initialize the hardware, and the code will fallback to use swrast (if it was in the list).

Quoted 4 lines

Some platforms add swrast as well
as hardware acceleration which based on what I read above, may breach
patents depending on which hardware its run on?

My understanding (from chatting with airlied on #dri-devel) is that it's one or the other, there is no fallback: "the drivers don't dynamically fallback ever"

If the driver can't initialize the graphics hardware, then it will fall back (fully) to swrast... if it was listed. This makes me wonder if "swrast" should be always added to the list of gallium drivers built on those platforms with hardware-supported gallium drivers? Wouldn't it be better to have the graphics system fail to come up if something is configured wrong, rather than to fallback to software rasterization and let the user think everything is okay?

Currently the OE code initializes the list of gallium drivers to be built to "swrast" then potentially adds others based on PACAKGECONFIGs
which are expected to point to which hardware is expected. Maybe the OE code should try to set a hardware-specific gallium driver, and use --enable-texture-float. If, at the end, no gallium drivers are listed,
then the OE code should set the list to "swrast" and not include --enable-texture-float?

If you're running mesa on platforms that have hardware support, the "swrast" is not required (as is my understanding, but I could look into this).

According to Dave Airlie, Fedora builds now include this option.
Specifically: "there is a fedora patch that mostly does that \n disable the float just for swrast". Then later: "actually the patch it
ships now just bars float on llvmpipe and softpipe". This requires some "reading between the lines", however. Of some interest might be that Arch also includes this option by default (2011) [1] as does "Intel mesa" (2012) [2]. I can't find anything definitive, but it looks like Ubuntu also includes this option by default (starting with 14?).

Sadly, if we don't add this option, mesa's advertisement will be limited to open gl (es) 2, even in cases where the hardware would support 3 (and greater?).

[1] http://www.phoronix.com/scan.php?page=news_item&px=OTUxMg
[2] http://www.phoronix.com/scan.php?page=news_item&px=MTIwOTg

We should look at how Fedora "just bars float on llvmpipe and softpipe" and perhaps look at copying that? Not that we enable llvmpipe at the moment either mind so presumably we're using softpipe.

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 <[email protected]>
	Date: Sun, 20 Mar 2016 13:27:04 +0100
	Subject: [PATCH 2/4] hardware gloat

	Signed-off-by: Igor Gnatenko <[email protected]>
	---
	 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)?

Quoted 7 lines

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!

Quoted 11 lines · Richard Purdie

Quoted 11 lines

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

Quoted 1 line

That sounds like exactly what we need to do!

Okay. The only caveat being, if someone actually *wanted* to enable float for swrast, this would prevent them from going down that path.

ajax on #dri-devel pointed out that some piglit tests go from pass to fail instead of being skipped as a result of the above patch since the
piglit tests are done with swrast and run very poorly without float enabled.

Quoted 14 lines · Trevor Woerner

Quoted 11 lines · Richard Purdie

Quoted 11 lines

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

Quoted 1 line

That sounds like exactly what we need to do!

Quoted 8 lines

Okay. The only caveat being, if someone actually *wanted* to enable float for swrast, this would prevent them from going down that path.

ajax on #dri-devel pointed out that some piglit tests go from pass to fail instead of being skipped as a result of the above patch since the
piglit tests are done with swrast and run very poorly without float enabled.

If someone really wants to enable it, they can drop the patch. I'm open to feedback from others like Ross/Jussi but IMO I think we can accept the degraded piglit results for swrast...

Quoted 3 lines · Richard Purdie

If someone really wants to enable it, they can drop the patch. I'm open to feedback from others like Ross/Jussi but IMO I think we can accept the degraded piglit results for swrast...

Sounds like a completely reasonable compromise to me.