07:13 tzimmermann: danvet, how do you feel about making simple_encoder the default for drm_encoder_init() that has no funcs argument?
08:21 danvet: tzimmermann, the trouble I see is that strictly simple_encoder only works with drmm_
08:22 danvet: if if the encoder is embedded into the drm_device structure (well the overall driver struct that also contains drm_device)
08:22 danvet: or by allocating it with kzalloc and having a kfree in your encoder->ops->cleanup function
08:22 danvet: or with drmm_kzalloc
08:23 danvet: so for most drivers which don't have their own ->cleanup there's a bug
08:23 danvet: only exceptions are the simple ones
08:23 danvet: hence why I think we should try to figure out how to cut encoders over to drmm_
08:23 danvet: or at least, how that works together really neatly
08:23 danvet: to make sure we're going in the right direction
08:24 danvet: that was at least my plan, atm I'm busy getting rid of the interim drmm_add_final_kfree :-)
08:24 danvet: pq, thx for writing my reply for me
08:25 danvet: j4ni, you too :-)
08:27 danvet: j4ni, I already mentioned somewhere else that we need this in i915+nouveau
08:27 danvet: or upstream wont care
08:27 danvet: 2nd part implied
08:33 tzimmermann: danvet, just asking before i convert all these drivers to the simple encoder. i cannot use it for writeback connectors, as they are in core and simple encoder is in helpers. but it's no big deal
08:35 danvet: tzimmermann, yeah essentially my idea would be that with the drmm-ification we'd also move the default cleanup to core
08:35 danvet: or something like that
08:36 danvet: but I haven't looked at any of this in detail yet, so my gut feeling is totally out of tune most likely
08:36 danvet: this = drmm + simple encoder
08:36 tzimmermann: danvet, yeah
08:37 danvet: I'm also pondering a lot how to make sure bugs don't come back
08:37 danvet: e.g. if we have a drmm_encoder_init (automatically simple or not tbh)
08:37 danvet: to make sure that drivers _dont_ allocate this with devm_kzalloc (which would be buggy)
08:38 danvet: need to work on some debug patch for devres and discuss that with gregkh
08:38 danvet: but the drmm_add_final_kfree removal I'm working on also has some patch for devres.c already that needs discussion
08:39 danvet: https://cgit.freedesktop.org/~danvet/drm/log/ sneak peek if you want, it starts with "drivers/base: Always release devres on device_del"
08:39 danvet: pinchartl, btw if you have time for some early reactions on https://cgit.freedesktop.org/~danvet/drm/commit/?id=6a39a64d8a5d0b6c6f55b8a0344f75443432b910
08:39 tzimmermann: i thought that drmm-code is supposed to become available for all subsystems? sort of compementing devres?
08:39 danvet: tzimmermann, atm it's drm only
08:39 danvet: well drm_device only
08:42 danvet: that idea was more "could be done if someone is interested"
08:42 danvet: tzimmermann, which other subsystem would you want this?
08:42 tzimmermann: danvet, that's quite a lot of description for a two-line patch :)
08:43 tzimmermann: danvet, i don't know about the other subsystems.
08:46 tzimmermann: danvet, i'm confused by the naming: shouldn't devm_drm_dev_alloc() be called drmm_dev_alloc()?
08:46 danvet: nope
08:47 danvet: because the cleanup action of devm_drm_dev_alloc is a devm action, which calls drm_dev_put
08:47 danvet: so devm prefix
08:47 danvet: it does the drmm_add_final_kfree to set that up, but that will soon be an implementation detail
08:48 danvet: only after the drm_device is set up can you do drmm_ stuff
08:48 tzimmermann: danvet, then it makes sense. thanks for explaining
08:49 danvet: this is the entire problem here, there's 2 distinct auto-cleanup things now, tied to two different lifetimes
08:49 danvet: and often very tricky to figure out which one should be used
08:49 danvet: hence why distinct names (so that people at least ask the question when reading code)
08:49 danvet: and also trying to have debug code to make sure you can't mix them
08:49 danvet: like devm_kzalloc together with a drmm_encoder_init
08:51 tzimmermann: danvet, true. it can be confusing to understand the requirements of when to GC each structure
09:10 pq: danvet, ahaha, you're welcome :-)
09:13 j4ni: danvet: ditto ^
09:14 j4ni: pq: also happy that the responses aren't just i915 centric
09:17 MrCooper: pq: and for me too o/\o
09:19 pinchartl: danvet: for what it's worth, converting test drivers to real drivers is what V4L2 has done
09:19 pinchartl: (well, not convert them, they were real drivers from the start)
09:20 pinchartl: and I think that would be a nice model, as otherwise we may run into other issues caused by the fact they're not real drivers, and will have to fix those too
09:20 pq: This is the best feedback I've got... ever? :-o :-D
09:21 danvet: pinchartl, I guess we can bikeshed that on-list ... it only affects 3 drivers really
09:21 danvet: plus the final cleanup, which I haven't typed yet
11:03 daniels: ivyl: i've pushed a change which will reduce igt-ci-tags impact on fd.o storage cost a little bit, but could you please look into using the ci-templates project? that will make your containers smaller and more efficient, and as a bonus also eliminate a lot of the open-coding you currently do \o/
12:03 ivyl: daniels: thanks! I have switch on my todolist. I had a lovely chat with a some of the people involved and for us this would need few new things in ci-taempaltes first
12:11 daniels: ivyl: oh nice, that's great, thanks
12:11 daniels: ivyl: please let me know how you get on
12:33 danvet: daniels, btw are we tracking anywhere the various project specific efforts for size/bw reduction
12:34 danvet: hm wrong chat
12:34 danvet: maybe for including in Lyude's summaries
12:34 daniels: yeah would be a good one to track, not currently anywhere apart from IRC
13:13 hakzsam: is marge borken?
13:14 danvet: daniels, I guess there's no easy way to search specific issues across all projects?
13:15 danvet: so that we could file issues with projects and still track them globally
13:16 danvet: daniels, like maybe some kind of global milestone we could assign them all to?
13:17 danvet: i can only create milestones for groups
13:17 daniels: not that I'm aware of; the bronze solution is just referencing them all from one fdo master issue and tracking by hadn't
13:18 danvet: well we do seem to have milestones
13:18 danvet: I think that's a recent addition
15:15 MrCooper: shadeslayer: please always check the "Allow commits from members who can merge to the target branch" box when creating an MR
15:16 MrCooper: so others can rebase & control pipelines
15:23 robclark: it would be nice if gitlab could let us make that checked by default
15:26 Venemo: daniels: CI is giving me trouble again. this time it's the x86 build: ERROR: Preparation failed: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
15:30 shadeslayer: MrCooper: oh, I wasn't aware, I'll make sure to keep that in mind next time
15:34 MrCooper: anholt: any idea why Marge isn't merging https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4373 ?
15:36 kisak: MrCooper: Marge Bot @marge-bot merged 1 day ago?
15:36 hakzsam: yeah, it's merged?
15:36 MrCooper: sorry, I mean https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4349
15:37 hakzsam: yeah, it's weird
15:37 hakzsam: oh, pipeline passed this time, it's a start
15:52 shadeslayer: Could someone reassign https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4377 to marge bot?
16:20 hakzsam: MrCooper: marge failed to merge it again but pipeline passed ...
16:30 anholt: MrCooper: https://gitlab.freedesktop.org/hakzsam/mesa/pipelines/127171/builds shows a bunch of erstarts of meson-clang jobs such that the pipeline probably lasted longer than marge's timeout
16:30 MrCooper: no, that's not the issue
16:31 MrCooper: Marge is just sitting there doing nothing even if the pipeline passed
16:31 MrCooper: (or failed)
16:31 hakzsam: yep
16:31 anholt: so, what was going on with those meson-clang jobs in that pipeline?
16:32 MrCooper: some of the packet runners were having issues
16:32 MrCooper: see #freedesktop
16:32 anholt: I hear that, but was that not the pipeline that for marge or something?
16:32 anholt: if that pipeline spanned as long as the "hours ago"s listed in that link, then I would expect marge to time out
16:34 MrCooper: Marge was still sitting there doing nothing even after that pipeline had failed
16:35 MrCooper: until she timed out
16:36 MrCooper: then I restarted the failed jobs and re-assigned the MR to Marge, and she again didn't do anything, even after the pipeline passed, until she timed out
16:37 anholt: hmm. if you restarted the failed jobs then reassigned to marge, I would expect the old pipeline to go from failed back to running, and marge would have the MR back in the queue to be re-rebased and a new pipeline run. but maybe my expectations for marge are wrong?
16:37 MrCooper: that same procedure worked before
16:37 anholt: We unfortunately only get about 3 minutes of logs from marge, so there's not much I can do after the fact.
16:37 MrCooper: Marge just waited for the pipeline to pass and then merged it
16:38 MrCooper: but now she seems to be having trouble getting the pipeline status (notifications) or something
16:39 anholt: don't see any upstream changes to pull
16:39 anholt: for marge
16:42 MrCooper: let's see what happens with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4084
16:55 MrCooper: she merged that, so far so good
16:55 SolarAquarion: i'm interested in this https://gitlab.freedesktop.org/cubanismo/mesa/-/tree/nouveau-improve_format_modifiers
16:56 SolarAquarion: although it's quite a big development afaik because nvidia doesn't like gbm
18:03 hakzsam: daniels: meson-windows-vs2019 seems to take a lot of time before being picked up by a runner
18:03 robclark: anholt: just had a look at scrollback in #freedreno-ci .. # of reported flakes is down *massively* in last couple days :-)
18:04 daniels: robclark: \o/ \o/
18:04 anholt: yeah, I think most of them are just un-rebased branches
18:04 daniels: hakzsam: guess it's popular then ... surprising as it only takes 6min per job and we have one job per pipeline. i'll look at what we can do for capacity.
18:05 robclark: yeah.. the garbage ubwc thing seems to have been the biggest issue..
18:05 daniels: thanks a lot for fixing that up both of you
18:05 hakzsam: daniels: great, thanks
18:44 jcristau: is gitlab the right place to report possible mesa security issues?
18:44 anholt: jcristau: probably, in an issue marked confidential/non-public (for what that's worth)
18:49 krh: robclark: fantastic, nice catch anholt
18:54 anholt: krh: we still need to sort out the initialization bit, but it's nice to have the freedreno flood of intermittent failures in my inbox gone
18:54 anholt: now it's s390x and collabora's lava lab
18:56 ajax: is s390x about flaky tests or about timeouts?
18:57 imirkin: anholt: memset of the uwbc flags fixed everything?
18:58 anholt: ajax: the timeouts
18:58 anholt: I think it's "spinning up 150 qemus takes too long when the system is under load" as we see single-process tests sometimes take a few seconds.
18:59 anholt: we could maybe just crank the timeout on that test up to 5 min or something
18:59 anholt: but "5 minutes of faffing in emulating the compiler" makes me think that we might be doing something silly.
19:01 ajax: the compiler's not emulated, it's cross-building. the tests get emulated.
19:01 anholt: I meant the glsl compiler
19:02 anholt: (and, ftr, I'm pretty sure the "something silly" is "initializing glsl builtins 150 times" and making that less slow is actually hard because we've tried many times already)
19:06 ajax: enh? it's just ninja test, it's not running piglit or anything. there are glsl compiler tests but the format checking stuff is way more of the runtime afaict.
19:12 daniels: anholt: yeah, I don't know why our LAVA lab has so suddenly gone so bad, but I've not seen those failures before. we're trying to work it out, and if we can't then we'll disable it until we can
19:12 anholt: ajax: even a non-timeout job suggests that glcpp tests are the slow ones under qemu https://gitlab.freedesktop.org/llandwerlin/mesa/-/jobs/2130141
19:13 anholt: (compared to formats)
19:13 ajax: blah, clearly i meant blend
19:13 robclark: imirkin: well, it at least fixed teh UBWC related flakes.. (we may still want to move the memset to blitter.. or maybe the hw gives us some bit we can set to indicate that there is no valid ubwc).. there are still some xfb flakes (which is actually nothing to do w/ xfb and something to do w/ varyings.. which might be related to the unexplained nops blob sometimes inserts at start of frag shader)
19:14 ajax: and, tbqfh, the primary reason to want the s390x tests is keeping llvmpipe linking and the format code big-endian-clean
19:14 ajax: so if there's a way to skip those jobs if you're only touching iris, i'm totally fine with that
19:19 mattst88: there are various unit tests in mesa that fail on big endian (u_format_test comes to mind, https://gitlab.freedesktop.org/mesa/mesa/issues/1036)
19:19 gitbot: Mesa issue 1036 in mesa ">=19.0.0 fails u_format_test on x86/ppc/ppc64" [Bugzilla, Opened]
19:20 anholt: mattst88: the tests have incorrect expectations on BE for certain classes of formats, unfortunately.
19:20 mattst88: yeah, that was my conclusion as well
19:21 mattst88: it's somewhere way down my todo list to reinvestigate...
19:21 anholt: (there's also some hilarity in llvmpipe needing formats to be mis-specified on BE in a certain way to work around llvmpipe handling formats wrong!)
19:21 mattst88: just got to make sure you have an even parity of errors
19:21 anholt: it's the big endian way!
19:23 krh: I like big endians and I cannot lie
19:25 anholt: let's try this https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4411
19:34 robclark: jekstrand: nir_from_ssa question.. is this a bad idea? https://gitlab.freedesktop.org/robclark/mesa/-/commit/4ce810a17e7c89a0792bde5d7158baef218af1a7 .. it is a massive help for flow-control-heavy shaders, perhaps *too* good..
19:38 anholt: I'd noticed that pattern back at broadcom, too. would be nice to get a fix!
19:38 krh: huh, yea... seems unfortunate to turn that into a long dependency chain
19:41 jekstrand: robclark: Oh, boy.....
19:41 jekstrand: robclark: In principle, it should be ok but it might break the algorithm
19:41 jekstrand: I would have to give it a VERY careful read to be sure it doesn't
19:42 robclark: I *think* restricting it to ssa should be ok, or at least I've not managed to convince myself otherwise..
19:42 robclark: but it is a pretty massive win in some flow control heavy shaderytoy ;-)
19:42 jekstrand: :)
19:44 jekstrand: robclark: Is it also a win on Intel? We don't have delay slots but a MOV is like 14 cycles
19:46 jekstrand:reads nir_from_ssa code
19:47 robclark: not sure about intel.. this is possibly (assuming correct) the sort of thing we want to make a driver configurable thing?
19:48 jekstrand: Oh, I'm not worried about making it worse. I want to know if it makes something better. :-)
19:48 robclark: could be higher register pressure by keeping the ssa value live longer, too
19:49 robclark: but yeah, I'd assume not having dependent read/write changes could help
19:49 robclark: jekstrand: fwiw, this was the shader I was looking at: https://www.shadertoy.com/view/3l23Rh
19:49 anholt: why, I happen to have a fun little tool here that I would like to throw a perf change at over lunch right now. let me build that hack.
19:51 jekstrand: robclark: My gut is that what you did there is probably mostly correct (might need a bit more tweaking). The primary issue with it is that it leads to registers beeing "freed" more slowly and increases the chance we hit a cycle and have to allocate a new register to resolve.
19:52 robclark: it looks (from a limited # of sample points) like it helps manhattan a bit too, although most of the flow control there is VS
19:53 robclark: jekstrand: hmm, ok.. don't suppose you have an example evil shader? I can look at that some more after lunch.. (at least having an example would help me understand the logic there better)
19:54 jekstrand: robclark: No, I don't
19:54 jekstrand: robclark: But I suspect that, if we restrict to SSA only, we'll be very unlikely to find an "evil" shader.
19:54 jekstrand: robclark: I'm going to shader-db this
19:55 robclark: ok, cool
19:55 jekstrand: robclark: I suspect it's a good idea
19:55 jekstrand: I seem to have recalled thinking about this when I wrote out-of-SSA
19:55 anholt:throwing it at 80 traces
19:55 jekstrand: Which also makes me think I ruled it out for some reason. :-(
19:57 jekstrand: robclark: Ok, I'm pretty sure now that your patch is NOT correct as-is
19:58 jekstrand: Hrm... Or maybe it is?
19:58 jekstrand: Bah. This algorithm is tricky
20:02 jekstrand: robclark: I think I found a better patch that's more obviously correct
20:02 jekstrand: robclark: It also works even in non-SSA cases :)
20:02 robclark: ok, cool
20:04 jekstrand: robclark: How big of a delta did you see in that shader toy?
20:05 robclark: not quite 2x.. but close to it!
20:05 jekstrand: dang
20:06 robclark: so either there is something wrong about my patch, or there are a *lot* of loop iterations ;-)
20:07 jekstrand: I can't remember, is --disable-gpu-sandbox enough to run a custom mesa with Chrome?
20:10 robclark: hmm, oh, yeah, could be you need tha if you are trying to override LD_LIBRARY_PATH?
20:10 robclark: jekstrand: kmscube has a shadertoy mode fwiw ;-)
20:11 robclark: so you can watch clouds on a spinning cube
20:17 jekstrand: robclark: Does this give you the same benefit?
20:17 jekstrand: https://gitlab.freedesktop.org/jekstrand/mesa/-/commit/bc4b3b3ae704cd5c30a3f05677135d4d5c9d3cec
20:17 robclark: let's see..
20:18 jekstrand: robclark: Do you have a simple shader_test file which shows this off?
20:19 robclark: yeah, https://paste.centos.org/view/7a88a556
20:20 robclark: yup, looks like I get the same gain
20:21 robclark:bbiab
20:24 anarsoul: robclark: nice
20:24 anarsoul: (shadertoy mode)
20:28 jekstrand: robclark: I find your numbers extremely suspect
20:28 jekstrand: robclark: Also, the thing that's doing nasty things for you is a constant.
20:29 jekstrand: Which your back-end may not be able to figure out if they're not ssa values.....
20:29 jekstrand: I guess I tend to forget how spoiled we are with FS's copy-prop.
20:30 jekstrand: robclark: Shader-db resulted in no change on Intel
20:31 jekstrand: robclark: Probably because this only tends to come up in reality when you splat 0 out to a vector and things of that like
20:31 jekstrand: I'm going to double-check that shader-db though...
20:31 jekstrand: robclark: Also, That's a tiny change in a very large shader. How does it result in 2x perf?????
20:32 krh: maybe a lot of iterations
20:32 jekstrand: But there's piles of unconditional math in that loop
20:33 jekstrand: I bet it's just twiddling with RA and you're getting massive differences due to that.
20:34 krh: maybe it increases register pressure, which bumps us up into the next register bucket, which let's us pipeline a lot more math...?
20:34 jekstrand: That would also make sense
20:35 jekstrand: In any case, I'm very sure this isn't the real problem
20:35 jekstrand: That said, what it was doing before was stupid if MOVs cost anything at all so I'm happy to land it.
20:40 anholt: no statistically significant perf difference over lunch on glmark2, bgfx, dolphin, humus, supertuxkart
20:49 jekstrand: robclark, anholt: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4412
20:50 jekstrand: No shader-db impact on Intel. I checked twice.
20:50 jekstrand: But I still think it's better so there you go
20:51 jekstrand: Oh, and when I say "no shader-db impact" I'm including cycle estimates. Likely no shader changed at all.
20:51 anholt: well, that would also explain my intel results :)
20:51 anholt: though I find it surprising given how often I remember a pattern like this from v3d days
20:51 jekstrand: I think our copy-prop is just more awesome than yours
20:51 jekstrand: It gobbles through that chain and undoes it
20:52 jekstrand: Those kinds of direct MOV chains are what a good non-SSA copy prop pass eats for breakfast.
20:55 anholt: yeah, I think I got my v3d copy prop to do it, too.
21:04 robclark: jekstrand: yeah, our backend isn't clever enough to clean that up.. I do think that other than generic things (ie. spending less time w/ threads diverged) that it is helping reducing our GPR read conflicts (since a lot of the movs from regA to regB turn into things w/ an immediate encoded, so no GPR read)
21:05 robclark: iirc I wasn't seeing a change in register footprint.. so that isn't the thing for us (but let me double check that)
21:10 robclark: anholt: hmm, I think your query resource_used() change needs some locking?
21:10 robclark: https://www.irccloud.com/pastebin/Fg17MOcp/
21:13 anholt: cool, hidden under #ifdef DEBUG
21:15 robclark: yeah, might be good to do debug builds in CI..
21:18 robclark: jekstrand: yeah, it is helping a lot on GPR reads.. the short version is this shader has a lot of SFU (sin/cos/rsq/etc).. which like tex/mem instructions execute async.. ie. they even read their src regs and begin exec async from alu instructions.. the hw can sustain 2 gpr read per cycle, which is cool if you are all 2src alu instructions.. but throw in mad's and SFU/TEX also competing w/ ALU instructions to read
21:18 robclark: from register file and you start getting stalls.. so replacing those mov's w/ mov-from-immed helps
21:18 robclark: https://www.irccloud.com/pastebin/Goetz3bJ/
21:41 anholt: my trace perf testing tool is now updated with renderdoc support: https://crates.io/crates/gpu-trace-perf
21:55 jekstrand: anholt: Doesn't inserting a timestamp query per draw nuke perf?
21:59 robclark: shouldn't really.. although timestamp is less useful for tilers
22:03 robclark: (well, it has some effect on perf.. but not as bad as needing a WFI between draws)