00:51 <airlied> 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:12 <airlied> okay tip is repaired

19:22 <soreau> 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:35 <HdkR> 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:36 <HdkR> 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:44 <HdkR> 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:44 <HdkR> er, not really unexpected to do renaming*

19:45 <daniels> when you bind a texture to an FB, it binds to the FB object that the ID references at the time

19:52 <soreau> I'm just trying to figure out what the offending component is with mesa #12707, the driver, wlroots or the compositor

19:53 <soreau> because wlroots and the compositor use the texture id and don't expect it to increment, at least from what I've read

20:04 <soreau> and the fact that it affects the mouse cursor, feels like some clue

20:05 <soreau> the cursor might be a black square or, filled with texture bits from another surface

21:16 <AndrewR> 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:16 <AndrewR> disable Vulkan decode, but my guess it just uses lavapipe in this case, because it really slow?

21:17 <AndrewR> Sorry for asking here, ffmpeg-devel IRC apparently (according to their website) for ffmpeg development ONLY

22:08 <Lynne> AndrewR: what do you do with the output frames?

22:47 <AndrewR> Lynne, we use av_buffersink_get_frame

22:51 <Lynne> AndrewR: does the issue still happen without libplacebo?

22:51 <Lynne> also which ffmpeg version?

23:01 <AndrewR> 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:06 <Lynne> AndrewR: you should consider git master

23:06 <AndrewR> Lynne, if only it was breaking less ...

23:06 <Lynne> I don't think we broke that much for 8.0

23:07 <AndrewR> Lynne, but still, I think I findamentally do something wrong. Should I explicitly add hwmap filter?

23:08 <AndrewR> Lynne, it was enough for us to break ... I have patch around, but not tested it late lately ...

23:13 <AndrewR> Lynne, https://pastebin.com/c3JCViyr

23:18 <Lynne> 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:18 <Lynne> either that, or the libplacebo interop had a memory leak

23:19 <AndrewR> Lynne, can you try to build our software? :)

23:31 <soreau> 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:36 <Lynne> 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:43 <AndrewR> Lynne, git://git.cinelerra-gg.org/goodguy/cinelerra.git

23:46 <AndrewR> Lynne, https://cinelerra-gg.org/download/CinelerraGG_Manual/Notes_about_Building_from_G.html