How to handle mesa customization in BSP layers

How to handle mesa customization in BSP layers

[Nicolas Dechesne]

hi there,

in the meta-qcom BSP layer, I need to customize mesa to enable
Gallium/freedreno driver which is not enabled in OE-core by default. I
have been using a bbappend , see [1] so far.

However it was reported by Koen that his is causing issues, at least
in Angstrom, though it's not specific to this distro.. See github
comments on [2].

The issue is that mesa is arch specific, not machine specific. So if
you start mixing machines from the same arch, we are getting
unexpected/wrong rebuilds.

How am I supposed to handle that properly in a BSP layer? I don't
think that enabling the freedreno driver should be a distro config, am
i right?

thanks
nico

[1] https://github.com/ndechesne/meta-qcom/blob/master/recipes-graphics/mesa/mesa_10.%25.bbappend
[2] https://github.com/ndechesne/meta-qcom/commit/dc00771aaba1051a3c679dd8f782089b499cbdbb

Re: How to handle mesa customization in BSP layers

[Koen Kooi]

> Op 20 okt. 2015, om 11:32 heeft Nicolas Dechesne <nicolas.dechesne@linaro.org> het volgende geschreven:
> 
> hi there,
> 
> in the meta-qcom BSP layer, I need to customize mesa to enable
> Gallium/freedreno driver which is not enabled in OE-core by default. I
> have been using a bbappend , see [1] so far.
> 
> However it was reported by Koen that his is causing issues, at least
> in Angstrom, though it's not specific to this distro.. See github
> comments on [2].
> 
> The issue is that mesa is arch specific, not machine specific. So if
> you start mixing machines from the same arch, we are getting
> unexpected/wrong rebuilds.
> 
> How am I supposed to handle that properly in a BSP layer? I don't
> think that enabling the freedreno driver should be a distro config, am
> i right?

I agree that making it a DISTRO thing is not the right answer, but it is exactly what I ended up doing: https://github.com/Angstrom-distribution/meta-angstrom/commit/549d58dd00cd0683d92b942e9574ef0d1e347e51

In this specific case I think we should enable freedreno for armv7/armv8 in OE-core, but the problem remains for other recipes like this.

regards,

Koen

Re: How to handle mesa customization in BSP layers

[Trevor Woerner]

On 10/20/15 05:37, Koen Kooi wrote:
>> Op 20 okt. 2015, om 11:32 heeft Nicolas Dechesne <nicolas.dechesne@linaro.org> het volgende geschreven:
>>
>>
>> The issue is that mesa is arch specific, not machine specific. So if
>> you start mixing machines from the same arch, we are getting
>> unexpected/wrong rebuilds.
> In this specific case I think we should enable freedreno for armv7/armv8 in OE-core, but the problem remains for other recipes like this.

Are you suggesting that every armv7 device should have their mesa tuned
for freedreno and freedreno added to their filesystem? That seems quite
overly-broad!

On the surface[1] it would seem as though the decisions as to how one
builds mesa and which graphics solution to install is more similar to
the decision as to which DEFAULTTUNE to use, rather than which
architecture is involved?







[1] which is my way of saying "I don't have the experience of actually
having done this, unlike you people" ;-)

Re: How to handle mesa customization in BSP layers

[Nicolas Dechesne]

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

Le 25 oct. 2015 00:00, "Trevor Woerner" <twoerner@gmail.com> a écrit :
>
> On 10/20/15 05:37, Koen Kooi wrote:
> >> Op 20 okt. 2015, om 11:32 heeft Nicolas Dechesne <
nicolas.dechesne@linaro.org> het volgende geschreven:
> >>
> >>
> >> The issue is that mesa is arch specific, not machine specific. So if
> >> you start mixing machines from the same arch, we are getting
> >> unexpected/wrong rebuilds.
> > In this specific case I think we should enable freedreno for
armv7/armv8 in OE-core, but the problem remains for other recipes like this.
>
> Are you suggesting that every armv7 device should have their mesa tuned
> for freedreno and freedreno added to their filesystem? That seems quite
> overly-broad!

No. Only building the driver. It won't be installed unless you add it into
your image.

>
> On the surface[1] it would seem as though the decisions as to how one
> builds mesa and which graphics solution to install is more similar to
> the decision as to which DEFAULTTUNE to use, rather than which
> architecture is involved?
>

DEFAULTTUNE is a generic config that impacts all packages. What Koen
proposed is to change mesa to build more drivers by default.

>
>
>
>
>
>
> [1] which is my way of saying "I don't have the experience of actually
> having done this, unlike you people" ;-)

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