[PATCH] mesa: potentially enable texture float for gallium

[PATCH] mesa: potentially enable texture float for gallium

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

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.

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
 meta/recipes-graphics/mesa/mesa.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index 447fd6d0df..7ea3a88b9f 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -64,7 +64,7 @@ GALLIUMDRIVERS_LLVM = "r300,svga,nouveau${@',${GALLIUMDRIVERS_LLVM33}' if ${GALL
 GALLIUMDRIVERS_append_x86 = "${@bb.utils.contains('PACKAGECONFIG', 'gallium-llvm', ',${GALLIUMDRIVERS_LLVM}', '', d)}"
 GALLIUMDRIVERS_append_x86-64 = "${@bb.utils.contains('PACKAGECONFIG', 'gallium-llvm', ',${GALLIUMDRIVERS_LLVM}', '', d)}"
 # keep --with-gallium-drivers separate, because when only one of gallium versions is enabled, other 2 were adding --without-gallium-drivers
-PACKAGECONFIG[gallium]      = "--with-gallium-drivers=${GALLIUMDRIVERS}, --without-gallium-drivers"
+PACKAGECONFIG[gallium] = "${@'' if '${GALLIUMDRIVERS}'.strip() == 'swrast' else '--enable-texture-float'} --with-gallium-drivers=${GALLIUMDRIVERS}, --without-gallium-drivers"
 MESA_LLVM_RELEASE ?= "3.3"
 PACKAGECONFIG[gallium-llvm] = "--enable-gallium-llvm --enable-llvm-shared-libs, --disable-gallium-llvm, llvm${MESA_LLVM_RELEASE} \
                                ${@'elfutils' if ${GALLIUMDRIVERS_LLVM33_ENABLED} else ''}"
-- 
2.13.0

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

[Richard Purdie]

On Fri, 2017-05-26 at 17:22 -0400, Trevor Woerner wrote:
> 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.

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?

Cheers,

Richard

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

[Trevor Woerner]

Hi Richard,

Thanks for your review.

On Mon, May 29, 2017 at 7:25 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Fri, 2017-05-26 at 17:22 -0400, Trevor Woerner wrote:
>> 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.
>
> 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).

> 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

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

[Richard Purdie]

On Tue, 2017-05-30 at 01:28 -0400, Trevor Woerner wrote:
> On Mon, May 29, 2017 at 7:25 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > 
> > On Fri, 2017-05-26 at 17:22 -0400, Trevor Woerner wrote:
> > > 
> > > 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.
> > 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).

The issue is that mesa isn't built per MACHINE, nor is it machine
specific, we build it once, enabling all the drivers for a given
architecture and then packaging them separately in some cases.

We then RDEPEND on specific sets of drivers for specific machines.


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

See above, mesa is not machine specific (nor should it be).

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

Right, that makes sense. We do run on platforms where we do need
swrast, e.g. all our qemu testing. We also support generic platforms
like genericx86 where we don't know which hardware we'll run on.

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

Cheers,

Richard

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

[Trevor Woerner]

On Tue 2017-05-30 @ 08:47:55 AM, Richard Purdie wrote:
> 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.

If you build for AMD's gizmo2 (meta-amd), it uses llvmpipe (although it's
doing a lot of its own stuff with mesa):

	http://git.yoctoproject.org/cgit/cgit.cgi/meta-amd/tree/common/recipes-graphics/mesa/mesa_git.bbappend?h=master


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

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

[Richard Purdie]

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

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

[Trevor Woerner]

On Tue, May 30, 2017 at 11:44 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>> 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!

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.

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

[Richard Purdie]

On Tue, 2017-05-30 at 12:00 -0400, Trevor Woerner wrote:
> On Tue, May 30, 2017 at 11:44 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > 
> > > 
> > > 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!
> 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...

Cheers,

Richard

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

[Jussi Kukkonen]

[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]

On 30 May 2017 at 19:19, Richard Purdie <richard.purdie@linuxfoundation.org>
wrote:
>
> On Tue, 2017-05-30 at 12:00 -0400, Trevor Woerner wrote:
> > On Tue, May 30, 2017 at 11:44 AM, Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> > >
> > > >
> > > > 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!
> > 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...

Sounds like a completely reasonable compromise to me.

Jussi

[-- Attachment #2: Type: text/html, Size: 1831 bytes --]

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

[Trevor Woerner]

On Wed, May 31, 2017 at 3:15 AM, Jussi Kukkonen
<jussi.kukkonen@intel.com> wrote:
> On 30 May 2017 at 19:19, Richard Purdie <richard.purdie@linuxfoundation.org>
> wrote:
>> 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.

Okay, thanks.

It looks like there's a patch in the pipe for mesa.inc, I'll wait
until that is in place before doing and sending this update.