00:09bnieuwenhuizen: jekstrand: what do you think about instrumenting the vulkan driver (in particular including the WSI) with ftrace tracepoints so they can be seen in gputrace? Behind an env-var/drirc if needed
00:12bnieuwenhuizen: (e.g. on vkQueueSubmit and vkQueuePresent)
00:24anholt_: daniels: it's my home machine, 75/15 mbps comcast cable.
00:28daniels: anholt_: weird - if you look at the lava-build jobs on !3370, it took like 6 minutes just to pull the containers and clone the repo
00:30anholt_: daniels: one thing I've wondered about docker: if multiple things try to pull the same container at once, does it deduplicate the downloads?
00:31anholt_: I would love to drop using my personal runner, but we really need to sort out shared hw.
00:32anholt_: by which I mean, a kubernetes runner that isn't a trashfire.
00:36daniels: anholt_: nfi tbh
00:37daniels: anholt_: a3xx also seems unhealthy https://gitlab.freedesktop.org/kwg/mesa/-/jobs/1345451
00:38anholt_: I've noticed that our deqp runner doesn't seem to give ongoing output these days.
00:40anholt_: hah. gitlab-runner got oomkilled
00:46kisak: anholt_: out of idle curiousity was there many riddles to deal with the RPi3 since the vc4 had been in circulation for a fair while by the time it shipped
00:47anholt_: my pi3 work was just upstreaming 2710 so I could develop vc4 on top of it
00:47anholt_: but basically no
00:49anholt_: 27 fails left in gles nir-to-tgsi
00:49anholt_: (all in geometry shaders)
00:51bnieuwenhuizen: anholt_: what do you think about instrumenting the vulkan driver (in particular including the WSI) with ftrace tracepoints so they can be seen in gputrace? Stuff like vkQueueSubmit/vkQueuePresent and the like. Behind an env-var/drirc if needed
00:55anholt_: bnieuwenhuizen: possibly interesting? but those commands sound like things that ought to be connected to linux perf events on the kernel side, too, and if we visualized those would we want more?
00:55bnieuwenhuizen: anholt_: I think stuff like vkQueuePresent is not connected to a kernel thing commonly, because it just gets passed around to X/wayland
00:56bnieuwenhuizen: and seeing where your latency ends up being is actually one of the interesting usecases here
00:56anholt_: bnieuwenhuizen: I've been talking to keithp too much, thinking of present as a kms operation :)
01:00anholt_: daniels: db410c-1 is back, and -3 had also seemed to wander off and has been returned. we have distressingly few working db410cs now, since -2 and -4 totally died (would probably need to take them out and hook up a monitor to see what's up).
01:14Kayden: robclark: 4cda61f11e922fb5914ae73d22cc0c495abf0377 seems to be breaking 30000+ tests on i965
01:18airlied:assumes due to the yub path
01:18airlied: yuv path
01:21robclark: Kayden: you can revert the assert to unblock CI.. but that sounds like there is something wrong w/ i965, because nir_lower_tex won't really work correctly unless you lower derefs
01:21robclark: (would be nice if we had some minimal intel CI hooked into gitlab ;-))
01:22airlied: I think the state tracker does just that
01:23robclark: oh, I guess that and the following patch should have gone in the opposite order
01:23robclark: the patch after it should fix the assert for gallium drivers
01:31jekstrand: bnieuwenhuizen: I have no idea what that would require. I'm not opposed though.
01:37bnieuwenhuizen: jekstrand: a tracepoint mostly involves writing to seomthing like /sys/kernel/tracing/marker (or something like that), if the file exists and we have permissions to do so
01:38Kayden: robclark: Yeah, I think you're right - it looks like i965 is doing that backwards. I should be able to fix it
01:38Kayden: I'm going to revert for now to try and get CI green and hopefully can fix it properly tomorrow
01:47jekstrand: bnieuwenhuizen: If it's nicely wrapped up in a helper, I see no reason not to.
01:47jekstrand: bnieuwenhuizen: What kind of stuff would we want to trace? Just entrypoints?
01:47bnieuwenhuizen: jekstrand: possibly some WSI internals?
01:47jekstrand: bnieuwenhuizen: If just entrypoints, I could just make ANV's python dispatch stuff do it.
01:47jekstrand: If we want to do more internals, it'd have to be hand-rolled
01:47bnieuwenhuizen: if it is just entrypoints might be better put in a layer
02:05Plagman: yeah that's easy enough
08:19MegaFox: Hello, could you please pay attention to this shortcoming again? I really need this feature.
08:23MegaFox: (Native direct3d9 on gallium-xlib)
08:32daniels: MegaFox: the odds of someone here having the time to do it are extremely low. not to mention that we all have our own to-do lists and priorities, most of which don't invite a proprietary X server which is no longer developed.
08:33MegaFox: I think that one of the thousands of your developers will be able to find time in half a year.
08:34MegaFox: X-сервер остаётся востребованным, и я могу запустить в OpenGL, но не могу Direct3D, при том, что изначально я разрабатывалась именно для x11.
08:35MegaFox: The X server remains in demand, and I can run in OpenGL, but I can’t Direct3D, despite the fact that I was originally designed specifically for x11.
08:35MegaFox: Sorry for bad translate
08:38MegaFox: I was just tired of enduring performance drawbacks due to the translation of gdi to x11. I just can't start direct3d with normal performance on cpu without kernel modules that are not supported on android (runs in exagear).
08:40MegaFox: Even if I emulate opengl in x11, I still get terrible performance due to wined3d.
08:41MegaFox: Therefore, I would like to help myself and users of exagear with directx games.
08:48MegaFox: Even the implementation of vulkan from swiftshader (vulkan) / kazan was not too lazy to add xlib support. And you have already done this for opengl. Please think about it.
09:07MrCooper: daniels anholt airlied: FWIW, the piglit-quick_gl job seems to be taking longer since llvmpipe is using NIR, despite NIR validation being disabled
09:08daniels: MegaFox: if it actually was thousands of developers, things would be very different. it's not.
09:15MrCooper: specifically, for st/nine there's only really one person, who has expressed no interest
09:26ramaling: seanpaul: global var for srm_data was created so that we can skip the parsing if the version of the SRM is same as old srm_data parsed. But that is not implemented yet.
09:32ramaling: if simultanious read of fw file is fine, we can remove the mutex and hence the setup and tear_done calls from drm_sysfs calls.
09:41MrCooper: eric_engestrom: got a minute to look at https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3361 ? Would be nice to get this merged before Marge times out for an MR with no code changes again
10:07tomeu: daniels: this MR would get the lava jobs to use the arm builders, but needs reviewers: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295
10:25daniels: tomeu: heh, I was already reviewing it as you wrote that :P
10:25daniels: lgtm but also needs a manual rebase
10:25tomeu: yep, already on it :)
10:34daniels: hopefully that should help - last night it was very much the case that the arm build was blocked on x86 availability, which meant that the arm jobs didn't start till late, and thus also didn't complete till late
10:34daniels: (they were all behind piglit-quick_gl anyway, but then that would be helped by having more x86 capacity available, and if nothing else it at least separates x86 and arm to reduce interdependency)
10:34tomeu: yeah, I think given the order of jobs, from now on the lava jobs will start pretty early, while there's still other build jobs running
10:35daniels: ooi, is there any reason to not use --depth=1 in the VK-GL-CTS clone?
10:49tomeu: daniels: we used to need a specific revision
10:56daniels: ah, so you can only use --depth with a head rather than a commit, or?
11:06tomeu: actually, i have checked and the problem is that we cherry-pick two commits from another branch
11:16daniels: ahh, right
11:24eric_engestrom: MrCooper: just had a look at MR !3361, r-b with a couple minor notes that can be taken care of after landing this 👍
11:27daniels: kusma: could you please merge stuff by assigning to marge-bot? helps reduce useless CI runs by running pipelines on repeated rebases
11:28kusma: daniels: sure thing. I wasn't sure marge was working, because it spewed errors yesterday. But I see it merged some stuff again this morning.
11:28daniels: kusma: hmm, if it's spewing errors please let me know about it - it definitely shouldn't be
11:29kusma: daniels: it said something about being broken on the inside and needing someone to fix her
11:29daniels: poor thing
11:29kusma: I'll let you know next time I see that
11:29daniels: thanks! :)
11:31kusma: np, sorry for not double checking first
11:33daniels: meh, all good
11:47daniels: anholt: a630 flake on dEQP-GLES3.functional.fbo.blit.conversion.r16ui_to_r8ui
14:01benjiG: airlied: hi, may I ask you to have a look on this patch ? https://patchwork.freedesktop.org/patch/342999/?series=69393&rev=3&_sm_au_=irWjF54qCTZr08QrcLpsvK618Vf61
14:12dj-death: oh so now we're using Part-of: tag?
14:12kisak: dj-death: Marge handles that
14:13dolphin: Part-of, where? (not KMD I take)
14:14kisak: pull request gets assigned to Marge-bot, Marge rebases and adds part-of to each commit in the series, and a tested-by to the last commit of the series, then CI test and automerge
14:24daniels: tomeu: so, whilst !3295 looks to have been really useful for reducing x86 runner contention, the arm_build job is now _really_ long
14:25daniels: tomeu: it would be more manageable - runtime likely cut in half - if it was split into separate arm64 + armhf jobs
14:26tomeu: daniels: but that job is very seldomly run, isn't it?
14:27daniels: ideally, yeah
15:13dolphin: daniels: is Notification level "Participate" not a superset of "On mention"?
15:13dolphin: I don't seem to have gotten a notification e-mail for mention of myself in the freedesktop project
15:53daniels: dolphin: no idea I'm afraid, but it should be documented
15:53daniels: anholt: any objections if I raise marge's ci timeout to 2h? atm it looks like if we push new base images, we can get a horrible cascading bubble, where MRs run with the new tag but before the tag has been pushed on master, so they also rebuild it themselves, so we collapse in a contention hole and then further MRs also try to rebuild the new tag on master. the worst thing we can do at that point is to move on and
15:53daniels: trigger yet more rebuilds with rebases - we should just grimly stick with it and wait until the first one completes.
15:57bnieuwenhuizen: dolphin: did you mention yourself in one of your own messages? In my experience I mostly get no updates for whatever I post myself, even with 'Watch' set
16:56MrCooper: daniels: the downside is that could result in wasting lots of time waiting in other cases where starting a new pipeline would be the right course of action
16:57daniels: MrCooper: which other cases?
16:57MrCooper: e.g. a hanging job
16:58daniels: do we still have many of those? i thought we were quite good with timeouts these days
16:58daniels: (apart from when a6xx OOM-kills the runner process)
17:00MrCooper: probably not "many", but not really "none" either I'm afraid
17:02MrCooper: would be really good to make the arm_build image building faster again, or split it up into multiple faster jobs
17:23anholt_: daniels: my concern with kernel in artifacts is that that's 30MB or whatever on every single pipeline that fd.o has to store for 4 weeks.
17:25daniels: anholt_: yeah, that makes sense
17:31MrCooper: that'll be on the order of 10s to 100s of GBs
19:47anarsoul: tomeu: daniels: looks like lima jobs in CI take close to 15 mins, I guess it's not acceptable
19:48anholt_: anarsoul: how many boards are there in the lab? can we just use parallel flags to split the run across boards?
19:52anarsoul: anholt_: I'm not sure. It's collabora's lab
19:52anarsoul: but panfrost can finish similar set of tests in under 5 mins, so I guess there's some room for optimization
19:53daniels: anarsoul: what's the machine type?
20:00daniels: that's not in our lab, it's BayLibre I think?
20:00anarsoul: oh, OK
20:11airlied: MrCooper: I have added a lot more coverage to it, by enabling extensions, so it might not be just enabling NIR
21:08bnieuwenhuizen: xexaxo1: dcbaker: you know what is going on wrt a 20.0 release? The release calendar does not mention it yet. (Alternatively, who should I poke?)
21:15jhli: any drm committers free mind helping merge this: https://patchwork.freedesktop.org/patch/345498/?
21:17Lyude: jhli: yeah, I can merge that. will do it once I finish up looking at this patch from amd
21:20jhli: Lyude: thanks! much appreciated
21:22dcbaker: bnieuwenhuizen: My understanding is that Juan was doing the 20.0 release
21:23Lyude: jhli: pushed
21:23Lyude: (to drm-misc-next)
21:28jhli: Lyude: awesome, thanks again!
21:28Lyude: jhli: np
22:05dcbaker: pendingchaos: I tried to backport one of your aco patches to 19.3, its the tip of staging/19.3, could you let me konw if that looks right?
22:06dcbaker: also 809c8feb92d33c43ace3ef25584a2adca24b1be0 doesn't apply and its not clear to me what to do about it
22:06dcbaker: dschuermann: 05c81875d7bf871f73f24903e04dad3d286ed02e is also tagged as a fix for 19.3, but doesn't apply
22:10pendingchaos: dcbaker: the backport looks right
22:10pendingchaos:looks at 809c
22:39dschuermann: dcbaker: thx for letting me know, I can create a new MR for 19.3 for 05c81875d7bf871f73f24903e04dad3d286ed02e
22:40dcbaker: dschuermann: Thanks! Please target the staging/19.3 branch and assign it to me.
22:42pendingchaos: dcbaker, dschuermann: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3397
22:42pendingchaos: backport for 809c8feb92d33c43ace3ef25584a2adca24b1be0
22:43dschuermann: slowly 20.0 is diverging from 19.3... are there many more releases on 19.3 planned? :/
22:45dschuermann: when it gets too complicated, we'll probably just leave 19.3 as is (don't expect too much maintenance of experimental stuff in early stage!)
22:45dschuermann: (only talking about aco)
22:48anholt_: Kayden: can you think of anything that I might have missed dumping for comparing before/after on i965 in the ssbo dumping series?
22:49Kayden: I'm honestly at a loss there, everything seems to be entirely in order
22:58dcbaker: dschuermann: Our release policy is that N.1 and N-1.last happen at the same time, ie 20.0.1 and 19.3.last
22:59dcbaker: non-trivial backports really are up to the owners, if you guys don't want to bother with ACO backports for 19.3 we can ignore them
23:03anholt_: yeah, took a more serious look at the assembly today under dwdiff, and it looks great.
23:11anholt_: the final ssbo write isn't storing (at least to the right buffer)
23:24anholt_: awww. ksim fails the testcase even in the "before" case.