robclark changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Chrome OS Trogdor Devices - Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630 - Lenovo ThinkPad X13s - and various other snapdragon laptops) - https://oftc.irclog.whitequark.org/aarch64-laptops
louist103 has joined #aarch64-laptops
<louist103>
Its about that time... Does anyone have a good make.conf for the c630? I was going to go with -march=native -mtune=native -O2 and call it a day.
<steev>
i'd ask nerdboy but he's not in here on either of his nicks, maybe in gentoo-arm?
<steev>
i can't remember if he has one or not
<louist103>
Alright I'll try there
Mathew has quit [Quit: Leaving]
f_ has quit [Read error: Connection reset by peer]
f_ has joined #aarch64-laptops
<Segfault[m]>
is it just me or does freedreno have real trouble with whole system stutters? at least in gnome things like opening the calendar or expanding quick setting menus cause the system to miss a number of frames when on less powerful intel gpus that stutter never happens
<HdkR>
How do you know it's a freedreno issue?
<Segfault[m]>
i don't, but it doesn't seem to happen on my other gpus so i figured i'd ask here first
<Segfault[m]>
<jhovold> "Segfault: Could you see if the..." <- yep i'll test that as soon as i can
<HdkR>
I haven't noticed that on my X13s at least
<Segfault[m]>
<HdkR> "I haven't noticed that on my..." <- it's strange because the stutters happen on my x13s but not things like my t480 which has a much slower gpu
<HdkR>
Maybe get nvtop and htop and see if there is some spike of activity while it stalls out
<Segfault[m]>
hmm, nothing shows up in nvtop, htop shows like 70% utilisation of one core when repeatedly opening and closing the calendar (which almost completely freezes the system while it's being closed and opened repeatedly)
<HdkR>
nvtop - Nothing showing up as in no use, or too old of a version to see the A690?
<Segfault[m]>
no use
<Segfault[m]>
i checked that gpu use was showing properly with some other apps
<HdkR>
So entirely CPU side getting smashed is good. So perf should capture something
<Segfault[m]>
how would i get a stack trace of gnome?
<Segfault[m]>
s/stack/perf/
<HdkR>
You can attach perf to a process
<HdkR>
-p or -t depending on if you want the whole process or the single thread
<HdkR>
so probably something like `sudo perf top -t <tid>`
<HdkR>
replace top with record or whatever
<Segfault[m]>
cool, i'll give that a go when i get a chance
<HdkR>
Then theoretically that flame graph project will let you create a cool interactive SVG file to see each time it spikes when you open the menu :)
<Segfault[m]>
oh yep sure enough like 90% of the cpu use is in msm_dri.so, i'll have a closer look
<HdkR>
Hopefully not a debug build or a software fallback
<HdkR>
There was a software fallback that Counter-Strike: GO was hitting four months ago. Caused the game to go sub 1FPS. Once fixed it was then >100fps. Could be a similar situation
<Segfault[m]>
for some reason the stackcollapse thing isn't giving me any output
<robclark>
I would be interested in seeing symbolized perf report showing high msm_dri.so .. I've not seen probs and I use x13s daily.. but I guess I don't use whatever calendar app you are using and there could be some badly behaving legacy gl fallback (testing on ToT mesa would be useful)
<Segfault[m]>
i don't mean the calendar app, i mean the in-shell calendar that you can open by clicking on the clock in the status bar
<HdkR>
"in-shell" meaning whatever calendar application is built in to the DE you're using?
<HdkR>
I'm guessing Gnome-Shell?
<Segfault[m]>
yes
<HdkR>
Since not everyone uses that :)
<robclark>
hmm, that seems fine to me.. I use g-s fwiw.. f39 so I guess gnome 45 or so
<Segfault[m]>
i did mention gnome above :P
<Segfault[m]>
rawhide here but i've seen the same issue on versions at least as old as f38
<Segfault[m]>
so gnome 42 i think, i wouldn't be surprised if it goes back further
<robclark>
(yeah, dnf says gnome 45)
<HdkR>
robclark: Was the fallback for CSGo in 23.3 or did it end up in 24.0?
<robclark>
HdkR: not sure offhand, give me a sec and I can dig up mesa commit
<Segfault[m]>
can i send files here or will that screw with the bridge?
<robclark>
Segfault[m]: maybe some extensions is causing problems? perf-report w/ mesa debug syms would be informative
<robclark>
re: bridge, idk
<HdkR>
I think the bridge usually gives a URL to click
<robclark>
HdkR: 62f931204b1805a4c19ad3b7f56dd6a39749a9ce landed Sept 20th? If that helps... tbh I don't pay much attention to release branch dates since we are using ToT mesa
<HdkR>
robclark: Just checked, looks like it is in 23.3
<HdkR>
Segfault[m]: Yea, get some symbols in there. Definitely something spicy
<HdkR>
Probably also make sure you have at least 23.3 if not a newer mesa :)
<robclark>
Segfault[m]: yeah, you want to install debuginfo for mesa... since my debug syms aren't going to match your mesa build
<robclark>
after that, pasting flamegraph or perf-report output could be useful.. or just perf-archive to package up the perf data w/ debug syms and then I can dig in more deeply
<Segfault[m]>
oh and yeah i'm on mesa 24
<Segfault[m]>
hmm, does fedora not have a mesa debuginfo package? that's unfortunate
<robclark>
hmm, I _think_ it should.. tbh I'm usually using my own mesa build.. maybe run something like glxgears under gdb and let it d/l syms for you?
louist103 has quit [Remote host closed the connection]
matthias_bgg has quit [Ping timeout: 480 seconds]
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
<Segfault[m]>
<robclark> "hmm, I _think_ it should.. tbh I..." <- i tried doing that and it downloaded a bunch of debug info but it's not showing up in the perf trace or the svg
<HdkR>
Could be that perf doesn't understand how to load those debug files
<Segfault[m]>
it's odd because there do seem to be some function names showing up, just not any in msm_dri.so
<Segfault[m]>
aha figured it out
<Segfault[m]>
needed to manually add the debuginfo files to perf
<HdkR>
Sounds like something that robclark will want to fix :)
<Segfault[m]>
so i'm not sure i'm reading that right but is it a software fallback for an image format conversion?
<HdkR>
Indeed
<HdkR>
Looks like there is a format conversion happening with a texture upload that is happening on the CPU instead of some GPU conversion
<Segfault[m]>
interesting
<HdkR>
An interesting test would be to use Zink as the GL driver, since it might bypass the CPU conversion
<HdkR>
No idea how to pass environment variables to the DE for that though
<Segfault[m]>
i can try setting it in /etc/environment
<HdkR>
If you set `MESA_LOADER_DRIVER_OVERRIDE=zink` then it should force zink. Just be aware that it'll force everything to use zink in that case
<HdkR>
Well, every GL application anyway
<Segfault[m]>
yeah i know, it did seem to stop the stutter when opening those two things but it doesn't perform very well and it's very prone to locking up the whole system
<HdkR>
Interesting
<HdkR>
There's definitely cases where zink is worse off
<Segfault[m]>
or no ssh does still work it just wasn't connecting to ethernet for some reason lol, so just the gpu then
<Segfault[m]>
HdkR: i've seen a number of instances where vulkan locks up the gpu on this
<HdkR>
You're not wrong, there's still a few of those to work out even with the last kernel+mesa fixes
<HdkR>
Something in dmesg about something not collapsing
<Segfault[m]>
one sec i'll try it again and get a dmesg log
<robclark>
Segfault[m], HdkR: re: fallback, the question would be what format is it trying to use? Maybe attach gdb (if you can ssh to the laptop from another machine?) and then `b convert_ubyte` and then `c`, and when it hits the breakpoint `bt`
spoonerUK has joined #aarch64-laptops
<Segfault[m]>
yeah i can try that in a bit
<Segfault[m]>
<jhovold> "Segfault: Could you see if the..." <- i've powered on and rebooted the laptop a couple times and not seen any more failures, i'll test it some more tomorrow but yeah it's looking good
<jhovold>
Segfault[m]: that's good to hear, thanks for testing
<jhovold>
Segfault[m]: ah, there must be something else causing this then
<jhovold>
does it seem harder to trigger now, or were you just lucky the first few reboots?
<jhovold>
you said you hit it as often as every 2 out 3 boots before, right?
<Segfault[m]>
seems like i was just lucky, even before 6.8-rc4 it seemed to work more reliably after the device had been on and running for a while, maybe heat related?
<robclark>
thx
<robclark>
hmm, converting from GL_BGRA to GL_RGBA8 ??
<robclark>
Segfault[m]: if you can recompile mesa, try:
<Segfault[m]>
heh, funnily enough this now runs way smoother than it does on windows, for some reason there the gpu drivers get a lot less responsive after the device comes out of suspend
matthias_bgg has joined #aarch64-laptops
<robclark>
I think what we really want is PIPE_TEXTURE_TRANSFER_BLIT_IF_NOT_MEMCPY ..