How to override mesa VULKAN_DRIVERS and GALLIUMDRIVERS variables?

How to override mesa VULKAN_DRIVERS and GALLIUMDRIVERS variables?

[trent.piepho]

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

I'd like to change the value of these.

However, they are set like this:
VULKAN_DRIVERS = ""
VULKAN_DRIVERS:append:x86 = ",intel,amd"
VULKAN_DRIVERS:append:x86-64 = ",intel,amd"

...
VULKAN_DRIVERS:append ="${@bb.utils.contains('PACKAGECONFIG', 'freedreno', ',freedreno', '', d)}"

Setting VULKAN_DRIVERS in an bbappend or machine conf file to something like "intel" doesn't work, because the append actions still append to that value all additional drivers.
Trying to remove other drivers with something like VULKAN_DRIVERS:remove = ",amd" doesn't work either, as remove only matches on word boundaries and the list is command delimited, not space delimited.

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

Re: [poky] How to override mesa VULKAN_DRIVERS and GALLIUMDRIVERS variables?

[Alexander Kanavin]

On Sun, 3 Aug 2025 at 08:28, trent.piepho via lists.yoctoproject.org
<trent.piepho=igorinstitute.com@lists.yoctoproject.org> wrote:
>
> I'd like to change the value of these.
>
> However, they are set like this:
> VULKAN_DRIVERS = ""
> VULKAN_DRIVERS:append:x86 = ",intel,amd"
> VULKAN_DRIVERS:append:x86-64 = ",intel,amd"
> ...
> VULKAN_DRIVERS:append ="${@bb.utils.contains('PACKAGECONFIG', 'freedreno', ',freedreno', '', d)}"
>
> Setting VULKAN_DRIVERS in an bbappend or machine conf file to something like "intel" doesn't work, because the append actions still append to that value all additional drivers.
> Trying to remove other drivers with something like VULKAN_DRIVERS:remove = ",amd" doesn't work either, as remove only matches on word boundaries and the list is command delimited, not space delimited.

VULKAN_DRIVERS is basically internal to the recipe. You need to set
PACKAGECONFIG for mesa to include the needed set:

VULKAN_DRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG',
'freedreno', ',freedreno', '', d)}"
VULKAN_DRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG',
'broadcom', ',broadcom', '', d)}"
VULKAN_DRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG',
'gallium-llvm', '${VULKAN_DRIVERS_LLVM}', '', d)}"
VULKAN_DRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG',
'imagination', ',imagination-experimental', '', d)}"
VULKAN_DRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG',
'panfrost', ',panfrost', '', d)}"
etc.

It's possible something is missing in the above, in which case,
patches to fix that are welcome.

Alex

Re: [poky] How to override mesa VULKAN_DRIVERS and GALLIUMDRIVERS variables?

[Trent Piepho]

On Mon, Aug 4, 2025 at 3:15 AM Alexander Kanavin via
lists.yoctoproject.org <alex.kanavin=gmail.com@lists.yoctoproject.org>
wrote:
>
> On Sun, 3 Aug 2025 at 08:28, trent.piepho via lists.yoctoproject.org
> <trent.piepho=igorinstitute.com@lists.yoctoproject.org> wrote:
> > Setting VULKAN_DRIVERS in an bbappend or machine conf file to something like "intel" doesn't work, because the append actions still append to that value all additional drivers.
> > Trying to remove other drivers with something like VULKAN_DRIVERS:remove = ",amd" doesn't work either, as remove only matches on word boundaries and the list is command delimited, not space delimited.
>
> VULKAN_DRIVERS is basically internal to the recipe. You need to set
> PACKAGECONFIG for mesa to include the needed set:
>
> VULKAN_DRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG',
> 'freedreno', ',freedreno', '', d)}"

Not sure I follow what you're saying.  If I add the above code inside
a machine conf file or via bbappend, I'm stuck only adding new drivers
and not able to remove those the recipe has already determined.  While
it is possible to turn off, e.g., freedreno by PACKAGECONFIG, it can
be done for neither intel nor amd.

Or are you saying that the mesa recipe should be modified to work
entirely this way: allowing *all* drivers to be configured via
PACKAGECONFIG?  Ditto for the GALLIUMDRIVERS configuration, which has
the same issue.

If the latter, is there a reason to not use `VULKAN_DRIVERS .= "${@…,
',driver', '', d)}"`.  It seems like as soon as recipes start to use
:append internally, they get harder to layer via bbappend and conf
files.

I did find a workaround to configure the mesa drivers.  In a mesa
bbappend, set the configure command line arguments directly:

PACKAGECONFIG[gallium] = "-Dgallium-drivers=iris, -Dgallium-drivers='', libdrm"
PACKAGECONFIG[vulkan] =
"-Dvulkan-drivers=intel,-Dvulkan-drivers='',glslang-native
vulkan-loader vulkan-headers"

But this unnecessarily duplicates internal code from the recipe that
will need to be kept in sync.  IMHO, being able to select drivers via
package config would be a better design.

Re: [poky] How to override mesa VULKAN_DRIVERS and GALLIUMDRIVERS variables?

[Alexander Kanavin]

On Mon, 4 Aug 2025 at 19:19, Trent Piepho via lists.yoctoproject.org
<trent.piepho=igorinstitute.com@lists.yoctoproject.org> wrote:
> Or are you saying that the mesa recipe should be modified to work
> entirely this way: allowing *all* drivers to be configured via
> PACKAGECONFIG?  Ditto for the GALLIUMDRIVERS configuration, which has
> the same issue.
...
> But this unnecessarily duplicates internal code from the recipe that
> will need to be kept in sync.  IMHO, being able to select drivers via
> package config would be a better design.

It would help to step back for a bit and see what are the values for
GALLIUMDRIVERS and VULKAN_DRIVERS that you're trying to arrive at,
what version of yocto you are using, and what is your target machine.
Then we can take oe-core master and see if that still has the same
issue, and how it can be addressed.

A better mailing list for this discussion is openembedded-core, as
poky is for meta-poky/ and meta-yocto-bsp.

Alex

Re: [poky] How to override mesa VULKAN_DRIVERS and GALLIUMDRIVERS variables?

[Quentin Schulz]

Hi Trent,

On 8/4/25 7:19 PM, Trent Piepho via lists.yoctoproject.org wrote:
> [You don't often get email from trent.piepho=igorinstitute.com@lists.yoctoproject.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> On Mon, Aug 4, 2025 at 3:15 AM Alexander Kanavin via
> lists.yoctoproject.org <alex.kanavin=gmail.com@lists.yoctoproject.org>
> wrote:
>>
>> On Sun, 3 Aug 2025 at 08:28, trent.piepho via lists.yoctoproject.org
>> <trent.piepho=igorinstitute.com@lists.yoctoproject.org> wrote:
>>> Setting VULKAN_DRIVERS in an bbappend or machine conf file to something like "intel" doesn't work, because the append actions still append to that value all additional drivers.
>>> Trying to remove other drivers with something like VULKAN_DRIVERS:remove = ",amd" doesn't work either, as remove only matches on word boundaries and the list is command delimited, not space delimited.
>>
>> VULKAN_DRIVERS is basically internal to the recipe. You need to set
>> PACKAGECONFIG for mesa to include the needed set:
>>
>> VULKAN_DRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG',
>> 'freedreno', ',freedreno', '', d)}"
> 
> Not sure I follow what you're saying.  If I add the above code inside
> a machine conf file or via bbappend, I'm stuck only adding new drivers

The above code already exists in mesa.inc, Alex was just pointing at the 
implementation and why setting PACKAGECONFIG appropriately would add 
what;s needed to VULKAN_DRIVERS.

> and not able to remove those the recipe has already determined.  While
> it is possible to turn off, e.g., freedreno by PACKAGECONFIG, it can
> be done for neither intel nor amd.
> 

VULKAN_DRIVERS_AMD = "${@bb.utils.contains('PACKAGECONFIG', 'amd', 
',amd', '', d)}"
VULKAN_DRIVERS_INTEL = "${@bb.utils.contains('PACKAGECONFIG', 'intel 
libclc', ',intel', '', d)}"
VULKAN_DRIVERS_LLVM = 
"${VULKAN_DRIVERS_SWRAST}${VULKAN_DRIVERS_AMD}${VULKAN_DRIVERS_ASAHI}${VULKAN_DRIVERS_INTEL}"
VULKAN_DRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 
'gallium-llvm', '${VULKAN_DRIVERS_LLVM}', '', d)}"

So in order to have your intel and amd vulkan drivers, you need "amd 
intel libclc gallium-llvm" in PACKAGECONFIG at the very least. Removing 
other should just be a matter of not adding them to PACKAGECONFIG in the 
first place.

If you don't have this code in mesa.inc, this means that you're using an 
older version of OE-Core than current master so it'd be nice to specify 
which one so it's easier for us to help you out, especially since mesa 
has seen a fair amount of changes recently.

> Or are you saying that the mesa recipe should be modified to work
> entirely this way: allowing *all* drivers to be configured via
> PACKAGECONFIG?  Ditto for the GALLIUMDRIVERS configuration, which has
> the same issue.
> 

GALLIUMDRIVERS_AMD = "${@bb.utils.contains('PACKAGECONFIG', 'amd', 
',r300', '', d)}"
GALLIUMDRIVERS_IRIS = "${@bb.utils.contains('PACKAGECONFIG', 'intel 
libclc', ',iris', '', d)}"
GALLIUMDRIVERS_RADEONSI = "${@bb.utils.contains('PACKAGECONFIG', 'amd', 
',radeonsi', '', d)}"
GALLIUMDRIVERS_LLVM = 
"${GALLIUMDRIVERS_LLVMPIPE}${GALLIUMDRIVERS_AMD}${GALLIUMDRIVERS_ASAHI}${GALLIUMDRIVERS_IRIS}${GALLIUMDRIVERS_NOUVEAU}${GALLIUMDRIVERS_RADEONSI}${GALLIUMDRIVERS_SVGA}"
GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 
'gallium-llvm', '${GALLIUMDRIVERS_LLVM}', '', d)}"
PACKAGECONFIG[gallium] = 
"-Dgallium-drivers=${@strip_comma('${GALLIUMDRIVERS}')}, 
-Dgallium-drivers='', libdrm"

So you need "amd intel libclc gallium gallium-llvm" at a minimum in your 
PACKAGECONFIG for this to build properly.

> If the latter, is there a reason to not use `VULKAN_DRIVERS .= "${@…,
> ',driver', '', d)}"`.  It seems like as soon as recipes start to use
> :append internally, they get harder to layer via bbappend and conf
> files.
> 

We could remove the use of :append indeed as this is very likely 
suboptimal in terms of parsing time and doesn't bring much. It's not as 
simple as jsut removing the :append, because of a few :override 
mechanism there but isn't rocker science either. However, I really don't 
think you should be modifying the variables 
(GALLIUMDRIVERS/VULKANDIVRERS) directly. PACKAGECONFIG is there for 
that. If it's not precise enough or is wrong, then it's something we can 
change in the mesa.inc to make sure other people benefit from it instead 
of just keeping some changes in your own layer.

> I did find a workaround to configure the mesa drivers.  In a mesa
> bbappend, set the configure command line arguments directly:
> 
> PACKAGECONFIG[gallium] = "-Dgallium-drivers=iris, -Dgallium-drivers='', libdrm"
> PACKAGECONFIG[vulkan] =
> "-Dvulkan-drivers=intel,-Dvulkan-drivers='',glslang-native
> vulkan-loader vulkan-headers"
> 
> But this unnecessarily duplicates internal code from the recipe that
> will need to be kept in sync.  IMHO, being able to select drivers via
> package config would be a better design.
> 

You should already be able to do that so please help us in helping you 
by telling us your PACKAGECONFIG (in your recipe and returned by 
bitbake-getvar -r mesa PACKAGECONFIG) and OE-Core version you're using. 
Note that this shouldn't be working according to our recipe as intel 
drivers should be requiring libclc. We may have a made a mistake here 
though, but something we could fix with the right amount of information, 
context and testing :)

Cheers,
Quentin

Re: [poky] How to override mesa VULKAN_DRIVERS and GALLIUMDRIVERS variables?

[Trent Piepho]

On Mon, Aug 11, 2025 at 5:29 AM Quentin Schulz <quentin.schulz@cherry.de> wrote:
> >> VULKAN_DRIVERS is basically internal to the recipe. You need to set
> >> PACKAGECONFIG for mesa to include the needed set:
> >>
> >> VULKAN_DRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG',
> >> 'freedreno', ',freedreno', '', d)}"
> >
> > Not sure I follow what you're saying.  If I add the above code inside
> > a machine conf file or via bbappend, I'm stuck only adding new drivers
>
> The above code already exists in mesa.inc, Alex was just pointing at the
> implementation and why setting PACKAGECONFIG appropriately would add
> what;s needed to VULKAN_DRIVERS.

I'm using Scarthgap.  Should have said that in the beginning.  So that
code isn't there already.  It could be added in a bbappend, and would
parse, but wouldn't have the desired effect.

> So in order to have your intel and amd vulkan drivers, you need "amd
> intel libclc gallium-llvm" in PACKAGECONFIG at the very least. Removing
> other should just be a matter of not adding them to PACKAGECONFIG in the
> first place.

I'm using scarthgap, which is different here.  The intel and amd
drivers sets don't use PACKAGECONFIG.  It seems this is just a
limitation of scarthgap's mesa build that has since been fixed.

In the current master-next, nouveau and svga are :appended to
PACKAGECONFIG by default, rather than being explicitly enabled.  But
since it's space delimited instead of comma delimited it's possible to
remove them.  But it's not possible to add a machine override with the
PACKAGECONFIG value set to the desired list, as it's using append to
add them.  It's only to remove options from the default list.

> GALLIUMDRIVERS_IRIS = "${@bb.utils.contains('PACKAGECONFIG', 'intel libclc', ',iris', '', d)}"
> GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'gallium-llvm', '${GALLIUMDRIVERS_LLVM}', '', d)}"
>
> So you need "amd intel libclc gallium gallium-llvm" at a minimum in your
> PACKAGECONFIG for this to build properly.

There's an additional line later in the file:
GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG',
'intel', ',i915,crocus', '', d)}"

So that PACKAGECONFIG will also include the i915 and crocus drivers
along with the iris driver.  I'm trying to only include iris.

I'm not using amd, but it seems to have a similar issue: adding amd to
the PACKAGECONFIG will enable multiple amd drivers and there's no way
to edit the list via :remove or other layering techniques.

> Note that this shouldn't be working according to our recipe as intel
> drivers should be requiring libclc. We may have a made a mistake here
> though, but something we could fix with the right amount of information,
> context and testing :)

I'm using the scarthgap versions, perhaps the libclc requirement is
newer than that?  But I'm quite sure this config builds and that
chromium's GPU acceleration works.  I have since disabled vulkan,
since it doesn't appear to work correctly in chromium (at all).  So
I'm not completely sure if the vulkan driver config works, including
if the swrast driver (which can not be disabled via PACKAGECONFIG) is
truly necessary to be forced on.

Re: [poky] How to override mesa VULKAN_DRIVERS and GALLIUMDRIVERS variables?

[Quentin Schulz]

Hi Trent,

On 8/11/25 7:12 PM, Trent Piepho wrote:
> On Mon, Aug 11, 2025 at 5:29 AM Quentin Schulz <quentin.schulz@cherry.de> wrote:
>>>> VULKAN_DRIVERS is basically internal to the recipe. You need to set
>>>> PACKAGECONFIG for mesa to include the needed set:
>>>>
>>>> VULKAN_DRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG',
>>>> 'freedreno', ',freedreno', '', d)}"
>>>
>>> Not sure I follow what you're saying.  If I add the above code inside
>>> a machine conf file or via bbappend, I'm stuck only adding new drivers
>>
>> The above code already exists in mesa.inc, Alex was just pointing at the
>> implementation and why setting PACKAGECONFIG appropriately would add
>> what;s needed to VULKAN_DRIVERS.
> 
> I'm using Scarthgap.  Should have said that in the beginning.  So that
> code isn't there already.  It could be added in a bbappend, and would
> parse, but wouldn't have the desired effect.
> 
>> So in order to have your intel and amd vulkan drivers, you need "amd
>> intel libclc gallium-llvm" in PACKAGECONFIG at the very least. Removing
>> other should just be a matter of not adding them to PACKAGECONFIG in the
>> first place.
> 
> I'm using scarthgap, which is different here.  The intel and amd
> drivers sets don't use PACKAGECONFIG.  It seems this is just a
> limitation of scarthgap's mesa build that has since been fixed.
> 
> In the current master-next, nouveau and svga are :appended to
> PACKAGECONFIG by default, rather than being explicitly enabled.  But
> since it's space delimited instead of comma delimited it's possible to
> remove them.  But it's not possible to add a machine override with the
> PACKAGECONFIG value set to the desired list, as it's using append to
> add them.  It's only to remove options from the default list.
> 
>> GALLIUMDRIVERS_IRIS = "${@bb.utils.contains('PACKAGECONFIG', 'intel libclc', ',iris', '', d)}"
>> GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'gallium-llvm', '${GALLIUMDRIVERS_LLVM}', '', d)}"
>>
>> So you need "amd intel libclc gallium gallium-llvm" at a minimum in your
>> PACKAGECONFIG for this to build properly.
> 
> There's an additional line later in the file:
> GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG',
> 'intel', ',i915,crocus', '', d)}"
> 
> So that PACKAGECONFIG will also include the i915 and crocus drivers
> along with the iris driver.  I'm trying to only include iris.
> 
> I'm not using amd, but it seems to have a similar issue: adding amd to
> the PACKAGECONFIG will enable multiple amd drivers and there's no way
> to edit the list via :remove or other layering techniques.
> 

OK so I believe we can improve the situation (in master, not existing 
releases though).

A first step would be to get rid of all the :append we have for "final" 
variables before they are used in PACKAGECONFIG by migrating them to use 
.= instead (or += wherever we need a space).
I'm thinking of VULKAN_DRIVERS, TOOLS, TOOLS_DEPS and GALLIUM_DRIVERS.
Something similar for PACKAGECONFIG as well, I don't like the forced 
append on x86/i686 machines and on native build.
This would allow users to override whatever they want from a bbappend by 
using a simple = operator.

We can also use intermediate variables where we have :append based on a 
PACKAGECONFIG value, e.g.:

GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'intel', 
',i915,crocus', '', d)}"

to

GALLIUMDRIVERS_INTEL = "${@bb.utils.contains('PACKAGECONFIG', 'intel', 
',i915,crocus', '', d)}"
GALLIUMDRIVERS:append = "${GALLIUMDRIVERS_INTEL}"
or maybe rather
GALLIUMDRIVERS_INTEL = ",i915,crocus"
GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'intel', 
'${GALLIUMDRIVERS_INTEL}', '', d)}"

then you can simply decide to build only crocus and not i915 whenever 
intel is put in the PACKAGECONFIG.

However I don't like it too much that we'd be expecting users to 
override those variables. It would be a mix of configuration through 
PACKAGECONFIG and specific variables (which may be renamed between 
releases for example).

I'm assuming it makes sense to enable all drivers (gallium, vulkan) and 
tools for a given hardware platform. e.g. when I enable panfrost, I only 
need to enable gallium, vulkan or tools for the panfrost drivers and 
tools to automatically be included without having to do more. This is 
useful for extending mesa based on DISTRO_FEATURES (e.g. vulkan gets 
automatically pulled in when DISTRO_FEATURES contains it). I'm assuming 
if you want to support panfrost and your distro has vulkan enabled, it 
doesn't make sense to give the user a way to disable panvk (the vulkan 
driver related to panfrost). But this gets more complicated once you 
have a PACKAGECONFIG which spans multiple drivers, like intel or amd for 
example, where we have i915 and crocus for gallium drivers, intel for 
gallium-llvm driver and intel for vulkan driver. I'm not sure what's 
best there. We could have a PACKAGECONFIG per driver if we wanted 
something like ga-i915, ga-crocus, gallvm-iris, vk-intel, and 
tools-intel (if there exists one in the future).
This seems very verbose though and one would have a LOT of PACKAGECONFIG 
to select. We could have a meta PACKAGECONFIG called intel which would 
automatically pull in ga-i915, ga-crocus whwnever gallium PACKAGECONFIG 
is selected ,pull gallvm-iris whenever gallium-llvm is selected, pull 
vk-intel whenever vulkan is also selected. "intel" itself wouldn't do 
anything but simply include other PACKAGECONFIG. Honestly I don't know 
what would be a good interface for users to configure mesa here. Maybe 
you have some idea or recommendation?

I think removing the :append in favor for .= is a good step forward 
though. It would allow us to override the drivers automatically selected 
by PACKAGECONFIG.

Cheers,
Quentin