Originally posted by Michael
View Post
Announcement
Collapse
No announcement yet.
The Linux 3.13 Kernel Is A Must-Have For AMD RadeonSI Users
Collapse
X
-
Originally posted by darkbasic View PostI didn't notice any performance increase with 3.13 on HD 7950.
What I'm worried about is now that the driver is using all its render cores at their rated speeds, the easy performance grabs are gone, and yet performance is still abyssal. The same cards under Catalyst would still be performing twice as fast in most cases. So what else is there to fix?
Comment
-
Originally posted by zanny View PostIf you forced DPM on and had 3.12.7 or later you had most of the bulk performance increases.
What I'm worried about is now that the driver is using all its render cores at their rated speeds, the easy performance grabs are gone, and yet performance is still abyssal. The same cards under Catalyst would still be performing twice as fast in most cases. So what else is there to fix?
Guess One: Poorly optimized shader generation. LLVM was supposed to be better than r600, but maybe its not perfect yet.
Guess Two: Poorly (or not at all) optimized code paths. Development is: make it work THEN make it fast.
Factoid: Radeon in general has fairly poor memory allocation in comparison to Catalyst, and the better your card is the more obvious this becomes because then Memory becomes the bottleneck. By poor memory allocation I mean the driver is kind of 'dumb' about where things should be in memory, whats safe to move out of GPU memory / just drop completely, and the likes. Its on the 'volunteer todo list' last I heard, because optimized memory algorithms were never on the original AMD roadmap and plans.
One additional note... In most cases, especially high end cards, Catalyst will ALWAYS BE FASTER. Kernel and Mesa would never accept code that said
If (CardID == 7970)
{
Codepath 1
}
else If (CardId == 7770)
{
Codepath 2
}
else // See: Low and medium cards
{
CodePath 3
}
Meanwhile Catalyst just might, and probably does, because they have a financial incentive to make sure that every single card gets the most performance that it can get, even if it means micro-managing code paths. The Kernel and Mesa devs will accept the code that works the best on the most cards as possible, and is the most maintainable, even if that means maybe only hitting 90% performance of the possible because you've got a high end cardAll opinions are my own not those of my employer if you know who they are.
Comment
-
ohhhhhh.....
I like the number of games that are getting close (and a few surpasing!) catalyst.
It will be interesting to see Micheal's comparison (please include the ungine benchmark :-)
Comment
-
Originally posted by zanny View PostIf you forced DPM on and had 3.12.7 or later you had most of the bulk performance increases.
What I'm worried about is now that the driver is using all its render cores at their rated speeds, the easy performance grabs are gone, and yet performance is still abyssal. The same cards under Catalyst would still be performing twice as fast in most cases. So what else is there to fix?Guess Two: Poorly (or not at all) optimized code paths. Development is: make it work THEN make it fast.
So what else is there to fix?
* 2D (GLAMOR) has allot of potential optimizations. Its almost completely unoptimized. They have just started working on speeding it up. Interestingly, since glamor uses 3d calls, some of the 3d optimizations should speed up 2D.
* Ram usage.
* Shader compilation.
Comment
-
Originally posted by Sonadow View PostHow's the 2D accel performance under GLAMOR in RadeonSI?Michael Larabel
https://www.michaellarabel.com/
Comment
-
How's the 2D accel performance under GLAMOR in RadeonSI?
EDIT:
Hah. Micheal beat me to the punch! :-D
Comment
-
Originally posted by Ericg View PostOne additional note... In most cases, especially high end cards, Catalyst will ALWAYS BE FASTER. Kernel and Mesa would never accept code that said
If (CardID == 7970)
{
Codepath 1
}
else If (CardId == 7770)
{
Codepath 2
}
else // See: Low and medium cards
{
CodePath 3
}
or, maybe you would be surprise of the kernel maintainers flexibility. snd_hda_intel does almost exactly what you have described. not with big if/elsif blocks but they extensively use function pointers to customize the driver behavior based on the model. please take a look at sound/pci/hda/patch_xxx.c
Comment
Comment