08:30 pepp: airlied: mareko was faster than me. Thanks for the fix :)
08:53 ivyl: Sumera: lsgpu should be build/tools/lsgpu if you are building igt yourself
09:12 MrCooper: airlied: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7957 should fix it
09:14 MrCooper: JEEB: it would be better to explicitly clear only new back buffers when they are allocated; zerovram is a bigger hammer, yet it may not always help (if the BO is reused from a user-space cache)
09:16 JEEB: well, I was noted that there might not be a way to fix from the client's perspective on X11 w/ EGL
09:17 MrCooper: I mean in Mesa GLX/EGL/DRI3 code
09:17 JEEB: ah
09:17 JEEB: ok
09:18 pq: JEEB, clearing new buffers is a security fix to stop information leaks. I don't think you should be assuming that clearing happens to produce opaque black always (in fact, with RGBA, the clear would be to fully transparent, not black, when cleared to zeros - but you should not assume zeroes, IMO).
09:18 JEEB: yea, I agree with that
09:19 JEEB: that's why my initial question was "how do I best figure out where things are going awry"
09:19 JEEB: instead of "you're doing stuff differently to other implementation, pls fix"
09:20 JEEB: but I guess I'll just have to figure out at which case the surfaces get exchanged and a new one gets installed
09:20 JEEB: because we had a full-blown re-fill of a buffer at each render call, which ended up killing perf on apple+intel
09:20 JEEB: and it did not fix resizing windows
09:20 JEEB: on amdgpu
09:20 JEEB: so clearly there's some uninitialized/-set memory somewhere leaking
09:21 JEEB: or well, not sure if I used the right amd driver name, sorry.
09:23 JEEB: for me putting an open source application onto the zerovram compatibility list is the worst alternative, which is why I popped up here to see if I could get any hints on how to figure out where the issue happens on the user space side
09:24 pq: JEEB, X11 garbage on resize is fundamentally unfixable, AFAIU, though I'm not sure if participating in the X11 hand-shake protocol with the WM might help, and it might depend on whether a compositing manager is used or not, etc. - I forgot the name of the hand-shake
09:25 JEEB: yea, so if that happens to no longer happen if zerovram is set then I'd almost say that then that's it?
09:25 pq: I'd say it's a hack ;-)
09:26 pq: JEEB, maybe this might be relevant? https://fishsoup.net/misc/wm-spec-synchronization.html
09:27 MrCooper: JEEB: to be clear, setting zerovram for mpv only helps (i.e. it's not needed for Xorg as well), right?
09:28 JEEB: MrCooper: according to LaserEyess and the reporter of the issue on the mesa issue tracker who actually are affected by this note that yes, that's enough
09:29 pq: JEEB, the fundamental issue on X11 from what I understand is that the window system can resize your window from under you, and resizing means allocating new buffers that contain "garbage". Then it tells you about this afterwards, and your rendering will catch up with the new size at some point, but in between you are drawing to buffers not of the size you thought they are.
09:29 MrCooper: pq: since clearing new buffers on the client side fixes the corruption, it's not the problem you're thinking of
09:30 MrCooper: though that is definitely a potential issue with Xorg as well
09:30 pq: MrCooper, you mean that if it was, one would need the zerovram flag on X server to make a difference?
09:30 MrCooper: yep
09:32 pq: MrCooper, hmm... Mesa GL allocates a new buffer on the first draw call as needed, right? So could it be that client-side Mesa has already seen the new size, but the app code has not had a chance to see it, hence still drawing with old size?
09:32 pq: into new-sized buffer
09:33 MrCooper: yeah, something like that
09:33 amonakov: if there's a compositing wm involved, client-side zeroing helping makes perfect sense, no? the window buffers are shared between the wm and mpv, and Xorg is not involved?
09:33 pq: and if the app uses e.g. Scissor, that would mean glClear would be ineffective as well
09:34 MrCooper: amonakov: the initial window pixmap is always allocated by Xorg, so the issue described by pq is still possible if the client doesn't post contents for the new size in time
09:36 pq: I suspect that looking at the buffer alloc side is a dead end, and something like the NET_WM resize protocol would be the proper solution?
09:37 MrCooper: Wayland is the proper solution :)
09:37 pq: assuming one must stick to X11 :-P
09:38 amonakov: pq: I'd look into how much mpv may delay SwapBuffers after receiving a resize notification; probably right now it can delay by as much as inter-frame time gap
09:39 amonakov: pq: if so, a possible solution is to redraw once immediately after receiving a resize event
09:39 pq: amonakov, but any timing based solution is prone to racing anyway, isn't it?
09:39 JEEB: if you're interested in an apitrace in case it could show SomethingObvious which mpv is doing badly, I think the mesa bug report by aufkrawall contained such
09:40 yshui`: I am seeing some weird behavior of GLSL, which I don't know if it's a bug of Mesa or I am doing something wrong. Can someone help?
09:40 amonakov: pq: yes, but as said, it's an unfixable race in X11, so best we can aim for is to minimize the race window
09:40 pq: ..but maybe it'd fix it by 95%
09:41 yshui`: Basically, I am doing `if ( c == vec4(0.0,0.0,0.0,0.0) ) discard; else gl_FragColor = c;`, and the pixels aren't rendered
09:41 yshui`: but if i just do `gl_FragColor = c;` then it works
09:41 pq: amonakov, yeah, but there is the NET_WM protocol I referred to...
09:41 yshui`: i know this code is weird, just want to know if there is a bug here
09:42 MrCooper: pq amonakov JEEB: the _NET_WM_SYNC protocol can work, *if* the app only ever queues one buffer swap
09:42 pq: yshui`, what do you expect to see when you discard; ?
09:43 MrCooper: otherwise the X server will use the contents from the first pending swap, which will correspond to the old window size
09:43 yshui`: the discarded pixels have alpha 0, they won't appear in either cases
09:43 yshui`: but in the first case, the pixels that shouldn't be discarded also don't appear
09:44 pq: yshui`, oh that kind of issue. No idea.
09:44 MrCooper: yshui`: discard in divergent control flow is not allowed in GLSL
09:45 yshui`: ah, is that so? that would explain it.
09:45 yshui`: thanks.
09:45 MrCooper: hold on
09:45 MrCooper: I may be mixing something up
09:46 HdkR: discard in divergent control flow is valid. You're probably thinking of the derivatives in divergent flow quirk?
09:47 MrCooper: yeah, I was, sorry for the noise
09:49 yshui`: ok, then is this a bug?
09:49 MrCooper: discard would be a bit useless if it could only work for constant conditions :)
09:50 MrCooper: yshui`: apparently; which driver/HW are you testing on?
09:50 yshui`: AMD, mesa
09:51 yshui`: I am on ef9362acb81
09:52 yshui`: I can tell you what I was running if you want to know.
09:52 MrCooper: hmm, none of the discard related piglit tests seem to be failing here at least with radeonsi
09:58 yshui`: i can see if this happens on intel
10:04 yshui`: it behaves as expected on intel
10:05 yshui`: really smells like a bug now
10:06 yshui`: let me try downgrading mea
10:12 yshui`: not working on 20.3 either
10:43 yshui`: and it works fine on llvmpipe
11:18 hakzsam: panfrost CI failures unrelated to the MR https://gitlab.freedesktop.org/mesa/mesa/-/jobs/6008551
11:56 yshui`: i can't read GCN ISA...
11:56 HdkR: It can be a bit of a mindfsck when looking at it initially
12:02 MrCooper: it passes :)
12:12 yshui`: can someone help me a little bit? or should I just open a bug report?
12:22 HdkR: If a renderdoc capture repros then an issue might be the easiest route yshui`
12:23 yshui`: it's not renderdoc capable, but code of the project is available.
12:36 yshui`: reported as https://gitlab.freedesktop.org/mesa/mesa/-/issues/3942
12:45 pepp: yshui: "Another composite manager is already running" - how do you run picom?
12:45 yshui`: you need to stop whatever compositor you are already running. depends on what desktop environment you use.
12:46 amonakov: doesn't picom offer the --replace command lnie flag?
12:46 yshui`: it only replaces another picom instance
12:52 daniels: hakzsam: rectified now I believe, thanks
12:52 pepp: yshui: I can't reproduce it using "startx ./build/src/picom --corner-radius 20 --backend glx --config /dev/null"
12:52 hakzsam: daniels: thanks, trying again
12:52 yshui`: so the round corner works in both cases? pierre-eric
12:54 pepp: yes (I'll double check to be sure that radeonsi is really used and not llvmpipe)
12:54 yshui`: I am using a 5700XT, maybe it's only reproducible on that?
12:58 HdkR: Oh, I had completely forgot about that gungeon issue
13:05 HdkR: Definitely haven't tested to see if Gungeon works without issue on latest version :P
13:08 baryluk: amonakov: picom doesn't have --replace
13:09 yshui`: baryluk indeed. i must misremembered
14:16 pepp: yshui: what llvm version are you using?
14:16 yshui`: pierre-eric: 11.0.0
15:02 yshui`: thanks for looking into this
17:25 paulk-leonov: hi
17:26 paulk-leonov: just wondering something: I have a device with a LCD on a 8080 interface and a parallel interface (with a HDMI bridge) connected to the same CRTC
17:26 paulk-leonov: so obviously I can only use one at a time
17:26 paulk-leonov: is there a way in DRM to dynamically allow switching between the two?
17:27 paulk-leonov: (also, 8080 interface currently isn't supported, or am I mistaken?)
17:27 paulk-leonov: that's the device: https://linux-sunxi.org/F60_Action_Camera
18:22 kusma: jenatali: Sure, great 6
18:22 kusma: Uh, yeah. Forget about that one :)
18:22 jenatali: :P
19:13 jenatali: After reading a bunch of code, I think I know the answer to this, but just checking... is there a driver today that does hardware rendering + software present?
19:14 airlied: jenatali: zink kinda
19:14 jenatali: airlied: Oh hm, let me look closer there
19:17 airlied: jenatali: I think screen->winsys being set indicated the sw paths
19:18 airlied: and zink_screen.c:zink_internal_create_screen has how it's setup
19:18 jenatali: airlied: Yeah, I'm chasing it back a bit more but thanks for the pointer
19:28 jenatali: airlied: Of course that means I did a bunch of work for next-to-nothing (so far, at least)... *sigh*
19:53 ardera: good evening
19:53 ardera: i'm trying to self-build mesa to debug some graphics problems on my Pi 4
19:54 ardera: I'm using the options "-Ddri-drivers=", "-Dgallium-drivers=vc4,v3d", "-Dglx=disabled", "-Dplatforms=drm" and debug buildtype
19:56 ardera: however, when using these self-compiled mesa binaries with my OpenGL ES project, mesa fails to load the correct driver and (tries) to fall back to the software rendering driver "swrast_dri.so"
19:56 anholt: one of the missing pieces is you haven't enabled kmsro
19:57 ardera: thanks, I'll try compiling with that
20:00 ardera: worked, thanks!
21:26 airlied: anholt: is it your rust runner that doesn't print times so well
21:26 airlied: Pass: 9690, ExpectedFail: 36, Skip: 29185, Timeout: 1, Duration: 5:2, Remaining: 4:2
21:26 anholt: airlied: it's fixed in the uprev in ci-asan
21:26 airlied: ah cool
21:27 anholt: yeah, big whoops
22:53 Kayden: yikes. so I fixed the sse and sparc assembly for things reading GLmatrix::inv[]
22:53 Kayden: but it looks like there's a bunch more stuff reading GLmatrix::m[] that I missed, in the SSE, x86, 3dnow, and sparc code
22:54 HdkR: Just delete 3DNow, save yourself the trouble ;)
22:54 Kayden: I am kind of wondering how valuable this code really is after some of the optimizations to the general code
22:55 mattst88: 3DNow in particular is pretty much never going to be used. I assume the SSE code implements the same stuff, right?
22:55 Kayden: yeah
22:55 HdkR: 3DNow isn't even available on the latest AMD CPUs at this point
22:55 mattst88: if so, the only CPUs that have 3DNow and not SSE are AMD K6-era chips
22:56 HdkR: (Aside from prefetch but that's a different bit)
22:56 Kayden: heh, Tim actually deleted the 3dnow normal code in 2014 saying it'd been turned off for a decade
22:57 mattst88: oh, I'm kind of wrong. the original Athlon CPUs didn't have SSE
22:57 mattst88: so things older than Athlon XP
23:13 anholt: +1 to removing 3dnow at this point
23:14 anholt: we can't even in theory make unit tests to check that it still works on current hw...
23:24 glennk: fwiw i think qemu supports 3dnow...
23:26 HdkR: I could also add 3dnow to my emulator, but I see no need until I find an application that uses it unconditionally :P
23:29 anholt: glennk: good point if so