00:01dcbaker: jekstrand: add https://gitlab.freedesktop.org/-/snippets/7356 to your subprojects
00:12dcbaker: which sidesteps the whole problem, and should at least get your going until I can get back to working on the cargo integration
04:46jekstrand: dcbaker: Any chance you can rebase on 1.0? I'm using bindgen stuff that's only in 1.0.
04:47jekstrand: I can go back to doing it the old horrible way but ugh.
04:47dcbaker: I Can look at it tomorrow. I have no idea what the conflicts are going to look like
04:48jekstrand: dcbaker: Thanks! If you get in too deep, I can revert my bindgen stuff back to manually mangling include dirs.
04:48jekstrand: dcbaker: But it's way nicer now that rust.bindgen() supports `dependencies :`
04:48dcbaker: Did you try the hand ported version of syn I’d linked you to?
04:49dcbaker: Yeah… I really need to get cbindgen integration going next
08:25MrCooper: DavidHeidelberg[m]: no matter how many times it passes, it can randomly break again for any MR, because we have no idea yet what causes it to break with LTO
08:31tzimmermann: sravn, the include cleanup is now in drm-misc-next
08:33Lynne: nice, first part of vulkan video landed
08:41MrCooper: DavidHeidelberg[m]: also, if it passes once for a given commit, it'll pass every time
11:54oneforall2: hmm now to figure out how to get snd working in cli no x running with pipewire..
13:19ondracka: Hi, why do nir_fdotx_replicated opcodes have 0 for input sizes? I would expect it should be the specific size, e.g., 3 for nir_fdot3_replicated. In other words if I have a random nir_alu_instr, how do I reliably get input sizes?
13:44ondracka: Nevermind, that was my bug, it actually returns the expected size...
14:37DavidHeidelberg[m]: ANV feels totally broken when changing sharding. Multiple additional tests are flaking/failing
14:46dj-death: DavidHeidelberg[m]: I would moderate "totally broken"
14:46dj-death: DavidHeidelberg[m]: dEQP-VK.draw.dynamic_rendering.linear_interpolation.* already has failures
14:46dj-death: DavidHeidelberg[m]: dEQP-VK.drm_format_modifiers.export_import.* already has crashes
14:52DavidHeidelberg[m]: dj-death: yeah, it's the time for the magic solution... asterisk :D
14:53dj-death: dEQP-VK.draw.dynamic_rendering.linear_interpolation.* is a pain in the bum... I have no idea why it's not working, passes fine on simulation
14:53dj-death: modifiers might be easier to fix
15:07DavidHeidelberg[m]: dj-death: what about core dump from CI, would it help?
15:08DavidHeidelberg[m]: *help with debugging
15:11dj-death: DavidHeidelberg[m]: I can repro the modifier stuff here
15:11dj-death: DavidHeidelberg[m]: I'll look into it
15:12DavidHeidelberg[m]: yay! Thanks :)
15:13DavidHeidelberg[m]: I'll push meanwhile the MR with * to not have to worry about them for now :)
15:27bl4ckb0ne: if anybody has a bit of time to review a new egl ext impl pls https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18011
15:46bl4ckb0ne: DavidHeidelberg[m]: I dont get your comment regarding the license
15:47DavidHeidelberg[m]: oneline SPDX
15:47DavidHeidelberg[m]: https://spdx.dev/ids/
15:47bl4ckb0ne: so just a one line SPDX license, no copyrights?
15:48DavidHeidelberg[m]: bl4ckb0ne: no copyright should be there (you filled only XXX instead of name), but whole licence can be supplied by SPDX one-liner with licence identification
15:48DavidHeidelberg[m]: which reminds me I should fish for more (dis)likes on https://gitlab.freedesktop.org/mesa/mesa/-/issues/7957 for Mesa
15:49psykose: just remove every header
15:49psykose: bike shedded successfully
15:50bl4ckb0ne: what about no source file and all the code in headers
15:50ajax: delete all the files
15:50ajax: all bugs are in files, after all
15:50ajax: no files, no bugs!
15:50DavidHeidelberg[m]: :D no code rule, I see. You're man of culture :D
15:51ccr: just like "serverless"! serverless = no servers = no running code = no security vulnerabilities or other technical problems!
15:51DemiMarie:imagines formally verifying a GPU driver
15:51bl4ckb0ne: pushed a fix
16:06daniels: ajax: your personal brand remains strong
16:13alanc: wouldn't formal verification require making the risky assumption that the hardware actually works as documented?
16:30bl4ckb0ne: there is an issue with the python ci in piglit
16:30bl4ckb0ne: >ERROR: Job failed: failed to pull image "python:3.10" with specified policies [always]: initializing source docker://python:3.10: reading manifest 3.10 in quay.io/libpod/python: manifest unknown: manifest unknown (manager.go:237:0s)
16:31CounterPillow: daniels: is anyone from collabora working on rk3588 video output or is that up for grabs?
16:32eric_engestrom: bentiss: ^ for the docker resolution issue
16:32eric_engestrom: ah, bentiss is not on this channel
16:32eric_engestrom: bl4ckb0ne: post that error again in #freedesktop :)
16:46pinchartl: CounterPillow: I'm interesting in the camera side, you can have the video output :-)
16:46pinchartl: (but I'm not from Collabora anyway)
17:05daniels: CounterPillow: we don't have anyone actively working on VOP2 atm; I know bbrezillon had some patches from a while ago but it got parked because in order to make the insane HDMI PHY clocking work, sre had to go do a bunch of enablement in the core clk bits
17:05daniels: I _think_ the latter has all landed now but let me check
17:06CounterPillow: The clock gating stuff?
17:06CounterPillow: this is a high quality downstream driver https://github.com/rockchip-linux/kernel/commit/95b6a39dab6d229f7e6e52077d727eceb0c14d3a#diff-6058b4e65573c31487232efcfd3ad87310cc982ae7d8614303e18a445a9723cdR7168
17:10daniels: isn't it just ...
17:25daniels: CounterPillow: yeah, so the issue was that some clocks have two parents (already somewhat weird). in the downstream tree, they deal with lighting up one parent via the clk framework, with the other sidechained via PM to activate it. upstream doesn't yet handle that. on the codec side, they're dealing with this by just manually lighting up both from the driver, even though it should be handled by clk.
17:25daniels: proper upstream solution is WIP but itmt that'll get you around one of the pain points
17:26CounterPillow: alright, I feared there was some weirdness going on. Thanks for the pointers
17:27CounterPillow: guess it's not so much a clock tree as it is a clock DAG then :)
17:33daniels: heh yeah :)
17:33daniels: and np
18:59Rayyan: https://lore.kernel.org/dri-devel/20230118184817.608551-1-rayyan@ansari.sh/T/#u
19:32DavidHeidelberg[m]: anholt: Hello! You will know: Error: Failed to parse dEQP-VK.draw.dynamic_rendering.linear_interpolation.* as CSV test,status[,duration] or comment at line 49. But if I use ".....*,fail" it seems to not detect that fail
19:32anholt: you can't glob fails
19:33anholt: I'd be open to supporting that, though
19:34DavidHeidelberg[m]: anholt: if I push it into skips until dj-death figure out the issue?
19:34DavidHeidelberg[m]: would it be acceptable?
19:34anholt: I'd -1 that. just list the fails.
19:34anholt: like, unless there are thousands
19:35DavidHeidelberg[m]: well, with changing of shards these fails/crashes changes
19:35airlied: I had the same problem revving the cts
19:35airlied: though that made me fix all the lavapipe fails at least
19:35airlied: when shards change the results files get left behind
19:36anholt: one of the things we've been talking about is having nightly full runs and maintainers having some channel giving them updates for those.
19:37DavidHeidelberg[m]: For now, I'll list everything manually. It's I think third run of marge :(
19:37anholt: so then hopefully the encoded xfails follow pretty closely and fraction changing ends up separate from xfail management (unless you've got nasty state leaks, hi nouveau).
19:38airlied: DavidHeidelberg[m]: only 3, seems lucky :-P
19:38airlied: between 500 and 503 errors I've had to bounce MRs off marge quite a lot the last few days, I just end up baby sitting it now
19:47DavidHeidelberg[m]: airlied: working on workaround :)
19:53daniels: DavidHeidelberg[m]: you could also ping lfrb to add fail globs
19:56DavidHeidelberg[m]: daniels: who is that?
19:57daniels: DavidHeidelberg[m]: he works for us ;) available on Mattermost
19:57DavidHeidelberg[m]: robclark: how many a630 are currently online? Seems like pipelines waiting on them (a630+zink-a630).
19:57DavidHeidelberg[m]: oh, I'll ping him
19:58anholt: looks like 7 cheza right now
19:59DavidHeidelberg[m]: anholt: all exclusive for MesaCI or shared with something else?
19:59anholt: small load from kernel is all
20:00DavidHeidelberg[m]: ok, we utilizing 13 jobs (12 a630; 1 zink-a630) :(
20:01robclark: DavidHeidelberg[m]: looks like there are at least two idle at this second
20:02DavidHeidelberg[m]: yeah, now the MR is finishing
20:03DavidHeidelberg[m]: a630_gl has 4 shareded jobs per ~ 10 minutes, we could go to 2 shareded ~ 20 minutes
20:04DavidHeidelberg[m]: edit: probably ~ 15-18 minutes, because we save a few minutes on bringup I guess
20:05anholt: note that job count isn't the only thing, some of the 630 jobs are really short.
20:06DavidHeidelberg[m]: I saw some are around ~ 5 minutes, but this could bring a bit saving around power-on
20:08DavidHeidelberg[m]: maybe just slightly go from 4 sharded jobs to 3 ( it'll run for ~ 13 minutes for sure anyway)
20:09anholt: if you want to save power-on time, it would be sorting out if we can run the winsys tests in the normal gl run.
20:10anholt: or merging skqp and piglit (since both trigger on gl and vulkan)
20:10anholt: skqp+piglit had some blocker last time I tried, I think
20:15pinchartl: daniels: clocks with two parents ? oh my :-S
20:17daniels: yep …
20:20pinchartl: what are they used for ?
21:47DavidHeidelberg[m]: jekstrand: btw.I got pinged about https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9989 any chance to run the failing test on the nvidia blob and show results?
22:40DemiMarie: alanc: the ideal approach would be to verify the driver and the hardware’s HDL against a common specification.
23:17jenatali: Ugh, wanted to run GFXBench on dzn, but I get a "network error" whenever dzn is available as a VK ICD... seems awfully suspicious and not network-like at all
23:18jenatali: Apparently it's the same error that happens when it's run on WINE, so that's fun
23:19robclark: I mean, for the android version of gfxbench, I've seem camera bugs break it..
23:20jenatali: Wow
23:23robclark: I _think_ it is using the camera to try to detect that it is running on a real device (and the device claimed)?? Just a guess..
23:25bnieuwenhuizen: IIRC one of these benchmarks (I think it was gfxbench, but might have been 3dmark?) just errors out because the server doesn't like some device info