Amd/ati apu

[rohcQaH]

I still believe that having two drivers is big waste of time and resources. How many people are working on the Open Source driver: two to three? Those would better suited to fix long-standing bugs in the OpenCL or multimedia stacks...

Sounds perfect. And while they're at it, let them also fix some other deficiencies of the fglrx driver: missing KMS support, inability for out-of-the-box installs, possibility to obtain full backtraces, support for kernel-features marked as non-tainted-only, ...

oh, wait.

[Jonno]

IMHO, having a single good driver is better than two incomplete ones.

Very true. The problem is that the proprietary driver can never be "complete" due to it's proprietary nature, while the open source driver can (at least in theory), but will require a lot of work, probably years even if AMD put all it's engineering effort into it, to surpass the proprietary driver in every use-case (it already surpasses it in some). So for the long term concentrating on the open source driver would be better, but in the short term working on the proprietary driver is a necessary stop-gap measure.

[chaos386]

Those would better suited to fix long-standing bugs in the OpenCL or multimedia stacks...

I agree on the multimedia stack, but how can you have *long-standing* bugs for an API that reached 1.0 less than a year ago?

[droidhacker]

How many people are working on the Open Source driver: two to three? Those would better suited to fix long-standing bugs in the OpenCL or multimedia stacks... IMHO, having a single good driver is better than two incomplete ones.

Interesting that you should mention the number of devs that are working on the OSS driver... it seems to me that AMD planned this one out VERY well... for the minimum about of resources required to get the drivers up to their targets at the moment when it is truly needed.

Another thing to note: from my perspective, slower moving driver development seems to be beneficial at this stage in the game. There are MASSIVE architectural changes being implemented, so pouring all your resources into getting "full support" out for current architecture might mean wasting a huge amount of it when the current architecture becomes obsolete. When you slow down, you get to see the big picture, and get to adapt to the trends rather than ending up with something that is really out of place -- like, for example, both AMD's and NVIDIA's blob drivers lack KMS. Intel, moving at a snail's pace and leaning a little more open (even with their CLOSED drivers) have KMS implemented across the board.

[pingufunkybeat]

I still believe that having two drivers is big waste of time and resources. How many people are working on the Open Source driver: two to three? Those would better suited to fix long-standing bugs in the OpenCL or multimedia stacks... IMHO, having a single good driver is better than two incomplete ones.

Once Fusion becomes a reality, they will need open source drivers.

People will grudgingly accept closed drivers for their graphics card, but I don't think that anyone will accept installing a binary driver for their CPU. The whole thing needs to be supported in the kernel.

[Panix]

Another thing to note: from my perspective, slower moving driver development seems to be beneficial at this stage in the game. There are MASSIVE architectural changes being implemented, so pouring all your resources into getting "full support" out for current architecture might mean wasting a huge amount of it when the current architecture becomes obsolete. When you slow down, you get to see the big picture, and get to adapt to the trends rather than ending up with something that is really out of place -- like, for example, both AMD's and NVIDIA's blob drivers lack KMS. Intel, moving at a snail's pace and leaning a little more open (even with their CLOSED drivers) have KMS implemented across the board.

Bah... that perspective would progress towards inevitable failure. It's contrary to that, you want to be able to adapt and be quick for such progressions and changes. Going slow just means you're always playing catch up and various projects will be made 'broken' or made obsolete. It's what AMD/ATI does right now and obviously, it's not working and many Linux users are dissatisfied.

I think it's possible to take a long look at the big picture and where things are heading without taking it slow. The main problem is having quality when you work towards efficiency.

[droidhacker]

Bah... that perspective would progress towards inevitable failure. It's contrary to that, you want to be able to adapt and be quick for such progressions and changes. Going slow just means you're always playing catch up and various projects will be made 'broken' or made obsolete. It's what AMD/ATI does right now and obviously, it's not working and many Linux users are dissatisfied.

I think it's possible to take a long look at the big picture and where things are heading without taking it slow. The main problem is having quality when you work towards efficiency.

Implement now for the future: You end up with something that doesn't work now and might never work.
Implement now for now: You end up with something that works now, but won't for long.

Wait until things settle down a little bit: You save a pile of $$ and end up with something that works in the future.

[Gizmot]

I came exactly to the same conclusion as droidhacker.

Look at what AMD did in the 07-09 years: pretty much nothing.
R800 comes out: some sort of support for the chip and OpenGL+CL support.
In the last months: mainly power management.

The plan was never to actually support ATI cards. closed driver is there for FireGL cards. Legacy cards (that will include evergreen) will be supported probably half of 2011 since they will need the driver for fusion. Their aim is to release fusion with great opensource support so system admin can build massive servers based on fusion with thin clients around.
My guess other guess is that nvidia is waiting for AMD to spend money developing their hardware for them to opensource their own driver.

[Panix]

I guess I don't know the process but if that was the policy, it would be constant catchup and alternate with 'watch and react.' Planning and anticipating can always be done. Video drivers need a constant mod since various architectures that effect it are constantly changing and progressing. Constantly working on them means you learn and adjust.

If you implement for later and there's issues, what do you have to trace back?

[Panix]

The plan was never to actually support ATI cards. closed driver is there for FireGL cards. Legacy cards (that will include evergreen) will be supported probably half of 2011 since they will need the driver for fusion. Their aim is to release fusion with great opensource support so system admin can build massive servers based on fusion with thin clients around.

Well, then that's the problem then. No plan for support. You're done, finished. The End.