[OE-core] [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 at 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