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> Obviously the best improvement of a7xx is that it can run Aperture Desk Job and X4: Foundations :P
<robclark> it has some nice incremental improvement.. and it seems some (native, not emulated) raytracing support.. ofc it has the annoyance of being similar enough to a6xx that it makes sense to share code with a6xx in tu and gallium, so we are working on sorting out how that can work
<robclark> (similar in terms of how the cmdstream is constructed)
<HdkR> :D
<HdkR> I look forward to the inevitable a7xx device when I get it. Seems like Danylo and you will have it sorted before I even get to it
<HdkR> a780 class hopefully :P
<robclark> danylo has been doing most of the a7xx specifics.. and has some compute shaders running with computerator running.. for more 3d things there will be some more some more changes to deal with concurrent-binning and such.. but I think we are getting close to having the groundwork in place
<robclark> an 8 core version of a7xx (successor to a690) will be fun
<robclark> a690 is already kinda a beast compared to other a6xx things
<robclark> nice thing about GPUs is they scale up well
<HdkR> Yea, a690 is quite nice compared to lower end parts. It's a bit sad when compared against a740 though
<HdkR> Heck of a perf uplift
<robclark> a660 is 3x sp cores compared to a690 8x sp cores.. similar upscale for 7xx should be fun
<HdkR> I was already suprised seeing a bunch of GPU bottlenecks going away with a660 -> a690. Getting the same surprise again will be great for something like God Of War will be awesome
<robclark> I think going a660 to a690 at least doubled the # of ddr interfaces.. which I expect would also hold for future things... moar bw is a thing gpu's like
<HdkR> Yea, double bus width size between those two
<HdkR> and since 8CX G3 is still on LPDDR4X, we're going to get quite a big jump with the next compute chip going to LPDDR5
<robclark> qcom seems to know how to keep things balanced.. you don't see a lot of silly things like pointlessly doubling up gpu without corresponding memory bw increase
<HdkR> Theoretically it'll have at least 100GB/s, which will be nice
<robclark> indeed
<HdkR> It might actually be able to replace my Macbook before Apple comes out with the M4
<robclark> I guess it comes down to how apple's hickup on the mobile side bubbles up into their "compute" side vs how long arm ltd manages to delay future custom cores
<HdkR> If ARM ltd made competitive high-end cores then it would likely matter less :P
<HdkR> And if Apple is the first to market with a CPU that supports 256-bit wide SVE2 then it's obvious which hardware I'm going to buy
<robclark> arm ltd makes good cores for a purpose (ie. optimizing cost/power/perf).. but it would be nice to see more than just apple exploring other areas of the cost/power/perf space
<HdkR> yea
<quinine> anyone tried adding venus node to sc8280xp? i looked at it a little bit, but i have no experience in this area, so i don't know how to start.
<HdkR> quinine: Maybe flailing at the ACPI dumps and hoping for the best? I'm not a kernel dev so I also don't know wtf I'm doing there :)
<quinine> HdkR: i read a little bit, but i couldn't read acpidump 🤣
<HdkR> Sounds like my experience. It's a bit of reading tea leaves and hoping something matches
<quinine> I'm thinking if qcom provides complete dts for community, we'll dev much faster than asahi
<HdkR> Day 0 upstream support for SoCs would be nice
<robclark> all of the qc chromebooks have been.. so it's possible ;-)
<HdkR> robclark: How soon until an SM8550 Chromebook though? :P
<HdkR> steev: Confirmed that the M.2 ethernet device you found with A+E key doesn't fit. I have a B+M key one that should arrive tomorrow for testing.
<steev> that sucks, but not unexpected
<steev> there's already an acpidump fwiw quin
<HdkR> yea, definitely expected that one since I'm /pretty/ sure it's B key
<robclark> HdkR: I don't think a chromephone is on the roadmap ;-)
<HdkR> robclark: hehe, future SC8380 then rather than SC7380 :D
<HdkR> Need a new Pixelbook
<robclark> not the sort of thing I could talk or speculate about
<HdkR> Of course
<HdkR> I already know the result is "Chromebook doesn't need that power and cost" It's cool
<HdkR> It's a shame that Pixelbook set that precedent
<robclark> lot of cool heroics go into the cheap and cheerful end of the spectrum (looking fwd to arcvm on these things).. you just need to get more steam running on arm so there is more reason for bigger things to exist :-P
<HdkR> Gimme that venus support :P
<robclark> oh, you'll have native tu soon
<HdkR> zram and VM swap space as well right? :)
<robclark> swap in host.. not sure it is useful in guest b/c host has better picture of what is going on (at least that seems to be the direction that both arcvm and borealis are going)
<HdkR> As long as the guest can get more than 8GB of RAM visible to it at least
<robclark> but on host side, defn zram swap.. it is the way to go
<HdkR> 11GB is tight for any game beyond indie
<robclark> yeah, arcvm is gated on 64b host (which is already on stable channel for trogdor)
<robclark> probably for serious games you want devices with more than 8GB phys... but there needs to be a market for that first... if you build it, they will come ;-)
<HdkR> I can totally show off the meme game of Crysis on Snapdragon once Vulkan and more memory is live
<robclark> x13s should have enough ram?
<HdkR> Oh yea, I can totally show Crysis running on it
<HdkR> But it's not ChromeOS :P
<robclark> sure, but at this point if it runs on linux w/out vm.. on same hw w/ CrOS it will run in vm..
<HdkR> Let's run some crysis
<HdkR> Takes a while to sync when the ethernet peaks out at 41MB/s
<quinine> <steev> ""; <- this looks very useful. but I grep it and it seems that there is no venus keyword at all in dsdt of x13s. 🤔
<HdkR> Sadly it'll be called something /significantly/ less intuitive in ACPI
<quinine> sad
<steev> yeah, i can't remember what it's called either
<steev> i know qcdx8280.inf_arm64_a0cfad4751f88353 is the firmware folder in windows
<steev> you can also always go look at the device under windows
<steev> in device manager to figure out its acpi name
<quinine> Unfortunately, I did not keep windows partition
<steev> well, i haven't :)
<steev> "lenovo system hardware update" dated 3/3/2023
<quinine> I should keep a windows for update bios 😂
<steev> bios update *should* be doable with fwupd, and the exe files on lenovo's site *are* just done with inno, so innoextract works on them
<quinine> i have not tried it yet
<steev> i haven't either, that's why i said should
<HdkR> robclark: Dang, I don't even know how to get Crysis running outside of Emulation even. It's just crashing on my desktop
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Ping timeout: 480 seconds]
<steev> actually... idk wtf they call it
<steev> assuming windows system information is correct
<steev> it should be ACPI\VEN_QCOM&DEV_0636&SUBSYS_QRD08280&REV1823
<steev> so 0636?
<steev> which is weird because that's part of the gpu?
<HdkR> Windows does heck it up and tie video to the GPU just like a lot of the desktop parts
<HdkR> So not too unexpected
<HdkR> Encode+Decode shows up under the "GPU" tab of task manager
<steev> yeah but i'm not seeing the... stuff? in the dsl
<steev> the clocks and whatnot
<HdkR> Entirely described in PEP to make everyone's lives pain? :P
<steev> that would be easier at least :(
<steev> they'd show up in strings like the bluetooth one did
<steev> looks like new qcslpi firmware
<HdkR> Got a Youtube video uploading/processing, will be done in 40 minutes
<HdkR> Video still processing, only SD atm
<steev> not the easiest to read, and i don't think most of it even matters
<steev> wow
<HdkR> X13s is a beast
<anarchron> Incredible
laine_ has quit [Ping timeout: 480 seconds]
irctian12 has joined #aarch64-laptops
irctian1 has quit [Ping timeout: 480 seconds]
matthias_bgg has quit [Ping timeout: 480 seconds]
matthias_bgg has joined #aarch64-laptops
<abelvesa> jhovold, bamse: this is the MHI failure I see when the wlan doesn't work every now and then on boot-up:
<abelvesa> mhi mhi1: MHI did not load AMSS, ret:-5
<abelvesa> mhi mhi1: Device failed to clear MHI Reset
<abelvesa> mhi mhi1: Error moving from PM state: Firmware Download Error to: DISABLE
Evaia6310 has quit [Quit: Hack the Gibson]
<abelvesa> actually, it is because of this:
Evaia63101 has joined #aarch64-laptops
Evaia63101 has quit [Quit: Hack the Gibson]
Evaia63101 has joined #aarch64-laptops
<jhovold> abelvesa: no, that gdsc warning should be benign and unrelated
<abelvesa> jhovold: yeah, I figured that out already
<abelvesa> jhovold: thanks
<robclark> HdkR: nice, need to get some perfetto instrumentation in fexemu to see what is going on with those couple stutters but otherwise looks smooth
<robclark> mind if I re-paste in #freedreno?
<HdkR> robclark: Go for it
<HdkR> We have gpuvis instrumentation
<robclark> hmm, can that slurp in turnip's perfetto perfcntrs and renderstages and such?
<robclark> (although seeing aarch64 syscalls in a x86 app might melt perfetto's mind)
<HdkR> I'm not actually sure
<HdkR> Every time I tried perfetto I never got much out of it
<robclark> would be nice to see what is going on with the janks.. but otherwise framerate looks pretty good
<HdkR> probably translation taking a bit too long
<robclark> I guess stuff gets cached so smoother with time?
<HdkR> cached in memory, nothing on disk yet
<robclark> ahh, ok
<HdkR> We need to solve disk caching, it's one of the major perf wins once it gets implemented
<robclark> yeah, indeed
<robclark> heh, I think it looks smoother the second time I watch it.. so maybe some of the janks are my internet connection :-P
<HdkR> :D
<robclark> need more views on youtube, to trigger youtube to re-encode with lower bitrate and higher quality (and distribute out to storage closer to me) ;-)
hightower2 has quit [Remote host closed the connection]