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

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