ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
<HdkR>
agl7_: It's because it would be the same file. a690 is effectively just a bigger a660 so the same file works for both.
<mayco>
hey, on the x13s, I'm having an audio issue with wired headphones where it seems like gain is being throttled if audio is too loud for more than a fraction of a second. it's a little nauseating to listen to. anyone know about this?
<agl7_>
HdkR: Which is a nice thing: Cinnamon now doesn't say "Software rendering" with the a690_gmu.bin, so now it's the graphics hardware's turn.
<agl7_>
The load is much lower!
agl7_ has quit [Quit: Leaving]
schaeffer has quit [Quit: well, bye]
schaeffer has joined #aarch64-laptops
mayco has quit [Remote host closed the connection]
agl7 has quit [Quit: bis denne]
hightower2 has joined #aarch64-laptops
rfs613 has quit [Quit: restart]
rfs613 has joined #aarch64-laptops
<robclark>
yeah, the sqe fw is generally the same within the "sub-generation" of a6xx.. but named after the first device of that sub-generation.. a660 and a690 (and others) are all subgen 4 so they all use a660_sqe.fw
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
iivanov has joined #aarch64-laptops
jhovold has joined #aarch64-laptops
<steev>
quick hide everyone, johan is back
<HdkR>
\o
<jhovold>
:)
rfs613 has quit [Quit: restart]
rfs613 has joined #aarch64-laptops
matthias_bgg has joined #aarch64-laptops
svarbanov has joined #aarch64-laptops
godvino has joined #aarch64-laptops
<HdkR>
`Configured Memory Speed: 1555 MT/s` Memory reclocking on the Lenovo X13s not working?
<HdkR>
`Speed: 2092 MT/s` Roughly correct speed
<HdkR>
But configured incorrectly even under load?
<HdkR>
Might explain my memory benchmark not getting expected numbers
<HdkR>
Any way to force it to maximum clocks?
<HdkR>
That looks to be around 50GB/s of its theoretical peak of 68GB/s. Which my memset benchmark is able to pull ~44GB/s out of
<Kelsar>
After reading here for a while, I decided to stay on x86 for atleast one more generation ;)
hightower3 has joined #aarch64-laptops
godvino has quit [Read error: Connection reset by peer]
godvino has joined #aarch64-laptops
hightower2 has quit [Ping timeout: 480 seconds]
godvino has quit [Read error: Connection reset by peer]
_xav_ has quit [Ping timeout: 480 seconds]
iivanov_ has joined #aarch64-laptops
iivanov has quit [Ping timeout: 480 seconds]
_xav_ has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
iivanov_ has quit [Ping timeout: 480 seconds]
hightower3 has quit [Remote host closed the connection]
matthias_bgg has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
agl7 has joined #aarch64-laptops
matthias_bgg has quit [Ping timeout: 480 seconds]
<clover[m]>
Blasphemy
matthias_bgg has joined #aarch64-laptops
<HdkR>
bamse: Anything about the memory reclocking not working on X13s right now?
matthias_bgg has quit [Quit: Leaving]
hightower2 has joined #aarch64-laptops
agl7 has quit [Quit: bis denne]
<bamse>
HdkR: how much not working?
<HdkR>
bamse: 1555MT/s instead of the expected maximum of 2092 MT/s, which is about 75%
<HdkR>
According to dmidecode anyway
<bamse>
HdkR: i've seen that number as well...
<bamse>
HdkR: i apparently had a relevant pull request in my inbox...
<bamse>
but when you let it idle it goes back to 1018MHz, right?
<HdkR>
nope
<bamse>
hmm, it should
<HdkR>
Well that's probably a different issue I guess :)
<bamse>
HdkR: do ou have two devices in /sys/bus/platform/drivers/qcom-bwmon ?
<HdkR>
I don't even have a qcom-bwmon
<bamse>
then that's the reason why you don't see that number dance around
<bamse>
the MT
<bamse>
/s
<bamse>
but that said, when i'm running my memory benchmark i get 2096 as well...
<HdkR>
That's good, so just dmidecode not getting new information
<bamse>
checking...
<bamse>
no, it doesn't move as the ddr frequency changs
<bamse>
changes*
<HdkR>
Quirky but okay
<bamse>
those layers are not involved in the frequncy change, so they would need to go the extra mile to update the data i think
<bamse>
more than the extra mile...
<HdkR>
bamse: Do you know if there is a way to get BW usage by client on the bus?
<HdkR>
Curious about querying BW usage of the CPU clusters and GPU
<clover[m]>
what do you guys do for chatgpt prompts? right now im using Bing Chat in the chromium browser
<HdkR>
You say that like I would waste my time with an AI network
<steev>
i don't even know what the question means
<clover[m]>
are there any cool open linux software you use or know of for AI? preferably something not connected to the big tech companies or censored or anything
<HdkR>
AMD's FSR I guess. It's better than most TAA implementations :P
<HdkR>
Wwait, is that one AI yet or just a modified Lancos filter with temporal information? Maybe the 3.0 release was going to be "AI" based.
<HdkR>
Lanczos even
<bamse>
HdkR: we have two bwmon instances in the upstream dts, one measures the traffic in/out of the cpu subsystem, the other measures the traffic between llcc and ddr...
<HdkR>
So just missing the GPU cluster which would be the most interesting bit
<robclark>
currently we just tie the gpu's icc vote to opp, so gpu running at higher freq, we ask for more bw
<HdkR>
Very reasonable for just ensuring the GPU has all the bandwidth available to it
<HdkR>
I used to just keep tegrastats open when porting games to the SHIELD TV which had super nice GPU BW stats. If a scene starting crossing 50% memory BW of the device, it meant that I need to start looking at optimizing that
<robclark>
we at least _used_ to do that for CPU as well, pre bwmon
<HdkR>
Sounds like it's potentially viable. Just needs to be wired up somewhere
<steev>
do it
<HdkR>
As a testament to this statistic being useful. In one game we found a scene that wasn't 60fps. GPU load by itself was something like 90FPS, CPU Load by itself was like 120 "FPS", Together? like 50FPS. Tegrastats with its total memory BW utilized statistic pointed immediately towards a bottleneck since it was at like 80% utilization
<HdkR>
Optimized the GPU to stop overdrawing so hard and it was fixed :D
<HdkR>
Also optimized the crap out of a vertex wave generator, which didn't show any uplift in perf because memory BW bounded
<HdkR>
steev: But that would require me to do kernel development when I'm already swamped with stuff that I know how to do. Rather than jumping in to the empty pool of kernel development
<steev>
didn't stop me from shoving out the bluetooth driver!
<HdkR>
steev: Sounds like you're willing to do kernel work :)
<steev>
i don't even have a clue what you're talking about
<steev>
maybe you could convince abelvesa to do it
<clover[m]>
just ask chatgpt to do it
<HdkR>
abelvesa: Can I get a way to get live BW consumption numbers pumped to userspace somehow? Total bus usage numbers, CPU, and GPU clients broken out. GB/s sort of thing :)
<HdkR>
AMBA/AXI obviously has this information somewhere since Tegra X1 had the stats
<steev>
note: i only picked on him because he did some bwmon stuff before