New AMD Catalyst Beta Supports Linux 3.8, TF2 Fixes

[ext73]

3.9.x compatibility

These drivers - 13.3 beat3 works very well under kernels Linux-3.9.x

https://dl.dropboxusercontent.com/u/...3-kernel-1.png

https://dl.dropboxusercontent.com/u/...inux-3.9.x.png

[Gps4l]

Is the SS3BFE flicker problem solved?

It's easy to alt+enter twice to restart de renderer and get the fllicker away, but...

Not with the 13.3 beta 3, I installed.
( and I just checked my firefox downloads, it says 13.3 beta 3 )

Date: 26 march.

[entropy]

Sometimes I try to imagine how working at the AMD Linux binary driver division must be...
This all feels so uninspired and incredibly passionless.
Depressed, sad faces all around - they probably hate their jobs. :/

[zigfreed]

Doesn't look different.

Wait, Catalyst 13.3 beta 3?
Shouldn't it be 13.3 beta 4?
Or more appropriate, 13.4 beta 1?

Don't tell me AMD kept the naming while this is actually a new, improved binary...

Yeah, the checksum is the same as the 2013-03-26 release. I'm assuming that there isn't a beta4, and this just announces that the release notes have been published.

[bridgman]

Sometimes I try to imagine how working at the AMD Linux binary driver division must be...
This all feels so uninspired and incredibly passionless.
Depressed, sad faces all around - they probably hate their jobs. :/

I think you're missing the point. The priorities and goals for the binary mostly come from the workstation business unit, and WS customers are quite a bit more likely to run on stable enterprise distros.

It's not a black-and-white thing but last time I asked the workstation folks there was more customer interest in supporting RHEL 4 (!!) than in supporting the fastest moving consumer distros.

Open source drivers focus more on upstream and fast-moving distros. Originally there was a big gap between what the radeon and Catalyst drivers covered but the gap is closing over time.

[schmidtbag]

Being an Arch user, I don't tend to care what kernel version is supported because the Arch devs seem to do a fantastic job at making it work anyway. Now if only they could do the same for xorg-xserver.

It's nice to see both Nvidia and AMD are putting a little more attention toward linux lately, but I do fear things like Mir will deter their efforts. Fragmentation is one of the main reasons why regular software devs don't focus on linux. It's one thing for AMD, nvidia, and intel to have to deal with different kernels, versions of Xorg, and little tweaks that every other distro decides to make - imagine how much more difficult it will be to have to support wayland and Mir on top of it. I don't blame AMD and nvidia for being uninterested, however, if they open sourced their code they could let the community take care a lot of these problems for them.

[Vim_User]

The priorities and goals for the binary mostly come from the workstation business unit

Sure, that that must be why they primarily fix gaming issues.

Seriously, AMD has to get their stuff right, now that the gaming market comes to Linux and they probably want to sell their stuff to Linux gamers. Nvidia has no problem with that and that makes Nvidia to me much more attractive than AMD. It is not that AMD has plenty of money so that they can afford to piss off their consumer customers. Almost all my stuff is AMD, but with basically saying "Hey, we care only for business users, the consumers can use old stuff or the incomplete FOSS drivers" this will not be anymore so in the future.

But back to the question I asked earlier: Is there some sort of roadmap for the binary driver? And if so, do you have access/are allowed to release it?

[Gps4l]

Sure, that that must be why they primarily fix gaming issues.

Seriously, AMD has to get their stuff right, now that the gaming market comes to Linux and they probably want to sell their stuff to Linux gamers. Nvidia has no problem with that and that makes Nvidia to me much more attractive than AMD. It is not that AMD has plenty of money so that they can afford to piss off their consumer customers. Almost all my stuff is AMD, but with basically saying "Hey, we care only for business users, the consumers can use old stuff or the incomplete FOSS drivers" this will not be anymore so in the future.

AMD has already achieved that on the steam for Linux, and other Linux game forums, nobody is considering an AMD graphics card anymore.

I am not even mad nor disappointed anymore.
But my next vid card will be nvidia.

[Calinou]

Being an Arch user, I don't tend to care what kernel version is supported because the Arch devs seem to do a fantastic job at making it work anyway. Now if only they could do the same for xorg-xserver.

It's nice to see both Nvidia and AMD are putting a little more attention toward linux lately, but I do fear things like Mir will deter their efforts. Fragmentation is one of the main reasons why regular software devs don't focus on linux. It's one thing for AMD, nvidia, and intel to have to deal with different kernels, versions of Xorg, and little tweaks that every other distro decides to make - imagine how much more difficult it will be to have to support wayland and Mir on top of it. I don't blame AMD and nvidia for being uninterested, however, if they open sourced their code they could let the community take care a lot of these problems for them.

It's one thing for AMD, NVIDIA and Intel to deal with different Windows versions too.

[Sonadow]

It's one thing for AMD, NVIDIA and Intel to deal with different Windows versions too.

Except that Windows' stable ABI makes it trivial to maintain backwards compatibility between different versions.

Last i checked, one can install a Vista-era graphics driver into Windows 8 and the operating system will accept it and chug along fine, albeit with some minor hiccups here and there. That was exactly what I did for my legacy HD3470 in my notebook when running Windows 8. That's a 6 yr old driver we're talking about on a 6 month old operating system.

Try doing that with a 6 yr old version of Catalyst or ForceWare on a recent distro with say, a v3.4 kernel and xserver 1.12and see if X has not been completely hosed after the reboot.