AMD Is Exploring A Very Interesting, More-Open Linux Driver Strategy

[GreatEmerald]

Hmm, this is quite along the lines of what I was suggesting earlier. Though my idea was more akin to refactoring Catalyst into closed plugins for the FOSS driver (something like the S3TC situation is now). That would mean even less Catalyst and more radeon[si].

Highly doubt that NVIDIA is interested in AMDs OpenGL "secret sauce" since they clearly don't need it. AMD doesn't have a competitive advantage over NVIDIA when it comes to OpenGL so what's there to lose?

Yea, plus, isn't that what patents are supposed to be for?

[Calinou]

Too bad, they said nothing about the firmware which is still proprietary (it's not like they didn't avoid that intentionally).

[bridgman]

Yea, plus, isn't that what patents are supposed to be for?

Patents are a really expensive way of protecting IP, and don't work particularly well in a closed source environment since you have no obvious way to know if a violation occurred. You also have to make the information public as part of the patent process, and in many cases the idea is more useful than the patentable details (since patents really describe a specific implementation rather than an underlying idea).

Patents work well when the IP is visible to the general public by virtue of how it is used in a product, but in a closed-source environment using trade secrets requires less effort, less expense, and is generally more effective... and yes that does make closed source software a bit of a self-perpetuating thing.

Someone asked earlier about making everything open source except a few small binary modules containing the secrets. Problem is that reverse engineering small binary modules surrounded by open source is really easy. The idea has been tried a few times already (IIRC Intel used to have a binary shader compiler module, for example) but never seemed to work for anyone.

[hajj_3]

bridgman, how long do you reckon it will take until catalyst's performance is about the same as the windows version?

[bridgman]

bridgman, how long do you reckon it will take until catalyst's performance is about the same as the windows version?

I think it's a function of what you test with. Performance work on the Linux Catalyst stack is mostly focused on workstation apps, and I suspect the performance delta relative to Windows is already pretty small.

[agd5f]

bridgman, how long do you reckon it will take until catalyst's performance is about the same as the windows version?

One important thing to note is that catalyst Linux is focused on workstation application performance.

[bridgman]

Too bad, they said nothing about the firmware which is still proprietary (it's not like they didn't avoid that intentionally).

Calinou, are you talking about the microcode images or about AtomBIOS ? Guessing you're talking about HW microcode, since we already publish the data structures for AtomBIOS data tables and provide an open source interpreter for the command tables.

[dungeon]

bridgman, how long do you reckon it will take until catalyst's performance is about the same as the windows version?

They can reduce differencies and be somewhat similar, but will never be the same - so, long live to benchmarking .

[bridgman]

They can reduce differencies and be somewhat similar, but will never be the same - so, long live to benchmarking .

Right. Sometimes Linux will be faster

[AJSB]

One important thing to note is that catalyst Linux is focused on workstation application performance.

So , in a nutshell , when we play games with Catalyst , we actually are using a driver FULLY optmized for workstations and NOT gaming....no wonder all the stuttering when doing so...