00:13 <logan2611> GPU doesn't work on -next still, but it looks like now it tries to deference a null pointer for some reason https://0x0.st/KFDe.txt

00:19 <icecream95> robclark: I probably should have better explained the bug... the Valgrind report ( https://0x0.st/KUQt.txt ) should make it more clear.

00:19 <icecream95> st_pbo_draw uploads a vertex buffer, then sets constants, then draws using both, but if consts go to a new resource then pipe_upload_constant_buffer0 deletes the resource for the vertex buffer

00:20 <icecream95> Looks like crocus might have a different bug, which may be hard to find without using Valgrind or ASan

00:21 <robclark> try nerfing vbuf, I think that fixes the issue.. I'm a bit suspicious of u_vbuf_set_driver_vertex_buffers() but still digging thru how this is _supposed_ to work post zmike-mr

00:22 <robclark> I know there is some interaction btwn const uploads and streaming uploads.. but don't think that is the root issue

00:25 <icecream95> st_pbo.c uploads the vertex buffer, then calls cso_set_vertex_buffers, which I guess no longer takes a reference to the resource, so the only reference is in the uploader.

00:26 <icecream95> If the uploader is used again before the draw_arrays, then the uploader can release the reference

00:27 <icecream95> I guess that without vbuf, setting vertex buffers goes into the driver and takes a reference there?

00:38 <icecream95> robclark: Oh, and perhaps you can suggest that people debugging run with GALLIUM_THREAD=0, since otherwise threaded_context obscures the stack trace

01:06 <McCak[m]> SpieringsAE: i think it does, but i decided to compile it on my home server under podman ubuntu 25:10, still doesnt work tho as its complain about libssl-dev despite its already installed, weird issue but probably because i was using bindeb-pkg

01:06 <McCak[m]> i am thinking to setup ubuntu vm or just use my oci

01:16 <icecream95> robclark: I think I'm agreeing with you that it isn't the root issue... a bunch of drivers use the uploaders internally, and I think that's why the change doesn't fix crocus

01:17 <robclark> icecream95: rollover of uploader mid-draw seems like a critical thing missed in zmike's changes.. I think maybe tomorrow I'll try undoing the u_uploader part of that commit, since clearly u_uploader needs to hold a ref

01:18 <robclark> yeah, internal driver use is why I was skeptical of splitting uploaders as a "fix"

01:30 <icecream95> robclark: Perhaps the fix is just to use u_upload_alloc_ref for the vertex buffer in st_pbo_draw? (And then set releasebuf to vbo.buffer.resource)

01:30 <icecream95> Then instead of keeping the previous upload buffer alive, we keep the current one alive until the draw, which sounds like a better idea :)

01:35 <icecream95> But I am still confused about exactly what the responsibilities are... perhaps it's actually the const buffer upload's fault for unreferencing the buffer?

01:44 <robclark> I'd kinda prefer that u_upload owns the ref.. when zmike gets back, if he wants to change that it should be accompanied by better docs+debugging ;-)

01:45 <robclark> rather than crossing fingers and hope that u_upload doesn't roll over mid-draw

02:21 <icecream95> robclark: Looks like Gallium HUD is broken as well, and so is primconvert, and perhaps the blitter, and user indices, and vbuf, and... so undoing changes for now is probably a good idea

02:24 <robclark> yeah.. I kinda wish there was less stuff stacked on top of that MR, right now reverting is kinda messy.. this kinda sucks

02:25 <icecream95> Perhaps u_upload_mgr could keep an array of buffers, and then they all get unreferenced at once at safepoints

02:27 <robclark> I mean, it is all bodging around a fundamentally unsafe change.. the obv right thing to do is revert.. it is just that is messy

02:27 <robclark> but a bit under the weather today.. will take another look after a nights sleep

07:30 <steev> robclark: re: (python3:7668): Gdk-WARNING **: 01:25:28.116: Vulkan: ../src/freedreno/vulkan/tu_descriptor_set.cc:651: VK_ERROR_OUT_OF_POOL_MEMORY

07:30 <steev> - it occurs with Showtime (the default media player) on the T14s as well, is there any way we could make it less spammy though? i played maybe 15 seconds of the video and have 164K text file from the playback

07:31 <steev> https://p.defau.lt/?ykdQ369rpAdSmeVN2y5AiA

07:32 <steev> sorry, 20 seconds, not 15

07:33 <steev> sorry, i meant showtime is gnome's default media player, not ubuntu's

08:36 <Jadesheher[m]> <clover[m]> "Jade (she/her): can you do cat..." <- sure!

08:37 <Jadesheher[m]> qcom,sc8280xp-sndcard

08:38 <Jadesheher[m]> while my speaker is working it still sounds quite weird.

08:38 <Jadesheher[m]> like someone is just blowing in the microphone while speaking

08:38 <Jadesheher[m]> and my sway startup sound straightup doesnt work

08:41 <Jadesheher[m]> and running it manually has it distorted

08:42 <valpackett> the upstream UCM confs *still* have some very bad lines that break everything, see https://github.com/alsa-project/alsa-ucm-conf/issues/595

08:46 <icecream95> steev: Looks like allocating too small pools is deliberate, see https://gitlab.gnome.org/GNOME/gtk/-/commit/9e27acb0a6d62410f451570c151fe8e669698139

08:46 <icecream95> So everything is happening "as it should", just gtk isn't filtering the messages. I think you should report this as a gtk bug

08:47 <icecream95> GSK_RENDERER=gl should be a workaround

08:50 <Jadesheher[m]> I will try postmarketos for now

08:50 <icecream95> No wait... perhaps it is turnip's fault after all, see https://gitlab.freedesktop.org/mesa/mesa/-/commit/aa94220d7d952a67545ab73c9e6909f311fb4ddc

08:51 <Jadesheher[m]> im also having trouble with archlinuxarm itself

08:51 <Jadesheher[m]> the extra repo downloading at 8kbit/s is not really fun

08:59 <valpackett> oh i remember that.. i think even x86 arch had some horrific mirrors too

08:59 <Jadesheher[m]> i tried multiple ones from my region and none were fast enough

08:59 <Jadesheher[m]> gosh the USB speed is so slow postmarketos live cant cope with it

09:00 <valpackett> o.0 really? i have booted even ubuntu from usb2 sticks recentlyish

09:00 <Jadesheher[m]> i mean it booted

09:01 <Jadesheher[m]> just everything keeps crashing

09:02 <Jadesheher[m]> with my X13 (non s) I even sometimes run OS from external SSDs

09:02 <Jadesheher[m]> so the lenovo people dont see that I glue my SSD into the laptop

09:02 <valpackett> uh oh. i used pmos right from a usb stick on the x1e dell for initial bringup

09:02 <Jadesheher[m]> do I install the Postmarketos with a NVME USB Adapter or from this live install now?

09:03 <valpackett> and ubuntu concept on usb to recover from borking pmos on the ssd a couple times lol

09:03 <Jadesheher[m]> i have 2 ssds

09:03 <Jadesheher[m]> if pmos fails i will just use alarm

09:04 <valpackett> Jadesheher[m]: however you want.. with an nvme usb adapter you can even just `--sdcard` it from any linux anywhere! pmbootstrap is magic

09:04 <Jadesheher[m]> what does --sdcard do?

09:06 <valpackett> directly make a ready-to-use final install on a disk, just from a command line with pmbootstrap on any machine

09:06 <Jadesheher[m]> i think the current one is --disk

09:06 <Jadesheher[m]> im using that already

09:07 <SpieringsAE> jadesheher: I had a great alarm mirror on my opi5+ this weekend 80Mbyte/s

09:08 <SpieringsAE> its unfortunate that reflector doesn't seem to work with it, at least it didn't work when I tried it

09:43 <Jadesheher[m]> its somehow broken

09:43 <Jadesheher[m]> im now trying the postmarketos os-installer