04:37 MoeIcenowy: could someone take a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41532 ? (llvmpipe orcjit related)
06:33 lucaceresoli: marcf (Mark Filion?), melissawen, hwentlan__: I'm attending Display Next Hackfest next week, Friday only; is there an indication about the time slot duration available to present and discuss the topic?
06:33 lucaceresoli: Also, will there be a means to show a couple slides to support the discussion?
07:41 jani: airlied: that 7.0 in general or specifically 7.0.x stable?
07:49 airlied: jani: can't pinpoint since 7.0.x are being released one per atomic clock tick at this point
07:49 airlied: but it's likely we are seeing a lot of users moving from 6.19.x to 7.0.4 - 7.0.8 at least
07:50 airlied: there's also a chance it's not GPU related as well and something earlier in resume explodes, since I don't have lenovo p1g7 to play with
08:32 tjaalton: eric_engestrom: with 26.1.1 out, is 26.0.7 the final version of the 26.0.x-series?
08:33 jani: airlied: roger. I don't think we've seen this in CI, but I've posted this internally, let's see
08:46 jani: airlied: okay, so we've got a few reports within the last week about what seems to match your description. C10 PHY goes unresponsive.
08:56 airlied: jani: https://bugzilla.redhat.com/show_bug.cgi?id=2463170 has a dmesg in it, does it match?
08:56 airlied: i915 0000:00:02.0: [drm] *ERROR* Failed to bring PHY A to idle.
08:58 jani: airlied: yeah, that's it, there's also a gitlab issue with a link to your bugzilla
08:59 jani: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16042 https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16098 https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16064
09:01 jani: the first one has patches to try, each independently and then together
09:08 airlied: jani: I might try and make some test kernels tomorrow,
09:11 jani: airlied: I've pinged folks to put some more priority on this, although the reporters haven't been responsive to further questions or testing. I'm also a bit surprised we apparently didn't hit this in CI, I wonder what the difference is
09:56 valentine: logicalerzor: Please file an account verification request: https://gitlab.freedesktop.org/groups/freedesktop/-/work_items?sort=created_date&state=all&label_name%5B%5D=Account%20verification&first_page_size=20
10:09 valentine: np
10:25 karolherbst: Is there a way in vulkan to tell if a driver _always_ flushes fp16 denorms?
10:31 glehmann: karolherbst: no. if you want consistent denorm behavior, you have to request always flushing/preserving them
10:32 karolherbst: glehmann: yeah.. but for CL I kinda need to know so I can either flush or preserve, but I guess zink could do this: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41703/diffs?commit_id=5e5cd7fb034581ccb72fc81f94c70509ab536d3d#36a34260bbb8fb5c5978ce92be7578a512fd2f74_634_634 but I'm not happy about that
10:33 karolherbst: was wondering if there is a better way
10:33 karolherbst: or I add flags for "can preserve" and "can flush" ...
10:33 karolherbst: and deal with all the drivers
10:36 glehmann: if you do that, don't forget about VkShaderFloatControlsIndependence
10:38 karolherbst: yeah.....
10:38 karolherbst: I've had to deal with this, when I had to make zink use the spirv flags..
10:38 karolherbst: I'm just not looking forward to exposing the entire thing vulkan does through gallium...
10:38 karolherbst: but maybe I have to
10:39 karolherbst: _but_ at least for CL it's simpler
10:39 karolherbst: even "-cl-denorms-are-zero" is just a hint
10:40 karolherbst: so all I really need to know is whether the driver always flushes denorms
10:40 glehmann: do cl applications even work without fp16 denorms?
10:40 karolherbst: no idea :)
10:40 glehmann: there are ton of games that breaks with them
10:40 karolherbst: but we have drivers that always flushes them
10:41 karolherbst: so this is more about fixing CTS issues
10:41 karolherbst: at least in CL we can always preserve if we wanted to, even if we don't even advertise support for denorms
10:41 glehmann: I guess mobile hw?
10:41 karolherbst: yeah
10:41 karolherbst: freedreno prior 8xx
10:41 glehmann: because d3d12 requires fp16 denorms
10:41 karolherbst: (hardware also lacking real ffma 😭)
10:42 karolherbst: anyway atm rusticl does not advertize denorms, flushes fp32 ones and preserves fp16 and that's totally valid
10:42 karolherbst: but that sadly breaks in such hardware in subtle ways
10:42 karolherbst: *on
10:44 glehmann: in theory it would be better for amd hw to flush denorms because then we can use mad before gfx10 and we can use omod. in practice games don't like it 🙃
10:45 karolherbst: heh
10:45 karolherbst: but honestly, fp16 without denorms does feel a bit pointless
10:46 karolherbst: but I wanted to sort out the denorm mess sooner or later anyway
10:46 glehmann: are fp64 denorms required in cl?
10:47 karolherbst: yes, but fp64 is optional, soo...
10:48 karolherbst: I can just ignore it :)
10:48 karolherbst: some super precise physics simulation thing wants to use fp64 tho...
10:48 karolherbst: and also libreoffice calc for obivous reasons 🙃 so I'm kinda side eyeing on enabling fp64 properly, but yeah.. the denorm thing is a real mess
10:53 karolherbst: but yeah.. I need to rethink how zink sets the mode
12:24 lumag: mripard: gracious ping for https://lore.kernel.org/dri-devel/20260318-dsi-dsc-slice-per-pkt-v1-0-1bd66b7f9e0c@pm.me/
12:25 lumag: mripard: and also https://lore.kernel.org/dri-devel/20260513-hpd-irq-events-v3-0-086857017f16@oss.qualcomm.com
14:17 melissawen: lucaceresoli, no idea, I'm not involved in the organization. I also don't see Mark Fillion around. Perhaps daniels has more details.
14:18 lucaceresoli: melissawen: thanks, let's see whether daniels has info
15:45 daniels: lucaceresoli: hwentlan__ is handling the scheduling
18:12 lumag: mripard: another question. Is there a reason why drm_atomic_helper_duplicate_state() doesn't duplicate private objects?
23:20 pinchartl: airlied: could I get your ack to merge two drm driver patches through linux-media ? they're part of a cross-subsystem series (https://lore.kernel.org/dri-devel/20260511235637.3468558-1-laurent.pinchart+renesas@ideasonboard.com/). an Acked-by by e-mail would be appreciated
23:37 airlied: pinchartl: done
23:42 pinchartl: airlied: much appreciated, thank you