On 6/11/26 1:29 PM, Antonios Christidis via lists.yoctoproject.org wrote:

On 6/11/26 11:50 AM, Denys Dmytriyenko wrote:
On Thu, Jun 11, 2026 at 11:30:42AM -0500, Antonios Christidis via 
lists.yoctoproject.org wrote:
On 6/11/26 8:23 AM, Denys Dmytriyenko wrote:
On Wed, Jun 10, 2026 at 09:17:37PM -0500, Ryan Eatmon via 
lists.yoctoproject.org wrote:
On 6/10/2026 5:58 PM, Antonios Christidis wrote:
Dear Ryan Denys,


Let me know your thoughts on the overall patch. I am particularly
interested on your opinions on the following change:

On 6/10/26 5:51 PM, Antonios Christidis via lists.yoctoproject.org wrote:
BSP_MESA_PVR_VERSION:bsp-ti-6_18: = "2%"
So... I think what this does is establish the pattern for which
version it will match to.  And then from that pattern it will pick
the highest version.

So for ALL 6_18 builds it will probably choose 25 and never 24.
Which is not what you want.

... I think ...

We have never tried to mix versions like this in the past, so I'm
not 100% sure what the best course is.

Likely a mixture of the override based on machine needs to be in
there. And for that I'm thinking you might need an extra variable.

BSP_MESA_PVR_VERSION_6_18 ?= "25%"
BSP_MESA_PVR_VERSION_6_18:am57 = "24%"
BSP_MESA_PVR_VERSION_6_18:ti33 = "24%"
etc...

BSP_MESA_PVR_VERSION:bsp-ti-6_18 = "${BSP_MESA_PVR_VERSION_6_18}"


Something along those lines?  That would be the most clear for
people to follow as well.
It was done differently in this patch:

mesa-pvr 24 was maked compatible only with SGX platforms, while mesa-pvr 25
was marked compatible with the rest of the platforms. Also not ideal though.

I think Ryan's idea is easier to follow, compared to the flow I have
included in this series.

Another way of going about this (I'm not saying this is easier
and/or a better method) would be to create 2 MACHINEOVERIDES. On a
per platform level (ex: am62pxx.inc) to add ```MACHINEOVERRIDES =.
"rogue-core:"```, then within ti-bsp
```BSP_MESA_PVR_VERSION:bsp-ti-6_18:rogue-core = "25%"``` picking
the right version when paired against a sgx-core override.

An added benefit to this, the new overrides would cut down on the
need for duplicate variables tracking Rogue vs SGX (examples:
BSP_SGX_DRIVER_VERSION, BSP_ROGUE_DRIVER_VERSION).

A downside to this flow, tracking what is currently included
within MACHINEOVERRIDES , describing what architecture of GPU core
doesn't really fit well with pre-existing overrides.


Let me know what you think?
FWIW, we used to have separate "sgx" and "rogue" flags in MACHINE_FEATURES
years ago. Not exactly MACHINEOVERRIDES, but still easy to do conditionals.

But complaints were that all this needs to be unified and, first, both of
those flags were merged into "gpu" MACHINE_FEATURES and eventually completely
removed.

So, I'd argue if you do want to bump mesa-pvr version, it has to be done for
all the platforms regardless of the graphics core, SGX or Rogue. We've already
went through a lengthy period in kirkstone (2022 era) where SGX was completely
broken and customers were sent back to use dunfell (2020 era) just to get SGX
working at all...

I see, if the desired way is to migrate both cores  at the same time, then this 
would cause a big delay. Since migration for SGX cores from v24 to v26 is 
substantially more effort and can take weeks (as IMG provides no support). That 
being said, I have already planned for such effort, but that is later down the 
year when a legacy SDK release could happen.

I think its still worth the effort to migrate for mesa only for Rogue, 
especially when mesa-pvr v24 is staying around and can be used by SGX devices. 
Also worth a note, SGX devices are legacy and have not received a official 12.x 
release - so if any customer wants to use the latest SDKs for such devices they 
would have to go back to Scarthgap 11.x SDKs. So if this series or some 
different revision does get merged, the latest official SDK for such devices 
will not be changed.


If SGX isn't supported then what is wrong with updating Mesa to v25 anyway for
the SGX platforms and just letting it fallback to SW rendering? As you say if
customers want functioning SGX they need to stick to 11.x or wait till 12.1,
so nothing is lost here. (In theory HW accel might have still worked with SGX
on a Mesa v24 + Wrynose combo but that isn't verified, in fact Wrynose expects
Mesa v26 so even the current Rogue using Mesa v25 is a bit of an unknown..)

Andrew

Regarding the point of SGX and Rogue being unified, this might also be a good 
point to start making distinctions and branching the two cores, as the overall 
drivers and supporting software like Mesa are drastically different for the two 
stacks.

I wish there was a way to use syntax like
"BSP_MESA_PVR_VERSION:bsp-ti-6_18 = "24%|25%" or even
"24.0.1|25.2.8". Is there a better way of enabling this logic ?

Also already aware of the extra ":" post-pended to the variable, I
can send a v3 if that's all the feedback.


Kind Regards,

Antonios






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20038): 
https://lists.yoctoproject.org/g/meta-ti/message/20038
Mute This Topic: https://lists.yoctoproject.org/mt/119748763/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to