00:00 KungFuJesus: hmm, so something broke for me between mesa 24.1.7 and 24.2.8 for ppc64 big endian. It appears I can't start X with the modesetting DDX anymore after that
00:01 KungFuJesus: I can bisect but is there something specific that might definitely be causing this?
00:01 KungFuJesus: (this with Nouveau)
00:01 KungFuJesus: (nv47)
00:02 KungFuJesus: X log shows my monitor with all proper display modes from EDID, but I get "AddScreen/ScreenInit failed for driver 0"
00:03 KungFuJesus: The nouveau one works but without GLX, it seems
00:13 KungFuJesus: Alright I'll try to get a tighter bisection here between versions
01:15 KungFuJesus: looks like X was able to start in 24.2.0 but with broken glx and everything after that x won't start
11:26 javierm: lumag: thanks for suggesting `dim b4-shazam`, it's pretty neat!
12:34 stsquad: does anyone have the ops required to kick spammers in this channel?
12:41 karolherbst: stsquad: the issue is, that that person just comes back with a new account and IP
12:41 karolherbst: it's all the same person
12:42 karolherbst: they write stuff for like 10 minutes, and move to a new account
12:43 karolherbst: we are not happy about the situation either, it's just that you also can't do much about a person like that on IRC
12:44 dolphin: I wonder if he's using the same email each time
13:00 phasta: Probably it's a bot (orchestrated by a human)
13:00 phasta: Maybe we could ask the OFTC folks for advice? We're hardly the first party which encounters this problem
13:01 emersion: it's not a bot, and OFTC folks are already aware
13:04 mupuf: oh yeah they are. He's been at it for over 15 years!
13:11 phasta: What happens if you ban him all the time very quickly? Does he then create a new account every 10 minutes?
13:11 soreau: they just come back eventually
13:12 phasta: But if the bla bla is always the same, we might be able to train a ban-bot on that input-data ^^
13:12 soreau: or just give more people ban hammers :P
13:13 phasta: Or that (though if we write a nice proposal with lots of "AI" in it we even might get funding by an applauding manager)
13:14 soreau: I doubt anyone wants to accidentally get banned by a bot here
13:15 soreau: and the problem in question is easily solvable: ignore
13:20 HdkR: Also more moderation
13:21 karolherbst: thing is.. can't really delete sent messages, so can't really do much. Like you'd be there the minute they write. But anyway, happy to give trusted people mod powers, and a lot of people already have in this channel
13:21 karolherbst: but then he might just move to another channel
13:22 karolherbst: but anyway, if people are volunteering, could get special powers granted to deal with it, just ping me or any other on the coc team
16:19 eric_engestrom: mesa devs: the 25.0 branchpoint will be 7 days from now, on January 15th
16:19 eric_engestrom: if this is an issue and you would like it to be pushed back, or want to request an exception for a feature to be backported during RCs, please message me (tagging me here or DM) as soon as you can :)
16:19 eric_engestrom: (sorry for not sending this message this sooner; I'm still on medical leave and I didn't think about the next branchpoint until just now)
16:26 alyssa: eric_engestrom: ..perhaps we want to push back the branchpoint so you can medical leave....?
16:27 eric_engestrom: it finishes on the 15th, so it should be fine :)
16:28 alyssa: okie
16:28 alyssa: rest well :)
16:29 eric_engestrom: (although I'm seeing the surgeon on the 15th and I'm told by the physiotherapist they expect the surgeon will extend it, but mesa-release-managing is not a lot of work at the beginning of a cycle as there are very few conflicts and divergences to deal with)
16:29 eric_engestrom: thanks!
16:32 eric_engestrom: the main issue is basically "just" that I'm constantly exhausted, between my body rebuilding itself and the daily physio workout where I push myself as far as I can to get my muscles back; being unable to walk without crutches for a few more weeks is not relevant to this job ^^
17:33 dcbaker: eric_engestrom: if you need help with anything please let me know
17:34 dcbaker: mareko: The top radeonsi commit on the staging/24.3 branch needed a tiny bit of massaging from me, does it look okay to you?
17:35 dcbaker: karolherbst: I've got two "rusticl/device: fix ..." commits nominated for 24.3, but they don't apply and It's not at all clear to me how to resolve them, would you rather backport them or have me drop them?
17:37 mareko: dcbaker: yes, thanks
17:37 dcbaker: cool, thanks for checking
17:43 dcbaker: jnoorman: I've got "ir3: always set wrmask for movmsk" nominated for 24.3, but the conflict looks non-trivial to me, would your prefer to backport it or have me drop the nomination?
17:43 dcbaker: bbrezillon: Same question for "panvk: Don't invalidate the viewport on cull mode update"
17:51 jnoorman: dcbaker: I think it's fine to drop it as it fixes a very old bug that (AFAIK) hasn't caused any issues until a recent (not yet merged) MR. So it can probably wait until 25.0.
18:01 dcbaker: jnoorman: Thanks, I'll drop it and we can always un-drop it if it turns out to be important
18:22 alyssa: dj-death: been thinking more about the printf info problem ... the "collecting across multiple shaders, adding in offsets, doing relocs, etc" thing seems pretty complicated
18:22 alyssa: and the cute "well i only have one shader" thing I'm doing now in hk will cease to work once i'm doing cl in common code
18:22 alyssa: but.. why do we even need indices at all?
18:23 alyssa: I'm thinking about, like, calculating a 32-bit hash of each format string and then using that as the "index"
18:23 alyssa: then having a VkDevice-wide hash table mapping 32-bit hashes to const char *s
18:24 alyssa: (containing all format strings across the device)
18:24 alyssa: what I like about this:
18:24 alyssa: * multiple nir shaders with independent printfs work
18:24 alyssa: * no reloc / sideband / etc needed
18:24 alyssa: * generated code is basically the same as what we have now
18:25 alyssa: what I don't like about this:
18:25 alyssa: * tiny but nonzero chance of collisions (probably fine for a debug feature though)
18:25 alyssa: * still need driver code to collect all strings across the device (but that will be the case unless we literally embed the format string in the shader binary itself. which... we could?)
18:26 alyssa: (..Honestly that last idea is tempting if this is for debug only but I digress.)
18:27 alyssa: hmm... what if we zlib compress format strings at compile-time and then embed that instead......
18:27 alyssa: ("go home alyssa you're asleep")
18:28 zmike: what if the same perf but also faster
18:29 alyssa: explain
18:29 zmike: no
18:30 pac85: Are you trying to save bandwidth over just sending chars?
18:31 Ristovski: all I read was "faster" and I am convinced
18:31 Ristovski: unlike all of you non-believers, apparently
18:52 alyssa: pac85: effectively
18:52 alyssa: i am.. wondering to what extent that's actually necessary
18:52 alyssa: maybe for app opencl it makes sense since printf() is a thing we expose to apps
18:53 alyssa: but for driver cl, the expectation is that printfs are for debugging and are stripped out in release builds
18:53 alyssa: so maybe this is all silly and we should just do the simplest thing that works
18:54 alyssa: ...Honestly I don't hate it...
18:54 pac85: Given a human has to parse it I would have assumed you don't really need to handle GB/s of chars since humans can't parse something like that lol
18:54 alyssa: pac85: the problem is more bloating binaries and so on
18:54 pac85: Aaah I see
18:54 alyssa: every assert() is a printf
18:54 pac85: Right makes sense
18:55 pac85: Do you have a public branch with an implementation?
18:55 alyssa: Of what
18:55 pac85: Printf
18:55 alyssa: It's upstream
18:55 pac85: Ah cool
18:56 alyssa: honestly I'm inclined to add a knob for dumping the whole fmt string (possibly compressed) and calling it a day
18:56 alyssa: and then set that for driver cl but not for app cl
18:57 alyssa: the other huge advantage there (over either the hash table or array approaches) is reduced driver integration complexity
18:57 alyssa: which is good for a feature i'm (very openly) hoping to attract all the hw drivers to
19:05 bbrezillon: dcbaker: same for the panvk fix. We've noticed it by code inspection, and it doesn't seem to fix any CTS failure
19:05 dcbaker: bbrezillon: cool, thanks
19:20 dj-death: alyssa: yeah, lots of thinking for a debug feature ;)
19:21 dj-death: I feel okay with what I have, could move to a hash table, but what for really? :)
19:38 alyssa: dj-death: I mean, .. I need something I can recommend to every driver in tree to adopt
19:38 alyssa: and what anv has I don't think is it
20:12 dj-death: alyssa: one thing I would really like is ringbuffer printf so that you put the reader in a different thread
20:13 dj-death: alyssa: and keep printing while the GPU is running
20:13 dj-death: although it's probably going to be unreliable
20:20 alyssa: dj-death: hmm, it's an option..
20:20 alyssa: what's your use case?
20:32 mupuf: eric_engestrom: take care!
20:51 dj-death: alyssa: mostly no bubbles
20:52 dj-death: alyssa: because sometimes that works around problems (inserting bubbles)
21:06 alyssa: dj-death: ahh. yeah, good point.
21:30 mattst88: anyone know what's going on with https://gitlab.freedesktop.org/mesa/mesa/-/jobs/69067965 ?
21:31 mattst88: (trying to land https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32447 and it seems to be gumming up the works)
21:47 mattst88: huh, landed somehow
21:56 sehrkundemartin: alyssa: that stuff is fascinating indeed, towards the end there is some clear view at them, after x11 we had opengl to do such things, as there is no longer x11 pixmaps and whatever the images were called involved, then you have textures and framebuffers renderbuffers images backed by textures, surfaces like vbo&PBO&fbo and such, which would now take RGB/AXXXX format's so this would
21:56 sehrkundemartin: end up being one meg to 16mb buffers and such, entirely easily coded into one cpu or gpu register with my methods.
21:58 sehrkundemartin: I was graphics enthusiast for long, and i wanted X to do different like currently too, such as with opengl, however X was my love still, it was great with x11 pixmaps too.
21:59 sehrkundemartin: in history X held the hardware front and backbuffers straight actually more like buffered to hardware still, but as from EGL this task is fully for kernel.