02:12 airlied: Lynne: https://paste.centos.org/view/raw/5c6e47cb
02:13 airlied: seems to work for me, but lots of hackys
02:17 airlied:tries to refocus on dg2/av1
02:41 Lynne: airlied: very hacky
02:49 airlied: Lynne: I think taking the gap between the aligned ptr and the 4096 you added to slices was the most important thing
02:49 airlied: else there are frames where you don't map in enough pages and the gpu goes off the end
03:24 dakr: mbrost, this is Danilo
03:46 airlied: Lynne: if ff_vk_video_common_init fails, the uninit gets called twice
04:19 Lynne: encode or decode?
04:19 Lynne: should be encode, right?
04:20 airlied: yeah this was decode
04:21 airlied: vulkan_decode.c:1086, if it fails, it goto fail; which calls ff_vk_decode_uninit which calls the ff_vk_video_common_uninit
04:21 airlied: but that was already called inside ff_vk_video_common_init fail path
04:27 Lynne: what fails? is it the call to free the session?
04:29 airlied: Lynne: yeah I get a second call to destroy session and hit an assert
04:34 Lynne: pushed a fix
08:59 mripard: danvet: yep, fine by me
10:25 danvet: daniels, ^^ add ogabbay to drm-misc group pls?
11:06 ogabbay: daniels: I believe my ssh account name in fdo is actually gabbayo
12:25 DavidHeidelberg[m]: mupuf: where is your https://pypi.org/project/gfxinfo-mupuf/ ? :P
12:26 mupuf: DavidHeidelberg[m]: shit, what was still using this?
12:26 DavidHeidelberg[m]: mupuf: CI? :P
12:26 mupuf: Give me a job, please
12:27 DavidHeidelberg[m]: .gitlab-ci/container/debian/x86_test-vk.sh
12:27 DavidHeidelberg[m]: 71:pip3 install gfxinfo-mupuf==0.0.9
12:28 DavidHeidelberg[m]: sergi: ^ noticed when testing upreving
12:28 mupuf: I see
12:28 mupuf: sorry about this...
12:28 mupuf: valve-gfx-ci.gfxinfo is the project that should have been used
12:28 mupuf: I'm writing an MR
12:28 mupuf: and actually, not even sure why we still need that
12:29 mupuf: yeah, not needed
12:29 DavidHeidelberg[m]: mupuf: I guess you could sent MR without rootfs uprev, if it's not used
12:29 mupuf: on it ;)
12:30 DavidHeidelberg[m]: so we don't have to go trough all rebuild because of one drop
12:30 mupuf: yeah
12:31 mupuf: DavidHeidelberg[m]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20956
14:51 daniels: ogabbay: done!
16:01 ogabbay: daniels: thx
16:28 KungFuJesus: so here's a fun bug - accelerated X11 on big endian renders fonts mirrored (specifically in xterm and other terminal emulators). Any idea where to first look?
16:29 KungFuJesus: oh apparently I was googling wrong? https://gitlab.freedesktop.org/xorg/xserver/-/issues/1011
18:10 nanonyme: airlied, I noticed you disabled glthread from radeonsi in Fedora 37. What was the regression that resulted in that?
18:13 nanonyme: I'm trying to save time debugging texture corruption issue with suspiciously similar package combination
18:15 nanonyme: Ah, it was just lagging typing. Sorry, moving on. Will handle normally.
19:55 airlied: nanonyme: lots of gtk, gstreamer stuff broke, hope to fix it in f38 and reenable glthread
20:15 jenatali: Do people have opinions on how much we should consider vulkan/wsi/win32 common code? It supports lavapipe and Dozen. I'm wondering about how long I should wait before merging, how many reviewers, whether I need to add r-b tags, etc
20:20 Frogging101: kwin broke as well
20:47 DemiMarie: <jenatali> "Are you including Windows and..." <- They are closed source so do not count.
21:02 Ristovski: Has anyone looked into how well Sources `mat_queue_mode 2` (named "Multi-Core rendering" in L4D2/CS:GO) interacts with mesa_glthread=1?
21:02 nanonyme: airlied, we had a major regression in flatpak runtimes when updating to LLVM 15 and Mesa 22.3.2->22.3.3 and hit texture corruption with basically everything
21:03 nanonyme: We're not yet at this point able to prove if it's related with that same glthread thing. So I was thinking of trying to get more info from you on the symptoms on Fedora
21:05 nanonyme: airlied, did it look similar to this? https://matrix-client.matrix.org/_matrix/media/r0/thumbnail/matrix.org/2023-01-27_LkhGkNizbWzgvyYZ?width=100&height=100&method=scale
21:06 nanonyme: Maybe glthread enablemenet should simply be reverted in 22.3?
21:11 airlied: that doesn't look too good, but yeah that might be like it
21:12 airlied: nanonyme: the problem is it's uncovering app bugs, so we'd like to get those fixed if we can, since they are potential bugs on nvidia as well
21:12 cmarcelo: hakzsam: hi, there's a big MR we've been working on that will change slightly how certain constructs in SPIR-V are mapped. most of the cases the NIR will be the same, but in some situations we'll see less nested ifs and more "one iteration loops" loop { something something something; break }... I was wondering if you could run some tests from radv perspective, mostly to increase confidence that this
21:12 cmarcelo: won't regress performance for radv: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17922
21:12 zmike: cmarcelo: he won't be back until monday since it's weekend there
21:12 airlied: but yeah I do wonder if 22.3 should drop it for now, I think tarceri_ proposed a change, but mareko would have to decide
21:13 cmarcelo: zmike: ack! thanks!
21:16 nanonyme: airlied, we can't repro the regressions mesa-git flatpak extension that ships 28d6caad605bcb206f73c6ba11d27f4c982efa89 so I'm assuming there's something that's been integrated after 22.3.x series that helps
21:17 nanonyme: Repro them with that even
21:18 nanonyme: So I'm not confident it's just apps if Mesa changes fix things and glthread is still enabled in trunk
21:19 nanonyme: Haven't yet done bisecting on if there is something specific after which the screen corruption goes away
21:21 Ristovski: nanonyme: This only affects apps running with the flatpak runtime, right?
21:21 airlied: nanonyme: is it only on amd hw? if so that points towards glthread
21:24 nanonyme: airlied, largely, yes. According to reports even gtk3-demo was sufficient reproducer
21:25 airlied: okay then I'd just disable glthread until at least the gtk3 fix makes it way through
21:27 nanonyme: The hairy thing here is I don't think Steam uses Gtk at all and it's affected as well (that is, the store). But yeah, I'll try your change. We pushed previous runtime version out as immediate mitigation anyway.
21:31 nanonyme: Ristovski, not clear. We don't really target the level of distro-like activities to have something to run on physical hardare
21:31 nanonyme: I guess I could ask from gnome if they have a commit with known problematic GL stack
21:32 Ristovski: I see. fwiw the "Store" parts of Steam use CEF afaik
21:43 mareko: airlied: I'm OK with turning off glthread in 22.3
21:43 mareko: airlied: that's for the default enablement, not app profiles
22:26 nanonyme: airlied, at least one AMD RDNA3 user reported they were not affected. I will start trying to gather hardware info from users who hit the problem...
22:53 mareko: the 22.3.2->22.3.3 regression is very unlikely to be caused by glthread, glthread would affect all 22.3.x equally
22:53 mareko: flatpak is problematic because it contains its own version of Mesa, which can be incompatible with the host Mesa
22:55 mareko: using multiple versions of Mesa could cause some really nasty hard-to-figure-out issues
22:58 nanonyme: Well, currently biggest issue is flatpak made rollbacking too simple so we didn't really get to gather enough data during the incident.
23:12 nanonyme: mareko, I thought Mesa developers anyway reached consensus anyway a year or two ago that compat is important because if you break compat, you make git bisecting painful
23:13 nanonyme: And it was also covered distros are routinely doing development work of future releases through apps in containers
23:16 mareko: yes, we don't break intentionally
23:16 mareko: it
23:17 kisak: nanonyme: peanut gallery question, was LTO enabled with your snafu as well?
23:17 mareko: bisecting is already an ordeal due to LLVM incompatibilities
23:20 mareko: if you need to go back by more than 6 months, you're basically screwed with LLVM