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. > > marvi...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
