02:21 <quinine> > <@clover:ironrobin.net> browserbench.org/Speedometer2.0 results:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/UObSQBZKcZcZYlXUrzehRXnm>)

02:22 <clover[m]> Thanks now I'm more confused

02:22 <quinine> according to mozilla, firefox should have about 100 points in Speedometer. 🤔

02:23 <clover[m]> Arm64 different?

02:23 <quinine> Does it not perform well on x13s? 🤔

02:24 <HdkR> According to Mozilla on what hardware?

02:24 <quinine> clover[m]: Maybe something to do with gpu?

02:24 <HdkR> The CPU obviously isn't as fast as an Intel 13900k :P

02:29 <quinine> HdkR: makes sense, proportionally, chrome has the same regression.

02:31 <quinine> I don't know why chrome and chromium have different performance in mozilla's test.

02:33 <quinine> Maybe chrome has PGO enabled but chromium doesn't? 🤔

03:37 <akaWolf0> clover[m]: yeah, in Windows they do it right :)

10:14 <danielt> I finally knocked up a patch to get gnome-shell/wayland running on systems with an external monitor. Not yet sure if it is an approach that can work upstream but people are welcome to test it: https://gitlab.gnome.org/GNOME/mutter/-/issues/2398#note_1747075

13:03 <leezu> robclark: Does cros use/expose the Qualcomm DSP Hexagon cores or has plans to do so? Lazor/sc7180 for example has a 5 TOPS compute remote processor device that can be used to offload compute expensive workloads like ML model inference, but only the modem remote processor (mpss) seems supported in upstream Linux yet for sc7180. If anyone is interested, I found this article

13:03 <leezu> gives a good overview over the DSPs https://research.checkpoint.com/2021/pwn2own-qualcomm-dsp/

13:52 <robclark> leezu: I don't believe we use the dsp

14:11 <exeat> Seems like a nice little compute unit: https://iris-programming.github.io/pdf/hpec21-cosmiccastle.pdf

14:11 <exeat> (Buried under a mountain of proprietary cruft)

15:34 <amstan> leezu: every time we considered using the any DSP it's been like hitting a brick wall

15:34 <amstan> i believe audio uses some of it, but nothing else

15:35 <HdkR> The Hexagon is a pretty cool piece of kit. Shame about that userspace accessibility

16:25 <amstan> it's the usual story, hardware might nice but software lockdown ruins it

16:35 <HdkR> I can understand that context-switching the usage of it is hard

16:35 <HdkR> But GPUs have had this solved for a long time, I'm sure DSPs could sort their shit out at some point

16:44 <clover[m]> HkdR: would FEXRootFSFetcher work on arch linux arm?

16:54 <steev> danielt: to test that patch, i'm asssuming i should revert https://github.com/steev/linux/commit/2b0cc2eff7ccab34892db94cc50eff9407796085 ?

17:11 <danielt> steev: Testing either way round is somewhat useful since increasing confidence it won't cause regressions is good (if I got the logic in mutter right when gnome-shell/wayland should fire up with or without the hack patch in the kernel).

17:14 <HdkR> clover[m]: Yes, it would just fetch an Ubuntu image to use under FEX.

17:15 <HdkR> We don't have our tooling setup to generate Arch x86 rootfs images yet

17:15 <danielt> steev: ... but take a look at the chat on the issue tracker before deciding whether or not to invest time in testing... other contributors who posted today are right, the patch I proposed is at best a stop-gap since it simply maintains the illusion that you can look up "the" plane for a CRTC (it does not add smarts to mutter to help it adopt the "best" planes)

17:24 <steev> danielt: oh i did, i figured i'd test it anyway :) i don't like gimping the driver

17:35 <clover[m]> Hope it works

17:36 <steev> it's a stopgap either way

18:58 <agl7-x13s> Good Evening! :-)

19:34 <leezu> amstan: I thought the aDSP and cDSP are widely used on Android. What kind of issues did you face?

19:35 <amstan> leezu: i'm talking about chromeos

19:35 <amstan> i'm sure it's widely used on android, that's what qcom designs their stuff for

19:35 <leezu> Yes. I mean why do you face issues when trying to use it with cros?

19:35 <amstan> signing, documentation, toolchains, etc

19:36 <amstan> for a lot of stuff you have a choice to be an "app" in a proprietary DSP OS ecosystem or not use the DSP at all

19:36 <amstan> there's no open source option

19:37 <leezu> I see. For cDSP there is a mostly open source toolchain with llvm and tvm.apache.org, though in the end the code still nedes to be linked with a few proprietary libraries from the hexagon sdk

19:38 <amstan> you cannot run baremetal on most of those, at least it was not the case when i was looking into this for the sensor hub

19:42 <leezu> Yes, but the same applies to Android? There should be some OS on the DSP and Linux userspace can interact with it over IPC to load/invoke DSP libraries. They may need to be signed for aDSP, but unsigned should work with cDSP

19:44 <leezu> According to the https://research.checkpoint.com/2021/pwn2own-qualcomm-dsp/ article, I was expecting /dev/adsprpc-smd /dev/cdsprpc-smd devices for the aDSP / cDSP driver, but they are missing. aDSP and cDSP are declared in the sc7180 dts though https://github.com/torvalds/linux/commit/f5ab220d162c20c105e7e38852fffe5767679bec

19:46 <leezu> For the modem DSP, also declared in above commit, I can see it get's initialized: "remoteproc remoteproc0: Booting fw image qcom/sc7180-trogdor/modem-nolte/mba.mbn, size 283296"

19:47 <leezu> ("qcom-q6v5-mss 4080000.remoteproc: MBA booted without debug policy, loading mpss")

19:55 <konradybcio> that article describes a downstream stack using a 4.14 bsp kernel

20:26 <clover[m]> someone making a chromiumOS spin for the x13s? :P

20:28 <clover[m]> steev: i have some time this afternoon to test daniel's mutter patch if you want to update a branch with the kernel patch reverted

20:29 <steev> lenovo-x13s-linux-6.3.y-ironrobin

20:29 <clover[m]> kewl

21:08 <leezu> I think the problem for sc7180 is that qcom,fastrpc isn't declared in the dts for the adsp and cdsp. The FastRPC driver implements the IPC mechanism for the DSPs

21:11 <leezu> That's in contrast to the sc8280xp.dtsi, which correctly declares fastrpc. Anyone with a X13s may be able to confirm if they see the /dev/adsprpc-smd /dev/cdsprpc-smd devices, assuming remoteproc kernel configs are enabled (CONFIG_REMOTEPROC=y CONFIG_REMOTEPROC_CDEV=y CONFIG_QCOM_PIL_INFO=y CONFIG_QCOM_RPROC_COMMON=y CONFIG_QCOM_Q6V5_COMMON=y CONFIG_QCOM_Q6V5_ADSP=y

21:11 <leezu> CONFIG_QCOM_Q6V5_MSS=y CONFIG_QCOM_Q6V5_PAS=y CONFIG_QCOM_Q6V5_WCSS=y CONFIG_QCOM_SYSMON=y CONFIG_QCOM_WCNSS_PIL=y)

21:15 <ajhalaney[m]> personally steev I'd leave the kernel hack instead of hoping people move the patching to mutter... but that's my two cents :)

21:30 <steev> squeeky wheel gets the grease, or some such

21:30 <steev> i thought you fedora peeps were all "upstream first!" types :P

21:53 <clover[m]> mutter 44.1 with danielt's patch works

21:54 <HdkR> Aw, there was a recent folio change but it doesn't solve the 5gbit unhandled context fault problem

21:58 <HdkR> well, changes the backtrace at least

22:01 <HdkR> https://gist.github.com/Sonicadvance1/bd63f2da11dfd38cf6a08774cb26355b

22:01 <HdkR> What a nightmare

22:14 <clover[m]> this mutter patch works better than the kernel patch. if i remove cable while in clamshell mode the internal screen actually recovers now

22:15 <clover[m]> added https://github.com/ironrobin/x13s-alarm/tree/trunk/mutter

22:18 <steev> thanks... i'll keep it around as well... currently there's a broken unit test with some ubuntu patch so waiting on that for 44.1 in debian

22:18 <steev> though, a few of the wayland tests are also flakey on arm64

22:19 <HdkR> On arm64 or on X13s?

22:19 <steev> https://paste.debian.net/1280529/

22:19 <steev> arm64

22:19 <steev> they don't use the actual x13s stuff to run

22:20 <HdkR> I'm mostly thinking about the GPU instability

22:20 <steev> the event-delivery one is the test that's holdup

22:20 <steev> the gpu itself isn't tested, afaik

22:20 <steev> but who knows; i'm currently building it on the rock-5b, though it takes 18 minutes there, versus 8 on the x13s

22:21 <HdkR> ah cool

22:22 <steev> clover[m]: out of curiosity, does it run the tests there or only if you specify for it to?

22:23 <clover[m]> I commented out a testing part that blew up on my x13s and M1 pro https://github.com/ironrobin/x13s-alarm/blob/trunk/mutter/PKGBUILD#L101p

22:25 <clover[m]> I noticed manjaro arm devs did that so i guess its an arm64 issue

22:31 <steev> i've only had it "not fail" once in my builds - wherein it only failed on the same test that fails on amd64

22:41 <qzed> I finally got around to try out the proper usb-multi-port patchset

22:41 <qzed> worked on the first try, yay

22:41 <qzed> so I can finally drop my hacked-together monstrosity

22:53 <HdkR> Went through the process of updating my desktop to a newer kernel just to see if this was a new kernel bug with this ethernet adapter. Seems fine there

22:56 <HdkR> Got a device with an out of tree driver, so it's always exciting trying to get that working again

23:06 <steev> qzed: oh nice... that reminds me... vkoul how is sc8180x looking? :D

23:28 <steev> what the f

23:28 <steev> and now it succeeded

23:55 <qzed> any ideas why I get no display on 6.4-rc2 (sc8180x)?

23:55 <qzed> instead I get

23:55 <qzed> [drm:dp_aux_isr [msm]] ERROR Unexpected DP AUX IRQ 0x01000000 when not busy