01:48 robclark: karolherbst: btw, test_basic work_item_functions_out_of_range and work_item_functions_out_of_range_hardcoded .. I guess those are llvm spriv translator bugs? Idk if you are tracking those? With a pending MR (because 16b NaNs suck) those are my last two test_basic fails
06:40 karolherbst: robclark: correct
06:40 karolherbst: I closed the bug report on this yesterday :D
06:40 karolherbst: robclark: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/pull/3023
07:03 karolherbst: robclark: I wonder if the 16b bug is a CTS bug...
07:09 karolherbst: at least for CL_FLOAT it states: "NaNs may be converted to a NaN value(s) supported by the device."
07:09 karolherbst: wondering if it was forgotten to be specified for CL_HALF_FLOAT as well
07:10 karolherbst: but generally I don't see that an implementation is required to keep the numeric value of the NaN
07:14 karolherbst: I'll file an issue asking for clarification
07:17 karolherbst: mhh but this is an API function, where it doesn't matter what the CL C spec says
07:43 mlankhorst: Forgot to protect drm-misc-next-fixes, done so now. :)
07:51 dolphin: sima, airlied: sent drm-intel-fixes PR, just two picked up by tooling until today (this is short week in here)
09:37 mlankhorst: Midsommar!
09:45 jfalempe: mlankhorst: I've sent the drm_panic v10 without static variable. I'm trying to adapt your vram patch, but I'm wondering how I can add a struct xe_res_cursor to the struct intel_framebuffer?
09:56 mlankhorst: need to think on that
09:56 mlankhorst: would likely just be an allocated struct by xe instead, so it can differ from i915 and xe
11:04 lucaceresoli: hello, a gentle ping for https://patchwork.freedesktop.org/series/149581/
11:04 lucaceresoli: it's the last missing piece for the full conversion to devm_drm_bridge_alloc(), and it is the one patch blocking several other series from being sent
11:04 lucaceresoli: it is R-by lumag but I don't think this is enough for applying
12:38 robclark: karolherbst: for 16b NaN, I do have a workaround which isn't too horrible
12:38 karolherbst: yeah, I saw
12:38 robclark: karolherbst: does that PR also fix work_item_functions_out_of_range? It seems there needs to be some bounds checking somewhere
12:38 karolherbst: still a bit annoying
12:38 karolherbst: robclark: yeah
12:38 robclark: cool, thx
12:38 karolherbst: that PR adds bound checking to those CL builtins
12:39 karolherbst: in CL C they define OOR behavior, in SPIR-V they do no
12:39 robclark: 👍
15:35 jfalempe: mlankhorst: I've made a small test to pre-allocate a panic struct, so it can be different between xe and i915 : https://paste.debian.net/1380736/ (on top of v10)
17:33 lumag: narmstrong: ping https://lore.kernel.org/dri-devel/20250608-fix-aud-hpd-bridge-v1-1-4641a6f8e381@oss.qualcomm.com/
17:36 lumag: narmstrong: and https://lore.kernel.org/all/20250220-panel_prev_first-v1-1-b9e787825a1a@linaro.org/
19:34 mlankhorst: jfalempe: Yeah, seems useful. Perhaps make it a struct intel_panic_data *panic; Both drivers can define their own struct for that. :)
19:35 mlankhorst: They don't have to agree on what intel_panic_data looks like
19:35 mlankhorst: struct intel_panic_data; struct intel_panic_data *panic;
21:09 jfalempe: mlankhorst: ok, that will avoid some casts.
21:19 zzyiwei: robclark: wonder if you or anyone can help rb/ab the rest in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35561 Thanks!
21:22 robclark: I can look at the tu part.. just been busy
21:26 zzyiwei: (ㅅ´ ˘ `)
21:29 robclark: zzyiwei: very much a-b for removing code.. I'm just going to have to trust you on the android bits because I don't really have a way to test that atm ;-)
21:30 zzyiwei: Cool, no worries about that ; )
21:31 robclark: I guess you might have to hack some ebuild (I did, last time I built ToT mesa for arcvm, not too long ago), but other than that I guess it isn't too hard to sanity test on your end
21:57 zzyiwei: robclark: i did that once before, and so far the ebuild stuff is surprisingly robust. At least for the past year, I didn't have to touch a single line there (when testing ToT venus)
21:57 robclark: hmm, istr that some updates were needed for meson build option changes?
21:59 zzyiwei: nothing affects us (at least for venus). I didn't check the freedreno side but you had kept that pretty close to ToT previously.
22:02 zzyiwei: ah..looks like someone else has done the update while i was on pat leave: https://source.chromium.org/chromiumos/_/chromium/chromiumos/overlays/chromiumos-overlay/+/b47f08e297d54377ded2d6bee39835178ff1162a