06:32airlied: glehmann. karolherbst : difference between 40TFlops and 114TFlops with workgroup scope test was making shared matrix row stride 80 bytes instead of 64 to get better bank selection
06:32airlied: at least on radv, no idea what will be optimal elsewhere
07:12Daanct12: for a panel where it was wrongly defined in the first place (in this case, we have power-supply and enable-gpios, which doesn't make sense for this display), should i keep the values deprecated or remove it entirely?
07:13Daanct12: in the device tree
07:47cborah: vsyrjala, tzimmermann: Any thoughts on https://lore.kernel.org/igt-dev/20260506082242.2605199-1-chaitanya.kumar.borah@intel.com/ ? I know it's not very ideal but I could not find anything else that would work better for a multi-head setup. Open for suggestions :)
10:52glehmann: eric_engestrom: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41661 would be nice to have in 26.1.1 because it fixes native unity and unreal games
10:53glehmann: it would have made it in time if not for the riscv thing
10:55eric_engestrom: yeah that's my fault for being too quick to think it was fixed 😅
10:55pinchartl: Venemo: amdgpu.dcdebugmask=0x610 helps. I haven't seen the issue since I enabled it
10:55pinchartl: so what's next ? :-)
10:55Venemo: pinchartl: awesome. next is to check which bit it is that solves your problem. could be either 0x400 or 0x200 or 0x10
10:56eric_engestrom: glehmann: I actually already started the release process for 26.1.1, is it ok if it waits for 26.1.2, or is the breakage very wide-spread?
10:57eric_engestrom: (aka is it just one obscure game, or all unity & unreal games?)
10:57glehmann: currently, there is a bug report for one unity game, one unreal game, and the unreal editor in general
10:58glehmann: so I think it's wide spread
10:58eric_engestrom: :/
10:58eric_engestrom: ack, I'll wait for it to be merged then
11:11pinchartl: Venemo: I'll check that, thanks
11:16mripard: sima: hey, if you feel like it, could you have a look at https://lore.kernel.org/r/20260423-drm-state-readout-v2-0-8549f87cb978@kernel.org and let me know if that's what you had in mind, design-wise?
11:40bbrezillon: mripard: Hey! broonie keeps asking me to have topic branches for drm-misc-fixes/drm-misc-next conflicts. Am I doing something wrong to resolve conflicts with dim?
11:41bbrezillon: What I don't get is why all drm trees are pulled separately if we're already doing the work to combine them in drm-tip
12:09mripard: bbrezillon: you'll have to ask him, but he should not be pulling from either, we have a for-next branch meant to be just that
12:23sima: bbrezillon, topic branches for everything that conflicts is the classic maintainer approach, it doesn't scale well with committers
12:23sima: so that's why we do substantially less topic branches than any other subsystem
12:23sima: and just deal with the conflicts with dim
12:23sima: except linux-next doesn't participate in that and as a result, suffers
12:24sima: I've discussed this almost a decade ago with sfr, and he said he can cope
12:25sima: bbrezillon, the issue is that drm-tip contains a bunch more stuff than what should be in linux-next, so it's complicated
12:44bbrezillon: sima: okay. Mind chiming in to explain that?
12:45bbrezillon: ("[PATCH v4] drm/gem: Make the GEM LRU lock part of drm_device" is where this discussion is happening)
18:32alyssa: karolherbst: "what(): Unknown OpenCL version: OpenCL 3.1" /o/
18:32alyssa: I guess I need a new CTS :p
18:34alyssa:presses big red button
18:34karolherbst: :D
18:34karolherbst: there is a PR
18:34karolherbst: alyssa: https://github.com/KhronosGroup/OpenCL-CTS/pull/2690
18:35karolherbst: oh yeah.. somebody should review my asahi MR to fix a bunch of stuff...
18:39alyssa: karolherbst: cherrypicked, thx
18:40alyssa: karolherbst: a-b not that i've reviewed or tested it (:
18:40alyssa: jannau: ^
18:40karolherbst: Mary wanted to review it as well https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41386
18:41karolherbst: alyssa: have you looked into why mathbruteforce is broken for threaded runs on intel? or is that resolved with jay
18:42karolherbst: haven't really looked into it, just know that something is broken there
18:44alyssa: karolherbst: haven't looked & it's broken with jay
18:44alyssa: afaik
18:44karolherbst: mhhh
18:44karolherbst: could be related to mapping the same resource from multiple threads, but I haven't really verified anything there.. maybe I get to it soonish..
18:44alyssa: `basic vload_private` is failing on both brw&jay after my CTS uprev /o\
18:45karolherbst: mhhhhhhhh
18:45karolherbst: what types?
18:45karolherbst: or generally?
18:46karolherbst: but maybe I should uprev locally as well...
18:47karolherbst: oh wow.. my ffma MR merged on first try.. I'm surprised
18:49karolherbst: alyssa: well it passes here
18:49alyssa: wild
18:49alyssa: long2
18:50HdkR: You've heard of long, but have you heard of long2?
18:50karolherbst: did you test on a discrete GPU or embedded?
18:50karolherbst: ehh I guess integrated is the right term here
19:54airlied: jani: seeing a lot of chatter about 7.0.x on Fedora regression dpms or suspend/resume with meteorlake
19:57airlied: jani: lenovo p1 gen 7 seems to an example machine
20:18karolherbst: I just debugged the most horrible bug and you all have to know: so apparently nextafter is broken for fp16 on hw that always flushes denorms. Big deal, maybe something broken. Turns out... the code breaks if the driver lowers 16 bit float compares to 32 bit and then instead of fcanonicalize@16 (that would get not optimized away due to flush to zero
20:18karolherbst: mode) gets turned into a fcanonicalize@32 with a different denorm flushing behavior and the assumptions of nir_nextafter just fall apart at that point (it's implemented as +/-1 on the float value basically, with some handling for exceptional values)
20:36jenatali: :O
20:45karolherbst: yeah not entirely sure that's all there is to it... and if I'm really hitting the case, but that would for sure mess things up
20:45karolherbst: zink just removes the "preserve denorms for fp16" shader flag silently, so that's also great 🙃
20:46zmike: yw
20:48karolherbst: ~~might have to force softfloat~~
20:48karolherbst: but dunno how to deal with it... like
20:48karolherbst: not that it matters
20:49karolherbst: at least always preserving denorms is legal in CL, so whatever really
20:50glehmann: karolherbst: maybe you are lucky and https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41687 fixes it?
20:51karolherbst: oh it does
20:51karolherbst: but it's also +9 instructions or so
20:52karolherbst: I don't think the code is _wrong_ in itself, just something gets in the way
20:53glehmann: does anything besides cts even use nextafter?
20:54karolherbst: good question :)
20:54karolherbst: but my point is more that I don't see a problem with the impl itself
20:54karolherbst: and something else is wrong
20:54karolherbst: like I wish to understand what's broken/wrong there