04:27 airlied: glehmann: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/43730 still failing a few tests
07:08 jani: airlied: dim does always use cherry-pick -x, simply for tracking and distinguishing the cherry-picked commit from the original
07:11 MrCooper: airlied: in the end Greg seemed to begrudgingly acknowledge that commit IDs not in Linus' tree are the lesser evil than not being able to keep track of fixes
07:18 mripard: rodrigovivi: yep, ack to merge these two patches through xe
10:32 MrCooper: daniels: "enable ALLM if there are no games on screen" seems backwards :)
10:34 daniels: MrCooper: we’re innovating here
10:35 MrCooper: carry on
11:25 glehmann: dcbaker: did this change recently? https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/util/process_shader_stats.py#L22
11:42 danylo: eric_engestrom Seems like zink-tu-a750 job random failures are caused by something going wrong in filesystem of the one of a750 devices, specifically SALAD.machine_id=9fae360f - a number of `shader_test`s are not being read correctly and fail with "[require] section missing"
11:43 danylo: Only device machine_id=9fae360f fails that job and fails it every time, while other devices seem to be fine
12:41 danylo: mupuf Maybe you have a quick way to at least remove the above misbehaving device before investigating it?
12:42 mupuf: danylo: I can wipe the drive, and the next job will start fresh
12:42 danylo: sounds good
12:43 mupuf: do you have a link to a job?
12:43 danylo: mupuf e.g. https://gitlab.freedesktop.org/mesa/mesa/-/jobs/107664238
12:55 mupuf: danylo: done, sorry for the noise!
12:56 mupuf: and indeed, the job passed fine on another DUT
12:56 danylo: thanks!
12:56 mupuf: let me know if you are having more issues with it. Hopefully it was just a corrupted drive
13:46 rodrigovivi: mripard: thank you! sorry to bug you, but we have one more: https://lore.kernel.org/dri-devel/20260810112008.1858731-5-riana.tauro@intel.com/
13:47 mripard: rodrigovivi: I don't see any link to the userspace using it, but otherwise it looks good to me
13:49 rodrigovivi: mripard: it is there: sudo ynl --family drm_ras --subscribe error-report
13:49 rodrigovivi: ynl tool is distributed in the linux tree
13:50 mripard: I'm not familiar with the RAS stuff, but it doesn't look like it's using it
13:50 mripard: just dumping it
13:56 rodrigovivi: the subscribe doesn't just dump... it keeps listening and dumping when the event happens... https://docs.kernel.org/userspace-api/netlink/intro-specs.html ...
13:56 rodrigovivi: when drm-ras was discussed we were planning to have an IGT tool as the userspace reference tool, but since netlink got this nice ynl tool itself we prefered to use that instead of duplicating with the IGT
13:58 mripard: I mean.. yeah. But the fact that it dumps and keeps dumping doesn't really change anything?
13:59 mripard: it's still not doing anything useful with it
14:50 rodrigovivi: mripard: there are 2 types of errors, uncorrectable and correctable... correctable ones were corrected and no action needs to be taken... it is only informative when passed the threshold... for uncorrectable we have 2 cases, driver already took care of those with some kind of reset or it wedged the device.... in both cases this drm-ras event is only informative... the reset doesn't need action, the wedged is the one sending the uevent
14:50 rodrigovivi: with recovery hints to userspace...
15:06 mlankhorst: tursulin: I think even reverts should probalby get some review and acks
15:07 mripard: rodrigovivi: my concern is that we document that, for any new userspace interface, we have the requirement that we have an opensource userspace implementation, and "The open-source userspace must not be a toy/test application, but the real thing. Specifically it needs to handle all the usual error and corner cases."
15:07 mripard: And it doesn't look like we meet that requirement there.
15:07 mripard: from what you're saying, it looks like there's no "real thing" at all, in which case I wonder why it was needed in the first place
15:10 rodrigovivi: well, ynl is less of a toy than the previously planned IGT would be or any other planned customer facing tool...
15:22 mripard: so, "it could have been worse" essentially?
16:14 rodrigovivi: yeap :( basically....
16:49 danylo: Would be good to get more feedback from people who work on NIR about enforcing argument evaluation order for ir builders which is necessary to produce same shader binaries between difference CPU architectures: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42132
18:00 mareko: it may be worth requesting a gcc option to make the order deterministic or not using gcc for debug
18:11 mlankhorst: rodrigovivi: still need an ack on that other patch?
18:14 rodrigovivi: mlankhorst: no, they are all merged, thank you
18:49 tursulin: mlankhorst: don't worry, acks were received on the mailing list I only did not put them in the patches when applying
19:05 rodrigovivi: mripard: for the record, I had ended up merged the patch even earlier accidentally, but I decided to keep since the previously agreed path was the ynl (in replacement to the IGT tool). But we also have the implementation ready and merged on the level0-sysman: https://github.com/intel/compute-runtime/commit/2dc88556599aad1432da0278237c3934edb73b02 ... I'm working with that team now to educate them and make their merge flow to get in
19:05 rodrigovivi: sync with our uapi requirements flow... with order and acks... and hopefully they will get to some distro sometime soon... Meanwhile, please let's continue with ynl as our open source reference
19:51 linkmauve: Hi, with anv running on Kaby Lake, and ANV_DEBUG=video-encode in the environment, I don’t get VK_KHR_video_encode_h265 exposed but I do get VIDEO_CODEC_OPERATION_ENCODE_H265_BIT_KHR in the queue’s videoCodecOperations.
19:51 linkmauve: Should it be supported?
19:51 linkmauve: And with radv running on Polaris, and RADV_EXPERIMENTAL=video_encode in the environment, I do get VK_KHR_video_encode_h265 exposed but there is no video queue.
19:52 linkmauve: I guess I do get why both are hidden behind an environment variable. :D
20:31 mlankhorst: tursulin: I understand, but it would be better for bookkeeping to apply them instead of forcing the tools, or your dim is out of date