10:32 tzimmermann: melissawen, the new colorops are designed for HDR AFAIU. is it possible to implement some of the interface it with older hardware that only offers an SDR gamma lut?
10:40 melissawen: tzimmermann, compositors have enabled HDR before colorop being supported, only with the CRTC color mgmt matrix/LUTs, but they are using shaders for plane color mgmt... because there is no interface to use pre-blend hw blocks
10:41 melissawen: but LUT is just LUT, right? the only limitation would be its precision
10:44 tzimmermann: melissawen, for example, the ast driver exposes a gamma LUT on the CRTC. the hardware actually implements this on the primary plane. preferably, I'd expose the feature as colorop and have compositors implement gamma in top of that. DRM_COLOROP_1D_LUT looks like the right thing. is that supported?
10:45 melissawen: so an "HDR-standard" curve can be programmed in this LUT
10:45 tzimmermann: what is a "hdr-standard curve" ? the HW supports a gamma table with 256 entries for each channel
10:46 melissawen: tzimmermann, ah, okay, yeah, it would be, but CRTC/post-blend colorop isn't supported yet
10:46 daniels: but if it's implemented on the primary plane, it wouldn't be a CRTC op?
10:46 tzimmermann: the ast hardware has no post-blend features AFAIK, so that's not an issue
10:47 zamundaaa[m]: tzimmermann: if the lut doesn't apply to all planes, having it on the crtc would be a bug anyways. So, yeah, put the plane lut on the plane, and compositors will use it when possible
10:48 tzimmermann: daniels, the HW technically implements gamma LUTs on the plane. the driver exports it as old-style gamma lut on the CRTC. there are no other planes, so it looks correct in practice
10:51 tzimmermann: zamundaaa[m], ok, sure. there's only that one plane, so having it on the CRTC works on practice. the LUT currently provides nightmode and gamma correction. i would not want to switch to th enew interface unless I'd know that current compositors still support these use cases
10:52 zamundaaa[m]: tzimmermann: if there's only one plane, I'd maybe leave it on the crtc. At least KWin currently only uses post-blend lut for these things
10:53 tzimmermann: i see
10:53 tzimmermann: thanks
10:55 melissawen: zamundaaa[m], BTW, is a 256-entry LUT useful for programming HDR curve?
10:57 zamundaaa[m]: swick: for direct scanout KWin 6.8 will do it too, but with compositing + night light that's a little complicated atm
10:58 zamundaaa[m]: melissawen: it depends on what kind of curve you program. I *think* for KWin's gamma22->PQ it might just barely be ok
10:58 melissawen: tzimmermann, about the HDR-standard curves, I was talking about PQ/HLG that some hw vendors support it in the hw, or "translate" it to LUT, as AMD
10:58 daniels: melissawen: I can assure you that no-one is attempting to do HDR on ASpeed hardware
10:59 zamundaaa[m]: But yeah, for the PQ transfer function it's not enough :)
10:59 melissawen: I see :)
10:59 daniels: not only is it server-class hardware (used for BMCs), it's also 1992-class hardware (can do TTY and maybe a cursor if you're really brave)
10:59 tzimmermann: this ^
11:00 tzimmermann: my question wasn't so much about HDR, but rather it there's a place for old SDR functionality in the new interfaces
11:01 tzimmermann: i wouldn't want to use the lagacy gamma lut if there's a newer interface available
11:01 tzimmermann: 'interface' as in 'uapi'
11:03 pq: nice to get pinged when people talk about HDR ;-)
11:05 zamundaaa[m]: tzimmermann: in terms of porting to new interfaces, the post-blend color pipeline is an option for that
11:06 zamundaaa[m]: But it wasn't merged yet afaik
11:07 melissawen: I see... as post-blend isn't supported yet, we still use CRTC color mgmt props and I think those props will only be deprecated if you enabled colorops... for you gamma LUT, DRM_COLOROP_1D_LUT is the colorop you will need if you want to migrate to it, it's not designed to HDR
11:07 melissawen: it's designed to be flexible enough to expose hw caps correctly
11:07 melissawen: or I hope so :)
11:11 pq: tzimmermann, there is no difference with SDR and HDR functionality, as in, something would be fit for HDR but not SDR. Range and precision are important though, so it is possible that something is not fit for some use case - but that is again irrespective of SDR vs. HDR and everything about what exactly userspace is doing.
11:12 pq: oh dear I worded that poorly....
11:16 pq: SDR vs. HDR difference exists only in monitor signalling, how the video signal should be decoded by the monitor or the panel. There it's not binary either, we have many orthogonal variables with more than two values each. In the KMS color processing, it's all about precision and range for a specific use case, and use cases are not binary SDR-or-HDR.
11:40 tzimmermann: i see. that's an interesting discussion. thanks for the insights
11:42 tzimmermann: maybe i'll prototype the patch to see happens. until compositors support it, there's no point in changing the ast driver
11:46 zamundaaa[m]: swick: good question
11:50 zamundaaa[m]: Also, what happened to the yuv colorop stuff?
11:54 pq: is swick[m] talking here? I saw he joined, but no messages.
11:56 swick[m]: test?
11:56 pq: swick[m], works!
11:57 swick[m]: the matrix bridge is quite annoying. I asked why the post blend KMS color pipeline patches have no been merged yet.
11:58 pq: I'm somewhere between 120 - 8000 emails behind on dri-devel@...
12:03 zamundaaa[m]: Looks like https://lists.freedesktop.org/archives/dri-devel/2026-August/586702.html is the latest on the fixed matix prop
12:06 zamundaaa[m]: And https://lists.freedesktop.org/archives/dri-devel/2026-July/582421.html for the post-blend pipeline
12:25 melissawen: swick[m], lack of kernel review for post-blend. I see Robert is experimenting on Weston and I drafted on gamescope, so there is userspace usage at least. But yeah, I think fixed matrix should come first
17:03 melissawen: tzimmermann, mripard, mlankhorst: I want to apply this fix series to drm-misc-next-fixes, but dim is telling me I don't have commit-rights: https://lore.kernel.org/dri-devel/20260826104143.39077-1-mwen@igalia.com/
17:03 melissawen: dim is also telling me I should not apply to drm-misc-fixes because the bug isn't there yet
17:03 melissawen: where should I apply?
17:07 melissawen: or just wait for the merge window to close... >.<
17:08 tzimmermann: melissawen, drm-misc-next-fixes is likely closed. we only keep it open near the end of the release cycle.
17:09 tzimmermann: it it's not a P1 bug, the easiest solution is wait until next week and put the fix into drm-misc-fixes
17:12 melissawen: oh, got it. I'll wait then. Thanks!
17:26 mareko: zmike: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/43757
17:27 zmike: 🤔
17:36 daniels: melissawen: heh, we were waiting for more userspace to progress it, then summer holidays / leave kicked in :) if review is all we need then we can do that now easily
21:31 macromorgan: so question (guessing someone here might know)... when a display panel is rotated 90 degrees and uses the "rotation" devicetree property, should a touchscreen's 0,0 be before or after the rotation is applied?
21:45 karolherbst: so I got an email from somebody at khronos in regards to kosmickrisp and some third party project using it to create a conformant environment on macos.. who should I forward this email to? asking because I am not the right person to deal with that I suppose
21:47 zmike: probably lunarG
21:51 karolherbst: oh right.. we have email address in the git log 🙃
22:34 sghuge: konstantin: pixelcluster: Can we mark the geometry as inactive if we see bounds or vertices +INF/-INF? currently we are just marking them as inactive if it's NaN.
22:35 sghuge: or is it getting filtered but I am not seeing explicitly where?
22:44 pixelcluster: sghuge: the original rationale for not marking them as inactive was that "inactive" is a concept defined by Vulkan and a primitive is only inactive if it contains NaNs
22:44 pixelcluster: this is relevant for updates because by spec, apps aren't allowed to make inactive prims active (aka have a NaN prim in build and a non-NaN prim in update) and vice versa
22:45 pixelcluster: however if I remember correctly for updates we handle it differently now
22:45 sghuge: pixelcluster: ah I see. that make sense!
22:45 pixelcluster: because games aren't bound by trivial babble like API specs or valid usage rules
22:45 pixelcluster: :^)
22:45 pixelcluster: so maybe it's worth revisiting actually
22:47 pixelcluster: though then there's the question if you really want to filter primitives just because there's an inf
22:47 pixelcluster: (for example, what if you have a primitive with minX = -inf, maxX = +inf? shouldn't rays hit that in general?)
22:48 pixelcluster: it's a bit of a corner case of the spec and i'm not sure how much can actually be relied on with such things
22:48 pixelcluster: i just remember dealing with the topic at some point because we need to explicitly remove inf values on some hw
22:49 sghuge: I was reading some internal documentation for Intel, and they treat any +INF/-INF or NaN as inactive at traversal level..they just reject it. (Might have to read it closely)
22:49 pixelcluster: right I guess then all bets are off anyway
22:49 sghuge: so I looked at the leaf.h and I saw, we are just rejecting or marking inactive for NaN cases.
22:49 pixelcluster: fwiw the solution I went with in radv is https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/amd/vulkan/bvh/encode.comp#L226
22:50 pixelcluster: i.e. clamp to the largest non-infinite value
22:50 pixelcluster: that should make things like minX=-inf; maxX=+inf work while keeping the hw happy
22:52 sghuge: ACK!
22:52 sghuge: let me read the amd/encode.comp. Thanks for the ref.