[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