08:22 MrCooper: llyyr: the display connection may be a factor, e.g. the KMS driver may need to use lower bpc or even sub-sampling due to bandwidth constraints
08:23 llyyr: MrCooper: shouldn't be the case for 1080p60 over dp 1.4 I'd imagine, and the problem shouldn't go away if the client does its own dithering to the user configured display bit depth either
08:23 MrCooper: true
08:24 MrCooper: sounds like a compositor or KMS driver issue then
08:24 llyyr: I did a bit of digging and I think the dithering done by both amdgpu and intel's drm driver is simply low quality enough that if you use an artificial sample you can tell the difference with your bare eyes
08:24 MrCooper: though it's worth checking the "max bpc" KMS property, for this external display connected via a USB-C dock it defaults to 8
08:26 llyyr: I've been testing with https://0x0.st/X0sf.mp4 in case anyone else wants to dig further
08:28 llyyr: actually, the driver dithering seems to only happen in direct scanout case, when it's not directly scanned out no (or low quality) dithering is done
08:29 llyyr: I don't know what would be the ideal place to submit a ticket for this, probably not mesa?
08:30 MrCooper: I'd start with the compositor
08:31 llyyr: happens on mutter/kwin/wlroots so...
08:32 MrCooper: very plausible :)
08:32 MrCooper: nobody might have thought about this issue before
08:33 MrCooper: I guess compositors might need to enable dithering when the client buffer uses a higher-bpc format than its compositing buffer, or something like that
08:36 llyyr: wouldn't the wsi be responsible for that? opengl doesn't even offer 16 bpc swapchain formats, so the issue is dodged there. this only happens if with vulkan
08:40 MrCooper: WSI can't know if/when dithering needs to be done
08:40 MrCooper: only the compositor can know
08:58 Company: opengl doesn't offer 16bit swapchain formats?
08:58 Company: it does here
08:59 Company: well, it offers 16bit fbconfigs, swapchains is a vulkan term I guess
09:01 pq: llyyr, would you happen to have a verbal description of what's in https://0x0.st/X0sf.mp4 so one could evaluate what they should or should not be seeing?
09:04 pq: llyyr, also copyright and license. If you believe that's a good test case, we could link to it from https://gitlab.freedesktop.org/pq/color-and-hdr or even host it if necessary.
09:07 llyyr: it's a yuv420p10 hevc file that contains 8 and 10 bit gradients for red, blue, black and grey. if the display doesn't support 10 bit depth and no dithering is done, you should see banding on the 10 bit gradients
09:08 llyyr: the license is https://creativecommons.org/licenses/by-nc-sa/4.0 but I don't see how it would be useful to host it in that repo
09:11 llyyr: The easiest way to show it is with mpv, set the following keybind in your input.conf: `A cycle-values dither-depth "16" "8"` and open the file with `mpv --gpu-context=waylandvk` and make sure mpv window isn't directly scanned out
09:12 llyyr: zoom in at the grey/black gradient if necessary then press "A" a few times. When dither-depth=16 (i.e. no dithering is done in mpv), you should see banding for the 10 bit gradient. When dither-depth=8, (mpv dithers to 8bpc), no banding
09:13 pq: llyyr, what you just wrote is exactly the kind of testing instructions for compositor developers we'd like to host. :-)
09:15 llyyr: ah I thought the repo was just for the color-management protocol development resources
09:15 pq: this is very relevant to that
09:16 llyyr: If you'd like to link to it then it's available here https://github.com/jursonovicst/gradient
09:16 pq: anything that is in any way related to color display or encoding is generally welcome
09:17 mripard: mairacanal: thanks for the vkms reviews
09:17 pq: llyyr, ah, excellent!
09:21 Company: pq: I use https://gitlab.gnome.org/-/snippets/6635 for that
09:22 Company: (you need a tiff viewer that displays floating point though, which is GTK and gimp
09:23 Company: (and gimp runs on 8bit only because it uses GTK2/3 + Cairo to display)
09:24 Company: getting the whole stack to do the right thing with >8bpc is tricky because there's a lack of testing with that stuff, and because it's hard to see when it's broken
09:24 Company: in normal operation I mean
09:25 Company: one needs special test content to check
09:25 pq: yup, which is why a documented testing procedure would be valuable.
09:25 Company: it's why I'm always asking for a way to take >8bit screenshots
09:26 pq: so, eog is the right tool to view that tiff?
09:26 llyyr: FWIW, it seems this problem exists on windows as well. I always thought this was a bug, but it could be plausible that nobody ever thought about >8bpc content across various platforms
09:27 pq: hm, my eog cannot handle it
09:27 Company: pq: I think eog and loupe can't handle it
09:27 Company: also, eog is GTK3 so would use 8bpc
09:27 pq: Company, what's the right tool then?
09:27 Company: if you have a recent enough GTK, gtk4-image-tool show high-depth.tiff should work
09:28 Company: if you have a build, it's in tools/
09:28 pq: I guess Debian stable is just too old for this.
09:28 MrCooper: llyyr: right, or some people might just not care outside of direct scanout
09:28 Company: I think you need 4.16
09:29 MrCooper: Debian has that in the libgtk-4-bin package
09:30 Company: MrCooper: considering that for a long time Mesa didn't even able 16bit/float framebuffers, I suspect there's not a lot of demand
09:30 MrCooper: *Debian testing
09:30 pq: MrCooper, ah.
09:31 Company: with all this hdr/high depth stuff, I'd recommend keeping a git checkout of GTK
09:32 Company: because we have bugs and if you run a release that's >3 months old we've forgotten about all those breakages already
09:33 Company: note: there's no need to install it, I use LD_PRELOAD for all my testing
09:34 pq: I'm not personally far enough to test GTK apps yet, but thanks for the reminder.
09:35 Company: GTK auto-switches to 16bit float fbconfigs if you load 16bit images btw
09:35 Company: and has done so for a few years
09:36 Company: nobody noticed that we turned that on
09:36 pq: cool
09:36 Company: apart from AMD users I think because they had a bug
09:37 Company: and some apps had accidentally stored their icons as 16bit pngs
09:37 Company: so if you were scrolling through app lists, your screen got garbled
09:37 Company: that was the only thing that happened
09:37 Company: everything else just worked
09:41 MrCooper: Company: FWIW, if GTK doesn't support "meson devenv" yet, that would make running using binaries from a build tree easier for everyone
10:07 Company: MrCooper: devenv is needed only for custom modules - that's IM modules and media modules - you can run most stuff fine straight out of the build tree
10:08 MrCooper: the point of meson devenv is not needing to worry about details like that
10:09 MrCooper: surely it needs to set e.g. $LD_LIBRARY_PATH at the very least
10:10 Company: I think meson plays games with linkage on Linux that makes it work without for in-tree stuff
10:10 Company: because I've never used meson devenv
10:11 Company: I only started making sure it works recently when I started working with VSCode on Windows
10:14 Company: it's one of the longer-term goals I have - making sure libgtk works as a standalone thing - because it's so convenient for hacking if it's just a single file
10:15 MrCooper: that can only work for binaries in the same build tree (presumably via rpath or something like that), not for other binaries using GTK
10:16 Company: yeah, other binaries need a devenv or LD_PRELOAD
10:22 Company: I still want static linking to work, so one can ship apps as a single .exe on Windows
10:22 Company: but not there yet
17:27 jenatali: Company: What color space are you using for fp16 fbconfigs?
18:26 DemiMarie: Are there any compositors that offer LTS branches?
18:26 DemiMarie: Nevermind, wrong chat.
19:45 soreau: emersion: can you clarify what you mean about SOB trailer?
19:47 emersion: soreau: oh, sorry
19:47 emersion: https://docs.mesa3d.org/submittingpatches.html
19:47 emersion: i thought DCO was required, but it seems not
19:47 emersion: https://developercertificate.org/
19:49 soreau: emersion: but in the test snippet, gbm_bo_create_with_modifiers() with linear or invalid returns a NULL bo
19:49 soreau: if I use NULL, 0), then it doesn't
19:49 emersion: yeah, that's expected
19:49 emersion: you can compare before/after
19:50 soreau: well the commit message still doesn't seem accurate "gbm_bo_create_with_modifiers({LINEAR}) returns a BO with gbm_bo_get_modifier() = INVALID"
19:50 soreau: is that only on cards with modifiers?
19:50 emersion: only on cards without modifiers
19:50 emersion: the expected behavior is return NULL for gbm_bo_create_with_modifiers({LINEAR})
19:51 emersion: IOW: if modifiers are supplied but the driver doesn't support these, GBM should return NULL
19:53 soreau: emersion: ok, I removed the part it doesn't address and moved the fixes line to the end
21:08 Ermine: DemiMarie: what do you mean by that?
21:29 DemiMarie: Ermine: a stable version that gets bugfixes backported for a couple of years
21:37 alyssa: would anyone complain if i symlinked `src/gallium/drivers/asahi` to `src/asahi/gl`
21:47 pac85: Maybe `src/asahi/gallium` would make more sense since it also does cl etc.
21:49 pac85: ~~Unless we decide gl stands for gallium from now~~
21:52 cmarcelo: alyssa: wouldn't that surface duplicates with grep and friends? would be too bad to move the contents itself there? or is there a reason to keep the asahi gallium bits inside src/gallium/drivers?
21:53 cmarcelo: alyssa: not against your symlink. just asking to understand more since I from time to time wish iris was a subdir of src/intel...
22:34 DavidHeidelberg: ... and Nine :D
22:34 jenatali: alyssa: How do git symlinks work on Windows?
22:40 dwfreed: https://stackoverflow.com/questions/5917249/git-symbolic-links-in-windows/59761201#59761201
22:45 jenatali: Ah ok. No objection from me then I guess
23:02 Ermine: How does one spell rusticl ?
23:07 bl4ckb0ne: rusticl i reckon
23:07 psykose: pronounce? like icicle but with rust in front
23:08 bl4ckb0ne: like testicle