Originally posted by Snake
View Post
Announcement
Collapse
No announcement yet.
AMD fglrx 8.42.3 leaking gobs of memory in OpenGL apps - any known workaround ?
Collapse
X
-
Originally posted by Malikith View PostSuddenly, my hope in 8.43 just dropped like a rock.
It may well be the result of a single forgotten "free()" call, that simply gets multiplied with every frame (and as FPS drastically improved, so did the effect ).
We're on linux, where a bug is no "embarrassing taboo", but something that happens all the time (me being the exception, of course ). This is our operating system, so we are also resposible to improve it by helping tracking down and fixing those bugs. Perhaps AMD/ATI may even integrate a quick valgrind run into their QA procdures in future.
Let's help the devs, not bash them! It's a win-win, after all.
Comment
-
Originally posted by Snake View PostDon't get me wrong, I did not post this result to make anyone look bad, nor to demonstrate how "horrible" 8.42 is and that's about time to give up hope
It may well be the result of a single forgotten "free()" call, that simply gets multiplied with every frame (and as FPS drastically improved, so did the effect ).
We're on linux, where a bug is no "embarrassing taboo", but something that happens all the time (me being the exception, of course ). This is our operating system, so we are also resposible to improve it by helping tracking down and fixing those bugs. Perhaps AMD/ATI may even integrate a quick valgrind run into their QA procdures in future.
Let's help the devs, not bash them! It's a win-win, after all.
I can't even begin on how many bugs there are. I've done my share of bug reporting but it seems the list grows faster and faster with every driver release hehe.
Comment
-
Re: We're on linux, where a bug is no "embarrassing taboo" ...
Originally posted by Snake View Post<snip>
We're on linux, where a bug is no "embarrassing taboo", but something that happens all the time (me being the exception, of course ). This is our operating system, so we are also resposible to improve it by helping tracking down and fixing those bugs. Perhaps AMD/ATI may even integrate a quick valgrind run into their QA procdures in future.
Let's help the devs, not bash them! It's a win-win, after all.
I've reported a few bugs on http://ati.cchtml.com/, and find that I'm actually only talking to myself. I've always stated that I'm willing to help in further debugging, in the reports. There is no response, and all the bugs are still marked NEW, even though I've reported them a long time ago. So I stopped going there, because it feels utterly pointless. I just can't take that bugzilla seriously anymore.
I've also reported most of the stuff to AMD's customer feedback on the driver. But I have no idea if my reports are actually being looked at.
Then there's the Phoronix forums, but I don't know if any AMD devs are present and looking around.
Comment
-
Originally posted by oyvind View PostI agree with you on this. And I'd certainly be willing to help in any way possible, but the one-way communication eventually gets really old.
I've reported a few bugs on http://ati.cchtml.com/, and find that I'm actually only talking to myself. <--snip-->
The sad thing is that on this forum alone there are already lots of people that put their energy and knowledge into testing, trying to figure and report what exactly is going wrong and helping others. But without a "living" bug tracker all those efforts remain scattered pieces floating around, being discussed over and over again in variations without anyone being able to really catch all available info for the bug at hand.
I wonder if AMD/ATI could be convinced to actively use http://ati.cchtml.com/ (possibly even indirectly via a "trusted" mediator). They would gain a lot from detailed and focused bug reports, and for us there was a central place for documenting issues and known workarounds. But this requires that no one gets the feeling like throwing everyting into a "black hole of no return"
I'm not sure whether this "AMD/ATI public bug tracker"-thing was already "officially" discussed here before. But even if it was, AMD/ATIs attitude towards the community recently changed quite a bit, so perhaps it should be done now, anyway.
Michael, are you listening? Any ideas on how we could improve this situation?
Comment
-
I've run glxgears and fgl_fglxgears, but I haven't noticed any memory leaks. I haven't done any extensive checks, but I've been running it for a few minutes and I haven't noticed any change in memory usage in ksysguard.
Thinkpad T60p, FireGL V5200
Comment
-
I'm looking at whats happening on my system and I'm noting that the worst memory leak noted by valgrind is actually in libGL ... and apparently it occurs in both the libGL built by X and in libGL built by the ati install, but *only* when using the fglrx driver.
Overall at this moment I'm stumped as to where to go next. I've dumped my ati-drivers, and xorg installation and rebuilt from the ground up once already to see if I could eliminate the issue -- but it was NOT successful -- if anything I've ended up with a faster memory leak.
Comment
-
Now for the killer laugh of the week.
I ***have not touched my configurations one iota since the previous tests ........
What I DID do was power down the box and put my good old trusty 9550Pro 256M card back in the box, boot, start up , and run both glxgears and fgl_fglrxgears
Either there is *no* memory leak with this card, or the rate at which it leaks memory is ****substantially*** lower.....
Comment
-
Originally posted by yoshi314 View Post8.42 - "brown paperbag edition" (maybe we should buy some for fglrx devs - they're going to need them badly ;-) )
man, that's one hell of a leak. how did it get unnoticed?
Comment
Comment