06:12zzxyb[m]: may I ask how to enable driver_debug, I failed to set GALLIUM_DDEBUG=always
06:13zzxyb[m]: zzxyb[m]: gallium driver_ddebug
09:20sarahwalker: I'm looking at a corruption issue in a map_wc shmem buffer, and I see the comment in the shmem get_pages function - "TODO: Allocating WC pages which are correctly flushed is only supported on x86."
09:20sarahwalker: Does this mean I should expect the map_wc functionality to not work on arm64?
11:44bbrezillon: sarahwalker: Unless I'm wrong, 'write-combined' is just 'uncached' on arm64 (robmur01 to confirm that), so it should work just fine without any CPU-side cache maintenance operations. This being said, you might be in trouble if your system is coherent, and you map things uncached. I remember hitting this problem with panfrost on some MTK SoC.
11:48mripard: we had a discussion recently for longsoon iirc about this
11:50HdkR: Oh hey, I remember reading that comment when I was poking at why latest generation Radeons don't work on Solidrun boards
11:50mripard: and my understanding was that dma_alloc_wc semantics are that it allocates a DMA coherent buffer with WC attributes, so the assumption is that you cannot have any coherency issue
11:52mripard: I think the issue with longsoon was that the system (or device, I can't remember) was defined as coherent because it had an IO-coherency unit, but it didn't operate on the WC write buffer
11:54mripard: If you're in the same situation, then I guess it all boils down to whether the device can be considered coherent in such a case :)
11:57bbrezillon: mripard: it's a buffer allocated through shmem, so no dma_alloc_wc() taking care of the coherency prop to pick the right attributes AFAICT.
11:57mripard: oh, right
12:00bbrezillon: sarahwalker: I guess it's worth trying to force map_wc=false, just to see if that solves the problem
12:30msizanoen[m]: <doras> "I'm uncertain if this is a..." <- might be this line: https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:ui/gfx/linux/gbm_wrapper.cc;l=75;drc=df097ef9b722789243248f807ad66c7085a14099
12:50zmike: eric_engestrom: I'm gonna do an extra vvl version bump since I gotta rebuild the containers again anyway
12:51zmike: I'll assume you're okay with that as long as it passes ci
14:49robmur01: bbrezillon, sarahwalker: yup, from what I remember of hooking up Panfrost's coherency support, map_wc only means that the BO pages get a non-cacheable mapping to userspace - any touching of them from the kernel side still needs the appropriate DMA API business which you probably need to worry about getting right if you're doing anything cleverer than delegating everything to the helper libraries
14:50eric_engestrom: zmike: yeah, I just checked the new rev, it's still just a bump of the version number and the appropriate image tags, so it all lgtm
16:27eric_engestrom: gfxstrand, karolherbst: `meson test` no longer passes now that NVK has been merged; `mme_builder` seems to take forever to run (143sec on my machine, way above the default 30sec timeout, making it fail)
16:27karolherbst: uhhh....
16:28karolherbst: is that on a nouveau machine?
16:28eric_engestrom: nope
16:28eric_engestrom: (m2 air)
16:28karolherbst: that mme stuff shouldn't run on anything not being nouveau :D
16:28karolherbst: well.. some of it at least
16:28eric_engestrom: ack
16:28eric_engestrom: I guess the test needs to detect that and exit with 77
16:28karolherbst: there are two parts: unit tests and making sure the simulator agrees with the hardware
16:28eric_engestrom: (77 = "this test was skipped")
16:29zmike: ...are we debating how to make MEME_BUILDER pass?
16:29karolherbst: eric_engestrom: do you have a log?
16:29gfxstrand: The mme builder tests shouldn't need hardware
16:30gfxstrand: The only one that runs as part of `meson test` should be the one that is simulator-only.
16:31eric_engestrom: karolherbst: I have the test output if that's what you mean; they all take 0ms except "mme_builder_test.while_ine (143424 ms)"
16:32karolherbst: mhhhhhh
16:32karolherbst: maybe the simulator is buggy on arm
16:33eric_engestrom: I've also reproduced it on an x86 machine, so I'm not sure it's arm-specific
16:33karolherbst: mhh funky
16:33eric_engestrom: (or non-intel specific, I mean)
16:35karolherbst: maybe some weird undefined behavior happening somehwere
16:37karolherbst: well.. at least for me `[ OK ] mme_builder_test.while_ine (0 ms)`
16:39eric_engestrom: I tried leaving it running in gdb for various amounts of time, every time I break it it's in `eval_inst (sim=sim@entry=0xffffffff9848, inst=inst@entry=0xaaaaaad208f0) at ../src/nouveau/mme/mme_fermi_sim.c:283`
16:39eric_engestrom: not sure how helpful that is
16:40gfxstrand: Buggy on arm is possible. Other UB is also possible.
16:40gfxstrand: Should have ported it to Rust. :joy:
16:40gfxstrand: I do have an MR for that for the Turing MME sim.
16:41karolherbst: maybe running it with ubsan helps
16:41karolherbst: or asan
16:41gfxstrand: That's what I'd try
16:56eric_engestrom: karolherbst, gfxstrand: you can experiment on the CI, it also fails on these (x86) machines: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/46842186
17:09karolherbst: mhh https://gist.githubusercontent.com/karolherbst/4d780e7a2c1ad7232b588430d92e956d/raw/4c70b2e377d986610a5af65993a3498ec4dcb64d/gistfile1.txt
17:09karolherbst: but I'm sure there is more
17:09karolherbst: I'll make that tool ubsan+asan clean and submit patches
17:12dcbaker: karolherbst: sorry I didn't get back to you sooner, I had some personal stuff and was out all of last week. Did you get the bindgen + c++ stuff sorted out?
17:19karolherbst: dcbaker: no, as I got lost in the code :D
17:20karolherbst: dcbaker: but anyway, I filed a bug: https://gist.githubusercontent.com/karolherbst/4d780e7a2c1ad7232b588430d92e956d/raw/4c70b2e377d986610a5af65993a3498ec4dcb64d/gistfile1.txt
17:21karolherbst: dcbaker: anyway, besides that I think rust.bindgen has to detect if the input is c/c++ based on how it's done with other things, maybe even add `cpp_args`, and maybe even add a toggle to force c/c++ mode
17:22karolherbst: I think it's mostly the same thing, because meson shouldn't add the c++ default option if it's compiling as C
17:26dcbaker: yeah, we can do that.
17:26dcbaker: For sure we should handle the C/C++ detection + override
17:30karolherbst: yeah.. I kinda failed in parsing the global project options in a way it's not breaking wiht random compilers.. the biggest problem was that the compiler abstraction isn't really _that_ useful if you have tools using one of those internally
17:32daniels: karolherbst, gfxstrand: not sure if you know this but you wouldn't be able to have these memory-safety errors if you rewrote it in Rust
17:43karolherbst: uhh.. my system went OOM :D
17:44karolherbst: why is OOM handling still so messy tho
18:05karolherbst: dcbaker: btw, I'm also considering adding a `rust.doc` command to call rustdoc on existing targets
18:05karolherbst: kinda like `test`, but it needs to filter some arguments
18:05karolherbst: it's a pain to call rustdoc without build system support
18:06dcbaker: I actually thought about adding one of those too for the same reason
18:06dcbaker: Which reminds me, I have some cbindgen patches laying around I should send out
19:11karolherbst: eric_engestrom, gfxstrand: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24544 :)
19:11karolherbst: libasan really saves so much time
19:13karolherbst: I honestly looked at the while_ine code for minutes to find the bug and didn't catch this evil OOB access :')
19:15karolherbst: let's see if CI agrees with me here
19:35mupuf: karolherbst, gfxstrand: ready for the next nvk issue? We got deqp to start running on Ampere... only to instantly hang: https://gitlab.freedesktop.org/eric/mesa/-/jobs/46848798#L656
19:36mupuf: eric_engestrom: Worked better when using non-empty firmware ;)
19:44mupuf: karolherbst, gfxstrand: Should we try with less parallelism?
20:04mupuf: A retry actually starting going further: https://gitlab.freedesktop.org/eric/mesa/-/jobs/46849971
20:08eric_engestrom: karolherbst: thanks! it fixes the issue locally for me and I'm running it in the CI now: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/46851703
20:15airlied: so non-gsp ampere is probably going to die a lot, hell gsp ampere will also die a lot
20:16mupuf: airlied: interesting. What is the gsp improving here... aside from performance?
20:16airlied: not improving, just very different execution paths
20:16mupuf: I assume the gsp support is not available publicly yet, right?
20:16mupuf: oh, command submission goes through the GSP then?
20:17airlied: nope, but all the channel allocations do
20:17airlied: and the recovery
20:17mupuf: I see
20:17mupuf: makes sense
20:17airlied: and error reporting
20:17airlied: the non-gsp ampere firmware is not well tested by nvidia or nouveau
20:18mupuf: Sooooo, is there a tree somewhere that I could use?
20:18airlied: not really yet
20:18airlied: imo it's a bit early to throw ci at this
20:18airlied: unless you have resources to actually fix all the problems
20:19mupuf: No ressources, just wanted to propose the ga106 as a manual job
20:19mupuf: and daily runs
20:20airlied: if you want to hand make a gsp based ampere you could try and gather all the pieces but I think it's premature
20:20mupuf: I did not buy the GPU for this, I bought it to test the nvidia driver with dxvk
20:20airlied: if you can stabilise the non-gsp fw with cut down test lists or less parallelism then go for that
20:21mupuf: and running nouveau was a way for me to test a lot of the parts of the infra.... before I move on to supporting OOT drivers with boot2container
20:21airlied: I suspect 1 thread should be mostly stable
20:21mupuf: yeah, sounds like a good plan to me
20:21mupuf: 4 threads seems happy right now
20:21mupuf: but crashed on the first run
20:22mupuf: if this is gonna be like this (will maybe crash at first), then we can just auto-retry
20:22airlied: yeah there's some pretty random blow ups, we need to get to them, but CI is just going to add pressure rather than time :)
20:23eric_engestrom: airlied: it wouldn't be pre-merge ci, just a manual job that's there if you want it
20:23mupuf: right. So if we can identify a set of tests that reliably pass, then we can enable that
20:23eric_engestrom: for regression testing in MR and such
20:23mupuf: and use that to track regressions
20:23mupuf: eric_engestrom: mind sending another MR with 16 threads?
20:23airlied:has an ampere that won't even boot with the pre-gsp fw so it's a mess to sort out
20:24mupuf: I would love to see the impact :D
20:25airlied: zmike: is ../src/gallium/auxiliary/util/u_threaded_context.c:2589: tc_buffer_map: Assertion `!(tres->b.flags & PIPE_RESOURCE_FLAG_DONT_MAP_DIRECTLY)' bad?
20:25zmike: yeah
20:26airlied: seeing a bunch of those in nvk piglit runs
20:27mupuf: eric_engestrom: actually, let's try with jobs=1. We crashed again: got an irq nouveau did not ack
20:27zmike: I think that only gets set for really big buffers?
20:27mupuf: nouveau 0000:2d:00.0: fifo:PBDMA0: intr0 00800000
20:27mupuf: anyway, bed time!
20:28eric_engestrom: yeah, bed time for me too ^^
20:28eric_engestrom: mupuf: not sure what you meant by threads?
20:29eric_engestrom: FDO_CI_CONCURRENT ?
20:29mupuf: eric_engestrom: yes
20:29mupuf: would be nice if you could set it to 1
20:29mupuf: and we can run it tomorrow and see if it finishes
20:30mupuf: it will take a day or so to run :D
20:31eric_engestrom: sent now, we'll see how far it got when we wake up :P
20:31eric_engestrom: (https://gitlab.freedesktop.org/eric/mesa/-/jobs/46853208)
22:35airlied: zmike: found a fix, 24548
23:59DemiMarie: airlied: how does command submission work on Nvidia GPUs?