01:14 emersion: bnieuwenhuizen: yes! https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/8
01:17 emersion: daniels: btw, what's blocking this in your opinion? maybe i should update the weston patch?
01:18 emersion: ascent12: do you think you'll have time to continue your great work on the mesa/weston patches?
02:56 airlied: have at thee ttm 00/59
05:35 jekstrand: airlied: That is a good pile of patches
05:51 airlied: jekstrand: vaccuming as I go :-P
05:52 jekstrand: airlied: That's ok. That's like half of my NIR patches
05:52 airlied: my DG1 is in a fedex depo nearby :-P
09:16 danvet: tzimmermann, when you do the drm-misc-next-fixes pull this week, also make one for drm-misc-fixes
09:17 danvet: there's patches in both, I guess they should all go into the merge window pull ideally
09:17 danvet: mripard, mlankhorst ^^ fyi
09:19 danvet: Lyude, [PATCH] drm: fix drm_dp_mst_port refcount leaks in drm_dp_mst_allocate_vcpi <- for you I think
09:24 mlankhorst: danvet: hm isn't it me doing drm-misc-next-fixes atm? :p
09:24 danvet: hm dunno
09:24 danvet: I thought I poked tzimmermann for it last time around
09:24 danvet: or maybe that was -fixes
09:24 mlankhorst: yeah
09:24 danvet: in which case yes I guess it's you :-)
09:25 mlankhorst: will send both tomorrow
09:27 danvet: airlied, ^^ fyi maybe want to include these
09:33 karolherbst: why do we call it ppc64el? :D
09:33 karolherbst: in CI I mean
09:33 tzimmermann: danvet, i only do drm-misc-fixes ATM
09:34 danvet: tzimmermann, yeah mlankhorst fixed up my confusion already
09:34 danvet: karolherbst, ppc64lol too offensive?
09:34 karolherbst: lol...
09:34 karolherbst: danvet: for reasons I need to care about that stuff now :p
09:38 mlankhorst: tzimmermann: but 5.8 happened, so I have misx-fixes too
09:39 tzimmermann: 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:42 MrCooper: karolherbst: that's the Debian architecture name
09:43 karolherbst: MrCooper: ehhh
09:44 karolherbst: maybe we should start calling x86_64 x64_86 just for fun :p
09:44 danvet: tzimmermann, mlankhorst I pushed another patch to -fixes because it wouldn't apply to -next-fixes
09:44 karolherbst: but I assume the name is a pun itself
09:48 HdkR: I already call AArch64 Arm64 instead, much to the dismay of ARM :P
09:48 MrCooper: karolherbst: that's appropriately named amd64 :) IIRC it's consistent with previous bi-endian architectures, e.g. mipsel
09:49 karolherbst: I see
11:33 tzimmermann: mlankhorst, i'm going to send out -misc-next now
11:34 tzimmermann: i meant -misc-fixes; not -misc-next
11:56 karolherbst: mhhhhh... compiling mesa with dockercross isn't really working out that well :/
11:57 karolherbst: ohh wait.. I know what's up
12:14 frhun: 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:20 kisak: hi frhun, report the issue over at https://gitlab.freedesktop.org/mesa/mesa/-/issues so it's harder to get lost with time.
12:21 pendingchaos: it looks like there's already a issue for it: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3358
12:22 frhun: seems like someone that read it on the forum already created the issue
12:22 kisak: thanks pendingchaos
12:23 frhun: maybe someone running intel or nouveau could try if it effects their session too
12:24 bnieuwenhuizen: someone commented on that bug that it crashes in the compiler for intel
12:25 frhun: 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:27 pendingchaos: might be the same issue as https://gitlab.freedesktop.org/mesa/mesa/-/issues/3336
13:01 mlankhorst: tzimmermann: ah, after release that's usually for the next person. :)
13:02 tzimmermann: i thought so. mripard mentioned this with -rc1
13:02 tzimmermann: but i'm ok with either
13:02 tzimmermann: i just sent out -misc-fixes
13:03 mlankhorst: yeah, no worries, will pick up from here tomorrow
15:18 Lyude: danvet: thanks! will take a look
15:36 Lyude: Hm, I'm assuming since 5.8 just came out drm-misc fixes should be pushed to drm-misc-fixes? (cc airlied )
15:39 anholt: tomeu: we would also really like to see wayland and X dEQP EGL runs, so getting those sorted out would be great anyway
15:40 anholt: (https://gitlab.freedesktop.org/mesa/mesa/-/issues/1884)
15:42 anholt: chrisf: thanks a bunch, btw. looking forward to removing our last xfails from a630 (we have only two others besides that one)!
15:47 daniels: 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:48 daniels: anholt: should be pretty trivial really ... weston -Bheadless-backend.so with a recent version
15:48 daniels: 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:49 emersion: daniels: got it, np
15:49 anholt: daniels: worst case scenario is forcing a mode on the modesetting driver even without a connector probing connected.
15:50 anholt: I know I've seen a million messages go by about this on xorg :)
15:52 daniels: anholt: we'd still need a kms device to probe, no?
15:52 anholt: we should have those on all the boards
15:52 daniels: but on llvmpipe?
15:52 anholt: daniels: ah, context with tomeu was the freedreno stuff
15:53 anholt: llvmpipe we run against xvfb currently
15:53 anholt: for piglit, at least
15:56 daniels: fair enough
16:06 danvet: Lyude, we're in the merge window, so drm-misc-next-fixes
16:07 Lyude: danvet: gotcha, thanks
16:07 danvet: https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#where-do-i-apply-my-patch
16:07 danvet: I guess maybe this should clarify that in the merge window there's no current -rc ...
16:07 danvet: Lyude, it doesn't matter in practice since maintainers will check both trees for pending patches
16:07 Lyude: yeah-that's where I got a bit confuse
16:07 Lyude: danvet: ggotcha
16:52 danvet: 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:52 danvet: I do like the patches though, just in case you wonder why I leave those out
16:56 sravn_: 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:56 sravn_: And I should re-surrect my backlight_update_brightness() which does what you suggest
16:58 sravn_: 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:58 sravn_: In other words - power_off() is another way to turn off backlight - a little backward.
16:59 sravn_: Let me look a little on the users and get back to you later
17:04 danvet: sravn_, ok makes sense, I'll dig through your patches with that idea then
17:04 danvet: sravn_, I thought you've pretty much converted all raw access to bl_enable/disable helpers already?
17:05 danvet: ah no
17:33 alyssa:wonders why gcc doesn't like packed bitfields (clang is fine on the sample I tested)
17:47 jenatali: 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:47 karolherbst: :)
17:47 karolherbst: cool
17:48 jenatali: First up, to remember what the hell we decided to do about offset system values and try to implement that
18:30 sravn_: 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:30 sravn_: Which is a good argument to have a solution for the power state stuff
20:21 austriancoder: should nir_lower_bool_to_bitsize be used in the nir opt loop or after it?
20:30 austriancoder: maybe after nir_opt_algebraic_late
20:35 anholt: austriancoder: basically the last thing you do, iirc.
20:36 anholt: (should should have better optimization in your opt loop with 1-bit bools, and no further opt to do after the lowering)
20:43 austriancoder: anholt: thanks for the tipp
20:49 austriancoder:finds it from time to time quite hard to find the best sequence of ops and lowerings
20:52 jenatali: From time to time? :P
20:57 austriancoder: :) everytime a new opt pass gets added for instance
21:30 alyssa: genxml doesn't do typed unions it looks like?
21:34 jenatali: karolherbst: What's the status on your structurizer MR?
21:40 jenatali: 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:51 karolherbst: jenatali: I reworked the vtn bits now somebody needs to deal with the nir structurizer :p
22:52 karolherbst: at this point it's really only about getting the nir code into shape