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)
<shawnguo> steev: the latest tag in qrtr upstream tree https://github.com/andersson/qrtr is v0.3
<shawnguo> when you were talking about 0.6, did you mean tag debian/0.6-983b223423f3ec-1 in https://git.linaro.org/landing-teams/working/qualcomm/pkg/qrtr.git?
<shawnguo> in that case, I have to say the tag versioning is actually confusing. tag debian/0.3+47g9dc7a88-1 is actually newer and including more up to date upstream commit than debian/0.6-983b223423f3ec-1.
<steev> shawnguo: well, you seem to include the 0.6 in the 0.4 iso so... we're kinda stuck i guess?
<steev> that's why i assumed the 0.6 was newer :)
<steev> steev@limitless:~/git$ dpkg -l | grep qrtr
<steev> ii libqrtr1 0.6-983b223423f3ec-1 arm64 QRTR library
<steev> ii qrtr 0.6-983b223423f3ec-1 arm64 QRTR applications
strongtz[m] has joined #aarch64-laptops
<steev> well if the 0.3 is newer... i'll yank those down and rebuild my isos
<shawnguo> steev: Ah, okay. I cannot even remember why I included 0.6 in the first place. I suspect that's what linaro-overy gives back to Dec. 2020, when I was firstly trying to create the CD image.
<shawnguo> I will move to debian/0.3+47g9dc7a88-1 for the next release of cd-image.
<steev> :) good because, although he's not on here... _ keeps asking about it
<steev> why his name is, _, i don't know
<shawnguo> for easier spelling I guess :)
<steev> could be :)
<steev> i think it's because tables is already taken on oftc
<steev> i think, once the clk issue is tracked down, that would be a good reason to bump to 13 and have the lmh driver and ipa and whatnot
mattst88 has quit [Ping timeout: 480 seconds]
FizzBuzz has quit []
mattst88 has joined #aarch64-laptops
iivanov has joined #aarch64-laptops
alpernebbi has joined #aarch64-laptops
samueldr has quit [Remote host closed the connection]
samueldr has joined #aarch64-laptops
samueldr has quit [Remote host closed the connection]
samueldr has joined #aarch64-laptops
alpernebbi has quit [Quit: alpernebbi]
iivanov has quit [Remote host closed the connection]
<steev> finally built mesa on the flex 5g, works good
<HdkR> :D
<HdkR> Freedreno and Turnip is good stuff
<robclark> steev: so I should land the a680 MR?
<steev> robclark: please :)
<steev> HdkR: i have no idea how to do stuff with turnip tbh
<HdkR> vkcube is all anyone needs right?
<steev> robclark: you want me to Tested-By on it?
<bamse> robclark: the mesa a680 support?
<robclark> naw, was just waiting for someone to confirm that more than kmscube was happy
<robclark> yeah
<steev> it makes my alacritty translucent, that's all i care about
<steev> HdkR: robclark: should vkcube be telling me lavapipe?
<HdkR> womp womp
<robclark> nope
<bamse> robclark: i'm quite happy with it, i do sometimes have some flickering of parts of my windows in wayland, but i think this is good
<steev> hm, i have mesa-vulkan-drivers installed
<bamse> robclark: i've been using sc8180x as my desktop machine for a few weeks now and haven't had any issues with graphics
<robclark> parts of windows? Hmm..
<robclark> steev: you'll want to be using your own build of mesa for tu (as well as gl).. distro package probably wouldn't have it yet (since branch hasn't been merged yet)
<bamse> robclark: like the top 200px sometimes flickers (i.e. i see the wallpaper instead)
<robclark> huh
<steev> robclark: ah, all i had merged in was that patch on top of the debian package for 21.2.0
<bamse> robclark: might not be a rectangle though...perhaps a triangle...but i think it's always the top of the windows
<bamse> robclark: just a single frame every now and then, and i have no way to reproduce it :/
<bamse> robclark: but still, please merge what you have :)
<robclark> yeah, I assigned it to marge
<bamse> robclark: it's much less noticible than the issues i had on c630 with xterm
iivanov has joined #aarch64-laptops
<robclark> so, I'm thinking, pick something that I would expect to use gmem mode, like glmark2 (there is a wayland version).. if you see the same effect then I'm guessing it happens on composition.. so maybe we haven't completely flushed caches or something like that when display starts to scanout?
<bamse> in the main glmark2 repo, or some fork?
<robclark> main repo
<robclark> if your distro doesn't package the wayland version, the normal x11 one should be fine
<bamse> arch doesn't seem to pack glmark2...
<robclark> ahh
<bamse> well, not aarch64 at least, uncertain about x86
<bamse> but it's being built now
<bamse> and it sayd that it found wayland stuff
<bamse> says*
iivanov has quit [Ping timeout: 480 seconds]
<bamse> robclark: do i run glmark2 with some arguments?
<robclark> with no args it will just cycle thru the "tests"
<robclark> something like "-b build" should be fine
<bamse> [build] <default>: FPS: 453 FrameTime: 2.208 ms
<bamse> and no visible artifacts there
<robclark> should be somewhat faster than that (if icc wired up, and devfreq is cooperating, etc)..
<bamse> i still have the problem that my soc refuses to go above 34 degrees C
<robclark> but ok, that isn't triggering the window corruption
<robclark> oh, heh, ok
<bamse> or tsens is just broken
<bamse> but that seems unlikely, because i get something that looks sane...just that it's 33-34 degrees
<bamse> no corruption at all
<robclark> ok
<steev> here i got fps 719 frametime 1.391
<steev> bamse: i noticed the temp thing too, and it was odd to me that the c630 will go to 90 and the flex chills at 30 some
<bamse> steev: before lmh c630 wouldn't go above 70...so Thara and i am wondering if it's related to that
<bamse> steev: but i haven't found the time to play around with it more
<robclark> so little 'ol a618 in lazor should do ~1450fps
<HdkR> My HDK865 confuses me with its core scheduling. 100% CPU usage thread sometimes not being run on the prime thread. Very confusing
<HdkR> prime core*
<bamse> HdkR: i bet it's better than db820c, which has a tendency to schedule you on the 19.2MHz cores
<robclark> ouch
<bamse> i'm actually surprised that it works
<HdkR> wow
<steev> to be fair
<steev> i'm running on the initial base push that bamse did, i ahven't looked into updates or fixes at all
<bamse> steev: you still got 50% better result than me :)
<HdkR> Looks like the DTS has all the A77 cores rated at the same `capacity-dmips-mhz` of 1894. While the `dynamic-power-coefficient` ends up being 514 for the less powerful cores, then 598 for the prime. Wonder if I equalize the power coefficient if it chooses the prime core all the time
<HdkR> Weighted too heavily for preserving power maybe?
<steev> this is also uhh, linaro's fork of glmark2-es ?
<bamse> HdkR: it's not unlikely that those numbers are tweaked for a mobile usecase
<HdkR> I'm surprised the performance scheduler cares
<bamse> HdkR: does that affect the placement of the tasks?
<HdkR> No idea :D
<HdkR> But really if it's a mhz thing, the kernel should know 2.4Ghz versus 2.8Ghz, Would be weird that raising the capacity number would resolve the issue
<bamse> HdkR: doesn't sounds like they sound have the same capacity
<HdkR> It's capacity-dmips-mhz, which is dmips/mhz
<bamse> i see
<HdkR> ALU wise the cores are the same. Only difference is clockspeed and L2 cache
<bamse> so the dynamic-power-coefficient should tell the kernel that it has more juice to squeeze out of the prime core...
<HdkR> I increased the capacity, and lowered the power coefficient and now this single threaded bench is sticking to the prime core like glue
<HdkR> I'll need to test again with only one of these changing