06:30 wens: are drm/exynos patches merged through drm-misc or a separate tree? I see two entries in the MAINTAINERS file.
06:37 airlied: usually the exynos tree
06:46 wens: I see, the double entry was a bit confusing
07:26 MrCooper: kusma: your "Open Source and AI" blog post expresses my thoughts on the subject better than I could have myself, thanks!
07:43 pq: zmike, thank you very much for fixing the llvmpipe LastFragData!
08:54 mripard: airlied: sima: mlankhorst: tzimmermann: any opinion on https://lore.kernel.org/r/20260326-drm-drm-atomic-update-v1-0-2f7af5f4ad02@kernel.org ?
08:57 tzimmermann: mripard, well, ok
08:57 tzimmermann: mripard, the canonical name would be transaction
08:58 mripard: that's what sima suggested
08:58 tzimmermann: although that might over-sell it a bit
08:58 mripard: but the todo was "commit" :)
08:58 mripard: so I took the middle road ignored both equally :p
08:58 mripard: I'm ok with transaction too
08:58 tzimmermann: :D
08:59 sima: same, either is a massive improvement over the current situation
08:59 tzimmermann: the thing with transaction is that is doesn't really say what transaction. would that be clear from the context of drm?
08:59 sima: also historically drm_atomic_state was just a state and used clever tricks to make it a commit
09:00 sima: turned out the tricks where too clever and explicit old/new states so much better design
09:00 sima:did a little mistake
09:00 sima: tzimmermann, hm yeah I think commit is a bit more established within the context of kms than transaction
09:00 sima: either way, a-b: me
09:01 tzimmermann: there is an atomic_update callback already. having drm_atomic_update seems misleading
09:01 mripard: I'm fine with commit as well, but is there a concern with drm_crtc_commit?
09:01 tzimmermann: how about "struct drm_state_update" ?
09:02 tzimmermann: mripard, its not just 'crtc'
09:02 sima: mripard, that one is also about tracking an atomic commit, so I think that's actually bonus for consistency
09:03 sima: I've added drm_crtc_commit so that a generic nonblocking helper implementation is possible
09:03 mripard: ok, so we all agree to use drm_atomic_commit then?
09:03 tzimmermann: i can live with that
09:03 mripard: awesome
09:03 sima: not entirely awake, maybe collect a few more acks from big driver kms people
09:04 tzimmermann: a-b: me
09:04 sima: but yeah, sounds like the most fitting
09:04 sima: but I'm a-b: me on any of transaction/commit/update really, all better than the current one
09:04 mripard: I know pinchartl had opinions too :)
09:04 mripard: and I'll send a new version with drm_atomic_commit anyway, we can gather a-b there
09:04 sima: for merging probably best if airlied pushes it onto drm-next after -rc6/7 when all the big -next pr have landed
09:05 sima: that's probably the least painful point
09:05 sima: mripard, aye
09:05 mripard: that was my next question
09:05 mripard: sounds good to me
09:05 mripard: I'll send it today
09:05 mripard: thanks :)
09:05 sima: mripard, yeah don't have a better idea, but also good excuse to get acks from the other subtrees (msm, intel-display, amd) so they're at the ready for the asap backmerge
09:28 pinchartl: mripard: apparently I have opinions on everything :-)
09:29 pinchartl: I think I have a slight preference for commit, as it matches the UAPI naming
09:29 pinchartl: but I won't bikeshed much
09:36 tzimmermann: PSA: With -rc6 tagged, drm-misc-next-fixes is now open. Features still go into drm-misc-next. Fixes for v6.19 or stable go into drm-misc-fixes. Fixes for v7.0 go into drm-misc-next-fixes. Patches in -fixes branches should be small and have a Fixes tag.
12:12 zmike: pq: 🤝
13:06 MrCooper: pq: I'm thinking more and more that the "max bpc" property really isn't suitable for the stated use case (RGB vs YCbCr), instead what's really needed there is a property to explicitly control the bpc?
13:08 MrCooper: no need to guess what the intent was for setting "max bpc" to a given value then
13:13 pq: MrCooper, I've been ignoring 'max bpc' because it's completely unrelated.
13:14 MrCooper: it's currently required for the stated use case
13:14 daniels: well, it's part of it
13:14 pq: it is programmed IIRC, but not required
13:14 MrCooper: there's no other way to control bpc
13:14 pq: there is no need to control bpc for this use case
13:15 daniels: the usecase isn't specifically to log a warning - the usecase is to enable control UI to be able to have a feedback loop and take better decisions on resolution / refresh rate / colour model
13:15 pq: daniels, weston cannot do anything but log, though.
13:15 MrCooper: and it logs only if the user sets a value for "max bpc"
13:16 daniels: i.e. if you can hit 4k60 with no subsampling only by cutting down to 6bpc, the user (or media playback control) may decide that it would be better as a matter of policy to try 4k60+YUV422 to see if it will look less terrible, and if it still doesn't get any joy out of that, to pull down to 1080p
13:17 daniels: there's no universally-correct answer, hence why the kernel can't 'dtrt' - but if userspace has no idea what the kernel is even doing, it's impossible for userspace to tell the kernel what the right thing would actually be
13:17 pq: MrCooper, if you read my comments in the Weston MR, I have asked to not use max_bpc for that but add a new "desired bpc" settings.
13:18 MrCooper: then we agree on that; trying to (ab)use "max bpc" for something it's not intended for is something that bothers me about this
13:18 pq: yes!
13:18 daniels:shrugs
13:19 MrCooper: that would also largely side-step the issues we've been discussing — either the kernel can make the requested bpc work, or the atomic commit fails
13:19 daniels: I agree that max bpc is not what we'd ideally have as the sole control mechanism; otoh it's hard to say that we shouldn't have a feedback mechanism for the control mechanism that we do actually have upstream, and that it can only come with a control mechanism which can express quite a few different orthogonal things
13:22 MrCooper: the thing that bothers me the most is that the weston MR implies the "link bpc" value is expected to match the "max bpc" one
13:22 pq: daniels, there is nothing to argue anymore. The Weston MR just needs the changes I suggested ages ago.
14:44 mripard: pinchartl: tzimmermann: sima: new version of the patches sent
17:00 CounterPillow: vsyrjala: huge thanks for the i915 refactor series, with the YCBCR444 changes I sent as a review in response I was then able to reimplement "color format" on i915 with just two switch statements and the property registration. This should make my i915 patch in the next revision way easier to review.
17:06 alyssa: dschuermann: gfxstrand: Does it make sense to ban infinite loops in (lowered) NIr?
17:06 alyssa: (Like guarantee we DCE them in nir_opt_loop or something)
17:06 alyssa: This would probably eliminate special cases in multiple backends and statically infinite loops are UB anyway
17:11 alyssa: as always doing anything with loops in NIR is annoying, but it's probably less code there than the workaround in backend
17:15 glehmann: I think nir_opt_dead_cf already removes them?
18:42 alyssa: glehmann: maybe I'm not running that..? :/
18:43 alyssa: glehmann: no I don't think that handles this case
18:43 alyssa: since that bails if there are phis after the loop
18:43 alyssa: or something like that
18:45 glehmann: but why would there be phis after an inf loop?
18:45 alyssa: i'm not sure why that pass isn't working here actually
18:45 alyssa: but dEQP-VK.reconvergence.subgroup_uniform_control_flow_elect.compute.nesting2.0.32 has an example
18:46 alyssa: the second loop in there (block 9 for me) is statically infinite and dynamically dead
18:47 alyssa: Ah
18:47 alyssa: It doesn't kick in because there are side effects.
18:48 alyssa: right so node_is_dead() needs to ignore side effects / calls if the loop is statically infinite
18:49 alyssa: I think the phis and def-only-used-in checks are ok because of SSA dominance rules and the lack of a break
18:50 glehmann: one issue is that iirc inf loops with terminate are valid
19:49 alyssa: ...........Awesome.