07:04 mlankhorst: airlied: am I too late if I send a pull request in the next hour?
07:04 airlied: mlankhorst: for fixes or next?
07:04 mlankhorst: -next
07:04 airlied: yeah go for it, should be fine
07:05 mlankhorst: ok thanks, will do!
07:16 mlankhorst: What happened with drm-misc-next-2023-10-19 btw?
10:08 swick[m]: sima: the atomic commit state validation that's currently done on the current state to a new state, you said we'd need to change all drivers over to use arbitrary state to arbitrary state to improve the situation
10:09 swick[m]: sima: but why? can't we change one driver at a time and expose some cap or new uAPI?
10:32 yrlf: Company: emersion: if you use wl-mirror fullscreen on the same output it's recording it basically always displays a 1 frame old image
10:32 emersion: it depends on the timings
10:32 emersion: the outputs' refresh rates are not synchronized
10:32 yrlf: that it does
10:32 yrlf: that creates a pretty trippy "draw with your mouse" effect
10:33 emersion: oh, "on the same output"
10:33 emersion: then yeah, exactly 1 frame late
10:33 yrlf: yeah, wl-mirror is also still a pretty naive client. I think I'm not doing everything correctly with DMA-BUF import yet
10:34 yrlf: export-dmabuf works, but the dmabuf from the pipewire screencast (in my feature branch) displays black (with no gl errors)
10:34 emersion: ah, pipewire fun
10:34 yrlf: I need to check screencopy with dmabuf, and see if that behaves the same way
10:35 emersion:has nightmares with SPA_Pod in them
10:35 yrlf: the DMA-BUF from xdg-desktop-portal-wlr is created with libGBM i believe, which I am not using at all yet
10:36 emersion: you shouldn't need to use GBM
10:36 yrlf: oh god, SPA_Pod and the whole format negotiation shenanigans is ugly
10:36 emersion: grab the FDs+metadata from pw, pipe that into linux-dmabuf
10:36 yrlf: I need to import the buffer into gl, for some of the other effects wl-mirror is using
10:37 emersion: then you can use the EGL import API without GBM
10:37 emersion: GBM is mainly useful for allocating buffers
10:37 emersion: but you shouldn't need to do that
10:37 yrlf: afaik i'm using that EGL API already, but I'm not sure what's going wrong, since the buffer is just blank
10:48 columbarius: yrlf: for the negotiation stuff look at the PipeWire plugin in obs
10:51 sima: swick[m], the drivers you could convert easily are not the drivers where you want to know the answer ...
10:52 sima: so yeah we could do it one-by-one, but we kinda have been trying to push that ground work for years ...
10:53 sima: so at the current pace you'd never get this feature for the drivers where you actually want it
10:53 sima: plus to validate the uapi we'd need at least one such more complex driver where this uapi extension does something
11:15 pq: yrlf, texture min/mag modes in GL? Those helpfully default to "black screen" values for imported dmabuf, IIRC.
11:18 yrlf: columbarius: yeah, I've taken a lot of insights from the obs code, but currently my format negotiation is still very stubbed out, will expand that
11:19 yrlf: pq: thanks for the hint, will take a look; though I'm confused why the behaviour is different between wlr-dmabuf-export and pipewire
11:22 pq: yrlf, do you verify you don't get any EGL or GL errors? Have you tried https://docs.mesa3d.org/envvars.html#envvar-MESA_DEBUG ?
12:29 yrlf: pq: no mesa debug output, even when setting MESA_DEBUG=flush,incomplete_tex,incomplete_fbo,context
12:29 yrlf: I'll try to dig further; manually setting GL_TEXTURE_MIN_FILTER and MAG_FILTER after every dmabuf import also hasn't resulted in any change in behaviour or log output
12:36 pq: yrlf, so you have the same code path doing the same things, and for some dmabuf you get a good picture and for some you get black?
12:36 yrlf: yup!
12:37 pq: smells like driver failure to indicate failure :-p
12:37 yrlf: common code path: https://github.com/Ferdi265/wl-mirror/blob/706bbdff54562df498cc2ec0f92289786d8f4f2d/src/egl.c#L456
12:37 yrlf: working call site: https://github.com/Ferdi265/wl-mirror/blob/706bbdff54562df498cc2ec0f92289786d8f4f2d/src/mirror-dmabuf.c#L182
12:37 yrlf: non-working call site: https://github.com/Ferdi265/wl-mirror/blob/706bbdff54562df498cc2ec0f92289786d8f4f2d/src/mirror-xdg-portal.c#L990
12:38 yrlf: I think I'll try to find different hardware (non-intel) or try force mesa to run my entire desktop session in llvmpipe and check if the same happens
12:43 gfxstrand: airlied, karolherbst: We should consider switching to the LLVM SPIR-V back-end.
12:43 gfxstrand: I'm sitting through a presentation on it right now and aparently they have it compiling the entire OpenCL CTS so it should maybe be ready for us to use.
12:44 gfxstrand: This is different from SPIRV-LLVM-Translator
12:46 karolherbst: yeah...
12:46 karolherbst: with LLVM-17 or LLVM-18?
12:47 karolherbst: gfxstrand: but yeah, I'd be open for this, just need to check how much issues it would cause down the line. Anyway, is this all upstream already? And what's the ETA on availability?
12:48 gfxstrand: It's all upstream now
12:48 gfxstrand: IDK what version. I'm going to ask.
12:48 karolherbst: cool, thanks
12:49 karolherbst: airlied: that means we should also look into updating libclc to use that
12:49 karolherbst: would remove some distribution packaging pain
12:49 karolherbst: but that's assuming it can build libclc :)
12:50 gfxstrand: 17 should be okay, or so they claim
12:50 karolherbst: mhhhh
12:50 karolherbst: doubt, but okay
12:50 karolherbst: gfxstrand: mind asking how that looks like in regards to optimization levels?
12:51 karolherbst: because with the translator only O0 is supported
12:51 gfxstrand: -O2 and -O3 both work
12:51 karolherbst: okay
12:51 karolherbst: assuming they don't push annoying to optimize spirv to us, that would help a lot
12:51 karolherbst: okay, yeah I can look into it then once I'm done with all the zink stuff :D
12:52 karolherbst: worst case the first step is a runtime/compile time flag
12:57 gfxstrand: They're asking for bug reports. :)
12:58 karolherbst: cool
12:59 gfxstrand: And it has a properly LLVM legalize pass in front of it so it should be a lot more robust.
12:59 karolherbst: the only change for us is to use the spirv target and compile a bit furhter or somethign, right? Might be good to have some "what you need to change" slide, but shouldn't be hard to figure out
12:59 gfxstrand: Yeah, we just need to figure out what knobs to tweak to get LLVM to spit out SPIR-V directly instead of linking against and using SPIRV-LLVM-Translator.
12:59 gfxstrand: It would also mean Mesa can drop a dependency which would be nice.
13:00 karolherbst: I think I already done so in the past and the main difference is to use `spirv` instead of `spir` as the llvm target
13:00 gfxstrand: right
13:01 karolherbst: the sad part is, that clover doesn't use clc
13:01 karolherbst: the good part is airlied had patches
13:07 gfxstrand: There's an easy solution to that. ;-)
13:08 karolherbst: heh
13:08 karolherbst: yeah. fix r600
13:09 karolherbst: maybe we should amber clover...
13:24 gfxstrand: I'm a fan of amber clover
13:26 alyssa: do it
13:30 gfxstrand: Okay... new plan. We need to write a new compute-only gallium driver for nvidia that uses NAK. Let's make NVIDIA's OpenCL implementation obsolite.
13:35 tnt: does zink work over nak ?
13:42 gfxstrand: Trying to go through Vulkan is kind-of a pain still
13:56 gfxstrand: dcbaker: For now, I think I'm going to just update my meson wraps to set native:true inside the meson.build in the project.
14:03 gfxstrand: dcbaker: Okay, that gets it to configure but now I'm getting "^^^^ maybe a missing crate `core`?"
14:41 gfxstrand: cwabbott: Does turnip support tessellation?
14:43 zmike: yes
14:43 cwabbott: gfxstrand: yes, why?
14:46 gfxstrand: Tweaking the SPIR-V parser a bit and trying to make sure I get all the tess-capable drivers
14:52 karolherbst: gfxstrand: mhhhhh
14:52 karolherbst: I could do that I guess :D
14:53 karolherbst: unless somebody else wants to
14:54 karolherbst: but yeah... might also be a good idea to start a new gallium driver as compute only and see if that's even feasible
14:54 karolherbst: though.. radeonsi already does so with some of their GPUs
15:01 gfxstrand: karolherbst: We don't need to think about that for a bit.
15:01 gfxstrand: Just thinking that if we're going to amber all of nouveau GL, we might still want to keep enough around for rusticl.
15:01 gfxstrand: But use the new UAPI and everything
15:01 karolherbst: ohhhh
15:01 karolherbst: right...
15:01 karolherbst: does amber even support gallium?
15:01 gfxstrand: That sounds easier than revamping the entire GL driver.
15:01 gfxstrand: It should
15:01 karolherbst: yeah.. totally agree
15:01 karolherbst: and starting from compute might be a good idea anyway
15:02 gfxstrand: IDK how much we'd have to backport, though.
15:02 karolherbst: mhh.. yeah
15:02 karolherbst: well
15:02 karolherbst: sometihng we can keep in mind
15:02 zmike: amber2 ?
15:02 gfxstrand: We could make amber2
15:02 gfxstrand: jinx!
15:02 karolherbst: yeah....
15:02 zmike: I guess one of us has to take an extended vacation
15:02 karolherbst: I also don't know how hard it is to amber frontends
15:02 karolherbst: especially clover as it's so cursed
15:03 karolherbst: might have to merge this first https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/833
15:03 karolherbst: but....................
15:03 gfxstrand: Yeah, IDK
15:03 karolherbst: dynamic pipelader and amber doesn't work well together
15:03 karolherbst: on the other hand, we have nothing using it besides clover
15:03 karolherbst: sooo...
15:04 gfxstrand: Yeah, IDK
15:04 gfxstrand: Honestly, the clover+r600 that's in amber today is probably fine.
15:04 gfxstrand: We could back-port some fixes
15:05 karolherbst: r600 is in amber?
15:07 zmike: jenatali: can you check out https://gitlab.freedesktop.org/mesa/mesa/-/jobs/50879853
15:08 wv: I have this strange issue. cog/wpewebkit is running on mesa/freedreno. But I need to do some true pixel manipulation. Only the pixels I set may be set. Canvas is fullscreen and there is no scaling whatsoever. If I take a screenshot using webinspector it works fine. If I do a weston-screenshooter, it appears the pixels on top are also manipulated.
15:08 wv: https://pasteboard.co/0pX8YFTrtrGh.png
15:09 wv: but I have no clue what causes te pixels on the top. I already disabled dithering in freedreno (which is working as I already see banding now on gradients)
15:10 wv: but still something is interfereing
15:13 jenatali: zmike: Can it wait until next week? This is my last day of parental leave :)
15:13 jenatali: (re-sent since I forgot to auth)
15:14 zmike: jenatali: I guess? today's my last day for the year, so it won't get touched again until 2024
15:14 gfxstrand: Ooh, spicy!
15:15 karolherbst: anyway.. maybe I can file for rusticl on zink conformance like this or next week... :D
15:15 jenatali: zmike: ooh well that's bad timing
15:16 zmike: I didn't expect to be affecting anyone :/
15:16 jenatali: I don't have a set up to investigate right now so it wouldn't be a quick thing for me to look today, otherwise I would try
15:16 zmike: nbd
15:16 zmike: probably nobody will touch any of this for a few months
15:17 gfxstrand: Yeah, I think it can wait until January
15:17 gfxstrand: It's not like that error hasn't been missing for half a decade or more.
15:17 zmike: pipe down captain jinx
15:17 gfxstrand: :P
15:18 gfxstrand: That's Queen jinx to you! 😂
15:19 zmike: 👏👏👏
15:19 zmike: I'll be expecting full glcts conformance on nvk when I get back
15:19 jenatali: zmike: from the title of the MR and the fails/unexpected pass, it looks like there's some texture format(s) that fail to create in our driver
15:20 zmike: the XPASS I assume is just more correctly detecting a failure case, but the others are likely returning no support for some cases
15:20 jenatali: The new fails are ones that didn't try to use it and so they could query properties about it even though it internally failed to create
15:20 gfxstrand: https://www.youtube.com/watch?v=wIM1erbld5Q
15:20 jenatali: The new pass is a test that treated that format as optional and handled failure, but since the failure didn't bubble up, it just saw wrong results
15:21 jenatali: So just update the baseline
15:21 jenatali: Maybe file an issue on me too?
15:21 zmike: if you're okay with that then sure
15:21 zmike: gfxstrand: oh I didn't consider that
15:22 jenatali: Yeah. I really need to drive our fail list down, it's already way higher than I want. Adding a few more isn't a big deal
15:22 zmike: cool
15:24 karolherbst: I hope I haven't added any regressions in the meantime not caught by CI :')
15:36 zmike: anholt_: are you able to update your reviews today? I'd like to get things merged before I leave
15:42 pH5: g l
15:43 pH5: apologies, keyboard focus mishap
15:58 alyssa: jenatali: btw any plans for higher gl versions in glon12?
15:58 alyssa: or for dozen features to get dozenk up to gl4.6?
15:58 alyssa: zmike: is dozenk the right term
15:58 zmike: 😬
15:59 alyssa: type-c emoji
15:59 zmike: zenk?
16:00 ccr: :D
16:01 ccr: "Zenk" sounds like a laundry detergent brand.
16:02 zmike: I was thinking along the lines of https://knowyourmeme.com/memes/woll-smoth
16:03 zmike: robclark: seems like this affected you too https://gitlab.freedesktop.org/mesa/mesa/-/jobs/50882989
16:03 jenatali: alyssa: yeah, we've got active requests for 4.3
16:03 jenatali: But once we get there is really not much more to get 4.6
16:03 ccr: a cheap knock-off of the well-established Zink brand, "Zenk"
16:05 jenatali: alyssa: but also I have no idea what management's priorities for me will be. I've seen some emails that seem to promise I'll make 4.3 happen though
16:06 cmarcelo: for those who deal with compilers, I'm collecting input about renaming glsl_type (and some other small changes) in this issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10046
16:09 alyssa: jenatali: haha fair enough
16:09 alyssa: yeah, 4.0 seems to be the biggie
16:11 zmike: jenatali: I tagged you on the MR since it's not going to be mergeable today in any case
16:11 zmike: whenever you get to it is fine
16:19 jenatali: alyssa: we're already at 4.2
16:19 jenatali: zmike: 👍
16:21 robclark: zmike: hrm, wha?
16:21 zmike: no idea tbh
16:21 zmike: just adding gl errors to gl error cases
16:38 lileo: robertmader[m]: i've been following your direct-scanout development on mutter (nice!) I remember coming across a gitlab comment mentioning that you're looking into using libliftoff at some point. Just curious, what's the challenge with using it today?
16:38 lileo: Curious since I'm working on adding underlay support to libliftoff
16:39 lileo: maybe some of those challenges can be addressed along the way
16:39 robclark: zmike: so fd is rejecting some of the resource_from_memobj because the memobj is too small.. not sure if this is tu or test bug. (But also seems like the same tests failed before your MR, just with a different error)
16:42 robclark: zmike: possibly tu is picking linear and fd is picking UBWC?
16:42 zmike: 🤔
16:43 robclark: I'm not entirely sure how this is _expected_ to work because modifier isn't passed explicitly
18:04 robclark: zmike: can the EXT_external_objects thing be used across process, or only within the same process?
18:04 zmike: good q
18:05 DemiMarie: alyssa: congratulations on geometry shaders!
18:05 zmike: I'd have to review the spec more carefully
18:07 robclark: looks like it expects semaphores to be shared across process.. but not so clear about memobj's
18:09 robclark: or rather the uuid part mentions cross process, so I guess that is implied to apply to both semaphores and memobjs
18:16 jenatali: My gut says across processes
18:24 robclark: yeah, I could maybe get away without new kernel uabi if it wasn't cross process, but I think I'm not getting off so easily :-/
18:34 zmike: alright I'm off, see everyone next year! 👋
18:34 ccr: have a nice vacation :)
18:34 robclark: \o
18:51 javierm: sima, airlied: would there be another PR of drm-misc-next for v6.7 ?
18:56 javierm: or are we in that time where drm-misc-next-fixes should be used instead for fixes of patches that are going to land in v6.7 ?
19:08 airlied: mlankhorst: did i miss a mr? ill chexk later
19:13 airlied: gfxstrand: add functions calls to NAK :-)
19:15 airlied: javierm: should be in misc-next-fixes.time
19:23 javierm: airlied: thanks. And I guess that can cherry pick from drm-misc-next then if landed there
19:24 airlied: yup, though mlankhorst did send a late misc next pr
19:24 airlied: so check that
19:27 bl4ckb0ne: is it me or there's no way to get an EGL context reset notification strategy
19:28 javierm: airlied: I see. Sigh, I missed mlankhorst for hours :(
19:30 javierm: Ok, will cherry-pick then
19:37 javierm: dim cherry-pick pollutes the kernel history though because the same commit is twice, right ?
19:43 karolherbst: what's the best way to profile GPU memory usage of an application?
19:43 karolherbst: on vulkan
19:47 robclark: perfetto does device some memory related trace events.. not sure if anyone hooked those up.. Otherwise, nvtop?
19:49 karolherbst: "This version of Nvtop is missing support for reporting Intel GPU memory, power, fan and temperature" :')
19:51 karolherbst: well, in the end I just need something which tells me what memory I'm not freeing
20:02 javierm: airlied: hmm, but first I need to wait for drm-misc-next to back merge drm-next since is still in v6.5-rc2 ?
20:03 javierm: this is just a fix for a DT binding schema warning in a uncommon driver. I'll ask Rob if really wants this to be in v6.7 or could just wait for v6.8
20:25 mlankhorst: It only happens as needed
20:31 javierm: mlankhorst: I see. My vote would be to just wait for this DT binding fix to land in v6.8, it's basically just a fix for a doc warning so not worth the trouble IMO
20:31 javierm: I've asked Rob, let's see what he says
20:34 gfxstrand: airlied: Yeah... one day.
20:35 karolherbst: okay.. I think I found my last CL on zink bug 🙃
20:35 karolherbst: somehow the amount of mapped memory raises over time
20:36 karolherbst: *rises
20:39 HdkR: Woo, no more CL on Zink bugs, it was the last one!
20:39 javierm: airlied, mlankhorst: actually, I could just wait for drm-misc-fixes to be back merged and land it as a part of the -rc cycle. I'll do that, thanks again
20:39 karolherbst: HdkR: I haven't said I fixed it yet :D
20:39 HdkR: Finding the cause is halfway to fixing it :P
20:40 karolherbst: somehow not all memory gets unmapped
20:56 karolherbst: ahhhhhhhhh
20:56 karolherbst: it's a multithreading bug
20:56 karolherbst: RIP myself
20:59 alyssa: karolherbst: rewrite zink in rust
20:59 karolherbst: alraedy on it
20:59 alyssa: you have 2 months before zmike is back
20:59 karolherbst: zmike just haven't noticed yet
20:59 alyssa: i'll rb as a christmas present
20:59 karolherbst: yeah
21:00 karolherbst: but where is the data race...
21:01 karolherbst: atomics within a locked region also make total sense
21:02 karolherbst: ehh maybe in this case it does