[Mesa-dev] [PATCH 0/4] Add some memory alloc/free debuging to the r600 driver

Marvin marvin24 at gmx.de
Tue Jun 15 13:16:26 PDT 2010


Hi Tom, 

Am Dienstag 15 Juni 2010, 17:12:05 schrieb tom fogal:
> Hi, since this hasn't received a reply I figured I'd step in.
> 
> marvin24 at gmx.de writes:
> > patches below add some memory debuging functions to the r600 driver.
> 
> There was some recent effort to *remove* similar functions throughout
> the Mesa tree.  The justification was that they were useful a while
> back, but now we have valgrind, and it does a better job than any such
> wrappers.
> 
> Do these add something that valgrind cannot?

initially I added the debug messages because I wanted to find a huge memleak (~ 
30 MB/s) in a wine game. It's horrible to do this in valgrind because it's too 
slow. I knew it must have been somewhere in the r600 driver, because the llvm 
driver didn't show the leak. In the end, adding the code didn't revealed the 
cause (maybe s.o. could explain me be where the callocs in 
assemble_alu_instruction are freed, at least not in the driver itself). 

Given that there are ~1k of free() and ~1k of FREE() in the rest of the mesa 
code I gave up debugging this further. I guess it would be better to add a 
shader dumper to the r600 code to get a nice test case.

All in all, I still find it useful to macro-fy the memory alloc/free functions, 
because valgrind isn't always usable. This way you can also restrict the 
output to certain parts of the code.

Anyway, I also think there should be a decision to remove all macros or macro-
fy everything - given the statistics from grep, both seems to be the same 
amount of work while the latter gives you also some functionality.

Marc


More information about the mesa-dev mailing list