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

[Ryan Eatmon <reatmon@ti.com>]

On 6/17/2026 9:07 AM, Antonios Christidis wrote:
> 
> On 6/15/26 2:33 PM, Andrew Davis wrote:
>> 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..) 
> 
> Yeah I agree with this. Some background info, mesa 25 was picked cause 
> it is what IMG advertises as officially supported on DDK 26.1 (new DDK 
> for SDK 12.1).
> 
> Thoughts on this Ryan and Denys ?

I'm fine with falling back to software rendering when using this BSP. 
It's not ideal and might annoy some of the users, but it might be the 
best-worst choice.  The best choice would be to stop treating SGX like 
an after thought and taking 6-12 months to get everything working.


> 
>>
>> 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]
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>>
>>

-- 
Ryan Eatmon                reatmon@ti.com
-----------------------------------------
Texas Instruments, Inc.  -  LCPD  -  MGTS