You can login if you already have an account or register by clicking the button below.
Registering is free and all you need is a username and password. We never ask you for your e-mail.
The ATI/AMD drivers have historically been proven to be delicate at best, but the open source drivers are rock solid(albeit less feature complete and slower). AMD's moving to a model based on the open source stack(or, more specifically, aiming to merge the two at the kernel level, though they're not there quite yet), so any instabilities should be less of an issue going forward(whereas previously the drivers liked to take your whole system down for no reason).
Linus's law: "Given enough eyes, all bugs are shallow"
The various open source graphics drivers have shared infrastructure since practically the beginning, creating points where working on one benefited the rest. The single biggest innovation, however, is the creation of kernel modesetting(KMS): traditionally, the graphics card was handled by the X server directly, so that things like setting the resolution and drawing images did an end run around the kernel. This did, however, require X initialize the card each time it was returned to the foreground after a virtual terminal switch, since it had no way of knowing the state of the card otherwise(this applies to switching between different X sessions, as well). Not the biggest problem with simple graphics, but the addition of 3D rendering makes the whole process more error prone and likely to lock up your computer since the penalty for failing to properly reinitialize the GPU then is that it either stops working entirely or starts writing to system memory. This is the main area where AMD did an unnecessarily crappy job, though the driver would sometimes lock up under normal use for no reason whatsoever(nVidia's blob has had very few such issues over the years).
Where KMS steps in is that the kernel portion of the driver now manages the card to the exclusion of any userspace programs; when you switch to and from an X session, the state of the card is always known, so problematic reinitialization is avoided. This design also makes it easier to stop malicious programs from hijacking the GPU to bypass security, since there's one point of entry that can sanitize or reject them.
However, since this was all developed in the Linux kernel, a proprietary driver wouldn't be able to legally invoke the necessary subsystems(Linus et al tend to be lax about GPL violations, but there is a mechanism in the kernel that prevents non-GPL modules from accessing resources if that maintainer doesn't want them to). This is where AMD's new driver architecture comes in: with a carefully crafted module, they can benefit from the eyes and effort devoted to the open source stack while still being able to keep their driver code secret.
TL;DR: ATI/AMD's programmers just sucked that bad.
view the rest of the comments →
[–] ShinyVoater 0 points 1 point 1 point (+1|-0) ago
The ATI/AMD drivers have historically been proven to be delicate at best, but the open source drivers are rock solid(albeit less feature complete and slower). AMD's moving to a model based on the open source stack(or, more specifically, aiming to merge the two at the kernel level, though they're not there quite yet), so any instabilities should be less of an issue going forward(whereas previously the drivers liked to take your whole system down for no reason).
[–] pitenius ago
??? That's ... like ... the opposite of what I'd expect. I guess the clue is speed and features...
[–] ShinyVoater 0 points 1 point 1 point (+1|-0) ago
Linus's law: "Given enough eyes, all bugs are shallow"
The various open source graphics drivers have shared infrastructure since practically the beginning, creating points where working on one benefited the rest. The single biggest innovation, however, is the creation of kernel modesetting(KMS): traditionally, the graphics card was handled by the X server directly, so that things like setting the resolution and drawing images did an end run around the kernel. This did, however, require X initialize the card each time it was returned to the foreground after a virtual terminal switch, since it had no way of knowing the state of the card otherwise(this applies to switching between different X sessions, as well). Not the biggest problem with simple graphics, but the addition of 3D rendering makes the whole process more error prone and likely to lock up your computer since the penalty for failing to properly reinitialize the GPU then is that it either stops working entirely or starts writing to system memory. This is the main area where AMD did an unnecessarily crappy job, though the driver would sometimes lock up under normal use for no reason whatsoever(nVidia's blob has had very few such issues over the years).
Where KMS steps in is that the kernel portion of the driver now manages the card to the exclusion of any userspace programs; when you switch to and from an X session, the state of the card is always known, so problematic reinitialization is avoided. This design also makes it easier to stop malicious programs from hijacking the GPU to bypass security, since there's one point of entry that can sanitize or reject them.
However, since this was all developed in the Linux kernel, a proprietary driver wouldn't be able to legally invoke the necessary subsystems(Linus et al tend to be lax about GPL violations, but there is a mechanism in the kernel that prevents non-GPL modules from accessing resources if that maintainer doesn't want them to). This is where AMD's new driver architecture comes in: with a carefully crafted module, they can benefit from the eyes and effort devoted to the open source stack while still being able to keep their driver code secret.
TL;DR: ATI/AMD's programmers just sucked that bad.