03:22airlied: anyone else seeing nak builds fail with conflicts between nak_bindings and compiler about PIPE_FORMAT*
03:32airlied: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42109
07:11MoeIcenowy: Well it looks like http://www.x.org/docs/AMD/ is dead
07:11MoeIcenowy: seems that it's because of migration of x.org mainpage?
11:11melissawen: hi, about applying patches to `drm-misc-fixes`: I was applying a series with four patches all fixing something in kernel v6.18, but it was rebased on top of `drm-misc-next` and conflicted with three commits that are in `drm-misc-next` but not in `drm-misc-fixes`
11:12melissawen: so I sent a new version on top of `drm-misc-fixes`: https://lore.kernel.org/dri-devel/20260609110420.1298352-1-mwen@igalia.com/
11:12melissawen: so I can apply on top of `drm-misc-fixes`... is it the right way to go?
12:15dviola: just tried drm native context withi qemu and wow... impressive
12:15dviola: is virgl going away?
12:32mripard: melissawen: we're in the middle of the weird merge window phase where you have a "split" drm-misc-next, so it depends
12:33mripard: have the patches in drm-misc-next you need been sent in a PR to airlied and sima or not?
12:36melissawen: hmm.. I remember the drm_atomic_commit renaming yes, not sure about the others, lemme check
12:37mripard: melissawen: actually, I missed that you said it was fixing something for 6.18, then yeah, you did the right thing. Base them of drm-misc-fixes and merge that
12:37mripard: (and fix the conflict)
12:39Hazematman: MoeIcenowy: looks like you can still access it on wayback machine, if you're just trying to find a file. If you want it fixed probably worth messaging on #freedesktop and maybe creating an issue in https://gitlab.freedesktop.org/xorg/wiki
12:40melissawen: mripard, good, thanks for confirming
12:42Hazematman: If you try to access the links from here https://www.x.org/RadeonFeature/#documentation for any of the old stuff it links to AMD's documentation site which doesn't seem to have any of the old docs anymore
13:22MoeIcenowy: Hazematman: raise an issue
13:22MoeIcenowy: raised *
14:34alyssa: glehmann: Looking at ac:odyssey dxvk shaders I see a ton of `fma(+0, x, y)` with exact-math .. I don't suppose your recent work would fix that stuff?
14:36glehmann: not really, unless can nir_opt_fp_math_ctrl prove there are no NaNs involved
14:37alyssa: ack
15:55robclark: karolherbst: any strong opinions on pulling cl_ext_qcom.h into mesa and to implement some of the qc extensions? I've got some requests for a few qc extensions that various internal things use, to remove current dependency on blob cl.. Looks like we have cl_ext_intel.h although since that was added everything moved into cl_ext.h..
15:55karolherbst: robclark: I prefer there to be testing for those
15:56karolherbst: but yeah.. nothing against implementing vendor extensions in principle except that those normally don't really have great testing
15:56robclark: heh, there are a couple I'd be happy even w/ ext spec.. but I suppose adding piglit tests as I go could be done
15:56robclark: yeah
15:56karolherbst: not sure what's the stance in the official CL CTS to add tests.. it does test some ext extensions tho
15:57robclark: not sure either.. but at least we have piglit cl coverage in CI..
15:58karolherbst: yeah.. better than nothing.. kinda depends on the ext, maybe could also write rust tests... it's just problematic once the extensions also advertise hw features...
15:59karolherbst: robclark: are those extensions publicly documented?
16:00robclark: some are, that I've found so far
16:00karolherbst: and which ones are interesting here?
16:01robclark: cl_qcom_reqd_sub_group_size I couldn't find docs, but maybe we can substitute the intel version.. but maybe a bit awkward bc tons of stuff has #ifdef ADRENO / #ifdef INTEL type stuff
16:01karolherbst: mhhhh
16:01karolherbst: soooo
16:01robclark: there is a CP_CONTEXT_PERF_HINT_QCOM which is documented (and kinda simple/dumb)
16:02robclark: some other things like CL_PROGRAM_DISASSEMBLY_QCOM which isn't really documented but doesn't take too much imagination about what it does
16:02karolherbst: there is also an intel version of reqd_sub_group_size
16:02robclark: right
16:02karolherbst: I _think_ we already have everything we need for it...
16:03robclark: the qc version of that one looks only superficially different.. but idk if there is more to it
16:03karolherbst: well `CP_CONTEXT_PERF_HINT_QCOM` can probably be ignored, so if it's just to make the runtime not throw errors, that's always fine to add
16:03karolherbst: we kinda want a ext/khr version of it sooner or later anyway
16:03robclark: we probably should throw an error for hints other than HIGH?
16:03karolherbst: if it's a hint, we should just ignore it
16:04karolherbst: or do something with it if we can
16:04karolherbst: CP_CONTEXT_PERF_HINT_QCOM is just scheduling prio?
16:04robclark: it's documented to return error if perf level not supported... and HIGH is the default
16:04karolherbst: ohh it's about hw perf levels?
16:04karolherbst: mhhh
16:04robclark: yeah, probably poking at devfreq max clk, ig?
16:05karolherbst: I've implemented cl_khr_priority_hints recently
16:05karolherbst: but not sure if that covers it
16:05robclark: hmm, ok.. that might be an acceptable replacement
16:06karolherbst: no idea if the qc driver does something differently there or not..
16:11cwabbott: robclark: there's userspace clock control in kgsl so I assume it's connected to that
16:11cwabbott: it's crazy
16:12cwabbott: it's called "constraints" in kgsl iirc
16:12cwabbott: we stumbled upon it when trying to figure out why we were so much slower than the vk blob... turns out they try to do clock management in userspace
16:13robclark: hmm, fun
16:15karolherbst: could add gallium interfaces for it if you care enough
16:16dj-death: it's like the GuC low latency mode thing on i915/xe ;)
16:17robclark: there isn't (yet) any kernel UABI, so first step would prob be to just accept PERF_HINT_QCOM=HIGH and throw an error on the rest
16:30karolherbst: CL 3.1 CTS got finally merged :') so gonna get that out of the way (finally)