06:52 MrCooper: rpavlik: yeah it seems impractical for more reasons, guess we'll have to deal with the monotonic clock not ticking at a constant rate somehow
07:48 jani: mripard: tzimmermann: mlankhorst: drm-misc-next-fixes needs updating? https://lore.kernel.org/r/312158b1dc10c9e966df9e66e8e52e6279be4c19@intel.com
07:49 mripard: jani: on it
07:49 mripard: thanks for the ping :)
07:53 jani: mripard: yeah well I know how it is with email, might miss stuff in the firehose pointed at your general direction :)
07:53 mripard: also, just got back from vacation so under a mail DDoS :)
07:55 mripard: jani: done, and your patch is applied
09:34 jani: mripard: thanks a bunch
09:38 jani: mripard: mmh, did you push? :)
09:40 mripard: jani: yes, https://gitlab.freedesktop.org/drm/misc/kernel/-/tree/drm-misc-next-fixes?ref_type=heads
09:45 jani: mripard: ah, yes, drm-misc-next-fixes is fine, but drm-tip rebuild has conflicts
09:51 paulgdpr: Hi, I would like to submit a small MR on mesa (to fix tearing support on wayland) but I can't fork the mesa repo on gitlab, am I missing something?
09:52 stsquad: paulgdpr are you on gitlab.com or the freedesktop gitlab - and do you have an account there?
09:54 paulgdpr: freedesktop gitlab and I created an account there
09:56 paulgdpr: stsquad: "Limit reached You cannot create projects in your personal namespace. Contact your GitLab administrator."
10:05 stsquad: hmm - I guess you need to do that, forking mesa worked for me but I can't see any particular group membership or permission for that....
10:09 paulgdpr: Unfortunaly I don't see anywhere how to lift this restriction: https://docs.mesa3d.org/submittingpatches.html, nor how to contact the gitlab administrators
10:12 stsquad: paulgdpr I'd ask on #freedesktop or file a bug on https://gitlab.freedesktop.org/freedesktop/freedesktop (see https://gitlab.freedesktop.org/help)
10:14 paulgdpr: stsquad: ok thanks for the pointers
13:00 jani: airlied: agd5f_: drm-tip rebuild is broken because 6be28c11dcb7 ("drm/amd/display: Add i2c and EDID parsing tests for connector") from drm-next conflicts badly with f65198b3d073 ("drm/amd/display: Use HDMI FreeSync range from common EDID parser") from drm-misc-next. both commits from amd through different trees. I don't want to touch the conflict resolution because it's bound to go wrong.
13:03 jani: the drm-misc-next commits came afterwards, so I'd think Mario Limonciello should've noticed the conflicts when pushing them yesterday-ish
13:05 jani: locally, the conflict resolution is trivial, but 6be28c11dcb7 adds kunit tests that need functions being removed by f65198b3d073
13:32 agd5f: jani, will take look
14:27 jani: agd5f: thanks!
14:28 jani: airlied: I never know whether it's better to chime in on these discussions or just keep flying under the radar https://lore.kernel.org/r/CAMuHMdVBABOiOWDdCKE0zDffj856ui5qr3UFVptwcAn1_Hx7oQ@mail.gmail.com
14:29 jani: airlied: it's already going way off-topic for the thread. I guess the only possible positive outcome would be for someone to go ahead and make git deal better with cherry-picks somehow
14:53 agd5f: jani, it feels like the Linux bubble. Every other piece of software fixes bugs in mainline and then cherry-picks to stable branches.
15:25 jani: agd5f: yeah. I guess the argument is that Linus' tree is the mainline. but it just doesn't scale for large subsystems and drivers
15:27 jani: I hear maintainers in other subsystems complain about the merge window being painfully busy and they reply to patches with, "come back in a few weeks". and I'm like, you're doing it wrong. the weeks leading up to and including the merge window is the most peaceful time in a development cycle for me
15:43 agd5f: jani, yeah, exactly
19:40 alyssa: is protectedMemory supposed to work on Xe2?
19:41 alyssa: the tests usually skip but last boot I got fails in there (which I fixed and now they're skipping again after a reboot)
19:41 alyssa: what kind of witchcraft is this? did I accidentally click on something DRM'd in Firefox and then it changed my Vulkan CTS results? XD
19:42 Sachiel: they work on my lnl
19:43 alyssa: Test case 'dEQP-VK.protected_memory.stack.stacksize_128'..
19:43 alyssa: NotSupported (Protected Memory feature not supported by the device at vktProtectedMemUtils.cpp:113)
19:43 alyssa: wonder what I'm missing
19:43 Sachiel: seems to check for some kernel stuff, no idea what
19:44 Sachiel: simple ioctl query that I think should just be supported. I'm not aware of this being disableable
19:45 alyssa: wild
19:46 airlied: jani: at yet again whether or not we should use -x is mentioned as if we haven't gone around the loop a few times
19:46 alyssa: Sachiel: oh well. certainly not a Jay bug XD
19:58 glehmann: has anyone already done work on the common code for VK_EXT_cooperative_matrix_maintenance1?
20:03 airlied: glehmann: nah I was waiting for it to release, since it was mostly just bits of coopmat2
20:04 airlied: glehmann: I'm happy to do it later this week
20:04 airlied: glehmann: esp if me doing that means you can review any of the other backlog :-P
20:05 glehmann: I can do it myself, I was just asking to not duplicate work.
20:06 glehmann: dj-death: do you know if there is already an anv implementation somewhere?
20:11 Sachiel: glehmann: sort of, you'll hear from cmarcelo soon
20:12 glehmann: thanks, I'll wait for that then
20:12 airlied: glehmann: is GetCoordinate the only non cm2 thing?
20:12 glehmann: transpose also got more powerful iirc
20:13 glehmann: now it can do all type conversions like normal cmat casts
20:18 cmarcelo: glehmann: about cmm1, are you referring to the new spirv op + advertising, or something else? I'm double checking if we already have code for that.
20:19 airlied: I don't see any branches in khronos repo
20:26 glehmann: cmarcelo: the vtn bits
20:36 cmarcelo: glehmann: go ahead and work on those. we had just some incomplete stuff to try to get the tests running. (someone else is working on it that's why i had to double check).
20:37 cmarcelo: airlied: right, there's no branch in khronos repo.
20:41 cmarcelo: glehmann: airlied: I'll have a branch for long-vector and some related extensions soon btw.
20:47 glehmann: do you fully implement it in vtn, or how are you solving the nir vector length issue?
20:49 cmarcelo: vtn
20:49 cmarcelo: reorganized vtn to avoid making it look terrible
20:49 cmarcelo: and then lower long vecs into arrays.
20:49 alyssa: yo, we heard you like vectors..
20:50 cmarcelo: other extensions that build on top of that can add more explicit operations instead of lowering them immediately. I've built NV_cvec on top of it to test. (I had NV_cvec with "handles" like cmat is, for comparison).
20:51 cmarcelo: vtn approach is not ideal, but I think is a good intermediate step if we ever want to do a larger NIR first class support
20:52 alyssa: first class long vec in NIR scares me
20:53 cmarcelo: alyssa: that's why I haven't opened that door for now. we don't need that yet for the extensions that I'm looking into.
21:04 airlied: what is the main consumer for long vectors btw?
21:11 airlied: uggh they used the same feature name in two feature structs, messes up our generator
21:13 zmike: that's illegal!
21:14 airlied: guess someone has to go tell them that :-)
21:14 airlied: but it's in the vk headers/registry now
21:16 glehmann: airlied: we have a way to deal with that: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/vulkan/util/vk_physical_device_features_gen.py#L37
21:17 airlied: ah just need to add them, I thought RENAMED_FEATURES was a registry thing, I should have grepped more :-)
21:20 cmarcelo: airlied: in the public spec, there's none, but one can infer by the VK_EXT_shader_long_vector that the plan is to have cooperative operations on them.
21:24 airlied: cmarcelo: just wondering whether it's gaming or compute driven?
21:24 airlied: glehmann: I'm not sure that mechanism is sufficient
21:25 airlied: that is for renamed features, these features have the same name
21:25 airlied: but maybe I missed something
21:26 glehmann: it's exactly for that, different features but with the same name?
21:27 glehmann: for example, NV mesh and KHR mesh are not the same, so the nvidia feature is renamed to meshShaderNV
21:36 cmarcelo: airlied: the immediate workload I'm looking at is gaming. spec-wise I think people are also considering DX LinAlg that is a "combo" of cmat and cvec.
21:36 airlied: glehmann: in this case both features are called cooperativeMatrixReductions
21:37 airlied: oh maybe sticking an NV in there is sufficient
21:37 airlied: ah I get it now
21:38 airlied: it renames the ones in the spec, I thought it was trying to match the different spec ones