Valve Begins Publicly Tracking AMD Catalyst Linux Issues

[Mat2]

And your hard drive uses firmware. And monitor. And mouse. And so on. So it basically comes to the question what if could do. GPU lacks network connectivity and in modern systems if it would try something nasty like DMA to unrequested space, IOMMU would engage and illegal access will be caught. Can be an issue on old systems without IOMMU though. However, its not like if relatively small firmware can hold logic to patch arbitrary system. So I guess this problem is limited and not fundamentally worse than, say, HDD firmware (which haves all chances to return you wrong sector, potentially hijacking execution flow of kernel or application).

Well, You always can have backdoors in the CPU:

http://theinvisiblethings.blogspot.com/2009/06/more-thoughts-on-cpu-backdoors.html

if (rax == MAGIC_1 && rcx == MAGIC_2) jmp [rbx]

[vein]

Hmm... After looking at the issues on that page I can happily say that my rig (Sabayon on A10-7850K) has none of these problems with Catalyst. Everything just works...

I must be a very lucky guy

[pandev92]

Hmm... After looking at the issues on that page I can happily say that my rig (Sabayon on A10-7850K) has none of these problems with Catalyst. Everything just works...

I must be a very lucky guy

I have all of this problems , A8 5600K, I tried every distro , gentoo, sabayon, debian, ubuntu, archlinux, opensuse, fedora, rosa linux etc etc

[Nobu]

fglrx gets a lot of criticism, but for general desktop usage, I found it pretty stable. Even with games it was stable, aside from a few games in Wine in my experience.

fglrx stable? Maybe...haven't played too many games with it installed. It's buggy, though. Noticed clipping issues when playing Kerbal Space Program, and KDE had graphical issues too, and it didn't seem much faster, either.

With the radeon driver I almost never experience crashes (when I do, it's usually caused by a missing 32bit library), except for certain effects (partial transparency in Civ V, for instance) everything looks right. I get +200fps avg in CS:Source with almost everything maxed (AA set to the lowest, still enabled value), native resolution; don't really see a reason not to use the OSS driver.

This is with a Radeon HD7770; haven't tried with my A10-6800k's integrated graphics, might have different results with them.

[Passso]

They probably don't have the competence on staff to write drivers for somebody else's GPU hardware. It's AMD's responsibility to provide drivers for their hardware and they've never been particularly good at it.

Not only drivers work randomly, but AMD drops support faster than a corrupted boxer fall.

My "jurassic" 4 years old netbook must now run the radeon driver (after 14.04 upgrade...)

Good luck Valve

[sunweb]

So is there any reason for Valve not to help with opsensource drivers? I understand they're not pros but they could hire some smart devs and help out with clean realization of the drivers.

[nightmarex]

I'm not even entirely sure why they're still maintaining their closed source stack on linux so hard when it's obvious the opensource ones will overtake them by next year at this rate...
open source one is already far, far more stable.

The RadeonSI driver crashes far more than the Catalyst one that I have noticed... It's getting quite usable now thankfully and I am enjoying it but random lockups happen daily where catalyst could run for a month before a meltdown. Hopefully these bugs will be ironed out before I get a 280x.

[clavko]

So is there any reason for Valve not to help with opsensource drivers? I understand they're not pros but they could hire some smart devs and help out with clean realization of the drivers.

Ofcourse there is... Device drivers are manufacturer responsibility. And if manufacturer doesn't
care, then no one will/should, and they'll just go the way of dodo. That's life.

[DrYak]

I believe the security issue has to do with the GPU being connected via PCI-E which you can do almost anything to the computer with, like say, control another PCI-E card.

And as said, there ARE solution to that problem: IOMMU and the like which are basically the equivalent of memory protection, but applied to hardware to avoid hardware snooping on each other when not allowed. (like DMA attacks using any DMA-capable bus like Firewire)
The situation isn't 100% perfect yet, but at least there are long term solutions.

I'm not even entirely sure why they're still maintaining their closed source stack on linux so hard when it's obvious the opensource ones will overtake them by next year at this rate...

Yeah, but what do you run during this year?
That seems to be the current trend with AMD on Linux.
- Catalyst is used to run on the latest hardware that just arrived on the market and has no other driver
- opensource is used for older hardware and officially recommended by AMD for any older card for which they drop support from catalyst.

Not only drivers work randomly, but AMD drops support faster than a corrupted boxer fall.
My "jurassic" 4 years old netbook must now run the radeon driver (after 14.04 upgrade...)

As said that seems to be their official stance.
They don't have much resources, so they avoid spending it twice.
They won't maintain simultaneously support for the same card in both catalyst and opensource.
Thus they mostly concentrate their resources in catalyst for newer hardware (when there's no other solution).
And usually, by the time they drop support for some older card, the opensource support has reached "acceptable enough" performance for the same card.

Now indeed there are some important features still missing from the opensource drivers (support for Crossfire, a recent enough OpenGL, and stable/useable OpenCL)

So is there any reason for Valve not to help with opsensource drivers? I understand they're not pros but they could hire some smart devs and help out with clean realization of the drivers.

Yup, they could throw a bit resources on opensource drivers.
Correct me if I'm wrong but although some of the development of the opensource drivers are from people on AMD's payroll, there are also contributions by people working at other companies (Suse, Redhat, etc.)
Valve could similarly pay for additional driver developers.

That would be useful:
- for features that AMD themselves don't have enough resources to spread onto, but that are more in Valve's interest: Crossfire would be a good example (Crossfire isn't high on AMD's priority list, but Crossfire being useful for gaming, might be in Valve's interest).
- for features that are useful across the whole ecosystem: like support for newer OpenGL API (and indeed Valve has already contributed code toward openGL 4.x support in Gallium).

[tmpdir]

I have all of this problems , A8 5600K, I tried every distro , gentoo, sabayon, debian, ubuntu, archlinux, opensuse, fedora, rosa linux etc etc

Same here, have most of these problems using an A6 left over to test SteamOS.
Static noise isn't there when playing games, but starts when opening the buildin browser.
Sometimes SteamOS starts with a black screen, just restart and blackscreen is gone. Using an workaround script for this.
FPS is low compared to windows dualboot.
Haven't notice any instability problems.
I don't think there wil be many Steammachines running AMD GPU's, any company delivering this will be bankrupt before the end of the month.