[Mesa-dev] gallium r300 driver for PowerPC
eero.t.tamminen at intel.com
Mon Dec 14 01:10:48 PST 2015
On 12/14/2015 10:44 AM, Herminio Hernandez, Jr. wrote:
> I am new to this list. I have been trying to see if I can fix or at least pin point an issue with Radeon r300 driver failing on PowerPC systems. This has been a problem for a while and I would like to help to get this fixed. I have done some debugging with valgrind and I think I may see where the issue is but I would to have someone double check what I am doing. So when I set my Default Depth to 16 I do get 3D acceleration but when I set to the default of 24 it breaks. Valgrind reports memory leaks when I run glxgears with a Default Depth of 24 but shows no definite memory leaks with a Depth of 16. I then got the source code and created a dev environment andnran glxgears through valgrind with my default depth of 24 and saw similar memory leaks. Here is a sample of what I am seeing.
> ==25273== 108 (12 direct, 96 indirect) bytes in 1 blocks are definitely lost in loss record 54 of 78
> ==25273== at 0xFFB2868: malloc (vg_replace_malloc.c:299)
> ==25273== by 0xED0457B: ???
> ==25273== by 0xEEC6F3B: ???
> ==25273== by 0xE95A78B: ???
> ==25273== by 0xED7DF7F: ???
> ==25273== by 0xED7D5DB: ???
> ==25273== by 0xEC5B377: ???
> ==25273== by 0xEC567EB: ???
> ==25273== by 0xFDEDFD3: dri2CreateScreen (dri2_glx.c:1235)
> ==25273== by 0xFDB866F: AllocAndFetchScreenConfigs (glxext.c:799)
> ==25273== by 0xFDB866F: __glXInitialize (glxext.c:910)
> ==25273== by 0xFDB36F3: GetGLXPrivScreenConfig.part.2 (glxcmds.c:172)
> ==25273== by 0xFDB396B: GetGLXPrivScreenConfig (glxcmds.c:168)
> ==25273== by 0xFDB396B: glXChooseVisual (glxcmds.c:1249)
> It looks like the files in the src/glx branch is where the issue is. I am attaching the summary portion of the output I got from valgrind. Am I heading in the right direction?
Install debug symbols for the libraries that Valgrind is complaining
about, to see what actually leaks. Because they all come from through
GetGLXPrivScreenConfig(), I think this is something (inconsequential) in
your X libraries, not Mesa.
If you want to track run time memory leaks, quit the program with a
signal that the application doesn't catch, but which Valgrind can catch
(e.g. SIGHUP could be such). That way you avoid seeing memory leaks
that happen only when the application quits normally (those are also
good to fix, but not relevant for run-time memory usage).
PS. Do have you libdrm version that is compiled with Valgrind support?
(If not, Valgrind gives bogus errors because it doesn't know where gfx
memory comes from & what memory areas are valid to access.)
More information about the mesa-dev