OK, this looks like the mess I'm seeing with cairo-gl: I'm allocating and deleting on the order of 10 new textures a frame for mask and sw gradients rasterization and misc other reasons. So we're constantly creating new state cache entries for surface state pointing at these guys. Those entries hang around until they get evicted by exceeding the 1000-or-so entry limit, and they reference the texture buffers. So we end up hanging on to around 300 deleted textures, resulting in us exceeding the aperture size and spending about 30% of cpu time thrashing things around. (cache gets evicted every half a second or so at 60fps) This may account for several "memory leak" reports about the 965 driver.
Hi Eric, I've just noticed this bug last weekend and was going to report it and I guess it's been reported already. I created a simple program that made 1024x1024 texture, map it on a quad, and delete it afterward in a loop, and i saw memory leak happening. Basically the texture wasn't being deleted. I guess it's caused by what you've described below? Just curious, will this be fixed anytime soon? thanks a bunch~ Sung (In reply to comment #0) > OK, this looks like the mess I'm seeing with cairo-gl: > > I'm allocating and deleting on the order of 10 new textures a frame for mask > and sw gradients rasterization and misc other reasons. So we're constantly > creating new state cache entries for surface state pointing at these guys. > Those entries hang around until they get evicted by exceeding the 1000-or-so > entry limit, and they reference the texture buffers. So we end up hanging on > to around 300 deleted textures, resulting in us exceeding the aperture size and > spending about 30% of cpu time thrashing things around. (cache gets evicted > every half a second or so at 60fps) > > This may account for several "memory leak" reports about the 965 driver. >
Yes, I even have a patch I've been playing with to try to fix the problem. Only the patch made the problem worse for reasons I haven't solidly figured out yet. We've been stomping a bunch of other bugs that complicated the problem, and hopefully will have something better to show soon. It should still not be a leak -- you'd max out at approximately (texture size * bind bo frequency in state cache * 1000) memory usage.
Yes you're right. It's not a leak. I just saw a lot of swapping on my machine. =) I hope this issue gets resolved soon. Thanks~!
Mass version move, cvs -> git
commit 49fbdd18ed738feaf73b7faba4d3577cd9cc3e59 Author: Eric Anholt <eric@anholt.net> Date: Thu Feb 12 03:54:58 2009 -0800 i965: Fix massive memory allocation for streaming texture usage. Once we've freed a miptree, we won't see any more state cache requests that would hit the things that pointed at it until we've let the miptree get released back into the BO cache to be reused. By leaving those surface state and binding table pointers that pointed at it around, we would end up with up to (500 * texture size) in memory uselessly consumed by the state cache. Bug #20057 Bug #23530
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.