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
<owokitty[m]>
<kuruczgy[m]> "_mike: if you want the best perf..." <- does it work for vulkan software within the guest?
<owokitty[m]>
i tried to use venus with qemu and the vulkan support of crosvm many times in 2022 and 2023 but they never worked for me, only opengl works for me, so all my QEMU full system guests are configured for opengl only.
<owokitty[m]>
if that can fully enable vulkan inside QEMU full system guests, that would be very helpful and very powerful.
icecream95 has joined #aarch64-laptops
<icecream95>
_mike: If you are still using qemu-user, you should be able to use Freedreno directly if you recompile Mesa in the chroot with it enabled
<HdkR>
Sounds like the amd side might actually land soon, which would be awesome
<owokitty[m]>
wow.. wow.. amazing, just incredible. i never heard of such a thing for AMD GPU before in my life.. the real RADV and Radeonsi drivers BOTH inside the GUEST connected to the HOST amdgpu kernel space module.. that is incredible. they already made it before I even knew it was theoretically possible.
<abby>
owokitty[m]: please try to refrain from editing messages, it resends the message on irc. this is what we saw: https://0x0.st/8swl.txt
<HdkR>
There's also some work for a virtio OpenCL passthrough, which feels a little weird considering rusticl is becoming quite good.
<owokitty[m]>
<HdkR> "But yea, virgl and venus require..." <- the presentation gives the impression that this is a "3rd way" that continues to use virglrenderer on the host like virgl and venus do, but on the guest side does not actually use virgl or venus, instead replacing them, does that sound right?
<owokitty[m]>
I have been using virgl for opengl for a long time and that traditional way is definitely something quite different from this PR.
<owokitty[m]>
abby: ok i am sorry i had absolutely no idea that it does that. I assumed editing messages in matrix did nothing on IRC since IRC does not support native message editing.
<abby>
yeah the bridge renders most matrix features in awful ways
<abby>
replies, multiline messages, images are also not rendered great
<HdkR>
owokitty[m]: It still uses virgl for the final framebuffer passthrough I believe, but all the GPU work actually gets pushed through the virtio context. So low overhead for most of the GPU work.
tobhe has joined #aarch64-laptops
tobhe_ has quit [Ping timeout: 480 seconds]
<owokitty[m]>
it looks like if I want to try out this technology on AMD GPU hardware, I can construct a guest VM made out of the QEMU fork, kernel fork, libdrm git master and virglrenderer git master helpfully explained by trigger huang here https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658#note_2563331 , then I compile that mesa PR with build settings that "pretend" there's an AMD GPU present but additionally adding
<owokitty[m]>
-Damdgpu-virtio=true (i.e. into the guest's mesa source package) and install it in the guest, and vulkan and opengl should both start working simultaneously! thank you very much for telling me about this, if this works for me better than Venus does, it will tremendously help with a lot of things I do.
nothorseface has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
<_mike>
call me an idiot but doesn;'t uefi arm machines have a built in dt?
<_mike>
or could i use something like a chomeos device tree hardware prober to snap up the dtb?
<_mike>
iono back when i did porting with freebsd and zrouter.org there were no such things as dtb's afaik
nothorseface has quit []
nothorseface has joined #aarch64-laptops
nothorseface has quit [Ping timeout: 480 seconds]
nothorseface has joined #aarch64-laptops
SpieringsAE has joined #aarch64-laptops
<SpieringsAE>
_mike: AFAIK there are/is indeed dtb(s) in the firmware, I believe a couple of people did extract them from firmware update blobs, but they were incomplete (?)
<SpieringsAE>
I guess only enought to take care of what the firmware needs to take care of
SpieringsAE has quit [Remote host closed the connection]
<JensGlathe[m]>
yes, someone mentioned that these are used by EDK2. They give some insight in the things available, though. And there are some nodes for Gunyah, too. There are x1e/x1p64 (Hamoa) and x1p42 (Purwa) versions in the firmware. Gives you an idea which sensors are missing in Purwa.
<macc24>
they are good enough to boot from and not much more
nothorseface has quit []
nothorseface has joined #aarch64-laptops
nothorseface has quit []
nothorseface has joined #aarch64-laptops
nothorseface has quit []
icecream95 has quit [Quit: rcirc on GNU Emacs 29.1]
nothorseface has joined #aarch64-laptops
laine_ has quit [Read error: Connection reset by peer]
laine has joined #aarch64-laptops
nothorseface_ has joined #aarch64-laptops
nothorseface has quit [Remote host closed the connection]
srinik has joined #aarch64-laptops
<Jasper[m]>
@amstan @steev
nothorseface_ has quit [Ping timeout: 480 seconds]
nothorseface has joined #aarch64-laptops
srinik has quit [Ping timeout: 480 seconds]
lollarsheher[m] has left #aarch64-laptops [#aarch64-laptops]
<Jasper[m]>
@amstan @steev wakey wakey
nothorseface has quit []
srinik has joined #aarch64-laptops
nothorseface has joined #aarch64-laptops
nothorseface has quit []
<macc24>
i don't think i see the "random wakeup" issues on my slim7x
<macc24>
i left it suspended for 22-ish hours and it didn't wake up for no reason
srinik has quit [Ping timeout: 480 seconds]
hogliux has joined #aarch64-laptops
<hogliux>
macc24: with the lid switch working my slim 7x still randomly wakes up but then immediate goes back to sleep as the lid is still closed. Maybe you are seeing the same?
<hogliux>
macc24: but haven't tested this with the newest Lenovo firmware version so maybe this is fixed already
hogliux has quit [Remote host closed the connection]
<konradybcio>
pretty sure there's some infra in debugfs to check the wakeup reason
<konradybcio>
maybe you can add a systemd wakeup trigger of sorts
<konradybcio>
that would log it to a file
srinik has joined #aarch64-laptops
<steev>
Jasper[m]: hm? (also that was like 4-5am my time)
<ppd[m]>
steev: if you're on matrix there was someone that was shilling some telegram scam channel
<ppd[m]>
scroll through the history
<ppd[m]>
lemme check if they're in the irc logs
<steev>
i don't see it
<steev>
in irc
<steev>
i'm not on matrix
<ppd[m]>
fair enough
<ppd[m]>
but yeah dude went in and said "ooh look at me free money"
<abby>
oftc's moderation is probably better than matrix's, so they got banned irc-side i bet
<ppd[m]>
¯\_(ツ)_/¯
srinik has quit [Ping timeout: 480 seconds]
sally has quit [Remote host closed the connection]