07:58bbrezillon: mripard: I realize I queued patches to drm-misc-fixes just before the merge-window. Don't remember what happens in that case. Are you merging drm-misc-fixes into drm-misc-next, or should we wait for those fixes to be merged in Linus tree and ask for a main -> drm-misc-next backmerge?
07:59bbrezillon: context => we depend on those fixes for some work we develop against drm-misc-next
08:19mripard: bbrezillon: the latter, but fixes are sent pretty much every week so it shouldn't cause you too much troubles
08:22bbrezillon: mripard: sounds good, thanks!
10:50penguin42: karolherbst: Thanks!
10:50karolherbst: no worries. Will you look into wiring up proper profiling as well?
10:50karolherbst: and thanks for the help
10:50penguin42: I will, yes
10:51penguin42: just needs to kick a couple of other-project patches out first
11:12karolherbst: penguin42: in regards to the radeonsi load vectorization patch, you could also just open an MR with that with my updated patch or something
11:12karolherbst: just provide some data it helps. Maybe even check if it helps with GL? dunno
11:13karolherbst: though not many things actually use ssbos and I think for ssbos there are other optimizations in place
11:14penguin42: karolherbst: I can't honestly say I understand the innards of the code that the patch changes
11:15karolherbst: it just adds an optimization pass radeonsi calls
11:15karolherbst: and moves some bits around as currently radv is using it
11:15karolherbst: so it moves it into common code so it can be used by radeonsi, and then radeonsi uses it
11:15karolherbst: or rather the amd llvm compiler uses it
11:15karolherbst: actually...
11:15karolherbst: I have an idea
11:16karolherbst: mupuf: you all only test the aco radv perf in terms of performance regressions, right? Or are you also tracking changes for radeonsi and/or radv+llvm?
11:17mupuf: performance? We don't do any sort of performance testing
11:17karolherbst: uhh.. surprising
11:17karolherbst: but okay
11:17mupuf: I know ;) One day, one day!
11:17karolherbst: guess you just wait for users to report regressions
11:17karolherbst: :)
11:18mupuf: regressions? What's that word?
11:18mupuf: :D
11:18penguin42: mupuf: Look here! I have a particularly pointless piece of OpenCL code I want to run pointlessly fast
11:18karolherbst: yeah well.. it will affect everything else though
11:19karolherbst: but it might be that GL just doesn't hit this particular pattern, or maybe just not often enough
11:19orowith2os: karolherbst: tracking performance? not more fuel for zmike, surely ;)
11:19mupuf: more seriously, running benchmarks would be good... but there aren't that many we can run for vulkan...
11:19karolherbst: yeah.. but that's zink on radeonsi+aco
11:19penguin42: karolherbst: I guess it might depend what crazyness they do in their shaders
11:19karolherbst: and the patch in question only affects the llvm compiler
11:19karolherbst: well.. the only way of hitting this in OpenGL is via SSBO
11:20karolherbst: and SSBOs have 32 bit offsets
11:20karolherbst: though.. the pattern could still exist, just.. dunno, might just not happen
11:20mupuf: karolherbst: radv+llvm is known-broken :s
11:20karolherbst: fair
11:21karolherbst: ohh... we could run shader-db stuff...
11:21karolherbst: anybody tracking shader-db on radeonsi with a.... useful shader set?
11:21mupuf: karolherbst: it's called fossils for vulkan
11:22mupuf: tracking its performance would be tracking the compilation speed
11:22karolherbst: yeah sure, but the patch in question applies to the llvm compiler, so dunno what's best to do here
11:22karolherbst: but I also think this patch should just land anyway
11:23karolherbst: it's this one: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/fbbbaf0acab37cb3b012a073146918432f241283
11:46penguin42: karolherbst: And I'd replied in issue 9139 saying it helped a lot; https://gitlab.freedesktop.org/mesa/mesa/-/issues/9139#note_1945236
12:00karolherbst: yeah, as I said, just submit it as an MR with some more detailed data there
12:05penguin42:admits to being unsure about submitting a MR for a patch he didn't write, and doesn't understand the detail of
12:11LaserEyess: you can put `Co-Authored-By: Name <email@domain.com>` on the commit
12:15javierm: mripard, tzimmermann: do you know if commit d13b5d2b2b45 ("drm/i2c: Switch i2c drivers back to use .probe()") can still make it to v6.5-rc1 ?
12:15javierm: it's currently in drm-misc-next, Uwe wanted to know
12:15tzimmermann: javierm, it won't, sorry
12:16tzimmermann: we're past -rc6 already
12:16javierm: tzimmermann: ah, right. That's OK, I just wondered whether that was the case or not
12:17tzimmermann: javierm, i'd need one more review for my fbdev patchset. can you help?
12:24javierm: tzimmermann: sure, only https://patchwork.kernel.org/project/dri-devel/patch/20230613110953.24176-28-tzimmermann@suse.de/ is missing tag right ?
12:25tzimmermann: javierm, yes this.
12:27alyssa: anyone invested in NIR ergonomics wish to r-b https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23807 ?
12:27alyssa: kusma: maybe? I'll swap you for your NIR builder series ;)
12:27javierm: tzimmermann: looks good to me as well. Just answered in the list
12:27tzimmermann: thank you so much
12:29kusma: alyssa: I'll have to wait until tomorrow, I'm soon in back-to-back meetings :P
12:30alyssa: kusma: good luck ;p
12:57alyssa: dj-death: does your r-b also apply to the commit adding the macros, or just the replacement commit?
13:06dj-death: alyssa: I thought people still had suggestions for the first commit
13:07alyssa: dj-death: I reworked that commit taking the suggestions into account
13:08alyssa: Something of a compromise... I really liked Faith's solution until finding it doesn't compile (~:
13:26dj-death: alyssa: I wonder why you need the 2 loops
13:26alyssa: dj-death: To define two different variables of different types
13:27dj-death: alyssa: can't you do: for (impl = first_impl(shader); impl != NULL; impl = next_impl(impl->function)) ?
13:28alyssa: dj-death: That's Yonggang's solution
13:28alyssa: I'm not fundamentally opposed but it's definitely doing more "work" than the other approaches since the compiler can't know that fxn->impl->function == fxn
14:04dj-death: alyssa: I'm failing to see why it's more work, but you current change also work
14:04dj-death: alyssa: left a rb
14:14alyssa: dj-death: with the impl->function approach, every iteration the code dereferences function->impl and then dereferences again impl->function instead of just remembering function
14:14alyssa: (Is that actually better because of a lessened risk of spilling? well, that's a different issue I suppose.)
14:25dj-death: yeah
14:25dj-death: I'm not sure iterating functions is like a hot path ;)
14:28alyssa: Me neither :)
14:28alyssa: But nearly every NIR pass does it
16:24jenatali: Vulkan question: Can vkCmdClearAttachments be used to clear attachments that are currently not bound as color/depth-stencil attachments in the current subpass?
16:24jenatali: My spec reading says yes but that seems odd
16:28Company: jenatali: the command selects what to clear via the bound state, no?
16:28jenatali: No, you pass in an array of attachments
16:29jenatali: Oh, nevermind
16:29jenatali: You pass an array of aspects and/or color indices
16:30jenatali: Cool, thanks
16:30Company: yeah, it's a VkClearAttachment, not a VkAttachmentReference
16:30jenatali: Yeah, I'd just assumed instead of reading :P
17:25alyssa: in GL, can shared textures (ie winsys surfaces) be used with MRT?
17:26alyssa: It's my understanding they can't be bound as shader images, at least
17:26alyssa: (If they can I can deal with it -- I know I'll have to deal with it for Vulkan -- but it would be for convenient if they can't)
17:27alyssa: not even sure where to look in the spec for that
17:37alyssa: I guess so: eglCreateImage to a renderbuffer, glFramebufferRenderbufer to a nonzero attachment
17:37alyssa: Grumble grumble grumble. Ok. I'll figure out how to deal with it.
17:37alyssa: (I mean, shadow and blit. But ugh.)
17:38HdkR: Everyone loves their MSAA window buffers
17:38alyssa: HdkR: not MSAA, MRT
17:39HdkR: Oh! misread
17:40HdkR: But yea, sounds about right :D
22:57Lynne: bnieuwenhuizen_: made https://gitlab.freedesktop.org/mesa/mesa/-/issues/9251
22:57Lynne: we discussed this a few months ago but nothing came of it
22:58bnieuwenhuizen_: Ack