03:34gfxstrand: cwabbott: Maybe that's the thing to do, then.
03:35gfxstrand: cwabbott: The only driver using it right now is IMG
09:15cwabbott: gfxstrand: also, we have a bit of an unfortunate situation, where we need to know if any feedback loops involve input attachments or could involve any texture
09:15cwabbott: not sure how exactly to model that in vk_render_pass_state
09:15cwabbott: currently we have a feedback_loop_may_involve_textures flag
10:53tzimmermann: demarchi, if you like, please comment on https://lore.kernel.org/dri-devel/daf5bc36-0deb-631d-dfaf-396113d3d1d8@189.cn/T/#md187fc89908b60492660e23a5c3d7712f212a098
13:34jaganteki: mripard: Hi Maxime, I've posted v7 Allwinner DSI bridge conversion, in case if you have any questions please ping me here any time. thanks.
13:46danvet: robclark, tursulin, gfxstrand: I'm pulling the uabi-less pr, I think that should help move things a bit
13:46danvet: and at least unblock driver enabling while the uabi discussion hopefully settles on some consensus soon
13:49danvet: tursulin, I'll also backmerge -rc4, I'll ping everyone once that's done for backmerging needs
13:50gfxstrand: cwabbott: Isn't that just a combination of the pipeline bit and the render pass bits?
13:51cwabbott: gfxstrand: I don't think so
13:52robclark: danvet: thx.. I am holding out hope for at least the syncobj uabi (since I doubt anything about it will change.. but also it is a lot more paperwork for me to land it FROMLIST in CrOS ;-))
13:52cwabbott: it's true if the user isn't using render passes *or* the debug option is enabled and we're using the emulated render pass
13:53cwabbott: hmm, I guess we could derive it using the debug option?
13:54gfxstrand: cwabbott: Right now, vk_render_pass_state::*self_dep* is determined entirely by render pass things. It doesn't take feedback loops into account.
13:55gfxstrand: So feedback loops come from pipeline flags
13:57cwabbott: gfxstrand: yes, but if it's coming from the emulated render pass thing then we need to treat it the same as the pipeline flag
13:57gfxstrand: cwabbott: Right...
13:57cwabbott: if it comes from *our* renderpass thing then we need to *not* treat it the same
13:58cwabbott: if it comes from our renderpass, we know the feedback loop actually only involves input attachments that we can patch if we decide to be a tiler
13:58gfxstrand: ISTR there's some patches in my ANV MR that rework this a bit.
13:58cwabbott: gfxstrand: yeah, I'm looking at those now
13:59gfxstrand: I'm happy to land some of those ahead of the ANV enable. We just didn't have a big reason
13:59cwabbott: I had to rewrite those a bit to get it to work for turnip, there's a v2 of part of it in the fragment_density_map MR
14:00cwabbott: but anyway, even before the rework, we don't have what we need and the rework doesn't change that
14:05danvet: robclark, yeah makes sense, and then maybe 3rd pull when the chromium side is wired up for sync_file?
14:05danvet: or can you only use that with the virtio plumbing in place?
14:09gfxstrand: cwabbott: The important thing that I was getting at is that as of the 6-7 patches into that MR, you get feedback loop flags for self-deps that come in through vk_render_pass, not self-deps in the vk_render_pass_state. That means that anything you add there for driver-custom render passes will be separate and the feedback loop and vk_render_pass case look the same.
14:09gfxstrand: I though that's what you're asking for.
14:13cwabbott: gfxstrand: yeah, I guess that's the case, but we need to do some things similarly and some differently depending on whether it's an input-attachment-only self-dependency or not
14:14cwabbott: so it's more convenient for us to use the same flags but add a boolean
14:15cwabbott: also, in the totally-hypothetical case where an extension adds the ability to use input attachments in a dynamic render pass, well, we'd want to take the same path that classic renderpasses do
14:16gfxstrand: cwabbott: hehe. Sure. :)
14:18gfxstrand: cwabbott: I think what I was trying to suggest, more concretely, is that we take the first 7 patches in that MR, everything up through "vulkan: Drop vk_render_pass_state::*self_dependenc*" and then you add whatever you want for self-deps.
14:18gfxstrand: It can be a boolean, it can be a set of flags. I don't care.
14:18cwabbott: yeah, I'm doing pretty much that
14:18gfxstrand: If there is a future extension and you can guess what it'd look like and can make it to look a bit like that, bonus points.
14:18cwabbott: I had to rework it a bit to get FDM to work, though
14:19gfxstrand: Ok, Have you posted the reworked versions anywhere?
14:19cwabbott: in the common FDM MR
14:20cwabbott: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20304
14:20robclark: danvet: well I could use the sync_file bit in msm if I used dma-fence fd's for everything instead of MSM_WAIT_FENCE.. but for host side I only use fd's if they need to be exported.. maybe there are some paths where I could use it, but the best candidate atm is gnome-shell/kwin
14:21danvet: robclark, yeah might need to submit that patch to relevant people with explicit request to come up with userspace so we can land it
14:21gfxstrand: cwabbott: Cool. I'm good with the rename.
14:21danvet: zamundaaa, ^^
14:21gfxstrand: cwabbott: I think most of my feedback loop MR is reviewed so let's land some stuff.
14:21gfxstrand: cwabbott: I'm going to review the FDM stuff right now
14:22cwabbott: gfxstrand: I haven't posted the rewritten part where I plumb it into vk_render_pass_state because I literally just wrote it
14:22cwabbott: in the middle of rewriting all of the things atm
14:27gfxstrand: cwabbott: Core FDM MR is RB me now.
14:28gfxstrand: cwabbott: Once that's landed, I'll rebase and land the first half of !17892
14:28gfxstrand: Then SelfDependencyInfoMESA will be toast
14:29cwabbott: gfxstrand: should I just go and land it before landing the turnip implementation?
14:29gfxstrand: cwabbott: Sure
14:29gfxstrand: cwabbott: Besides that refactor which we're agreed on, I don't see anything controvertial in there.
14:29gfxstrand: Or I can just land the one patch from me
14:29gfxstrand: THat works too
14:31zamundaaa[m]: danvet, robclark: I'd be happy to write something up for KWin. I assume we're talking about something as straight forward as an ioctl to give the kernel a fence fd + deadline timestamp?
14:33danvet: zamundaaa[m], https://lore.kernel.org/dri-devel/20230308155322.344664-7-robdclark@gmail.com/ this one essentially
14:33danvet: I guess robclark can als give you a v6.3-rc branch with all the pieces
14:34robclark: zamundaaa[m]: yup.. that'd be great. And yeah, that was the link I was searching for
14:34danvet: maybe even a real impl for your gpu
14:34robclark: yeah, one sec
14:35robclark: zamundaaa[m]: https://gitlab.freedesktop.org/robclark/msm/-/commits/dma-fence/deadline/ has a "good enough" impl for i915 (in case you don't happen to have a snapdragon laptop ;-))
14:36danvet: zamundaaa[m], you might also need the dma-buf fence export ioctl to get at the right fence to begin with
14:37danvet: but I'm assuming you're already working on all that infra to make it possible to decide which frame you'll pick from clients
14:38zamundaaa[m]: yes-ish. Right now I'm working on the other side, where I pick when I send composited buffers to kms
14:38danvet: those landed in 6.0 fyi
14:38zamundaaa[m]: So what I have right now is a EGL fence with fd
14:38danvet: ah just the overall composited desktop?
14:40danvet: agd5f, robclark, tursulin, rodrigovivi, mlankhorst: fence deadline + rc4 backmerge landed in drm-next for your backmerge needs
14:40zamundaaa[m]: yes. So that cursor updates can still happen even if the primary plane is missing the vblank deadline
14:42gfxstrand: Thank you, dj-death for renaming functions as you did all this bindless state pool stuff. Finding my bugs via compile errors. :)
14:43robclark: zamundaaa[m]: so the main thing is you want to be boosting the client's fence (ie. not your own fence created after doing composition).. or maybe you want to boost both
14:43dj-death: gfxstrand: ?
14:43robclark: if implicit sync you can use the new fancy dmabuf ioctl to fish out the fence fd
14:44dj-death: gfxstrand: I guess I'm out of date on what I did after the EXT_descriptor_buffer :)
14:44gfxstrand: dj-death: hehe
14:47zamundaaa[m]: robclark: yeah I want to boost both, there's no use of having the client meet the deadline if the buffer can't be put on the screen in time
14:47zamundaaa[m]: Possibly stupid question, but with implicit sync, shouldn't the fence for the compositing result also result in client work being boosted too? It's a dependency after all
14:48robclark: yes
14:49robclark: if you are immediately doing the composition step.. but if there is some time btwn when you get the client buffer+fence and when you do composition then you'd want to set the deadline on the client fence immediately
14:49robclark: rather than wait until you have your own fence
14:50HdkR: Intel CI spending 5 minutes timing out and then 20 minutes before it starts running is pretty rough
14:51gfxstrand: dj-death: If you could run your eyes over https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22191, that'd be good. I *think* those patches *should* be landable.
14:51daniels: HdkR: agree
14:51daniels: HdkR: being furiously worked on atm
14:53HdkR: Speaking of CI, time to buy some more parts to make mine better
14:54KitsuWhooa: Sorry to interrupt; if a patch has made it to staging/23.0, does this mean that it will be present in, say, mesa 23.0.2?
14:55dj-death: gfxstrand: will do
14:55gfxstrand: cwabbott: That MR contains your version of my patch and your turnip patch from the FDM MR.
15:28MrCooper: KitsuWhooa: likely, but no guarantee until it lands on the non-staging 23.0 branch
15:29KitsuWhooa: Understood. Thanks!
16:23gfxstrand: cwabbott, dj-death: I fixed the obvious issue both of you pointed out with !22191
16:32cwabbott: gfxstrand: I think you misread my comment there
16:32cwabbott: I wasn't talking about just the rebase fail
16:34cwabbott: the call to `vk_get_pipeline_renderpass_flags` also has to be moved up, to get the FDM flags in the fragment shader stage
16:35cwabbott: or maybe we need to just pass that flag through directly? not sure
16:35gfxstrand: cwabbott: Hrm...
16:36gfxstrand: Right...
16:36gfxstrand: Ugh
16:36gfxstrand: I hate GPL
16:37cwabbott: maybe it would cause problems if you call it early in the fragment stage and then get the wrong flags that are only supplied in the output interface stage?
16:39cwabbott: I guess you have to properly merge the two rather than just copying one over
16:39gfxstrand: Yeah, let me throw a few brain cells at that for a minute.
16:39gfxstrand: I've rebased on the FDM MR so that should help.
16:39cwabbott: GPL is giving me headaches
16:39gfxstrand: It's horrible
16:43gfxstrand: Of course FSR/FDM flags and feedback loop flags are parts of different bits of state. :facepalm:
16:46gfxstrand: This is why I wrote common code.....
16:46cwabbott: there's one more thing it's not handling for me, which is raster order attachment access
16:47gfxstrand: right
16:47cwabbott: which is a bit awkard since it's not actually dynamic state but still has annoying (and seemingly incorrect?!?) GPL interactions
16:47gfxstrand: *sigh*
16:48cwabbott: it's supposed to not be dynamic because it affects shaders but it's part of the output interface state somehow?!?
16:49gfxstrand: :(
16:57dj-death: gfxstrand: will you rebase https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17892 too for the compile issue?
16:58gfxstrand: dj-death: Yeah, I'll get to that once I get this GPL stuff sorted.
17:40gfxstrand: cwabbott: Ok, I think I probably got the flags correct now. 😅
17:40gfxstrand:hates GPL
18:04anholt_: alyssa: should lower_frexp go in midgard_compile still?
18:12anholt_: ah, midgard_preprocess_nir
18:32alyssa: anholt_: yeah, probably preprocess
18:33alyssa: nothing should be rematerializing frexps
18:33alyssa: thanks :)
19:02daniels: gfxstrand: more of an Apache 2 enthusiast?
19:02gfxstrand: daniels: VK_EXT_graphics_pipeline_libraries
19:02gfxstrand: But, also, I prefer a less invasive license, yes.
19:03daniels: gfxstrand: [thats-the-joke.gif]
19:22gfxstrand: Sorry, my joke sensor's not working for some reason.
19:37HdkR: "I'm a part of MIT alumni"
20:04alyssa: just get ready for the AGPLv3
20:05alyssa: VK_ANDROID_graphics_pipeline_libraries3
20:05alyssa: you love to see it
20:05alyssa: "what if we took the most annoying part of GLES and mixed it with the most annoying part of Vulkan?" "Brilliant"
20:05alyssa:laughs in d3d12
20:09kisak: coming from you, my brain tried as hard as it could to read that as VK_APPLE_graphics_pipeline_libraries3
20:10alyssa: > Vulkan
20:10alyssa: > Apple hardware
20:10alyssa: impossible ;~P
20:10kisak: yes
20:11gfxstrand: Oh, come on. You know alyssa wants to run Android on her iPhone. :P
20:12HdkR: Sprinkle in some ARM nested virtualization and some virtualized hardware GPU contexts...
20:14alyssa: gfxstrand: no i want to run gnome on my iPhone get with the meme program
20:14alyssa: :-p
20:14gfxstrand: Oh, right, so you want to run TikTok in an Android container on GNOME on your iPhone.
20:16alyssa: I'm glad you understand
21:00alyssa: Kayden: glthread makes my brain hurt
21:01alyssa: can't tell if I found a bug in Iris or I'm the bug
21:06Kayden: definitely a fair bit of brain hurt there, yeah, hah :) and last I checked your species was not insectoid. you could well have found one though
21:06Kayden:is looking at u_threaded_context today
21:06Kayden: "oh, that's easy I can just do....no....can't....*swack*...stop that" hahah
21:07Kayden: (think I know the proper way, but eh, first prototyping)
21:07Kayden: what'd you find?
21:09alyssa: glthread requires CAP_MAP_UNSYNCHRONIZED_THREAD_SAFE which iris sets
21:09alyssa: but even unsynchronized maps can require a staging blit
21:09alyssa: so unless there's some locking happening inside blorp, that seems broken
21:10alyssa: and liable to blow up if multiple threads do [unsynchronized] maps requiring staging blits at the same time. not sure if glthread does that but the cap says it's allowed to.
21:12Kayden: ah, right
21:13Kayden: We mostly need staging blits to cope with image detiling
21:13Kayden: but PIPE_CAP_MAP_UNSYNCHRONIZED_THREAD_SAFE says "Whether mapping a buffer as unsynchronized from any thread is safe."
21:13alyssa: buffer is the keyword then. right. ok
21:13Kayden: I think it really means "buffer" there and not "resource".
21:14Kayden: at least - I believe it's only used for buffers, today
21:14zmike: this is correct
21:15Kayden: I don't think iris requires staging blits for unsynchronized -buffer- maps
21:16alyssa: zmike: Is that something that we can depend on for the future? if it's in the docs but not the cap name
21:16zmike: I don't know why anyone would want to map an image unsynchronized
21:17alyssa: I don't know why anyone would want to write to a texture midframe but quake does it.
21:19zmike: I don't know that a cap name is any more restrictive than docs
21:19zmike: it's gallium, nothing is the same from day to day
21:20alyssa: mood
21:34Kayden: yeah, just something worth keeping in mind if we ever decided to try and do that in the future
21:34alyssa: oh look it's the annual "Alyssa wonders why gallium/pp exists in $CURRENT_YEAR" day
21:34Kayden: pretty printer?
21:36alyssa: postprocessing
21:36alyssa: that random cel shading filter that doesn't work and morphological antialiasing filter that nobody remembers exists
21:36alyssa: but people were very protective of last time I tried to delete them
21:37alyssa: ( https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5448 )
21:38Kayden: oh, that's right
21:43HdkR: Just tell everyone to implement post-processing in Gamescope instead :)
21:43Lynne: anyone working on/with descriptor buffers getting errors with validation layers on that descriptor index 0 is unset?
21:44Lynne: my code works, but that error is making me doubt it works by design rather than by chance
21:45alyssa: HdkR: that's kinda my point, this should be done by a compositor or a layer
21:49zmike: fraps
22:16HdkR: zmike: I think Starbucks sells some fraps
22:17zmike: yuck that sounds like something irl
22:17zmike: I only want pixels
22:18HdkR: Meatspace fraps, the worst kind
23:29alyssa: eric_engestrom: ping
23:29alyssa: oh wait it's like 1am there ok
23:30alyssa: there 17 MRs in the marge queue and anholt's farm is down, um, how do we usually do this dance
23:30alyssa: i maintain this is the one case where direct pushing is the right call but I don't want to be the one to set the precedent
23:32alyssa: otoh Marge is currently spinning on a nouveau MR (which was running on anholt's boards until it went down) so direct pushing shouldn't interfere with a merge and that way the merge queue isn't disrupted
23:32alyssa: so I think I convinced myself bypassing Marge for this change is the way to go
23:36zmike: I think usually all the MRs get unassigned so a disable MR can go through
23:37alyssa: yeah, that's silly when there are 16 MRs in the queue, and that adds an extra ~30min bubble for Marge to run full CI for that
23:38alyssa: power outages happen. stopping the whole world for it is silly.
23:38alyssa: regardless maybe a moot point for tonight since anholt just commented it might be back up
23:38alyssa: I should be doing not mesa right now so
23:38alyssa: if somebody wants to land !22198 and it's still needed it's there
23:39alyssa: otherwise Marge will see it in 8 hours or so (-: