00:15Lynne: I don't think debugPrintfEXT works fine, it's reporting all push data is uninitialized (yet it's working)
00:45Lynne: yup, debugprintfext is broken, writing the data to a buffer says my push data is fine
02:22kode54: that +M annoyed me once again
05:08Lynne: the more I look at it, the more it looks like a radv issue...
06:20Lynne: seems like I fixed it, not sure which of the millionth refactorings did it
07:45MrCooper: kode54: FWIW, if you identify with NickServ, it changes your nick to the identified one, even if you're on +M channels
08:02danvet: javierm, tzimmermann I just learned about dev_err_probe ... is this something we should roll out to helpers like component.c or maybe the various probe helpers for bridge/panel?
08:02danvet: pinchartl, ^^
08:02danvet: it sounds pretty cool
08:02danvet: also automatically ties into device_set_deferred_probe_reason() infra
08:02pinchartl: danvet: it's a very nice helper, I like it
08:03danvet: it's very neat indeed
08:03danvet: just wondering whether we should do a gpu/todo.rst entry
08:03danvet: it seems to be one of the really good things which is just a notch to hard for cocci
08:03pinchartl: the only issue I can think of when using it in helper is that you make sure those helpers will only be called from a probe path
08:04pinchartl: and I'm not sure what would happen if the driver then called dev_err_probe() a second time in the error path
08:04pinchartl: this needs to be checked
08:04danvet: uh, maybe not quite so awesome, because device_set_deferred_probe_reason doesn't stack :-(
08:04danvet: pinchartl, yeah I just checked, it doesn't do the right thing
08:04danvet: so you cant just splatter this all over in common code
08:05danvet: but also shouldn't be too hard to make it a stack that resets on every probe attempt
08:06danvet: hm what was andrzej hajda's nick again
08:08javierm: danvet: I believe that doesn't stack because otherwise printing the deferral reason in /sys/kernel/debug/devices_deferred would be tricky
08:09javierm: or do you mean to print the first element (i.e: original deferred reason)?
08:10danvet: javierm, well just make it a logfile really
08:10danvet: like on every probe reset it to nothing, then record them all
08:11danvet: so you could do something like the shared panel lookup code could print something, then the driver, then maybe even component.c
08:11kode54: 19:21 -NickServ- You are connected using SSL and have provided a matching client certificate
08:11danvet: and you'd get the entire stack of how the probe_defer cascaded through
08:11kode54: it doesn't make this association until I take the main nick
08:11danvet: and don't have to make sure that there's only ever one to avoid accidentally overwriting the improtant one
08:11danvet: like if it doesn't stack we can't add something to component.c
08:12kode54: and the substitute nick is random
08:12danvet: because it might overwrite the one that matters
08:14javierm: danvet: right
08:19MrCooper: kode54: "/msg NickServ identify <password> kode54" and it will change your nick to kode54
08:19javierm: danvet, pinchartl: what we can do is to make deferred_probe_reason a list and then print something like: 'rockchip-drm 13970000.hdmi: can't find GPIO for bridge -> couldn't look up bridge'
08:19javierm: or something like that
08:20danvet: robclark, tzimmermann should we volunteer Dmitry Baryshkov for drm-misc commit rights? it's mostly msm stuff but I guess would help with pushing the non-msm patches
08:20danvet: robher, ^^ (I have no idea who's still at linaro doing gpu stuff)
08:20tzimmermann: danvet, no objections from my side.
08:23javierm: danvet, pinchartl: then device_set_deferred_probe_reason() could add another node to the list of probe deferral reasons
08:24kode54: MrCooper: that requires me to switch to my password keeper to retrieve my password
08:24kode54: client doesn't have it stored because it's in certfp auth mode
08:25kode54: either way, something I have to do manually any time it happens
08:33emersion: you can thank OFTC for having a server from prehistory
08:59mareko: does NIR have a utility returning whether an SSA def post-dominates another SSA def?
09:09danvet: robclark, https://lore.kernel.org/dri-devel/?q=20230405081650.797972-1-daniel.vetter%40ffwll.ch <- pls r-b
10:53javierm: tzimmermann: I've a very hard time trying to read Sui Jingfeng's email do how they format the text...
10:54javierm: *due
10:54danvet: something breaks lines and inserts an empty newline after that
10:55danvet: it does read a bit like a peom
10:56javierm: danvet: yeah, and also there are some underscore characters dropped randomly it seems
11:02dottedmag: danvet: javierm: One of their e-mail passed through GPT-4 with prompt "improve formatting, do not change text": http://paste.debian.net/1276381/
11:05danvet: lol
11:07javierm: dottedmag :D
11:08javierm: dottedmag: need to add an emacs script that does this :P
11:26dottedmag: javierm: You've got it https://github.com/stuhlmueller/gpt.el#usage
11:28javierm: dottedmag: cool
11:38DavidHeidelberg[m]: zmike: Valve traces seems to be still a bit flaky with zink+a630, is that expected? https://gitlab.freedesktop.org/mesa/mesa/-/issues/8782#flakes-errors-per-tests-top-10
11:38zmike: uhhhh
11:39zmike: I don't know?
11:39zmike: I ran them a bunch locally last week on a630 and they seemed fine
11:39zmike: beyond that I'm not sure I can comment
11:42javierm: danvet: I've reviewed your changes and look good to me. AFAICT the only blocker is the gma500 patch
11:50lina: Here's a thing I just stumbled upon while trying to optimize buffer formats... https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22311
11:51lina: I have no idea whether that makes sense though, would appreciate comments ^^
11:58DavidHeidelberg[m]: eric_engestrom: it almost passed :D haha, never mind, thanks for resolving the flake
12:00daniels: lina: tl;dr everything just works if the driver just does what it's told to and doesn't try to be too clever
12:00eric_engestrom: DavidHeidelberg[m]: yeah, sorry about forgetting to `--stress`-test the move to arm64 runners :/
12:01DavidHeidelberg[m]: haha, I need to finish that "reminder MR template"
12:01eric_engestrom: :P
12:04lina: daniels: How does the modifier stuff work with SCANOUT then? Right now when we get SCANOUT we force linear and create a dumb scanout resource at the display controller then import it, but if there is high-level negotiation of modifiers that doesn't make much sense...
12:04robher: danvet: neither do I not being at Linaro. :)
12:04lina: I really need to figure out how to not get highlights on "linaro"... ^^;;
12:05robher: linaro, linaro, linaro
12:06lina:might have fixed it ^^;;
12:07jannau: linaro, linaro, linaro
12:07lina: Yay! ^^
12:09daniels: lina: does DCP require allocations to be done from a dedicated area, or can it (provided it's linear) import dmabufs allocated by another device?
12:10jannau: it should be able to import and has its own iommu
12:10lina: It should be able to import them, and it can also handle compression though we haven't worked that out yet (nor whether it's the same exact compression we already support in AGX or something special)
12:11daniels: aight, so in that case don't overthink it. if EGL tells you to allocate only linear, then allocate only linear. if EGL tells you that you can allocate compressed, then allocate compressed :)
12:11lina: And do nothing special with the SCANOUT flag?
12:12daniels: as long as your compositor supports zwp_linux_dmabuf_v1 v4 (terrible naming I know), and you expose your modifiers via the EGL queries as well as KMS IN_FORMATS, everything will just work
12:12lina: How do the buffers end up mapped at DCP via kmsro then? On demand?
12:13daniels: kmsro and clients are very different
12:13daniels: clients won't (well, shouldn't ...) be using kmsro
12:13lina: I think they are... somehow...
12:14lina: glxgears hits the dev->ro && (templ->bind & PIPE_BIND_SCANOUT) codepath
12:20daniels: heh ok, which compositor?
12:20lina: kwin
12:21lina: (on xwayland)
12:21lynxeye: daniels: If the compositor provides the kms device node to the client, then the client will end up using kmsro
12:21daniels: I haven't looked too much into KWin, but I suspect it might be https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12796
12:23lynxeye: lina: even if the app isn't fullscreen the compositor might end up putting it on a plane, which might have different tiling, etc. capabilities than the renderer.
12:23lina: Yeah...
12:24lynxeye: the best way is really to rely on dmabuf-feedback for the modifiers and not do anything "clever" in your driver
12:25lina: So it should work if we just switch to GPU->display imports and don't apply any restrictions on scanout?
12:25lina: I think only vc4 does it like that now, all the other drivers seem to create buffers on the display side
12:25lynxeye: lina: PIPE_BIND_SCANOUT doing something special on some kmsro drivers is really just to work around the issue that some display engines need allocations that can't be satisfied from the GPU side (e.g. contig memory)
12:26lynxeye: lina: If your display engine is behind a iommu it should be able to deal with GPU buffer allcoations, so there is no need to allocate from the display side
12:28lynxeye: lina: and especially don't force linear, just because it's a scanout allocation. Rely on the modifier to tell you which layout can be used.
12:33lina: OK, I just tried doing it that way and the actual import works, but at least glmark2-es2-drm ends up with a compressed modifier DCP can't handle. I wonder if we're implementing that right on the DCP side...
12:35lina: As far as I can tell the KMS driver is listing only LINEAR as a supported modifier.
12:36daniels: lina: if you run wayland-info, which version of zwp_linux_dmabuf_v1 does kwin support? if it's not v4 then the protocol is missing
12:36lina: (This is glmark2 on raw kms so far, haven't tried kwin yet)
12:36lynxeye: might be a compositor issue. Without dmabuf feedback you get all supported modifiers, which includes the one that only the renderer can handle. With dmabuf feedback the compositor should send a preferred tranche with only the linear modifier when it determines that the app could go onto a plane
12:36daniels: oh right, in that case it's glmark2-es-drm's fault; it almost certainly doesn't parse the IN_FORMATS blob which it really should
12:37daniels: (dmabuf-feedback == zwp_linux_dmabuf_v1 v4)
12:39lina: It looks like it doesn't specify any modifiers at all
12:39lina: It probably makes sense to force linear for SCANOUT without any explicit modifiers?
12:40lynxeye: yea, at least that's what etnaviv does also.
12:45lina: OK, that works and fixes the glxgears issue, and kwin still works! ^^
12:45daniels: ++
12:46lina: Now I think the last thing to do is make the scanout export lazy (only when the handle is created), because otherwise we still end up with the glxgears buffer mapped to the display controller for no reason.
12:58lina: OK, that fixed it for the buffer on the glxgears side... but now XWayland is asking for the KMS handle for the glxgears surface and that causes it to be mapped to the display controller.
12:58lina: That has to be wrong, there's no reason for Xwayland to be trying to get KMS handles, is there?
12:59daniels: lina: Xwayland certainly does some pretty cursed things with GBM, and I would strongly suspect that MR I linked above would be what's leading it to pick the wrong device
13:00lynxeye: lina: There are a lot of legacy places in gallium that use a kms handle export to query properties of the resource. resource_get_param was introduced a lot later.
13:02daniels: I do need to get around to trying to help figure out that EGLDevice MR at some point, but all of the device-handling code is absolutely cursed, and it was also right around when all the DRI refactoring was in progress, so I figured if I waited it out then things might improve ...
13:02lina: ^^
13:03lina: OK, I'll punt on this one for now, hopefully it won't bite us too much
13:07daniels: if linear truly bites hard, you could always do the shadow-resource thing where you present the app a tiled buffer, then do a linear blit at end of frame (signaled by pipe->flush(PIPE_FLUSH_END_OF_FRAME))
13:09lina: It'll have to be some kind of heuristic, but then again maybe this is pointless once DCP supports compression anyway...
13:11daniels: heh, yeah
13:12daniels: lina: out of interest tho, if you run wayland-info against your version of kwin, what version does it say zwp_linux_dmabuf_v1 is, and if it's version 4, what does it say the main device is?
13:13lina: interface: 'zwp_linux_dmabuf_v1', version: 4, name: 44
13:13lina: main device: 0xE202
13:13zamundaaa[m]: KWin atm does not use EGL_EXT_device_drm_render_node at all, it always sends the primary node of the primary GPU
13:15daniels: yeah, so I guess it'd have to start using that, and we'd have to fix mesa to make that ext work with kmsro :P
13:16lina: That device is the display controller node, yeah
13:16lina: Are the listed formats/modifiers supposed to only be the ones supported by it?
13:16zamundaaa[m]: For the scanout tranche, yes. For the other tranches, no
13:17lina: I see 3 tranches and none of them seem to have any flags, and all of them have formats not supported by DCP
13:19zamundaaa[m]: KWin only passes along what egl returns from eglQueryDmaBufFormatsEXT + eglQueryDmaBufModifiersEXT
13:19daniels: for the scanout tranche, it should be intersecting with IN_FORMATS
13:19zamundaaa[m]: Are some formats maybe external_only? KWin filters those out
13:20lina: Which is the scanout tranche, how do I tell?
13:22zamundaaa[m]: It would be the one with flags: scanout
13:22lina: None of them have that
13:23daniels: wayland-info would probably never get sent scanout tranches as it doesn’t even create a window so could never be a candidate for direct scanout :P
13:31zamundaaa[m]: yeah
13:49Nefsen402: For PRIME situations in wayland, will mesa always blit to the primary GPU before handing the dmabuf to the wayland compositor? I'm asking about amdgpu specifically
13:50robclark: danvet: ack for lumag and r-b for patch
13:58danvet: lumag, ^^ want drm-misc commit rights? if so pls apply per https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-misc
14:20MrCooper: lina: Xwayland explicitly uses render nodes, so even if it asks for a "KMS handle", that should just be the GEM handle of the render node and shouldn't require mapping to DCP
14:21daniels: MrCooper: unless kwin has told it to open the DCP device ...
14:21MrCooper: doesn't use that yet
14:21lina: MrCooper: It's hitting the kmsro path so it's not using the render node...
14:22daniels: MrCooper: wl_drm
14:23MrCooper: hmm, xwl_drm_handle_device looks up the corresponding render node if it doesn't get passed one, but maybe that doesn't work in this case?
14:26MrCooper: AFAICT Xwayland/glamor only calls gbm_bo_get_handle(_for_plane) if it was built against old Mesa though, so I do suspect this is a Mesa internal issue
14:27daniels: right, due to that MR I linked above, right now if you have a system with disjoint display & render DRM devices, the clients will receive the 'wrong' device name, i.e. that of the KMS device you opened via GBM, rather than the GPU device that kmsro discovered
14:28MrCooper: right, I hadn't realized it's actually two separate DRM devices
14:29MrCooper: (maybe better not to assume everybody is aware of this ;)
14:29daniels: my bad!
14:30MrCooper: no worries, in hindsight "kmsro" was a giveaway
14:35alyssa: lina: We should be able to avoid splitting render passes to scanout as long as we get all the synchronization stuff right, hopefully
14:35alyssa: and then it's just an issue of partial renders. If we really care about optimizing that we can potentially use a compressed surface for the partial renders and linear for the final scanout and save a blit
14:36alyssa: (only works if there's a glClear at the start of the frame)
14:36lina: Wouldn't a game rendering directly to scanout possibly end up doing multiple passes?
14:37alyssa: hopefully not if we don't do anything sill
14:37alyssa: silly
14:37alyssa: we still do lots of silly things
14:37alyssa: like writing gallium drivers instead of zink
14:37alyssa: zmike: im learning slowly.
14:39zmike: don't hurt yourself
14:42alyssa:screams
14:44FLHerne: any recommendations for a random Mesa thing to look at while it's raining outside? :p
14:46FLHerne: I'm a C/Python programmer, have some experience with compiler internals, very little with graphics
14:47alyssa: FLHerne: random compiler stuff you say?
14:47alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=good-first-task&first_page_size=20
14:47alyssa: we've got some compiler stuff there
14:49FLHerne: oh, that's a nice tag
15:08alyssa: gfxstrand: Let's rename your compiler to "NAK", meaning Names Are Kindahard
15:12kisak: and put it right beside the NVIDIA Awesome Kompiler?
15:59lumag: danvet, robclark: ack, I will apply, thank you.
16:56javierm: danvet, tzimmermann: commented on the thread but maybe is easier to discuss here. Can't just land danvet's patch #1 as is and then do any further cleanups on top?
17:03jenatali: alyssa: A few weeks ago you were talking about the SM5 shift behavior and how it's weird that NIR inherited that and maybe adding new instructions that don't have the low 5 bits automatically masked. I just learned that apparently DXIL didn't inherit DXBC's behavior here and now it's undefined what happens with oversized shifts
17:04jenatali: All that to say, if you did add lowering for shifts to put that masking in nir, you'd have a second customer
17:04tzimmermann: javierm, i'll type up something on top of daniel's patchset
17:06javierm: tzimmermann: Ok
17:35alyssa: jenatali: Womp.
17:36alyssa: jenatali: You need to mask in your backend then or dozen/d3d12 are already broken, I have a .shader_test somewhere exhibiting the broken
17:36jenatali: Womp indeed. Looks like NV requires the manual clamp while other vendors still do the clamp for DXIL shaders
17:36jenatali: Yeah, I'm adding the mask. It manifests in some CL CTS tests and causes flickering in DOOM Eternal :P
17:37gfxstrand: Womp womp....
17:56danvet: javierm, you did review patch 1/3 in the check_var series ... I'm confused?
17:57alyssa: jenatali: I just inserted the mask in my backend and eat the instruction count hit. If you do something better in NIR (plumbing through the undefinedness from glsl and vtn) I'd use your thing. Have bigger fish to fry myself
17:57jenatali: alyssa: Yeah I just followed suit with what DXC and the DXBC->DXIL converter do, constant values get the mask applied to the constant, dynamic values just get an &
18:02alyssa: Yep
18:41zmike: Lynne: just a heads up I found and fixed a really annoying corner case in lavapipe's db implementation
18:41zmike: it's unlikely you've hit it, but if you're still testing there then you'll want to update from the branch
18:43Lynne: I don't think I've hit it, I got it working fine this morning on all vendors
18:44Lynne: and promptly proceeded to break it again in a way I don't understand on radv before committing -_-
18:47zmike: classic mistake
19:10danvet: robclark, planning a -fixes pull?
19:43DavidHeidelberg[m]: robclark: while you being pinged, any objections against kernel uprev to 6.3-rc5? Few whole CI runs, seems without regression
19:45robclark: danvet: not that I know of.. but there should be a -next soon
19:45DavidHeidelberg[m]: zmike: btw. the zink+a630 traces failures disappeared after rebuild with `CONFIG_PHY_QCOM_USB_HS=y` back in place not triggered anymore (my guess would be it could be some GCC fail?)
19:45robclark: DavidHeidelberg[m]: no objections, did you figure out the zink thing?
19:45robclark: huh
19:45robclark: odd
19:46DavidHeidelberg[m]: robclark: haha, nope; but my guess would be: random GCC/linker error.. since now we're at 6.3-rc5; but before I recompiled against 6.3-rc4 with different kernel config and it also NOT failed
19:47DavidHeidelberg[m]: robclark: btw. are a630 powered down or just getting reset signal?
19:49zmike: DavidHeidelberg[m]: zink has no bugs!
19:49DavidHeidelberg[m]: my guess would be that maybe one runner got flaky and it just presented on this job few times in a row
19:52robclark: DavidHeidelberg[m]: hmm, they still have interwebs access..
19:54anholt: DavidHeidelberg[m]: reset signal, pretty low level one
19:55DavidHeidelberg[m]: anholt: maybe GPU got altered into some weird state which persisted? or just got hit with rate 3 flakes in a row?
19:57anholt: I don't know what instability in particular you're looking at, but ci daily says zink-a630-traces at least has been quite unstable.
19:58DavidHeidelberg[m]: ok, the pipeline seems to be green, I run it few times, any ack/nack? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22255
20:02robclark: anholt: DavidHeidelberg[m]: hmm, some of the cheza last contact time was ~55min ago.. but then others have recent last-contact.. which is odd, I think
20:02robclark: since I think it really should be all the same NUC
20:02anholt: are they all the same format of runner tag?
20:03robclark: oh, google-cheza-new vs google-cheza
20:05anholt: I've cleared out the old mesa-cheza runner registrations from back before bare-metal, too.
20:06robclark: I guess it is fine, maybe fritz was playing remotely with the new runners
20:32javierm: danvet: I did, yes
20:32danvet: javierm, why did you say that it needs review then?
20:34javierm: danvet: no, I meant the other series, patch 1/8 because Thomas disagreed
20:34danvet: javierm, ah ok, that was the confusion :-)
20:35javierm: danvet: sorry if I pasted the wrong patchwork series
22:04Lynne: dj-death: could you rebase your anv descriptor buffer PR? I can test it on an alderlake
22:06Lynne: also, am I the only one who noticed 2 years ago when git pull --rebase started rebasing your tree on top of the remote, rather than the other way around?
22:07Sachiel: I don't think I ever used git pull
22:07Lynne: it makes you rebase changes twice in case you're pulling from a remote, once to go back, and once to go forward, twice solving conflicts, it's insane
22:07gfxstrand: I've never noticed git pull --rebase have that behavior, ever.
22:08gfxstrand: It's always rebased on top of the remote for me
22:09Lynne: could've sworn it was not the case, I think it only started doing this last year, in 2020 july
22:09Sachiel: some settings changed? The man page for it says it behaves differently depending on parameters
22:12Lynne: the settings themselves changed, first it started warning about not setting --ff-only or --merge or --rebase
22:13Lynne: but the new settings don't support the old behavior of rebasing on top of your current tree
22:35norris: danvet: are these (PSR + vblank + rockchip) something you want to take another look at, or should I get a Chromium-er to look?
22:35norris: https://patchwork.kernel.org/project/dri-devel/patch/20230109171809.v3.1.I3904f697863649eb1be540ecca147a66e42bfad7@changeid/ https://patchwork.kernel.org/project/dri-devel/patch/20230109171809.v3.2.Ic07cba4ab9a7bd3618a9e4258b8f92ea7d10ae5a@changeid/
22:36norris: you had feedback (and then seeming agreement) on v1 https://patchwork.kernel.org/project/dri-devel/patch/20230105174001.1.I3904f697863649eb1be540ecca147a66e42bfad7@changeid/
22:36norris: but I thought v3 was ready; just fell through the cracks
22:37danvet: hm I think I discussed them with robclark or maybe even seanpaul_ already?
22:37danvet: vague memories of that at least
22:37norris: on IRC? I can try to find if they're somewhere public
22:37danvet: norris, I think it's all good, doesn't need my input
22:38danvet: maybe inflict them on seanpaul_ :-)
22:39norris: OK, if you say so :) it's either been seanpaul_ or dianders as victims, although dianders sometimes wants a non-Chromium-er to look
22:48dianders: Yeah, seanpaul_ is probably better in this case since he's spent much more time in the PSR code than I have. I don't mind being a mule and doing the gruntwork to apply a patch that's been reviewed, but I haven't yet reviewed these ones. If seanpaul_ is unavilable / unable to review them then I'll try to learn enough about this codepath to give them a good review.