00:24 alyssa: psykose: Seemingly no regressions
00:24 alyssa: But in addition to the pixmark-piano hash changing (which I think we agreed is fine), there seems to be a legit regression iris-whl to the freedoom trace
00:24 alyssa: https://mesa.pages.freedesktop.org/-/mesa/-/jobs/44275320/artifacts/results/summary/results/trace@gl-intel-whl@freedoom@freedoom-phase2-gl-high.trace.html
00:25 alyssa: Not sure I can figure that one out without hardware..
00:25 alyssa: (Also weird to me that it's only happening on WHL, the other iris jobs are fine?)
00:26 alyssa: Maybe one of the Intel people has an idea why Whiskeylake is special?
00:27 alyssa: (is it drunk)
05:01 kurufu: Is it legal to call vkDestroySurfaceKHR twice with the same handle? The usages say the handle must be valid, but not that a destroyed handle is invalid...
05:26 cmarcelo: kurufu: spec in section 3.3 talks a bit about it but not a definitive answer. I'd expect once you destroyed the same amount of times you got that handle, it will become invalid. have you tried using the validation layer to see if it complains about it?
05:29 kurufu: Thats a good idea, i have not.
05:31 cmarcelo: (if its not an unique kind of handle, if it is unique, then you can get and destroy only once *that particular one*)
05:33 kurufu: I imagine surfaces are unique... hopefully the validator just calls it bad.
08:26 jfalempe: tzimmermann, can you review https://patchwork.freedesktop.org/series/117881/ ? if you're ok, I can push it to drm-misc-next.
08:29 tzimmermann: jfalempe, done
08:29 tzimmermann: you already r-b'ed it, so i probably didn't bother
08:30 jfalempe: tzimmermann, ok, thanks ;)
08:40 tintou: Do the RPI farm has issues currently?
08:40 tintou: I've got a few jobs that are stuck https://gitlab.freedesktop.org/mesa/mesa/-/jobs/44293742
09:20 MrCooper: tzimmermann: FYI, looks like amdgpu not setting output_poll_changed caused a regression: https://gitlab.freedesktop.org/drm/amd/-/issues/2649#note_1972402
09:54 tzimmermann: MrCooper, saw it
11:48 mairacanal: Is it possible to call copy_to_user() inside a run_job() DRM sched callback? I'm trying to do this and copy_to_user() is sometimes failing...
12:07 alyssa: deleting nir_registers+abs+negate+sat is going to make nir soooo nice
12:19 doras: hwentlan_: if it's not clear from the bug report, this is actually a regression: https://gitlab.freedesktop.org/drm/amd/-/issues/2186
12:22 doras: It worked fine with older kernel versions (can't say exactly which, though). Cursor movement was matching the update rate of the primary plane.
12:24 doras: This issue actually results in a "violation" of the atomic promise of KMS commits regardless of VRR; both the cursor and primary planes are committed together, but only the state of the primary plane is applied.
12:32 doras: I added this information to the issue just in case.
13:06 hwentlan_: doras, thanks for the regression info. might be good to try 5.18 and then bisect if it's not reproducible there
13:06 hwentlan_: I agree it is a violation of the atomic promise
13:13 bbrezillon: dakr: Are we sure drm_gpuva_remap() will never allocate stuff for the maple tree insertion of prev/next?
13:13 bbrezillon: feels like we should pre-allocate for those too
13:14 bbrezillon: and if not, it probably deserves a comment
13:25 bbrezillon: nevermind, if we end up remapping, that means the range was allocated in the maple tree, so we're not allocating
13:59 emersion: sima, jani: any chance to get this reviewed? https://patchwork.freedesktop.org/series/109887/
14:01 sima: let me take a quick look
14:02 sima: oh it's really old, that's why I dont have it in my gmail inbox
14:06 sima: emersion, https://lore.kernel.org/dri-devel/20221019143736.267324-4-contact@emersion.fr/ this could also happen when it's not leased and it's a lease fd
14:06 sima: not sure you want to make that distinction clear or whether we log that elsewhere already
14:07 emersion: but GETRESOURCES wouldn't return that CRTC then
14:07 sima: yeah it would be a fairly hilarious bug, but then it could lead to confusion if you know it's a crtc but it doesn't work
14:08 sima: just something you might want to check, imo no need to change the patch
14:08 emersion: right
14:08 sima: *check that we have enough dbg output in the lease code maybe
14:08 emersion: yeah
14:09 sima: https://lore.kernel.org/dri-devel/20221019143736.267324-3-contact@emersion.fr/ I think the two cases at the bottom are impossible, but *shrug*
14:09 sima: on the series: r-b: me
14:09 emersion: need to add more logging to __drm_mode_object_find
14:09 emersion: ty!
14:09 sima: if you type the patch and pastebin it here, I'll r-b stamp it :-)
14:18 emersion: sima: https://paste.sr.ht/~emersion/2860241334fa158fba4e06d6f961d044068c12c2
14:23 dakr: bbrezillon: correct, drm_gpuva_remap() will re-use the nodes of the old mapping. There is no allocation while storing the entry, see mas_store() vs. mas_store_gfp().
14:26 dakr: Maybe worth noting, there are also cases where we call mas_store() with a 'NULL' entry which possibly frees up nodes which are not needed any longer.
14:28 sima: emersion, rb:me
14:28 dakr: While we could potentially re-use them in a subsequent drm_gpuva_map() call, drm_gpuva_map() should carry pre-allocated nodes anyway, plus we could also fail before and hence leak memory otherwise.
14:28 emersion: thanks!
14:33 emersion: sima: hmm, dim complains about missing Link
14:33 sima: emersion, yeah need to submit it and pick it up from the m-l
14:34 sima: that check is to make sure patches get at least dumped there
14:34 emersion: ack
14:49 bbrezillon: dakr: sounds good
14:53 karolherbst: jenatali: soo yeah.. the flame graph of hashcat I showed you with the massive spvtools::Link thing is indeed caused by linking a single spirv file... I think it's probably better to handle this as a special case inside spirv-tools though and just shortcut it by skipping unneeded things or something
14:53 jenatali: Yeah probably
17:24 dcbaker: karolherbst: the -I stuff should go away when I finish splitting includes from non-includes in all dependencies (currently that's only true for declare_dependency() objects)
17:24 dcbaker: which, actually, I need to get back to that
20:03 Lynne: was not expecting cooperative_matrix to get khr'd
20:04 jenatali: Why not?
20:07 Lynne: hardly any interest
20:07 jenatali: For what it's worth, D3D published a spec/preview for it yesterday
20:08 Lynne: the NV extension had been NV for 4 years now
20:08 Lynne: I don't think anyone's going to start using them for AI, sadly
20:09 Lynne: but I do have a use-case for it in a denoiser I wrote
20:16 cmarcelo: jenatali: interesting, have a link to the D3D spec? (or a keyword I can search for)
20:16 jenatali: cmarcelo: https://github.com/microsoft/DirectX-Specs/blob/master/d3d/HLSL_SM_6_8_WaveMatrix.md
20:17 jenatali: Not sure if it's identical, honestly this one goes above my head and I haven't looked at the Vulkan one at all
20:21 cmarcelo: jenatali: tks
20:22 alyssa: eric_engestrom: interesting case I just hit
20:23 alyssa: there's a bug (?) with the vim clang-format integration that if you add a #define above another #define, nothing is formatted but clang-format wants to align them
20:23 alyssa: my `pub` hook caught this, trivial to fix (modify the second #define in any way whatsoever and the whole block gets fixed up)
20:24 alyssa: but if I didn't have the whole-file check, I would've missed it and suffered a CI failure
20:24 alyssa: I imagine git clang-format is susceptible to similar bugs
20:31 dcbaker: karolherbst: that C++/Rust bug is the bug that keeps on giving. Did you know that rustc on windows unconditionally links to the default MSCRT runtime? Which means if Meson compiles those libraries as debug and links them with the debug runtime linking explodes?
20:32 karolherbst: uhhhhhhhhhh
20:32 karolherbst: pain
20:32 dcbaker: the solution? inject the correct /MDd /MD /MT etc before linking any libraries...
20:32 alyssa: what if not windows
20:33 dcbaker: well, then there is not MSCRT...
20:33 dcbaker: :D
20:33 jenatali: Wow
20:33 alyssa: jenatali: sorry 2-1
20:33 karolherbst: granted the stuff I'm doing inside mesa with rust is also a bit wild
20:33 dcbaker: The original bug report for this issue is from 2017
20:33 karolherbst: oh wow
20:34 alyssa:looks for test coverage for multisampled images (incl writes and atomics)
20:34 alyssa: I see some in Vulkan but I don't have a Vulkan driver yet :O
20:34 alyssa: s/Vulkan/dEQP-VK/
20:34 jenatali: alyssa: MSAA storage images are pretty new I think
20:34 jenatali: I doubt you'll find great GL coverage, if it's even supported there
20:34 alyssa: right :|
20:35 alyssa:puts on the blindfold
20:35 alyssa: zink seems to support..
20:37 alyssa: oh well
20:39 alyssa: this will be for next week
20:39 alyssa:weekends~
20:48 HdkR: Weekends, for when real work needs to get done
20:48 alyssa:thinking
20:51 bluetail: HdkR idk. I've recently been relaxing a bit more cause I tend to not stop working all the time :D
20:54 bluetail: I started to finally take a week off...
20:55 HdkR: Time off? Feels weird
20:56 karolherbst: what's a time off
20:56 bluetail: vacation
20:57 bluetail: its pretty boring but if you are that tired you are basically either on a health checkup at the doc or sleeping all day
20:57 bluetail: I never had vacation outside... idk, I am an introvert
20:58 HdkR: I think I heard about those from fictional stories
20:58 alyssa:thinking
21:58 karolherbst: anholt_: soo.. looking at v3d again. Is there a simple way for me to guarentee I have a compiled shader before launch_grid? The problem I'm seeing is that binding a cso forces a recompile, which... I don't think is a great idea, at least from a CL perspective
22:00 karolherbst: ehh wait.. v3d_get_compiled_shader would just return a compiled one, okay, no, so that's fine I guess
22:03 karolherbst: mhh.. not having PIPE_CAP_SHAREABLE_SHADERS also hurts a lot
22:04 karolherbst: ehh wait, the default is 1 anyway
22:29 karolherbst: mhh, it might not be needed in the end, but that kinda depends if all CSOs can be launched wiht 256 threads or not
23:34 alyssa: eric_engestrom: mupuf: I have circumstantial evidence suggesting that freedoom/freedoom-phase2-gl-high.trace relies on undefined behaviour, reading from uninitialized variables in the shader.
23:34 alyssa: I have not yet identified the specific issue. But CI (and only CI, not a non-CI machine of the same type, and only WHL despite non-WHL jobs running the same trace) is getting random fails with my register MR
23:35 alyssa: goes away if GLSL_ZERO_INIT is forced
23:35 alyssa: It is extremely friday night so I'm not going to pinpoint what's going wrong right now, but taken together this reeks of application bug
23:36 alyssa: that trace only runs on iris and a6xx... the above is a good argument for removing it (especially if I can figure out next week exactly where it's collapsing)
23:37 alyssa: Also we should strongly consider forcing GLSL_ZERO_INIT in the premerge trace-based CI, because app bugs here are a dime a dozen
23:38 alyssa: (Or, frankly, forcing GLSL_ZERO_INIT globally because this is a stupid game of whackamole and the shaders it hurts are usually broken in the first place.)
23:38 alyssa: (But that's a different issue.)