[AsyncAwait]

> But all the Linux fanboys

You already lost the argument, if you have to go with that, but I'll try my best to explain anyway; what the kernel developers want is for people to use the standard, already maintained interfaces, instead of companies developing their own and adding unnecessary complexity to the kernel, which would then need to be maintained by someone for a long time.

AMD is basically writing an abstraction layer to allow them to use their Windows driver code, the Linux maintainers are saying; why should we have an "inferior" driver, that's basically "ported" from Windows? If you want to support Linux, write code that interacts with standard Linux interfaces, follows our conventions and benefits the community as a whole.

> Lesson learned: Never negotiate with terrorists.

So not wanting to merge shitty* code into your codebase is now terrorism?

[wolfgke]

> the Linux maintainers are saying; why should we have an "inferior" driver, that's basically "ported" from Windows?

As I wrote: AMD already indulged a lot (first specifications, then even an open source Linux driver). Even after the first step the kernel developers would be able to write a Linux drivers(though it is a lot of work). I already clarified: AMD did all this to satisfy what the Linux fanboys wanted (while NVidia did nothing). But instead of saying "thanks for all the work you did, AMD. The driver is currently not up to the standards that we desire, but it still helped us to make the driver development a lot less work. We [kernel developers] will do the remaining job and lift the kernel up to the superior quality that we want.". But that is not what the kernel developers did. Instead they want AMD to dance to the kernel developer's piping.

[AsyncAwait]

> The driver is currently not up to the standards that we desire, but it still helped us to make the driver development a lot less work. We [kernel developers] will do the remaining job and lift the kernel up to the superior quality that we want.

Do you know who the elusive kernel developers that you keep referring to are? They're mostly employees of various other companies who want their code merged into the kernel and have to follow the same standards to get their code in!

Why should AMD be any different? Why should somebody else pick the slack up for AMD? Does AMD pick the slack for Intel as well? And who would them keep up with their upcoming silicon etc. (It wouldn't be AMD, since this approach makes it easier for them). Why would one company be allowed to sidestep what is required to get your code into the kernel? Is it because they showed some good will in the past? Is that why inferior code should now be allowed?

> they want AMD to dance to the kernel developer's piping.

So let me get this straight. AMD wants to merge their code into the Linux kernel, (not the other way around), but it's the kernel developers who should instead "dance to the AMD developer's piping"?

Look, It's good that they are trying and obviously, the code may be accepted at some point in the future, if it's good enough, but for now, let's not let our emotion, (AMD are the good guys), override our rational thinking.

[wolfgke]

> They're mostly employees of various other companies who want their code merged into the kernel and have to follow the same standards to get their code in!

Hardware differs a lot in complexity. GPUs are very complicated.

Independently: The job security of these people also depends on the fact that it is so politically involved to get "their" driver into the kernel. So they surely have no incentive to make it easier for other companies/developers to get their drivers in (for example by very stable internal kernel interfaces).

> AMD wants to merge their code into the Linux kernel

AMD indulged on the desire of lots of Linux users for open source drivers. They did their job. NVidia did nothing.

[AsyncAwait]

> Hardware differs a lot in complexity. GPUs are very complicated.

Yes, Intel has an open-source GPU driver in the kernel, AMD can too, they just need to follow the conventions.

> they surely have no incentive to make it easier for other companies/developers to get their drivers in (for example by very stable internal kernel interfaces).

The kernel interface around DRI is actually quite stable, I don't think making it hard for AMD to merge in their driver would help with anybody's job security. It would certainly not be enough to affect GPU market share in a significant way, so it would be very risky for little gain?

Why invent conspiracy theories, rather than just accept the far more likely explanation that AMD's code is not up to the job?

> AMD indulged on the desire of lots of Linux users for open source drivers. They did their job.

No they didn't. If they wanted to fulfil the promise of delivering a kernel driver because their users demanded it, they would have done their job, had they produced code that follows the conventions and work with the maintainers to get the code accepted.

Throwing some code over the wall, does not meet any reasonable definition of "doing their job".

> NVidia did nothing.

Ah, so now it's about, "but look over here, they're even worse!"

I mean, OK, NVidia did nothing, AMD did something, but not enough. Intel did even more than AMD did and is still not perfect. Why couldn't AMD be at least as good, if not better than Intel? If you want to compare, why compare against the worst, rather than the best player?

And, why can't we judge this independently?

Irrespectively of NVidia or Intel, this is what AMD produced and it's not yet good enough.

[egil]

They ignored feedback from february[0]. How can that be "doing their job"? Do you think Ms would sign drivers that did the opposite of their guidelines?

[0] https://lists.freedesktop.org/archives/dri-devel/2016-Februa...

[wolfgke]

> Do you think Ms would sign drivers that did the opposite of their guidelines?

According to

> https://technet.microsoft.com/en-us/library/eb9b35a3-64e9-4c...

the central component that Microsoft requires is a code signing certificate (i.e. money and perhaps a little boring bureaucracy, which still can be done in a very systematic way). What Microsoft tests internally at the drivers is whether they have potential dangerous security bugs (e.g. buffer overflows). You can architect the drivers as you want to (though Microsoft provides guidelines and reference source code to make it easier to write drivers "the officially desired way").

Getting the drivers into the Linux kernel means - as one can see - going deeply into kernel politics. If Microsoft required something similarly, the hardware vendors would tap their forehead at Microsoft.

[msandford]

Great point! Microsoft does require something similar. You _only get to use the APIs they provide_ which absolutely means that you don't get to write kernel patches to change the source of the kernel to invent new APIs which you want to use to write drivers for your product. So yeah, Microsoft does exactly this.

It's not as though if AMD had developed drivers for Linux first that they could then go bully MS into allowing them to patch the Windows kernel so that they didn't have to modify their Linux drivers to get them ported to Windows.

[AsyncAwait]

> Getting the drivers into the Linux kernel means - as one can see - going deeply into kernel politics. If Microsoft required something similarly, the hardware vendors would tap their forehead at Microsoft.

I'd imagine if you wanted to include code in the NT kernel they would. But since they don't allow you to include your code in the NT kernel at all, they don't require what the Linux kernel developers require,

i.e. MS is not providing the same level of access, so it doesn't have the same requirements.

[htns]

There is also that the quality of the old closed source fglrx driver was just ass. It would be naive to think all code coming from AMD has acceptable quality.