06:10airlied: Kayden, dj-death : oh you've got a bit of a problem with llvm17 and intel-clc, going to write up an issue for spirv-llvm-translator, but not sure how best to move it forward
06:20airlied: filed 9791, 9792 and a spirv-llvm-translator
06:22airlied: karolherbst, jenatali : if you use spirv-link we might see fallout like this in other places
07:33kode54: Will be a while before that hits arch, somehow
07:33kode54: They just updated to llvm16 less than a month ago
07:51Kayden: airlied: thanks for the heads up
08:27tzimmermann: javierm, i resubmitted the boot-up logo series and rearranged some of the patches according to your suggestion. do you want to take another look or can i merge it?
09:37kode54: airlied: dk-death gitlab profile says “Offline until September 25”
09:37kode54: dj
09:37kode54: I swear I typed it right, stupid autocarrot
09:49javierm: tzimmermann: sure, go ahead
09:49MrCooper: kode54: stupid autocarrot indeed :)
09:50MrCooper: better stick to manual carrots
10:01tzimmermann: thanks, javierm
10:52karolherbst: airlied: thanks for looking into llvm-17
10:55karolherbst: but yeah.... that event stuff will be annoying
10:55karolherbst: or other opaque pointers to I guess
10:55karolherbst: ehh opaque types
12:57tzimmermann: sima, i still found two unmerged patches in drm-misc-next-fixes. i'd like to send a PR for drm-next and then also cherry-pick them into drm-misc-fixes. ok?
13:25penguin42: karolherbst: I figured out how to prod llvm with the debug ir's; if you save the chunk starting '; ModuleID..' to the bit ending '!0 =' in a whatever.ll file you can run it through llvm's llc or opt
13:25penguin42: karolherbst: and if you have a debug build of llvm you can pass llc --debug
13:26penguin42: now that's just 36k lines of debug output to understand :-)
13:59sima: tzimmermann, hm I guess you could also merge them into drm-misc-next-fixes
14:00sima: if you leave them dangling, then I think dim gets confused and keeps pushing drm-misc-next-fixes to for-linux-next
14:00sima: so whatever you do, pls make sure drm-misc-next ends up in there
14:00tzimmermann: sima. the patches are in drm-misc-next-fixes already
14:00sima: tzimmermann, oh I mean as an actual merge
14:01tzimmermann: i want to merge drm-misc-next-fixes into drm-next; even though it's not really open any longer
14:01tzimmermann: does that work?
14:01sima: well -next-fixes should have gone into -rc1
14:01sima: so it should go into drm-fixes?
14:01sima: otherwise those fixes are held up for an entire merge cycle
14:02sima: tzimmermann, is there a PR for these 2 patches on dri-devel?
14:02tzimmermann: not yet
14:02tzimmermann: i'd then cherry-pick them into drm-misc-fixes
14:02sima: there's still the issue that if you leave them dangling as unmerged stuff, then dim gets confused
14:03tzimmermann: the pull request against drm-misc-next is for consistency of the various drm trees.
14:03sima: so roughly what we can do is 1. PR for drm-misc-next-fixes 2. I merge that into drm-fixes 3. you base drm-misc-fixes on that
14:03sima: tzimmermann, I was wrong at first, it shouldn't go into drm-misc-next
14:03sima: if you want it there, backmerge from drm.git or so
14:03tzimmermann: yes
14:03tzimmermann: ok
14:04sima: also, I just came back from workout, my brain is not entirely online :-)
14:04tzimmermann: ok, sorry :D
14:04sima: well just double-check that what I said makes some sense
14:05tzimmermann: my question is: should these patches be merged into drm-next, or should they go into drm-fixes. i'd assume the former. but you just said it's the latter
14:05sima: drm-fixes, they're fixes
14:05sima: and also, we need to merge them or dim gets confused
14:06sima: since it uses "is drm-misc-fixes a strict superset of drm-misc-next-fixes" to decide whether we're inside or outside of the merge window freeze (which starts more at -rc6 for us)
14:07sima: tzimmermann, it's maybe less confusing if you look at this in terms of releases, the patches in drm-misc-next-fixes were meant for 6.6-rc1, so they should just make it in the next 6.6-rc, not get delayed until 6.7-rc1
14:07sima: which they would if you stuff them into drm-(misc-)next
14:08tzimmermann: sima, ok, thanks. makes sense
14:08sima: tzimmermann, if you want to sort this all out you can do the pr and ping me here and I'll land it right away
14:08tzimmermann: ok
14:09sima: then either backmerge or fast-forward drm-fixes into drm-misc-fixes to get it all sorted
14:19tzimmermann: sima, PR is out
14:24sima: it's compiling
14:59sima: tzimmermann, pushed
14:59tzimmermann: thank you
15:50zmike: anholt_: can you add hakzsam to restricted traces access? or can anyone do it
16:14HdkR: 11
16:49kisak: eric_engestrom / dcbaker: I want to NACK backporting https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19125 on the basis that it requires an xcbproto bump to 1.16.0 (3 weeks old) for a commit that landed over there ~2 months ago and that's not expressed well in mesa's meson config (or I'm missing something important there.)
16:50kisak: that's fine for 23.3.0 and going forward, but the dependency bump doesn't make sense in a backport to me.
16:51anholt_: seems clearly like a new feature that wouldn't qualify for backporting to me.
17:05zamundaaa[m]: kisak: the version bump was intentionally not added to not annoy people with the new dependency or have to wait ages with merging it. Or is there a way to add a version bump as optional?
17:08dcbaker: kisak: I'll hold off on that for now
17:09dcbaker: unless there's a really good reason to backport it
18:16anholt_: success! I can now generate .debs from a CI pipeline. https://gitlab.freedesktop.org/anholt/deqp-runner/-/releases
18:31kisak: Ah, so the boiler plate of !19125 doesn't match the contents. If it doesn't break the build without the xcbproto bump, then I shouldn't care one way or another.
18:41zamundaaa[m]: Yeah, the 'requires' is outdated
19:53zmike: gfxstrand: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25055
20:02gfxstrand: zmike: rb
20:02gfxstrand: Also, annoying
23:59airlied: karolherbst: okay https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25165 fixes the event thing in the most llvm compatible way, I didn't really want to backport a bunch of htings from llvm17 to 16