ChanServ 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
icecream95 has joined #aarch64-laptops
<icecream95>
I'm seeing some interesting memory bandwidth results on X1E... the limit appears to be about 2*read + write < 121 GB/s from the CPU (with a single core able to saturate read bandwidth, but two required for non-zva write)
<icecream95>
I wonder why reads seem to be exactly twice as expensive as writes... the other way around would make more sense!
<HdkR>
store queue latency hiding is pretty good, especially when stores retire in one cycle, where loads take like three
<HdkR>
Although the store queue is nearly 1/4th the load queue and L1 can handle 4 loads/cycle versus 2 stores/cycle, or a combination of 4 total
<HdkR>
Microbenching sure is hard, wonder if you're bounded somewhere else :)
<zdykstra>
is there a serial port that can be accessed on the x13s? Based on kernel logs it looks like there might be one.
<icecream95>
With four cores, I notice two get 20 GB/s read, and the other two (which share a cluster) only get 10 GB/s
<Nios34[m]>
macc24: Here is my dts file I'm using https://git.050821.xyz/_admin/gists/8, I'm running debian so I don't really know how to dump the acpi table
<HdkR>
icecream95: That's spicy, some of the cores in the clusters are different. Wonder if the scheduler models that correctly :)
<HdkR>
Cores 0-3 are variant 2, 4-11 are variant 1
<icecream95>
Well it seems to be more that the memory controller shares bandwidth between clusters, and doesn't know that one of those clusters has two threads rather than one
<HdkR>
Oh, you're saying 20/10GB/s while another cluster is hammering the memory controller?
<HdkR>
Because that's not really unexpected
<HdkR>
AMD has the same problem on Zen
<icecream95>
My formula predicts memcpy performance pretty well... the cost for that is 3*size, and indeed I see about 40 GB/s
<icecream95>
But it seems Chips and Cheese managed 80 GB/s read... I want my missing 20 GB/s bandwidth!
<robclark>
icecream95: idk if you want to test https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32869 with OpenMW.. it at least fixes the test case you came up with (for fd.. I haven't really had time to look into that with tu+zink and probably need to get back to $day_job work and other things)
<HdkR>
icecream95: What instruction are you using for reads? Because it can be very hard to get the full perf out of this chip
<HdkR>
At only 32bytes/cycle coming in to L1d, any sort of inefficiency crops up quickly
<HdkR>
:D
<icecream95>
HdkR: memchr... (which uses single vector load instructions). I don't know about L2, but my experience is that it's really really easy to saturate RAM bandwidth, at least to the level of my formula
<icecream95>
robclark: Yup, that fixes it, and now rendering looks the same as llvmpipe (except slightly faster)
<HdkR>
icecream95: Would have better luck if it used LDP then, vector loads are slower than GPR loads
<icecream95>
Zink isn't that important to me, though OpenMW intends to switch to Vulkan ... eventually
<robclark>
I would hope for more than "slightly" faster than llvmpipe, but idk too much about openmw rendering patterns (I guess if it were purely bw bound then maybe the diff btwn hw and cpu rendering would be less) ;-)
<robclark>
I hope that vk would at least better define the behavior in this case.. and possibly add some conformance tests
<icecream95>
robclark: It's more that llvmpipe is *almost* playable even at the native 2880x1620 resolution of my screen. But Freedreno is still much faster
<HdkR>
Freedreno also has the advantage that the CPU isn't going to bake itself :D
<HdkR>
Hopefully LLVM is a bit more efficient than my powerburn test at least
<HdkR>
llvmpipe*
<robclark>
idk how demanding openmw is.. if it is closer to memcpy on cpu vs memcpu on gpu, maybe it matters less.. but if it is more demanding or benefits from gmem/etc to reduce bw then gpu should be a win
<icecream95>
From actually comparing FPS numbers, OpenMW is about 15x faster with Freedreno than llvmpipe
<icecream95>
So not actually all that close
<icecream95>
Though I think it's funny that llvmpipe is almost the same performance as my RK3288 chromebook...
<HdkR>
At 6-8w per CPU core, LLVMPipe probably also consumes about 15x more power :P
<robclark>
idk from cpu perspective.. but bw costs power, so unless the thing causing the bw (assuming use-case is purely bw bound, ie. igpu's don't have vram) then I guess it could pencil out
<robclark>
but if there is a win for real gpu vs llvmpipe then it implies there is something more going on than memcpy ;-)
tobhe_ has joined #aarch64-laptops
<icecream95>
At 40W vs 6W over idle, llvmpipe is "almost" as efficient as the chromebook. But Freedreno gets the same frame rate at about 2W over idle
tobhe has quit [Ping timeout: 480 seconds]
<robclark>
heheh, I guess that implies there is more going on there than just "memcpy" bw limits, which gets into the areas that a gpu can be way more efficient
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<icecream95>
huh, it also seems like the GPU gets priority for bandwidth... while running a Vulkan bandwidth test the CPU gets only a tenth of normal bw
<HdkR>
That makes sense in most cases
<HdkR>
Tegra X1 did the same thing
<HdkR>
Apple also kind of did the same thing by their cores just not being able to saturate the whole memory bus :D
hipboi has joined #aarch64-laptops
ungeskriptet_ has joined #aarch64-laptops
ungeskriptet has quit [Ping timeout: 480 seconds]
hipboi has quit [Quit: hipboi]
ungeskriptet_ is now known as ungeskriptet
hipboi has joined #aarch64-laptops
nothorseface has joined #aarch64-laptops
alfredo has joined #aarch64-laptops
nothorseface has quit []
hipboi has quit [Quit: hipboi]
hipboi has joined #aarch64-laptops
icecream95 has quit [Ping timeout: 480 seconds]
hipboi has quit [Quit: hipboi]
nothorseface has joined #aarch64-laptops
nothorseface has quit []
alfredo has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
alfredo has quit [Quit: alfredo]
Dell has joined #aarch64-laptops
<Dell>
hi
<Dell>
how are you all
<Jasper[m]>
I'm kinda hoping you're a real person, but I don't hold out any hope since you sent the exact same message in the f-droid channel
Dell has quit [Read error: Connection reset by peer]
<travmurav[m]>
Terrible, as I'm deeply saddened by the fact that dtbloader is still two devices behind qcom for-next /s
<SpieringsAE>
welp I have another qualcomm device to mess round with, gf bought a lenovo thinksmart view, and now I have to make linux run on it, actually spotted you in my research travmurav
<travmurav[m]>
well the important part is actually ending up with your device added upstream :)
<travmurav[m]>
(which I'm happy to say all devices in dtbloader's list got to by now, nothing tentative left)
<SpieringsAE>
nice! most of the drivers for that lenovo thing seem to be, but the actual dts is not
<SpieringsAE>
there is some msm8953-mainline organisation on github with stuff for it though
<SpieringsAE>
and it seems quite up to date
<travmurav[m]>
Uh
<travmurav[m]>
SpieringsAE: cd 18781y?
<SpieringsAE>
yep
<travmurav[m]>
You probably want to align your work with them and Felix who worked on it
<travmurav[m]>
There is a matrix room but not sure if there is an irc bridge
<SpieringsAE>
guess I'll have to get on matrix then
<travmurav[m]>
MSM8953 Mainline
<travmurav[m]>
Duh irc bridge didn't even send the matrix link just wrote the pretty name of the room
<SpieringsAE>
cant seem to find it
<SpieringsAE>
ahahah
<travmurav[m]>
#msm8953-mainline:matrix.org
<SpieringsAE>
yep got it now thanks!
nothorseface has joined #aarch64-laptops
alfredo has quit [Read error: Connection reset by peer]
suihkulokki is now known as suihkulokkibak
alfredo has joined #aarch64-laptops
nothorseface_ has joined #aarch64-laptops
laine has quit [Ping timeout: 480 seconds]
suihkulokki has joined #aarch64-laptops
suihkulokkibak has quit []
suihkulokki has quit []
alfredo has quit [Ping timeout: 480 seconds]
nothorseface has quit [Ping timeout: 480 seconds]
alfredo has joined #aarch64-laptops
alfredo1 has joined #aarch64-laptops
frankenstein__ has joined #aarch64-laptops
alfredo has quit [Ping timeout: 480 seconds]
alfredo1 is now known as alfredo
nothorseface_ has quit [Ping timeout: 480 seconds]
frankenstein__ has quit []
alfredo has quit [Read error: Connection reset by peer]
SpieringsAE has quit [Remote host closed the connection]
alfredo has joined #aarch64-laptops
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
travmurav: just decided to run the dtbloader describe_hw script on my deepcomputing riscv laptop, but sadly most of the info is junk :(
<SpieringsAE>
couldve been the first supported riscv system
<SpieringsAE>
I wonder how to fill out the proper info in uboot
<SpieringsAE>
ah okay its a dtb thing, it seems that these riscv devices are starting to use mainline linux dtbs for U-boot.
<SpieringsAE>
Not sure if the kernel people will like those things in there
SpieringsAE has quit [Quit: SpieringsAE]
alfredo has quit [Remote host closed the connection]
Tony[m]1 has joined #aarch64-laptops
<macc24>
i don't think it'd be that useful for risc-v
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
well I have 2 options, make dtbloader work, or make refind able to load dtbs itself. dtbloader seemed like a nice shortcut
<SpieringsAE>
but why not? I've only seen dtb based riscv devices so far I think
<macc24>
wait, it runs on efi and not u-boot?
<SpieringsAE>
well uboot does efi boot
<SpieringsAE>
so uboot currently loads grub, which then loads the kernel and dtb
<SpieringsAE>
but I don't like grub, and refind has a very nice search function, so it also finds boot options on stuff like usb sticks
<SpieringsAE>
so it is very nice for firmware which doesn't have a seperate boot menu
<SpieringsAE>
I mean uboot technically does, but meh
<SpieringsAE>
If I wanted to type commands I'd just use the grub cli lol
<SpieringsAE>
which has the benefit of not needing a serial adapter
SpieringsAE has quit [Remote host closed the connection]
<dgilmore>
I updated the bios on my t14s yesterday, and now I seemingly can not access the bios or boot options, has anyone else experienced this?
<macc24>
is your fnlock on?
<macc24>
press reboot in windows with shift pressed, then go into "repair computer" "advanced options" "uefi firmware menu"
<dgilmore>
It was not on, I got in using windows and had to unset the option to allow f12 for boot and to show the bios option. apparently the bios reveresd the options. or likely just ignored what was set
<tobhe_>
i'll have a look at those and see if that works better than our current Ubuntu patch
<tobhe_>
another possibility I guess would be that it was fixed in the firmware update
<freekurt[m]>
I asked Santa for a tablet with a snapdragon cpu + e-ink display with mainline linux kernel support for Christmas. He didn't come through. I am starting to wonder if he is even real.
<Melody91>
he's Santa, not God, he can't make *miracles* happen