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
--
Ryan Eatmon [email protected]
-----------------------------------------
Texas Instruments, Inc. - LCPD - MGTS
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20045):
https://lists.yoctoproject.org/g/meta-ti/message/20045
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]]
-=-=-=-=-=-=-=-=-=-=-=-
