kts has quit [Read error: Connection reset by peer]
bmodem has joined #dri-devel
kts has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
marc2377 has quit [Remote host closed the connection]
epoch101_ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
epoch101_ has quit []
jsa has joined #dri-devel
kts has quit [Quit: Leaving]
marc2377 has joined #dri-devel
epoch101 has joined #dri-devel
Haaninjo has joined #dri-devel
karenw has quit [Ping timeout: 480 seconds]
bmodem has quit [Quit: bmodem]
Duke`` has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
javierm has quit [Ping timeout: 480 seconds]
epoch101 has quit []
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
cascardo has quit [Ping timeout: 480 seconds]
cascardo has joined #dri-devel
pixelcluster has quit [Quit: Goodbye!]
heat has joined #dri-devel
rgallaispou has joined #dri-devel
fab has joined #dri-devel
glennk has joined #dri-devel
tzimmermann has joined #dri-devel
frieder has joined #dri-devel
jfalempe has joined #dri-devel
frieder has quit [Remote host closed the connection]
frieder has joined #dri-devel
jkrzyszt has joined #dri-devel
<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
<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
<MrCooper>
true
<MrCooper>
sounds like a compositor or KMS driver issue then
<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
<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
<llyyr>
I've been testing with https://0x0.st/X0sf.mp4 in case anyone else wants to dig further
<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
samuelig has quit []
<llyyr>
I don't know what would be the ideal place to submit a ticket for this, probably not mesa?
samuelig has joined #dri-devel
<MrCooper>
I'd start with the compositor
rgallaispou has quit [Ping timeout: 480 seconds]
<llyyr>
happens on mutter/kwin/wlroots so...
<MrCooper>
very plausible :)
<MrCooper>
nobody might have thought about this issue before
<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
javierm has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
<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
apinheiro has joined #dri-devel
u-amarsh04 has joined #dri-devel
u-amarsh04 has quit [Remote host closed the connection]
<MrCooper>
WSI can't know if/when dithering needs to be done
<MrCooper>
only the compositor can know
amarsh04 has joined #dri-devel
amarsh04 has quit [Remote host closed the connection]
amarsh04 has joined #dri-devel
amarsh04 has quit [Remote host closed the connection]
<Company>
well, it offers 16bit fbconfigs, swapchains is a vulkan term I guess
lynxeye has joined #dri-devel
<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?
<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
<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
<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
<pq>
llyyr, what you just wrote is exactly the kind of testing instructions for compositor developers we'd like to host. :-)
<llyyr>
ah I thought the repo was just for the color-management protocol development resources
<Company>
(you need a tiff viewer that displays floating point though, which is GTK and gimp
<Company>
(and gimp runs on 8bit only because it uses GTK2/3 + Cairo to display)
<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
<Company>
in normal operation I mean
<Company>
one needs special test content to check
<pq>
yup, which is why a documented testing procedure would be valuable.
<Company>
it's why I'm always asking for a way to take >8bit screenshots
<pq>
so, eog is the right tool to view that tiff?
<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
<pq>
hm, my eog cannot handle it
<Company>
pq: I think eog and loupe can't handle it
<Company>
also, eog is GTK3 so would use 8bpc
<pq>
Company, what's the right tool then?
<Company>
if you have a recent enough GTK, gtk4-image-tool show high-depth.tiff should work
<Company>
if you have a build, it's in tools/
<pq>
I guess Debian stable is just too old for this.
<MrCooper>
llyyr: right, or some people might just not care outside of direct scanout
<Company>
I think you need 4.16
<MrCooper>
Debian has that in the libgtk-4-bin package
<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
<MrCooper>
*Debian testing
<pq>
MrCooper, ah.
<Company>
with all this hdr/high depth stuff, I'd recommend keeping a git checkout of GTK
<Company>
because we have bugs and if you run a release that's >3 months old we've forgotten about all those breakages already
<Company>
note: there's no need to install it, I use LD_PRELOAD for all my testing
<pq>
I'm not personally far enough to test GTK apps yet, but thanks for the reminder.
<Company>
GTK auto-switches to 16bit float fbconfigs if you load 16bit images btw
<Company>
and has done so for a few years
<Company>
nobody noticed that we turned that on
<pq>
cool
<Company>
apart from AMD users I think because they had a bug
<Company>
and some apps had accidentally stored their icons as 16bit pngs
<Company>
so if you were scrolling through app lists, your screen got garbled
rasterman has joined #dri-devel
<Company>
that was the only thing that happened
<Company>
everything else just worked
<MrCooper>
Company: FWIW, if GTK doesn't support "meson devenv" yet, that would make running using binaries from a build tree easier for everyone
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
u-amarsh04 has quit [Remote host closed the connection]
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
u-amarsh04 has joined #dri-devel
kode54 has joined #dri-devel
<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
<MrCooper>
the point of meson devenv is not needing to worry about details like that
<MrCooper>
surely it needs to set e.g. $LD_LIBRARY_PATH at the very least
<Company>
I think meson plays games with linkage on Linux that makes it work without for in-tree stuff
<Company>
because I've never used meson devenv
<Company>
I only started making sure it works recently when I started working with VSCode on Windows
<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
<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
<Company>
yeah, other binaries need a devenv or LD_PRELOAD
neniagh has joined #dri-devel
<Company>
I still want static linking to work, so one can ship apps as a single .exe on Windows
<Company>
but not there yet
Haaninjo has quit [Quit: Ex-Chat]
alphazone has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit []
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
androidui has quit [Remote host closed the connection]
<soreau>
emersion: but in the test snippet, gbm_bo_create_with_modifiers() with linear or invalid returns a NULL bo
<soreau>
if I use NULL, 0), then it doesn't
<emersion>
yeah, that's expected
<emersion>
you can compare before/after
<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"
<soreau>
is that only on cards with modifiers?
<emersion>
only on cards without modifiers
<emersion>
the expected behavior is return NULL for gbm_bo_create_with_modifiers({LINEAR})
<emersion>
IOW: if modifiers are supplied but the driver doesn't support these, GBM should return NULL
<soreau>
emersion: ok, I removed the part it doesn't address and moved the fixes line to the end
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
guludo has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Quit: Konversation terminated!]
<DemiMarie>
Ermine: a stable version that gets bugfixes backported for a couple of years
guludo has quit [Ping timeout: 480 seconds]
<alyssa>
would anyone complain if i symlinked `src/gallium/drivers/asahi` to `src/asahi/gl`
samuelig has quit [Quit: Bye!]
Duke`` has quit [Ping timeout: 480 seconds]
guludo has joined #dri-devel
samuelig has joined #dri-devel
<pac85>
Maybe `src/asahi/gallium` would make more sense since it also does cl etc.
glennk has quit [Remote host closed the connection]
<pac85>
~~Unless we decide gl stands for gallium from now~~
<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?
<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...
glennk has joined #dri-devel
jernej_ has quit []
jernej has joined #dri-devel
mbrost has joined #dri-devel
karenw has quit [Ping timeout: 480 seconds]
jernej has quit []
jernej has joined #dri-devel
anholt has quit [Ping timeout: 480 seconds]
jernej has quit []
jernej has joined #dri-devel
neniagh has quit [Read error: Connection reset by peer]
neniagh has joined #dri-devel
jernej has quit []
jernej has joined #dri-devel
rgallaispou has quit [Quit: WeeChat 4.4.2]
rgallaispou has joined #dri-devel
rgallaispou has quit []
anholt has joined #dri-devel
karenw has joined #dri-devel
rgallaispou has joined #dri-devel
<DavidHeidelberg>
... and Nine :D
<jenatali>
alyssa: How do git symlinks work on Windows?