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

Hi Trent,

On 8/11/25 7:12 PM, Trent Piepho wrote:
> On Mon, Aug 11, 2025 at 5:29 AM Quentin Schulz <[email protected]> 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