00:20penguin42: karolherbst: umr is very pretty, not yet figured out what to look for, but it is indeed very neat
00:33kode54: https://f.losno.co/v/mouse.mp4 interesting bug
01:11mareko: doing single-threaded memcpy on the GPU?
11:43mesa-user: Hi, have an issue with mesa. I get the issues in some releases and others are fine. Looks like horizontal lines cut into smaller segments. What is a search term, so i can fix it (if it caused by a setting)?
11:55penguin42: mesa-user: First try and cut it down; is it specific to a particular GPU or not?
11:59mesa-user: penguin42: It is an integrated lshw -> product: Polaris 22 XL [Radeon RX Vega M GL]
12:00penguin42: mesa-user: OK good, so Radeon - now does it only happen on one program or is it general?
12:02mesa-user: penguin42: Starts with sddm for the login - i need to switch version (sometimes a suspend helps)
12:05penguin42: blech interactions with suspend; I'm not sure where to point you
12:05penguin42: mesa-user: What kernel?
12:07jkqxz_: "Looks like horizontal lines cut into smaller segments" -> segments which are always the same length in the same place, maybe 64 bytes long?
12:08jkqxz_: Are some of the segements right and others wrong? It sounds like something to do with cache invalidation or flushing - a picture of the effect would help.
12:10mesa-user: penguin42: at the moment 6.5, but i had the problems for years (some releases) and with no screen usable and nothing in dmesg i never was eager to fix it, because i had no working UI. With 6.5 it is broken and i wanted to switch to a older release, but it was broken, so i run of CPU (i guess) and changed the package . This results only newly started programs are affected and i made a screenshot.
12:25mesa-user: penguin42: https://i.postimg.cc/GpQgQZff/img.jpg sry took a moment to crop, most tools too crop look like this
12:28mesa-user: jkqxz_: maybe the screenshot helps. It is clearly the content from the program or in sddm the background and i see the mouse move in sddm, but it effects the lines/segments.
12:40HdkR: `intel: Limit Intel Vulkan RT to x86_64` ARM64 users over here crying
13:07jkqxz_: mesa-user: That looks like a tiling problem. Given that it's the weird Intel-AMD hybrid chip, I would guess the problem is that it's rendering on one and then trying to display on the other, except they don't understand each other's tiling formats.
14:35mesa-user: jkqxz_: any way to provide more useful information and figure out the cause. Most of the time it runs without an issue, but some updates break it.
15:36penguin42: mesa-user: Do you think it's really 'some updates break it' or 'it works on some boots' ?
15:37mesa-user: penguin42: updates - i can reboot for week with one version and next one fails every reboot
15:41mesa-user: to clarify - i don't pin it on a release, i can pin the behavior on a build
15:44penguin42: mesa-user: I guess then you probably need to find the nearest good and bad build; if it's actually mesa then you could try building a local build and running with that and bisect with git to find some commit to blame
16:11mesa-user: penguin42: i have trouble to get a working build myself (it always contains the tiling issue). A older Package from the repo worked. I think i will leave the issue. The notebook is EOL very soon
16:35alyssa: InvalidBitWidth: Invalid bit width in input: 128
16:35alyssa: uh
16:37alyssa: oh clang was being stupid
16:37alyssa: it did not like 0xffffffffffffffffULL
16:51alyssa: well good news, agx_unpack works O:)
16:51karolherbst: \o/
17:04alyssa: and i think once i wire up load/store vectorization the codegen will be decent too
17:04alyssa: currently it is, loading one byte at a time (-:
17:12karolherbst: oof
17:12karolherbst: there are so funky bugs CL hits... I had something initializing a [100000] array to 0
17:12karolherbst: nir unrolls that memcpy entirely :)
17:13karolherbst: so 10 loc kernel OOMs your system
17:13karolherbst: the fix: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24764
17:14karolherbst: alyssa: how much function calling stuff does asahi support btw?
17:14karolherbst: or rather.. on what level
17:14karolherbst: uhm.. apple silicon rather
17:15karolherbst: just jumps or also some kinda hidden stack?
17:15alyssa: unclear
17:15alyssa: there might be a call stack. at minimum I thik there's a hw-defined link register
17:15karolherbst: guess registers needs to be saved manually anyway
17:16alyssa: yeah, it's something I eventually want to look at in terms of the RA side
17:16karolherbst: I was at some point wondering if we want to do all this stuff inside nir, so backends only have to deal with functions calls, no register saving
17:16alyssa: that .. doesn't really super work
17:16alyssa: I mean, if you're fine with that, nir_lower_shader_calls will do it
17:16karolherbst: and the nir will use scratch memory to save values
17:16alyssa: but it isn't.. "right"
17:16karolherbst: mhhh
17:17alyssa: ideally you do something like llvm's IPRA
17:17alyssa: definitely cant happen earlier than backend RA
17:17karolherbst: yeah, fair
17:18karolherbst: it's just painful, because I kinda have to require that for proper CL support and convincing every backend compiler to properly support function call is kinda a challange
17:18karolherbst: so I'm wondering if there is a less perfect path forward until a backend properly supports it
17:20karolherbst: but it will be terrible, because the only sane way of doing is to save all the values before a function call and it will give terrible performance
17:21alyssa: graph colouring RAs dont deserve CL
17:21karolherbst: yes.. I've noticed :D
17:22karolherbst: some benchmarks take like hours to compile
17:22karolherbst: and it's mostly RA
17:28karolherbst: mhh anyway.. I think the rpi4 is next...
17:37karolherbst: zmike: btw, mind doing another round of review on the rusticl/zink MR? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24839
17:37karolherbst: even with that I probably won't enable it as I want to figure out what to do with the loading side, but we could at least merge all of the enablement stuff
17:37karolherbst: "rusticl/kernel: lower vec8/16 to vec4" needs to be moved to zink as well, but we probably want to do that later as well
17:57pac85: I have a patch that introduces a driconf to fix a misbehaving game. Should it have a backport tag? If so, since there is no particular commit that it fixes, would it be `Cc: mesa-stable`?
17:57pac85: The patch in question https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24818
18:27mareko: at least I now have a video to forward to our ROCm folks
18:50pendingchaos: pac85: if it fixes a game for stable releases and is small enough, why wouldn't it be backported?
18:50pendingchaos: "Cc: mesa-stable" is the tag to backport to all current stable branches (23.1 and 23.2)
19:13mareko: zmike: the pass you're working on that converts lowered IO to derefs would be useful to have in the NIR core
19:13mareko: i.e. lower IO for all drivers -> optimize -> unlower IO for drivers that need derefs
19:21alyssa: karolherbst: CI is dead today, continuing to reassign marge is fruitless :(
19:21alyssa: all the whiskeylakes are dead and also the llvmpipe traces are dead (-:
19:21karolherbst: the last pipeline only had one failed job :')
19:21alyssa: consider not merging code, it works great for me
19:22karolherbst: :D
19:22karolherbst: fair enough
19:22alyssa: if your MR targetted asahi/mesa it would've been merged yesterday! :-)
19:22karolherbst: :D
19:23karolherbst: but but...
19:23alyssa: alternatively push patches to disable the broken jobs
19:24alyssa: but that's only gotten me in trouble so downstream it is! :)
19:29karolherbst: I'm going to make that tomorrows me problem
19:30pac85: pendingchaos: yes it's pretty small and the game has been broken since 6139493a. I guess I could have a fixes tag on that commit since there would be no point in backporting it any further (even though there is nothing wrong with that commit by itself, it just triggers bad behavior in the game)
19:32pac85: Uh CI is broken currently? I guess I'll try again tomorrow for this patch then. I came back to it seeing a commit by alyssa disabling a CI job that made my merge fail the first time
19:32alyssa: pac85: CI is usually broken
19:32alyssa: but it's especially broken today
19:32alyssa: see for yourself https://gitlab.freedesktop.org/mesa/mesa/-/issues/9737
19:35pac85: alyssa: uhm that 90% rate of failed merge pipelines tells me there is no point in reassigning marge
19:36alyssa: pretty much
19:36alyssa: welcome to mesa
19:41pac85: alyssa: thank you, btw I'm not exactly new, you might have seen me around as "antonino". On that note I wonder if you got to do anything with that passthrough gs shader in the end
19:41alyssa: I've paged out GS, working on other stuff right now
19:43pac85: Good I guess. Btw that thing took me forever to get "right". It was there before I did anything with it but was used in rare cases so pretty much untested. When I did my first MR on zink I had to enable it in more cases and as soon as I did all hell broke lose
19:50alyssa: yep
20:23DavidHeidelberg[m]: CI isn't that much broken, currently the underlying infra is KO. Before migration everything worked (reasonably) well. Easiest way to usually differentiate is seeing mesa build job flakes, because that's not usually caused by real compilation errors, but unstable infra.
20:52DemiMarie: Will the kernel driver tests help with the security of the kernel?
20:57pac85: DemiMarie: graphics kernel drivers? Are they tested directly?
21:23LaserEyess: is there a process for getting a mesa commit into a stable branch? In particular: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24836, as this fixes some pretty frequent hangs on rdna2/3 cards
21:24pendingchaos: creating a MR targeting the staging branch (optionally with the release maintainer assigned)
21:24pendingchaos: https://docs.mesa3d.org/submittingpatches.html#sending-backports-for-the-stable-branch
21:26LaserEyess: thanks