01:14emersion: bnieuwenhuizen: yes! https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/8
01:17emersion: daniels: btw, what's blocking this in your opinion? maybe i should update the weston patch?
01:18emersion: ascent12: do you think you'll have time to continue your great work on the mesa/weston patches?
02:56airlied: have at thee ttm 00/59
05:35jekstrand: airlied: That is a good pile of patches
05:51airlied: jekstrand: vaccuming as I go :-P
05:52jekstrand: airlied: That's ok. That's like half of my NIR patches
05:52airlied: my DG1 is in a fedex depo nearby :-P
09:16danvet: tzimmermann, when you do the drm-misc-next-fixes pull this week, also make one for drm-misc-fixes
09:17danvet: there's patches in both, I guess they should all go into the merge window pull ideally
09:17danvet: mripard, mlankhorst ^^ fyi
09:19danvet: Lyude, [PATCH] drm: fix drm_dp_mst_port refcount leaks in drm_dp_mst_allocate_vcpi <- for you I think
09:24mlankhorst: danvet: hm isn't it me doing drm-misc-next-fixes atm? :p
09:24danvet: hm dunno
09:24danvet: I thought I poked tzimmermann for it last time around
09:24danvet: or maybe that was -fixes
09:24danvet: in which case yes I guess it's you :-)
09:25mlankhorst: will send both tomorrow
09:27danvet: airlied, ^^ fyi maybe want to include these
09:33karolherbst: why do we call it ppc64el? :D
09:33karolherbst: in CI I mean
09:33tzimmermann: danvet, i only do drm-misc-fixes ATM
09:34danvet: tzimmermann, yeah mlankhorst fixed up my confusion already
09:34danvet: karolherbst, ppc64lol too offensive?
09:34karolherbst: danvet: for reasons I need to care about that stuff now :p
09:38mlankhorst: tzimmermann: but 5.8 happened, so I have misx-fixes too
09:39tzimmermann: mlankhorst, really? i was under the impression that -misc-fixes is still my job until -rc1 has been tagged? IIRC that's what i was told for 5.7
09:42MrCooper: karolherbst: that's the Debian architecture name
09:43karolherbst: MrCooper: ehhh
09:44karolherbst: maybe we should start calling x86_64 x64_86 just for fun :p
09:44danvet: tzimmermann, mlankhorst I pushed another patch to -fixes because it wouldn't apply to -next-fixes
09:44karolherbst: but I assume the name is a pun itself
09:48HdkR: I already call AArch64 Arm64 instead, much to the dismay of ARM :P
09:48MrCooper: karolherbst: that's appropriately named amd64 :) IIRC it's consistent with previous bi-endian architectures, e.g. mipsel
09:49karolherbst: I see
11:33tzimmermann: mlankhorst, i'm going to send out -misc-next now
11:34tzimmermann: i meant -misc-fixes; not -misc-next
11:56karolherbst: mhhhhh... compiling mesa with dockercross isn't really working out that well :/
11:57karolherbst: ohh wait.. I know what's up
12:14frhun: I have a problem with a hard driver crash on (it seems) all AMD RDNA cards. I have heard from someone that the same code causes a 4 sec freeze on windows/nvidia even. -- WARNING only click this link when you are ready to have your session fully crashed: https://www.shadertoy.com/view/ttf3Dj --
12:20kisak: hi frhun, report the issue over at https://gitlab.freedesktop.org/mesa/mesa/-/issues so it's harder to get lost with time.
12:21pendingchaos: it looks like there's already a issue for it: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3358
12:22frhun: seems like someone that read it on the forum already created the issue
12:22kisak: thanks pendingchaos
12:23frhun: maybe someone running intel or nouveau could try if it effects their session too
12:24bnieuwenhuizen: someone commented on that bug that it crashes in the compiler for intel
12:25frhun: when browsing shadertoy there seem to be quite a lot of shaders that crash the session, this is just the one i managed to get the link of before it crashed
12:27pendingchaos: might be the same issue as https://gitlab.freedesktop.org/mesa/mesa/-/issues/3336
13:01mlankhorst: tzimmermann: ah, after release that's usually for the next person. :)
13:02tzimmermann: i thought so. mripard mentioned this with -rc1
13:02tzimmermann: but i'm ok with either
13:02tzimmermann: i just sent out -misc-fixes
13:03mlankhorst: yeah, no worries, will pick up from here tomorrow
15:18Lyude: danvet: thanks! will take a look
15:36Lyude: Hm, I'm assuming since 5.8 just came out drm-misc fixes should be pushed to drm-misc-fixes? (cc airlied )
15:39anholt: tomeu: we would also really like to see wayland and X dEQP EGL runs, so getting those sorted out would be great anyway
15:42anholt: chrisf: thanks a bunch, btw. looking forward to removing our last xfails from a630 (we have only two others besides that one)!
15:47daniels: emersion: the blocker on my side is life not going to plan tbh. it's very high up on my list but I can't give an ETA with a straight face. sorry.
15:48daniels: anholt: should be pretty trivial really ... weston -Bheadless-backend.so with a recent version
15:48daniels: not sure what the Xorg surfaceless story is like (since I don't expect Xvfb to be useful for this), but you could maybe run a rooted Xwayland under that Weston for X11 testing :P
15:49emersion: daniels: got it, np
15:49anholt: daniels: worst case scenario is forcing a mode on the modesetting driver even without a connector probing connected.
15:50anholt: I know I've seen a million messages go by about this on xorg :)
15:52daniels: anholt: we'd still need a kms device to probe, no?
15:52anholt: we should have those on all the boards
15:52daniels: but on llvmpipe?
15:52anholt: daniels: ah, context with tomeu was the freedreno stuff
15:53anholt: llvmpipe we run against xvfb currently
15:53anholt: for piglit, at least
15:56daniels: fair enough
16:06danvet: Lyude, we're in the merge window, so drm-misc-next-fixes
16:07Lyude: danvet: gotcha, thanks
16:07danvet: I guess maybe this should clarify that in the merge window there's no current -rc ...
16:07danvet: Lyude, it doesn't matter in practice since maintainers will check both trees for pending patches
16:07Lyude: yeah-that's where I got a bit confuse
16:07Lyude: danvet: ggotcha
16:52danvet: sravn_, I'll wait with reviewing drm bl patches that containe a bl_update_status right after bl_set_brightness until we've found an answer for that
16:52danvet: I do like the patches though, just in case you wonder why I leave those out
16:56sravn_: danvet: for now patch 2 and patch 3 is the relevant ones. The remaining ones are more to verify that the abstraction is OK
16:56sravn_: And I should re-surrect my backlight_update_brightness() which does what you suggest
16:58sravn_: I have no clear plan how to get rid of the power part - but maybe I shall just realise that power_off() is the same as backligth_disable() and fix up callers accordingly
16:58sravn_: In other words - power_off() is another way to turn off backlight - a little backward.
16:59sravn_: Let me look a little on the users and get back to you later
17:04danvet: sravn_, ok makes sense, I'll dig through your patches with that idea then
17:04danvet: sravn_, I thought you've pretty much converted all raw access to bl_enable/disable helpers already?
17:05danvet: ah no
17:33alyssa:wonders why gcc doesn't like packed bitfields (clang is fine on the sample I tested)
17:47jenatali: karolherbst: Finally have a full CTS run going for CL which I actually expect to pass - should be able to actually focus on sending more stuff upstream now
17:48jenatali: First up, to remember what the hell we decided to do about offset system values and try to implement that
18:30sravn_: danvet: Nope, but if I give the backlight core one extra spin then I can have all the plumbing right, so I only need to touch the backlight drivers once.
18:30sravn_: Which is a good argument to have a solution for the power state stuff
20:21austriancoder: should nir_lower_bool_to_bitsize be used in the nir opt loop or after it?
20:30austriancoder: maybe after nir_opt_algebraic_late
20:35anholt: austriancoder: basically the last thing you do, iirc.
20:36anholt: (should should have better optimization in your opt loop with 1-bit bools, and no further opt to do after the lowering)
20:43austriancoder: anholt: thanks for the tipp
20:49austriancoder:finds it from time to time quite hard to find the best sequence of ops and lowerings
20:52jenatali: From time to time? :P
20:57austriancoder: :) everytime a new opt pass gets added for instance
21:30alyssa: genxml doesn't do typed unions it looks like?
21:34jenatali: karolherbst: What's the status on your structurizer MR?
21:40jenatali: I'm wondering if we should plan to merge the updated version I picked (https://gitlab.freedesktop.org/kusma/mesa/-/merge_requests/245) or if you think you've got more significant changes planned
22:51karolherbst: jenatali: I reworked the vtn bits now somebody needs to deal with the nir structurizer :p
22:52karolherbst: at this point it's really only about getting the nir code into shape