02:54 <justsid> I'm trying to track down a leak inside of Zink and I'm hoping someone can help me. Basically buffers created with `u_upload_alloc_buffer` (ending in `zink_create_resource`) are born inside of Zink witha +1 ref count and I can see it getting referenced and bumped when used in draws and then later on de-refed after getting submitted. However, it never goes below 1 and I'm not sure what that is. If I understand the code right,

02:54 <justsid> `u_upload_alloc_buffer` is expected to be gifted a reference to the new object, so I'm guessing the state tracking there is correct, although I'll admit the whole private ref count thing is pretty wild. I can also see zink derefencing the object inside of `zink_reset_batch_state()`, but it just never hits 0. Eventually I'm all out of memory and that's the end of that. I'm hoping someone who understand Zink/Mesa better than me can

02:54 <justsid> give me some pointers of how to track this down better?

03:06 <airlied> justsid: sound like reset batch should be the final deref

03:11 <justsid> That's what I assumed. Or at least, since the buffer is used as a magazine of sorts to stream index/vertex buffer data to, the last batch to reset should turn off the light. Yet no matter what, I'm left with a ref count of 1

03:17 <justsid> Actually... Having made the wise choice of drinking some coffee at 7pm, I think I see the problem. reset_obj_list doesn't actually delete the resources, it just puts them back into the pool of available resources. So I think the missing piece is actually the fact that Zink doesn't recycle the object, and will only ever create more through zink_create_resource()

03:17 <justsid> I swear I looked at the code before I wrote my question

03:18 <airlied> oh it should get recycled

03:18 <justsid> Actually it looks like it does de-ref it, just deferred through the bs->unref_resources list

03:24 <justsid> Is the recycling part maybe missing? I don't see it getting added to a list other than the unref_resources list. I can see the ref count drop down to 1 in unref_resources() as part of Zink submitting its command buffer, and then nothing seems to ever look at the object again

03:26 <justsid> And resource_object_create doesn't seem like it attempts to recycle any resources, just creating a new one. so u_upload_alloc_buffer will always create a fresh resource

03:27 <justsid> At least within Zink I can see the refs and derefs adding up to net 0. But the object is born with a +1 ref count, so who is responsible for dropping the last ref? Is it possible that I'm not triggering a path in Mesa that would clean up streamed resources like this?

03:28 <justsid> The object is created as part of some glBegin()/glEnd() calls. But we never end up swapping any buffers or even attempting to display anything, so I could imagine that scratch memory never gets cleaned up? Also sorry for being a bit spammy here, I'm just completetly clueless about the inner workings of Mesa so you are getting my inner monologue live

03:44 <airlied> hmm yeah maybe some clean up is hooked in somewhere, I'd have to go dig

03:44 <airlied> zmike would know but he's out for rest of year

03:44 <justsid> He even asked me if I had any questions before leaving the office and I was all like "nah, this is perfect the way it is" (:

03:45 <airlied> is unref_resources being called?

03:46 <justsid> It is, yeah

03:46 <airlied> so some queue submit should see the resource get destroyed

03:47 <justsid> yeah, I can see the ref count drop through zink_end_batch -> submit_queue -> unref_resources -> zink_resource_object_reference -> pipe_reference_described

03:47 <justsid> And I guess I figured out how the upload manager removes its last reference: When it makes a new buffer, it first derefs the old buffer. So that should be balanced too

03:52 <airlied> yeah upload use of private refs is kinda funky, but explained in a comment

03:52 <justsid> Yeah, it blew my mind so much I immediately considered stealing the design for our engine objects that suffer from similar problems lol

11:36 <kusma> justsid: Are you on the latest version? This sounds a lot like a bug I fixed recently...

11:36 <kusma> Specifically: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19068

11:38 <kusma> Ah, no. That's obviously not the same issue; that's about descriptor leaks, not resources. I saw "pool" and my spidey senses tingled.