06:59 Venemo: jekstrand, do you think it would be OK to make nir_opt_copy_prop_vars a little less zealous about barriers?
07:01 Venemo: I would like to use it to help same-invocation TCS output writes, but it refuses to cooperate with me because it finds a control_barrier or a memory_barrier_tcs_patch
07:02 Venemo: at a quick glance, if I remove nir_var_shader_out from apply_barrier_for_modes for these two barriers, it does help do what I need it to do, and this doesn't seem to break any of the tessellation related CTS tests, either
07:42 daniels: austriancoder: I've used Weston with the headless backend successfully
08:31 linkmauve: Hi, it happens extremely rarely, but sometimes when coming back from suspend, there is a fixed tearing in Weston, using iris on a kbl, but I once had the same issue using i965 on an ivb.
08:31 linkmauve: It happened maybe thrice since I got this computer, exactly one year ago.
08:33 linkmauve: The tearing shape is a horizontal line with a (I think) 16px vertical jump towards the top, then it finishes as a horizontal line.
08:33 linkmauve: And the bottom is always drawn earlier than the top.
08:34 linkmauve: It always appears when I unsuspend my computer, and will disappear again once I do another cycle of suspend/unsuspend, so it isn’t much of an issue once I know the workaround.
08:34 linkmauve: But still, I’d expect I’m not the only one this has happened to, especially given it happened on two different gen.
08:41 MrCooper: sounds like it ends up blitting to the front buffer instead of flipping
08:44 MrCooper: hmm, or maybe draws the next frame to the buffer which is still getting scanned out
08:55 linkmauve: I have no idea how to debug that.
09:00 MrCooper: it's likely a weston issue either way
09:04 linkmauve: Oh?
09:04 linkmauve: I was expecting an i915 module issue.
09:05 linkmauve: Since Weston AFAIK doesn’t do anything different from usual, it uses the DRM API as normal to submit the buffers for scanout.
09:05 pq: danvet, do you see a problem with implementing DRM device removal in Mutter by listening to uevents for device removed and then closing all fds to the device? I'm asking because I think it would be new userspace behaviour. A small step towards device hot-unplug.
09:06 linkmauve: Even surfaces put on planes have this issue.
09:08 MrCooper: it sounds like weston gets confused about which buffers are currently being scanned out
09:08 linkmauve: In the case of planes, Weston doesn’t even draw anything itself, it does an atomic flip using the client-provided buffer.
09:14 danvet: pq, should work
09:14 MrCooper: linkmauve: right, so it sounds like weston sends buffer releases for buffers which are still being scanned out, so the clients overdraw them
09:14 pq: danvet, thanks.
09:14 danvet: the rough idea for hotunplug uapi I have is that everything keeps working more or less (connectors probably all go to unplugged, pageflips might dummy out, but stuff like mmaps shouldn't result in SIGBUS since no one will handle that)
09:15 danvet: then you get the uevent, process it
09:15 danvet: and once all file descriptors are gone the kernel garbage-collects the memory and everything
09:15 danvet: but note this is the plan, there's lots of gaps
09:15 danvet: e.g. dma-buf aren't refcounting stuff correctly yet, nor dma_fences
09:15 pq: danvet, yes, that's the plan I remember hearing. Cool.
09:15 danvet: and mmaps might simply disappear and you die in SIGBUS
09:16 danvet: at least for all current usb or spi or otherwise "actually behind a cable you can unplug" drm_devices the mmaps should survive
09:16 danvet: since they're just system memory
09:16 danvet: the sigbus will be more for pci devices or stuff behind thunderbolt
09:16 linkmauve: MrCooper, wouldn’t that cause artifacts inside of the plane, and still be fixed when moving it?
09:17 danvet: pq, might be good to document that aspiration in drm-uapi.rst?
09:17 danvet: if you start using it
09:17 pq: yeah, I don't yet care about what happens between the physical device disappearing and uevent being processed. Part of the exercise is to figure out what explodes in EVDI, but it would also be a shame to not send the Mutter code upstream if we write it.
09:17 danvet: uh evdi
09:17 pq: yeah
09:17 MrCooper: linkmauve: maybe I misunderstood, I thought you were saying the same tearing occurs inside of planes
09:18 danvet: obviously no guarantees about the fireworks show there :-)
09:18 linkmauve: MrCooper, the same tearing happens everywhere, as if scanout started in the middle of the frame.
09:18 pq: heh, seeing the fireworks is the point - in fact EVDI more or less never removes the device, it has to be manually forced
09:19 pq: danvet, can you point me to a guide telling me how to make and submit a change to drm-uapi.rst? Like what branch to base on.
09:19 MrCooper: linkmauve: so you're saying the tearing occurs across plane borders?
09:19 linkmauve: Nothing different about planes, if I didn’t know Weston was using them I wouldn’t be able to differentiate them in this issue, but since I know they are planes I think it points towards i915.ko doing something weird.
09:19 linkmauve: MrCooper, yes.
09:20 danvet:mumbles apologies about kernel process
09:20 linkmauve: I have a plane, I move it, I can see two halves of the plane moving at different locations.
09:20 pq: I know how to work git-send-email, but the rest is a fuzz :-)
09:20 MrCooper: linkmauve: ah yeah, that sounds like a kernel driver issue then, sorry I misunderstood
09:21 danvet: pq, pick anything recent, drm-uapi.rst doesn't change that much
09:21 pq: danvet, so like, Linus' master? That's the only branch I know of.
09:21 danvet: the official standard recommendation is linux-next, but that's a rebasing horror-show
09:21 danvet: pq, I guess drm.git's drm-next might be marginally better and still reasonable
09:22 pq: oookay
09:22 danvet: https://cgit.freedesktop.org/drm/drm/ <- this one
09:22 danvet: pq, but for drm-uapi.rst linus' latest -rc should be fine too
09:22 pq: thanks, I'll note this down
09:23 danvet: pq, my dream is you just do a gitlab pull
09:23 danvet: and if you picked the wrong repo/tree, we'd just move the pull around
09:23 danvet: like we move issues
09:23 danvet: with a comment like "please rebase on this other tree thx"
09:23 danvet: because figuring out which tree is indeed impossible
09:24 danvet: aside from "use linux-next" which is rebasing, so totally breaks merge requests and assumes you got through git send-email
09:24 danvet: </rant>
09:40 pq: linkmauve, ooh, that sounds like very fancy breakage. Makes me wonder how it's even possible. :-)
09:42 linkmauve: Me too!
09:42 linkmauve: It’s happened maybe a dozen times in five years I’ve been using Weston, on two different computers.
09:43 linkmauve: It also is the only time I’ve seen a perfectly static tearing shape, it never moves from frame to frame.
09:46 lebomees1: really exceptional scientists who never understood how adders work, how the fuck are such people courageous enough to violate me?
09:47 linkmauve: Here is approximately how it looks: https://linkmauve.fr/files/tearing-shape.svg
09:48 linkmauve: With the red part being the newest frame, and the transparent part the older one.
09:53 pq: linkmauve, so it's not just a single horizontal tear line, it has steps?
09:55 linkmauve: Yes.
09:55 pq: I guess that is an interesting clue.
09:55 linkmauve: A small one, and a big one.
09:56 linkmauve: IIRC it used to be just one big step.
09:58 lebomees1: Maybe i should personally contact Linus Torvalds with my proposals to pimp up his operating system, i see sane path or way out of your maddness with minor work, i do not even know why they use video engines in the hw, you have not got it stable either , and those codecs do not make sense at all too.
10:10 lebomees1: it is a little bit bad situation where we have so many hardware which should be supported vastly better, we should be thinking not on the clicks and bugreports anymore with rewards towards broken code, but push something saner , maybe community does help funding some of the efforts instead.
10:26 lebomees1: Actually red hat recent hirings, karol seems like an ok C developer, but he needs to be little guided more to have sanity behind what he does, same thing with the other new guy maybe, i have mostly looked karols C code though!
10:27 lebomees1: he knows how to code in C; but....
10:58 Venemo: I don't think personal insults should fly on this channel
10:59 daniels: Venemo: everyone agrees on that - this is a troll who's been around for 10+ years, which is why he's banned on sight
11:00 Venemo: oh, the same troll? I didn't realize
11:02 XenoPL: Hey, is Axel Davy hangin' around here? I'm looking for some help with crashes of app using wine-nine
11:02 Venemo: XenoPL: yes, he goes by the nickname mannerov
11:03 XenoPL: Venemo: thanks
11:07 daniels: Venemo: yeah, you get pretty good at spotting it by the 11th year
11:43 danvet: MrCooper, is there (and where) amdgpu tests for userptr and gpu reset?
11:44 danvet: nothing big, just enough for lockdep to observe the code paths once
11:44 danvet:working on some new lockdep annotations
12:19 pepp: kusma: the new website looks great (oddly on Firefox when the red/green gears starts rotating they move down a bit)
12:39 kusma: pepp: Thanks! Yeah, I've noticed, but I actually believe that's a FF bug, as I can't find a reasonable reason for it :/
12:41 kusma: I haven't bothered reporting it to FF yet, but I guess I should do that soon...
13:10 MrCooper: danvet: try amdgpu_test in libdrm, or just cat /sys/kernel/debug/dri/*/amdgpu_gpu_recover :)
13:11 danvet: MrCooper, thx
13:11 danvet: I've set stuff on fire with modeset already, so not quite there yet for the cs side of things :-)
14:09 jekstrand: Venemo: If you can do so while maintaining correctness, sure. :-)
14:10 jekstrand: Venemo: Just because it doesn't cause failures for any CTS tests doesn't mean it's correct. It could just mean we need more CTS tests. :-P
14:10 alyssa: bugs that don't show up in the CTS are my favourite
14:46 Venemo: jekstrand: how do you deal with tcs output loads and stores on intel?
14:50 jekstrand: We read/write URB memory
14:51 Venemo: I wrote a NIR pass which lowers a cross-invocation tcs output load into a same-invocation load, and a subgroup intrinsic
14:53 Venemo: if I can teach copy_prop_vars to deal with barriers better, this will result in eliminating a bunch of stores and loads, and passing the values in registers
14:54 Venemo: not sure how expensive subgroup operations are on your hw, but if they are faster than URB memory, then maybe this can help you, too
14:56 Venemo: the only problem we've found is that this is wrong to do inside divergent control flow.
14:58 Venemo: but that can be worked around by simply skipping the lowering inside divergent cf
14:59 danvet: MrCooper, will I regret this when I run amdgpu_test while my desktop is running?
15:04 MrCooper: you might
15:07 Venemo: do you think this would be interesting to you, jekstrand?
15:29 jekstrand: Subgroup operations are very cheap for us
15:29 jekstrand: The difficulty is getting the invocation -> subgroup mapping correct
15:30 Venemo: what seems to work is load_subgroup_invocation - invocation_id + vertex_index
15:31 Venemo: should be OK as long as you can be sure that patches are not split between different subgroups.
15:33 Venemo: if the output vertex count is 1, then of course all vertex indices can be trivially replaced by the invocation id
15:33 Venemo: and if it's 2 or 4, I use quad_swizzle_amd or quad_broadcast
17:05 pcercuei: is there an API function to test a modeset state without committing it?
17:07 mripard: pcercuei: the atomic API has a flag for that iirc
17:08 pcercuei: context is, I would like to enhance the fbdev emulation layer so that drm_fb_helper_check_var() actually checks that what's requested is supported
17:09 mripard: ah, so not from userspace then
17:09 pcercuei: from kernel space, indeed
17:11 mripard: the function that implements it in the kernel is drm_atomic_check_only
17:13 pcercuei: awesome, thanks
17:14 mripard: I'm not sure how easy it would be to access the state fbdev is trying to use though
17:21 dcbaker: hakzsam: I had to make a few changes to a couple of your patches near the top of the staging/20.0 branch to get them to compile. Can you have a look and make sure they're okay?
17:21 hakzsam: yes
17:22 hakzsam: looks good
17:27 dcbaker: thanks
17:41 danvet: mripard, fbdev emulation is fully atomic nowadays
17:41 danvet: we build up the full state nowadays
17:42 danvet: pcercuei, it's not just check_var, but multi-screen should also check whether something would work with TEST_ONLY
17:42 danvet: just no one got around to it yet
17:51 thaytan: airlied, did you get the Rift S EDID quirk patch I emailed you last weekend? I sent it direct, because I wasn't sure which list to direct it to
17:59 danvet: thaytan, dri-devel
17:59 danvet: if it's meant for upstream
17:59 danvet: scripts/get_maintainers.pl will tell you
18:01 thaytan: danvet, ta
18:11 pcercuei: danvet: this is what I have so far: https://github.com/OpenDingux/linux/compare/afb849ffe4a5...for-upstream-modeset
18:11 pcercuei: with that, the userspace is able to request a mode using the fbdev API
18:12 pcercuei: but right now it assumes that the mode will be supported, that's the missing piece of the puzzle
18:12 danvet: pcercuei, hm do we _really_ need that many formats?
18:12 danvet: like RG and GR
18:12 danvet: or R formats
18:12 pcercuei: don't think so. This is very WIP
18:12 danvet: that sounds very funky if there ever existed an fbdev userspace that could drive this
18:14 danvet: pcercuei, I'm not seeing the mode stuff
18:14 danvet: lots of pixel format changes
18:14 danvet: but not where the mode is updated
18:14 pcercuei: the mode stuff is in drm_fb_helper_restore_fbdev_mode_unlocked()
18:14 danvet: pcercuei, for mode checking the big question is what you're going to do with multi-screen
18:14 pcercuei: I just make sure that the struct drm_fb_helper is updated prior to that
18:15 danvet: yeah but I only see you updating format related stuff
18:15 danvet: well and blindly adjusting pitches, that will probably go boom on many drivers
18:16 danvet: you can't just divide by cpp and then multiply by the new cpp
18:16 danvet: there's all kinds of alignment constraints normally
18:16 pcercuei: thought so :)
18:16 pcercuei: right now only the format is updated, indeed
18:17 danvet: I'd just leave pitches as-is
18:17 danvet: shouldn't hurt for lower bpp
18:17 danvet: and for higher bpp we can't reallocate anyway
18:17 danvet: plus default starts out with 32bit xrgb anyway, and you're not going to support anything with more than 4cpp
18:17 pcercuei: it wouldn't work if the buffer is CMA
18:18 danvet: so I dont think this will be a real world issue
18:18 danvet: ?
18:18 pcercuei: and your LCD controller can't do scatter-gather
18:18 danvet: fix your lcd controller :-)
18:18 pcercuei: fix the hardware?
18:19 danvet: except if you add an fbdev specific hack, there's no way for you to figure out the new pitch you need
18:19 danvet: so whatever you do, your code wont work on a bunch of things
18:20 danvet: you could reallocate, but fbdev really hates that
18:21 danvet: but the bigger problem is figuring out what you're going to do with multi-screen
18:21 danvet: since fbdev doesn't even have that as a concept
18:23 pcercuei: I could support the pitch being higher than the pixel line actually, since the DMA built in the video hardware supports chained descriptors. But that means one descriptor per line
18:25 pcercuei: about multi-screen, what's the problem exactly?
18:25 pcercuei: The way I understand it (which is certainly wrong) is that different screens mean different planes
18:25 pcercuei: unless you clone
18:27 danvet: pcercuei, it's more about what you're going to do with it
18:28 danvet: atm we're trying to light up native resolution everywhere
18:28 danvet: because that looks better with lcd panels generally
18:28 danvet: but then tell fbdev that only the smallest screen is available
18:28 danvet: so that you can see fbcon no matter which screen you look at
18:28 danvet: on higher-res screen fbcon simply sits in the top-left corner
18:29 danvet: so what are you going to do if you get a resolution change
18:29 danvet: both for smaller than smallest screen, and when you get one bigger than smallest screen's native resolution
18:29 pcercuei: control only the "primary" screen?
18:29 danvet: only thing that's clearly a reject is bigger than biggest
18:29 danvet: oh
18:30 danvet: can of worms
18:30 danvet: there's no primary screen
18:30 danvet: fbdev has 1 screen
18:30 danvet: kms has multiple
18:30 pcercuei: my setup is, a built-in 320x240 LCD, and a HDMI output. So there is no combination that allows me to show anything on the two screens at the same time
18:32 pcercuei: if you think adding modeset to the fbdev emulation is too complicated, I'll throw the towel and try to update my userspace instead (adding a DRM backend to SDL1)
18:36 danvet: pcercuei, I think modeset is doable
18:36 danvet: and I'm assuming these are 2 different gpus, so each has its own fbdev
18:36 danvet: so you can set independently
18:36 danvet: it's just we need to come up with something
18:36 danvet: one option could be that for single connected screen we change the native resolution
18:37 pcercuei: one LCD controller, whose DPI output is connected in parallel to the small TFT screen and a HDMI encoder (IT6610)
18:37 danvet: for multiple we just say "nope sorry"
18:37 pcercuei: there's a GPU but it's render-only
18:37 danvet: multiple on 1 single kms device
18:37 danvet: oh
18:37 danvet: hm more complicated
18:37 danvet: so you get native resolution on hdmi, but a 320x240 fbcon?
18:38 pcercuei: I get a 720p (max resolution of the CRTC) framebuffer if the HDMI is connected at boot time
18:38 pcercuei: I get a 320x240 framebuffer on the internal screen otherwise
19:47 kisak: https://gitlab.freedesktop.org/daniels/mesa/-/jobs/2599875 windows container builds blocks all CI and marge because there's only one runner?
19:49 airlied: thaytan: I did, but then promptly forgot to go back to it, if you can send it to dri-devel list someone will apply it :-)
19:49 daniels: kisak: it runs multiple jobs in parallel, but yes, building LLVM is a pretty tough DoS. we've been working on getting more capacity
19:52 tanty: daniels, do you have or can make an estimation of how many runners are needed for a specific target to be included in the CI ?
19:53 tanty: I mean, which is the minimal number of jobs that need to be run in parallel for a specific job (for a specific arch+gen) to not the the CI?
19:53 tanty: s/not the/not block/
19:56 daniels: tanty: depends how long your runs are. most of the ARM hw CI targets have 3 or 4 executors which has so far been enough for ES3, but for 3.2 + GL + VK, you need ... more. maybe ask anholt about utilisation of fdno runners
19:56 kisak: daniels: thanks, I was pondering why https://gitlab.freedesktop.org/daniel-schuermann/mesa/-/jobs/2602201 hadn't started and while all the other CI jobs were done for the next merge. Some unfortunate observational timing on my part.
19:59 daniels: kisak: yeah it is frustrating. hopefully we can hear back soon on more Windows capacity, but in the meantime we hopefully shouldn't need to be doing any more LLVM rebuilds for a while
19:59 tanty: daniels: thanks!
20:41 anholt: tanty: we've got 6 runner boards per chipset (4 core ARMs each, approximately, and CPU is limiting factor in dEQP), and that was more than enough even when all pipelines ran jobs.
20:41 anholt: you could probably get away with 4 these days -- you still want enough that you can run at least one pipeline's jobs (gles2, 3, 31, hopefully some day piglit, hopefully some day desktop GL) in parallel
20:42 anholt: and you want to have enough in place that things aren't on fire when one of them dies on you.
20:42 anholt: (we have 8 or 9 boards per chipset, and have lost a couple each early on)
20:43 anholt: I think I figured at this many boards, I could do an overnight run of full vk daily, and MRs just do a partial run unless you trigger a manual full run.
20:43 anholt: (manual would be the non-MR pipeline)
20:52 anholt: mripard: I've been assuming that your pi4 hdmi stuff is proceeding fine without my involvement. let me know if anything needs my blessing.
21:49 mripard: anholt: I'd still like a review at some point on the vc4 side, I don't really know that well the older ones so I might be missing something there
21:49 mripard: but the v3 is going to change a bunch of stuff, so you can skip the v2 if you feel like it :)
21:50 anholt: any chance for v3 we could get the series in manageable subsets? sitting down for 30 hard patches is challenging.