00:06RAOF: daniels: Yeah, the weird shadow gbm_bo is a problem with my proposal. I'm not clear about the bandwidth concern, though? If you're on embedded, you've got a gbm_bo you want to scanout of, but it's not in scanoutable memory what's the *better* approach than a blit?
00:08RAOF: Anyway, mainly my concern is that every time I look at this code I go "Urgh, I've got a dmabuf in a format the GPU claims to be able to scanout of, but we're setting up a bunch of EGL state, texturing from it, and hoping that the drivers are smart enough to just use the dma engine the GPU surely has".
00:10RAOF: So if gbm_bo_copy (possibly plus an "allocate a gbm_bo that'll be scanoutable in whatever format you'd most like to copy into" function) is an acceptable API then that also scratches my itch.
00:33alyssa: oh, hum, KHR-GLES31.core.compute_shader.simple-compute-shared_context is a new test
00:33alyssa: so maybe a test bug?
00:33alyssa: or maybe a weird mesa/st bug?
00:33alyssa: (failing before it even gets to the driver)
00:34alyssa: (fails under softpipe too)
00:39zmike: I filed a ticket about that failing on zink recently
00:42alyssa: spicy
00:42alyssa: I expect it's failing on all mesa drivers
00:45alyssa: updated your ticket
00:48Sachiel: seems to pass on iris
00:50jenatali: Guess I need to try it
00:54alyssa: Sachiel: even spicier.
00:55alyssa: debug build?
00:55alyssa: zmike: x86?
00:55Sachiel: release, it seems. Let's try a debug
00:58alyssa: the test looks ok.
00:59alyssa: I am very confused
00:59Sachiel: passes on debug too
00:59alyssa: I see the shader object added into mesa's hash table but not removed, and yet it can't be found later
01:00alyssa: memory corruption maybe?
01:00alyssa: valgrind doesn't complain
01:00alyssa: ooh
01:00alyssa: wait
01:01alyssa: there are multiple contexts flying around arent there
01:01alyssa: right, yes
01:02alyssa: it's trying to glDeleteProgram from a different gl_context than the shaders were created on
01:02alyssa: I am unsure if that's legal
01:03jenatali: Why not, if they're shared?
01:03jenatali: Isn't there a pipe cap for shareable shaders?
01:04alyssa: jenatali: "why not" well the entirety of mesa/st seems to believe it's not legal
01:04alyssa: and if that is false oh boy
01:05jenatali: Yeah seems like mesa/st needs to replicate them if it's false but maybe it's just not putting them in the share group now?
01:05jenatali:is guessing
01:05alyssa: yeah.. the two contexts have different ctx->Shared
01:05alyssa: I think that's the actual problem here
01:05jenatali: O.o
01:05jenatali: How could that ever pass? How does iris pass?
01:06alyssa: Unclear
01:11alyssa: jenatali: tracing up the call stack into WSI stuff
01:11alyssa: I'm using a surfaceless deqp
01:11alyssa: Sachiel: what window system is your deqp?
01:11jenatali: Ooh
01:11Sachiel: whatever it is when you don't specify one. I usually just look at vulkan
01:12Sachiel: since it does pop up a window, I assume it's not surfaceless
01:13alyssa: glx maybe
01:14alyssa: jenatali: driCreateContextAttribs called with shared = NULL
01:14alyssa: so far so bad
01:16alyssa: jenatali: ...and bug
01:17jenatali: ?
01:17alyssa: https://github.com/KhronosGroup/VK-GL-CTS/blob/main/framework/platform/surfaceless/tcuSurfacelessPlatform.cpp#L419
01:18alyssa: CTS creates two contexts with share_context=NONE, meaning they're not allowed to share anything
01:18alyssa: but then the new test tries to share shaders between contexts
01:18alyssa: that blows up
01:18alyssa: not our bug
01:18zmike: still kinda our problem since nobody fixes glcts
01:19jenatali: Our as in people, not our as in Mesa codebase at least
01:19zmike: also still confusing why this works on iris
01:19alyssa: zmike: It's CTS winsys dependent
01:19alyssa: egl/surfaceless is affected
01:19alyssa: x11/wayland i guess aren't
01:19zmike: I'm running glx/x11
01:20zmike: it passes on iris and nothing else
01:20alyssa: ????????
01:20alyssa: baffling
01:20alyssa: maybe there are 2 bugs then
01:22zmike: could be more than 2
01:23alyssa: it's allowed
01:23alyssa: though not recommended
01:23zmike: I think the recommended number of bugs is zero
01:23Sachiel: no bugs allowed, reclassify as features
01:25zmike: now we're talking
01:27alyssa: not even compile tested https://rosenzweig.io/0001-WIP-Fix-surfaceless-shared-contexts.patch
03:39dcbaker: gfxstrand, karolherbst the core of the meson cargo integration landed :)
07:19benjamin1: so I just had a wild time debugging a behavior in nvk where the number of pushes needed for a command buffer was very different between a debug and release build (674 vs 1025). turns out the root cause d9f8225398d12c3ca25e6a5d6455711781bdec9b, which sets P_IMMD to use immediate form _only when the compiler can prove that the value fits in 13 bits at compile time_.
07:19benjamin1: I am awed and horrified that it's even possible to do this :)
07:28pq: emersion, don't single-plane YUV formats always have full-resolution chroma, so no chroma reconstruction is needed?
07:30daniels: pq: no, e.g. YUYV is 2x horizontally subsampled
07:31jannau: pq: no, the most common single plane YUV format is YUY2 (and variants) which is 4:2:2 subsampled
07:40pq: aha
07:41pq: so what are the chroma siting rules for that? Are there more than one flavor, like there are for 4:2:0?
07:42pq: I've missed the 4:2:2, because it's never mentioned in the video standards I've been reading about broadcast and HDR.
07:43pq: handling 4:2:2 chroma siting is currently missing in the Wayland color-representation extension, too
08:07gfxstrand: dcbaker: \o/
08:08jannau: pq: it is co-located with the first luma sample in h264 and h265. av1 in practice as well unless it is externally signalled
08:08gfxstrand: dcbaker: If a fork of my nak/main branch magically appeared which uses said fancy new integration, I wouldn't mind. ;-)
08:35pq: jannau, and no other convention is used anywhere to warrant making the siting configurable?
08:37eric_engestrom: dj-death: any objection to pulling https://gitlab.freedesktop.org/mesa/mesa/-/commit/17e7fe9d975c3b2f295c7a23c69455f57f56b836 into 23.1? a user is reporting that is fixes issues for them: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3657
08:41dj-death: eric_engestrom: are we sure this is the fix though?
08:45dj-death: eric_engestrom: not sure how that would prevent a crash/segfault
08:46dj-death: eric_engestrom: the last comment seems to indicate the crash fix is in https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4184
08:46eric_engestrom: not at all; I've only been following from the sidelines, but they reported that this commit fixes the issue on main, and applying it on 23.1 also fixes the issue
08:47dolphin: airlied, sima: drm-intel-fixes PR sent, just 4 fixes and two were to selftests to appease static checkers
08:47eric_engestrom: oh you're right dj-death, I has missed the last comment 🤦
08:47eric_engestrom: nevermind then, nothing to do on mesa
08:47eric_engestrom:read this last night, and asked you this morning without re-reading the issue
08:53jannau: pq: I don't know how it's handled on display side but being specified as fixed in h264/h265 while it could have been easily signalled using the same syntax as 4:2:0 suggests that it is somewhat safe to assume that the chroma location is fixed for 4:2:2
08:56pq: jannau, very good.
08:56karolherbst: dcbaker: nice.. I hope my other fix will make it as well :')
08:56pq: and if it turns out contrary, the Wayland extension is easy to extend
08:57karolherbst: ohh.. CI was fixed, nice
08:57karolherbst: so my fix can land :)
08:57jannau: of course there will be media with incorrectly downsampled chroma but I'm not sure if that justifies making it configurable. especially if it is unclear how display output should deal with it
08:58pq: if it's incorrectly downsampled, then how would anyone know how it was really sampled, so can't do anything anyway
09:00rpigott: eric_engestrom: my bad, with the latest vulkan-validation-layers I was able to apply them without a crash.
09:16jannau: pq: wrong chroma location should introduce color artefacts on all vertical edges with color and brightness changes. you try to correct that but damage is already done
09:39gawin: today is stable release?
10:19karolherbst: 9bff18d13473a9fdf81d5158248472a9d8ecf2bd (very likely) introduced a use-after-heap regression in 6.3 for nouveau. You might want to check that out as well in other drivers.
10:36jannau: sigh, I hate the abstraction mismatch between apple's firmware display interface and drm/kms. it's all integrated in basically a single entity on apple's side but I still need to mux between "crtc" and encoders/outputs
10:38jannau: apple's model seems to be broken as well, I think it's not possible to get any information from connected displays if all "crtc" are used
11:26alyssa: ok, definitely up against 2 bugs in the CTS here
11:26alyssa: or a bug in CTS and a bug in Mesa, maybe
11:27alyssa: I fixed the CTS bug but the test is still failing
11:33mlankhorst: vsyrjala: ping!
11:34alyssa: fixed CTS bug #2 and now the test passes
11:35alyssa: everybody say it with me now~
11:35alyssa: --actually no opencl's is far worse
11:39alyssa: https://rosenzweig.io/surfaceless.patch
11:53alyssa: can I submit those patches without needing to learn gerrit challenge
11:57daniels: RAOF: hidden blits are problematic because I try to use planes greedily. if gbm_bo_import() silently allocs+copies, using planes is not a win compared to the GPU, so I'd rather just composite in almost all cases. even for the cases where it is a win, I'd really rather have that explicitly surfaced than the driver being 'helpful' but destructive
11:58daniels: I'd take gbm_bo_copy() tho
12:02MrCooper: how could a shadow BO be kept up to date, anyway
12:05lynxeye: daniels: If you don't want blow up GBM to deal with fences etc, better have the copy in EGL/Vulkan if you need it at all. I think James Jones had some proposal along those lines at XDC a few years back.
12:05emersion: ^
12:06daniels: yeah, makes sense
12:06daniels: MrCooper: ... quite
12:19mripard: jannau: it looks similar (in that sense) to the I2C/SPI panels that have basically all bundled in one. Did you have a look in the simple kms helpers?
12:48karolherbst: I want to add clippy to the CI (and only enabled for rusticl for now) in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23522
12:48zmike: anyone have any idea what's going on with this build fail https://gitlab.freedesktop.org/mesa/piglit/-/issues/92
12:48karolherbst: it will be a bit more trigger happy and potentially complain more with gallium changes, but it's probably still fine
12:52pac85: Whenever I run traces on CI I often find that the reference images are missing like here https://antonino.pages.freedesktop.org/-/mesa/-/jobs/43374717/artifacts/results/summary/results/trace@gl-zink-anv-tgl@valve@half-life-2-v2.trace.html, any ideas?
12:56jannau: mripard: it's not a simple driver. it has to support crtcs and outputs (both up ~10 (much more outputs if dp-altmode/thunderbolt tunneled dp counts separately))
12:57mripard: I'm not sure I get it, how can you support CRTCs if it's not exposed by the firmware?
12:58MrCooper: zmike: looks like os.path.exists never succeeds in the add_shader_test for loop? No idea why though
12:58zmike: it pretty puzzling
13:02jannau: mripard: not a real CRTC but the FW interface provides most of the functionality a drm_crtc needs (and more)
13:04mripard: ok :)
13:05mripard: I don't know if you've looked at it already, but the RPi has a (out-of-tree) KMS driver running on their firmware too that they've been using in production for a while
13:05mripard: https://github.com/raspberrypi/linux/blob/rpi-6.1.y/drivers/gpu/drm/vc4/vc4_firmware_kms.c
13:16daniels: oh no, diagram rendering broke in kerneldoc https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html
13:16emersion: i mean that's a perfectly readable diagram right here
13:17emersion: don't tell me you don't yet have a kernel doc renderer embedded in your brain
13:18daniels: too much brain surface area taken up by a fucking YAML parser
13:19jannau: that's more or less the same level we already have. hardcoded drm_{crtc,encoder,output} display pipelines. crtc and output provide their functionality via the same fw interface
13:22jannau: that stops being simple when crtc <-> output muxing has to be supported. The HW has usually more outputs than CRTCs
13:25mripard: jannau: yeah... tell me about it :)
13:26mripard: I spent way too much time figuring it out for the RPi :)
13:55tleydxdy: is there a vulkan format that puts alpha in byte 0? so ABGR in byte order
13:57emersion: tleydxdy: on LE, doesn't seem like it
13:57emersion: see e.g. https://pixfmtdb.emersion.fr/DRM_FORMAT_RGBA8888
13:58tleydxdy: rip
13:58emersion: though Vulkan has swizzles, which maybe you can use
13:59tleydxdy: yeah, thought I could avoid it somehow
15:01dcbaker: karolherbst: the ci issue is sorted, if you rebase I should be able to merge that today
15:02karolherbst: it's already rebased afaik
15:02karolherbst: ohh, new conflicts? I see..
15:03karolherbst: ehh no, it should be okay
15:04karolherbst: dcbaker: there is a change request active from you, but I don't think you requested anything?
15:04karolherbst: ohh some open comment about isystem maybe
15:07dcbaker: Probably, I can dismiss it
15:08dcbaker: I approved it
15:09karolherbst: cool, thanks
15:09dcbaker: It’s in the milestone, so if I don’t get to it someone else should merge it when the ci finishes
15:09karolherbst: I think with that all remaining rust related meson issues are resolved, at least the ones I hit
15:10karolherbst: well.. except full external crate support but I guess that will land over time
15:10dcbaker: gfxstrand: only the core functions and types landed so far, the actual integration is still in review.
15:10dcbaker: But there’s a lot of push to get it in 1.2.0 gstreamer is also itching for this work
15:11karolherbst: btw, I saw the remark around build.rs files, or is that not relevant in regards to external crates?
15:11dcbaker: Which one? There’s been a lot
15:11karolherbst: the one part of the core work landing
15:12karolherbst: https://github.com/mesonbuild/meson/commit/f02e26877de7a38fce672db9709666ed85706d43#diff-d8c30bce7c4d2588a455f4be4f7975418d6e3682829df6120ebf5c13dd507e4aR6
15:12karolherbst: I was curious about the practical implications on this
15:12karolherbst: *of
15:12dcbaker: Yeah, atm we’re not planning to deal with build.rs
15:13dcbaker: The guy working on gstreamer said there weren’t that many crates using build.rs
15:13dcbaker: In the gstreamer graph I mean
15:13karolherbst: mhh.. I see
15:14karolherbst: well.. syn has one
15:14dcbaker: I gotta run, but we have some ideas to reduce the number of build.rs files
15:15karolherbst: okay
15:22mattst88: dcbaker: when you're back, I'd like your opinion on https://gitlab.freedesktop.org/mesa/glu/-/issues/7#note_1947456
15:23mattst88: tl;dr: my gpg key isn't in the release-maintainers-keys.asc key, and someone is concerned about that in regards to a release of glu I did a year or so ago
15:24mattst88: I'm not really planning to make a bunch of releases or anything, so I wonder if dcbaker or eric_engestrom would like to tag and release a new glu?
15:24mattst88: it's currently got a few fixes in master that would be nice to ship to distros, like a fix for clang-16 support
15:24mattst88: and that would mean the latest release is signed by someone in the keyring
15:25mattst88: IIRC I just used the standard xorg/util/modular/release.sh script for glu previously
15:29eric_engestrom: mattst88: I can do that, but probably not this week
15:29mattst88: thanks, that's totally fine
15:29eric_engestrom: oh wait I just looked at the issue, is this just about signing the tarball?
15:30mattst88: the filed issue is, yes; but I think it would be nice to tag a new release anyway which would kill two birds with one stone
15:33eric_engestrom: mattst88: https://eric.engestrom.ch/glu-9.0.2.tar.xz.sig
15:33eric_engestrom: that's all I have time to do today, I have to go now
15:33mattst88: thanks
15:33eric_engestrom: o/
16:34dcbaker: I don't actually know if my key is in the public maintainers asc
16:49dcbaker: karolherbst: merged
16:50karolherbst: \o/
16:53mattst88: dcbaker: it is. see 677c1bd0559a4d96599348cae92750057f422942
16:53dcbaker: TIL
16:53dcbaker: lol
16:54dcbaker: I can probably make a glu release. Maybe this will motivate me to add autoconf support to my attempt to rewrite release.sh in python...
16:55mattst88: I'd suggest just doing the typical autotools make dist release that release.sh does
16:55mattst88: doesn't hurt meson to have the pre-generated autotools files
17:02dcbaker: Yeah. Right now the autotools path is a "raise NotImplementedError()" I've mostly been focused on mesa and trying to make the release process there smoother.
17:03dcbaker: like having release.py do all of the "generate docs, update docs, bump VERSION, make release, update docs again, etc"
17:10gfxstrand: mareko, Kayden: How ephemeral is pipe_surface? Is it intended to be created/destroyed by the state-tracker at-will or is it okay to hang on to pointers to them?
17:11gfxstrand: robclark: ^^
17:12robclark: they are dynamically created in a bunch of cases
17:13robclark: I mean, they are refcnt'd so you can hold on to one.. but the next frame/blit/whatever you might just end up with a new instance of an identical surface
18:18mareko: gfxstrand: they are only render target views, refcounted, and created at will
18:19mareko: drivers should hang onto them only if they are bound, frontends and utils can hang onto them however long they want
21:27zmike: this is an ominous question
21:32airlied: the egg came first
21:34HdkR: Whoa, controversial
21:40karolherbst: oh no... shared atomics are busted in iris if the source isn't an SSA
21:41karolherbst: value
21:41karolherbst: ehh, the offset
21:41karolherbst: probably the atomic rework causing that
21:45karolherbst: or maybe something else :) who knows, let's await my bisect
21:55dj-death: karolherbst: odd
21:55karolherbst: 068bf1378d71e6498a4763666be3bb28a0a2e5a6 intel/fs: enable SSBO accesses through the bindless heap
21:59dj-death: huh
21:59karolherbst: wait.. it makes sense
21:59karolherbst: just not looking at the commit
22:00karolherbst: let me paste the line
22:00karolherbst: dj-death: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/intel/compiler/brw_fs_nir.cpp#L3733
22:02karolherbst: div r6 = intrinsic shared_atomic (r5, ssa_127) (base=0, atomic_op=iadd)
22:02dj-death: yeah looks like 2 changes interacted in a bad way
22:02karolherbst: yep
22:02karolherbst: (I really should wirte up CL testing for iris)
22:02karolherbst: *wire
22:04dj-death: easy enough to fix
22:04karolherbst: though it's kinda funny I only hit this with the CL CTS if I run it in spir-v mode instead of source
22:04karolherbst: oh well...
22:05dj-death: I can see that
22:05karolherbst: yeah.. just it makes no sense, because the source also gets translated to spir-v almost through the same path.. probably something funky I didn't account for in my aot compiler
22:06dj-death: karolherbst: https://gitlab.freedesktop.org/llandwerlin/mesa/-/commit/93d708089483bff730e467ff06f65d36342e6966
22:06dj-death: there a bunch of NIR passes that would not deal with register well
22:07karolherbst: yeah.. makes sense
22:07karolherbst: I totally get it for images
22:08karolherbst: luckily, CL isn't as crazy as GL and indirect textures don't exist at all :)
22:08dj-death: DG2 is really interesting
22:08dj-death: you can address surface from 3 different heaps
22:08karolherbst: dj-death: yeah, seems to fix it btw
22:08karolherbst: oh wow
22:08dj-death: for buffers
22:09dj-death: the sampler still just 2
22:09dj-death: it's nice, but also a bit wtf
22:09karolherbst: doing a full run and see if anything else stands out, but I think this was the only iris regression so far :)
22:09dj-death: you can tell different HW teams working at different paces
22:10karolherbst: I don't see why there isn't just "surface memory" but whatever :P
22:10dj-death: I mean the surface descriptions can belong to 3 different heaps
22:11dj-death: I don't know how it is for other HW
22:11karolherbst: yeah.. it's just weird to have different heaps at all
22:11karolherbst: well... on nvidia here is just one heap: the VM
22:11dj-death: looks like AMD has a way to build the HW description in the shader
22:11dj-death: which is nice
22:11dj-death: or maybe it's just shaders
22:12karolherbst: there is a table for direct surface accesses you can set up, but that's just handle to pointers into the normal global memory heap
22:12Sachiel: someone at intel really misses segmented memory
22:13karolherbst: nvidia also got rid of the shader heap, but that was just a bound pointer into the global memory and shaders got 32 bit address offsets...
22:14karolherbst: but I'm sure Intel folks know what they are doing there :) It just feels weird to me to make those things overly complicated
22:14karolherbst: (for the driver side that is)
22:17dj-death: it's kind of a theme around here
23:31karolherbst: okay next: fmod being broken on radeonsi :)