Re: [meta-ti][wrynose/master][PATCH V2] mesa-pvr: Migration from v24.0.1 -> v25.2.8

[Andrew Davis <afd@ti.com>]

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 (#20033): https://lists.yoctoproject.org/g/meta-ti/message/20033
> Mute This Topic: https://lists.yoctoproject.org/mt/119748763/3619733
> Group Owner: meta-ti+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [afd@ti.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>