00:51airlied: ugly conflict in xe_svm.h, I'm not sure I've got time to solve it now, will try to resolve it over the weekend, unless someone gets to it first
06:12airlied: okay tip is repaired
16:40soreau:wonders what might happen if a texture is bound to a framebuffer with glFramebufferTexture2D and either the texture is deleted or the framebuffer but not both in tandem
19:22soreau: more specifically, what might happen if a texture is bound to a framebuffer and the texture is deleted but another created with the same id? would it break the framebuffer completeness?
19:35HdkR: soreau: I would assume since GL serializes everything that either it either silently is renaming behind the scenes to the real object, or you're going to introduce a stall.
19:36HdkR: I don't even know if you would expect to get the same ID back if you're doing deletion and creation in the same frame.
19:44HdkR: GL drivers already need to do a pretty big effort renaming texture IDs because legacy GL 1.x behaviour, so it's not really expected.
19:44HdkR: er, not really unexpected to do renaming*
19:45daniels: when you bind a texture to an FB, it binds to the FB object that the ID references at the time
19:52soreau: I'm just trying to figure out what the offending component is with mesa #12707, the driver, wlroots or the compositor
19:53soreau: because wlroots and the compositor use the texture id and don't expect it to increment, at least from what I've read
20:04soreau: and the fact that it affects the mouse cursor, feels like some clue
20:05soreau: the cursor might be a black square or, filled with texture bits from another surface
21:16AndrewR: Lynne, I am trying to get both hw (Vulkan) decoding and filtering (libplacebo) in cinelerra-gg. I modified our filter-creating function: https://pastebin.com/ti9ikQhJ But for some reason I see a lot of kernel activity, memory usage increase to 3Gb, for small frame sizes I got one blank frame and then memory usage increases again and we freeze :( Is there anything special about libplacebo? It works slowly if I omit RADV_PERFTEST=video_decode and thus
21:16AndrewR: disable Vulkan decode, but my guess it just uses lavapipe in this case, because it really slow?
21:17AndrewR: Sorry for asking here, ffmpeg-devel IRC apparently (according to their website) for ffmpeg development ONLY
22:08Lynne: AndrewR: what do you do with the output frames?
22:47AndrewR: Lynne, we use av_buffersink_get_frame
22:51Lynne: AndrewR: does the issue still happen without libplacebo?
22:51Lynne: also which ffmpeg version?
23:01AndrewR: Lynne, ffmpeg 7.0. I was unable to make other filters (like *_vulkan) do something .. :( so probably my attempt at linking hw_context still not right ...
23:06Lynne: AndrewR: you should consider git master
23:06AndrewR: Lynne, if only it was breaking less ...
23:06Lynne: I don't think we broke that much for 8.0
23:07AndrewR: Lynne, but still, I think I findamentally do something wrong. Should I explicitly add hwmap filter?
23:08AndrewR: Lynne, it was enough for us to break ... I have patch around, but not tested it late lately ...
23:13AndrewR: Lynne, https://pastebin.com/c3JCViyr
23:18Lynne: AndrewR: I can't remember the state of vulkan decode in 7.0 since it was over a year ago, but I think it had a memory leak
23:18Lynne: either that, or the libplacebo interop had a memory leak
23:19AndrewR: Lynne, can you try to build our software? :)
23:31soreau: daniels: how does mesa make the association between the underlying object and the texture or fb id? it's been reported to me today that mesa #12707 also happens on intel and nouveau
23:36Lynne: AndrewR: as it happens I'm interested in it, since I'll be editing a film and still haven't decided whether to use blender or something else
23:43AndrewR: Lynne, git://git.cinelerra-gg.org/goodguy/cinelerra.git
23:46AndrewR: Lynne, https://cinelerra-gg.org/download/CinelerraGG_Manual/Notes_about_Building_from_G.html