9 ms·

Dave Airlie's followup is pretty great, > Here's the thing, we want AMD to join the graphics community not hang out inside the company in silos. We need to en

Dave Airlie's followup is pretty great, > Here's the thing, we want AMD to join the graphics community not hang out inside the company in silos. We need to enable FreeSync on Linux, go ask the community how would be best to do it, don't shove it inside the driver hidden in a special ioctl. Got some new HDMI features that are secret, talk to other ppl in the same position and work out a plan for moving forward. At the moment there is no engaging with the Linux stack because you aren't really using it, as long as you hide behind the abstraction there won't be much engagement, and neither side benefits, so why should we merge the code if nobody benefits? > The platform problem/Windows mindset is scary and makes a lot of decisions for you, open source doesn't have those restrictions, and I don't accept drivers that try and push those development model problems into our codebase.

X86BSD 10y ago
That's an interesting take from someone who develops a kernel that the rest of the world has to rip out all sorts of "linux'isms" from code daily and deal with the pain of porting non portable Linux code to their platform. Jesus the hypocrisy is deep.
- eVeechu7 10y ago
  If someone writes application software that depends on the linux kernel, and someone else wants to port that code to another platform, how is the fact that code changes are required the fault of the kernel developers? I don't see any hypocrisy.
  - dom0 10y ago
    I feel X86BSD here, because Linux has a history of being different for the sake of being different. A relatively recent example could be getentropy (BSD) vs getrandom (Linux). OTOH Linux has some extremely useful syscalls that others just don't have, sometimes causing major performance regressions. Case in point: sync_file_range. But then Linux also has a history of screwing up and having a bunch of different syscalls on different platforms because somebody introducing a syscall didn't quite think it through. Case in point: sync_file_range. This "only" causes extra work for developers directly working with syscalls - so usually libc devs.
    - raverbashing 10y ago
      Yes, and this discussion makes perfect sense on user level code. Yes, Linux, Mac OSX and BSDs have their differences. But in the kernel, code is going to (or even has to) be less generic
      - dom0 10y ago
        Indeed
      - fithisux 10y ago
        Not if you choose a uKernel design and para virtualize the legacy OSes.
        aseipp 10y ago
        That's a nice computer science project but ultimately irrelevant in the context of kernel mode drivers, for like 99.99% of people who use Linux. Not that tiny hypervisors and stuff aren't cool, though.
    - AsyncAwait 10y ago
      Linux is Linux. BSD is BSD Windows also has different sys calls than both Linux and BSD, that's because it's a different OS. Yes, there's POSIX in there, but generally it is its own OS and you need to treat is as such, same as Windows really.
    - jordigh 10y ago
      > because Linux has a history of being different for the sake of being different. Heh. I get the same feeling about git when I'm working with hg, the Canada[1] of git. For svn, darcs, bzr, and Mercurial, "revert" means to change the working directory to the repo state. Why did git use it to mean creating a new commit that undoes an old commit? There's no use rallying against the majority software when it doesn't follow the standard. When you're the majority, you just get to make your own standards because you are the standard. BSD being the Canada of Linux, it's a little funny to hear them complaining about things that Linux does. -- [1] http://itre.cis.upenn.edu/~myl/languagelog/archives/005497.html http://itre.cis.upenn.edu/~myl/languagelog/archives/005497.h...
- aangjie 10y ago
  I upvoted your comment because it is a real pain. But I don't agree with blaming the Linux kernel developers for it. Neither do I think it's analogous to this particular discussion either, because a, Linux kernel developers can optimize/prioritize their kernel code as they please. b, In this case, AMD is submitting a patch to make it easier for them to support linux for their GPU. So the "ball is in their court" to find a solution the community finds acceptable. Your case is about porting code between different OS kernels.
- ionforce 10y ago
  I don't understand what this means.
  - bb611 10y ago
    I believe X86BSD is referencing the fact that Dave Airlie works on Red Hat Linux
    - solarengineer 10y ago
      Ah, I believe he is talking about the general pain all non-linux distros have faced over the years where we have to painfully keep replacing linuxisms in the code with portable code.
- AsyncAwait 10y ago
  So Linux is not allowed to demand quality code that is following their conventions and has to be satisfied with the minimum amount of effort for AMD's Windows code to run? Why should the Linux kernel include an abstraction layer for AMD's Windows code? Why would any sane person agree to that? > all sorts of "linux'isms" from code daily and deal with the pain of porting non portable Linux code to their platform. If you're developing for Linux, using Linux specific technology, then of course there would be porting effort required. Same as if you want to make you Windows stuff work on Linux, there should be porting required - after all, it's a different platform, What AMD wants to do is to sidestep as much of the porting as possible, by effectively shipping their Windows code inside the Linux kernel.
  - wolfgke 10y ago
    > So Linux is not allowed to demand quality code that is following their conventions and has to be satisfied with the minimum amount of effort for AMD's Windows code to run? Why should the Linux kernel include an abstraction layer for AMD's Windows code? Why would any sane person agree to that? Linux is open source, so if the kernel developers desire better designed code, they are free to change the code up to their quality levels. If the kernel development team does not have the manpower for this, they should better think about a way to maintain the kernel that involves less work. One example (among many) would be to think about a way to keep the internal kernel interfaces typically stable over many years so that only rarely there is a lot work to be done for updating all the drivers to the new internal kernel interfaces. > If you're developing for Linux, using Linux specific technology, then of course there would be porting effort required. The released open source drivers seem to work quite well (as they do on Windows). The problem is that they don't fit the taste of the kernel developers.
    - AsyncAwait 10y ago
      > Linux is open source Open source does not mean, "any code accepted here!" > if the kernel developers desire better designed code, they are free to change the code up to their quality levels. They are also free to reject bad code and demand that if you want you code in, you should improve it. I don't get this mentality at all; why should the kernel developers accept inferior code and then improve it? Isn't that the responsibility of the vendor who designed the product? After all, AMD is a for profit company, not a charity. Why should the other developers provide charity to make AMD code better? So that AMD can sell more units or have better PR? What? >The problem is that they don't fit the taste of the kernel developers. That's not the problem. The problem is that the drivers were designed for Windows, not Linux and such code is not suitable for inclusion in the Linux kernel.
- aseipp 10y ago
  dave airlie forces people at gunpoint to only write software for Linux and nothing else, meaning HEROES like myself have to pick up the slack. fact-a-mundo. it's also perfectly well known that if you dump 100,000 lines of code on a project, they are MANDATED BY LAW to accept it and not have standards to abide by. who do these jerks think they are????????? i'm definitely not mad and bitter about Linux in any way, grasping at straws in an attempt for relevance. i promise you. pinky swear.
  - throwaway3322 10y ago
    Austin, can you expand on the instances you reference where you've had to pick up the slack? Was it something in GHC?
    - lodi 10y ago
      Re-read it sarcastically...
wolfgke 10y ago
The problem is: Good driver developers are not always good politicians/diplomats and vice versa. What this followup demands is that developers are suddenly supposed to become politicians to get their implementation accepted. I mean: Lots of developers have a deep hate for "organizational politics" (IMHO rightfully so) - and this is suddenly something that should be accepted/loved when it is about Linux? I prefer to hold up the same standards to all kinds of organisations and don't make exceptions just because it is "for the good/open source/Linux".
- tremon 10y ago
  That's not how I read it. The driver developers are now acting as politicians, trying to merge their own AMD-specific worldview into an open structure and trying to convince the rest of the DRI world that that is a good thing. DA instead is saying to the developers that they need to play ball and work with the existing Linux DRI world and not silo themselves off.
  - wolfgke 10y ago
    > That's not how I read it. The driver developers are now acting as politicians, trying to merge their own AMD-specific worldview into an open structure and trying to convince the rest of the DRI world that that is a good thing. If AMD decided to simply leave their driver as closed-source blob, they would not have this problem. But all the Linux fanboys that they want AMD to open source their graphics drivers. Just to state one thing clear: AMD already released specifications beforehand such that the kernel developers could have developed an independent graphics driver if they wanted. But it is better to shitstorm companies not to develop a driver than to sully one's hands. AMD was nice and did its job. But instead of being satisfied with the result they now want AMD to start playing the political game with them (for the protocol: IMHO the correct thing to do would be to bring the driver to the staging area and now it's part of the kernel developers to sully their hands to bring the part up to the standards they want). NVidia simply refuses to open source their drivers and does not get into this kind of trouble. Lesson learned: Never negotiate with terrorists.
    - 10y ago
fithisux 10y ago
I agree with Dave. If they need an HAL, that is why standards are for. USB does not need any HAL. It is standardized. And this is where Khronos group falls short. They provide a standard implemented by the driver and not the hardware. There is not even a standard to get performance metrics for GFX cards. Nothing. I agree with Dave. If you do not want to create the standard, leave others to do it. But having an HAL inside the driver is problematic. Shall we have a cross-platform standard for writing cross-platform drivers? Write once, run everywhere? Why not as long as it is open source. But it still needs someone to govern it, like linux kernel project and device companies do not seem interested. Which says a lot for their intentions.

X86BSD 10y ago

That's an interesting take from someone who develops a kernel that the rest of the world has to rip out all sorts of "linux'isms" from code daily and deal with the pain of porting non portable Linux code to their platform. Jesus the hypocrisy is deep.

eVeechu7 10y ago
If someone writes application software that depends on the linux kernel, and someone else wants to port that code to another platform, how is the fact that code changes are required the fault of the kernel developers? I don't see any hypocrisy.
- dom0 10y ago
  I feel X86BSD here, because Linux has a history of being different for the sake of being different. A relatively recent example could be getentropy (BSD) vs getrandom (Linux). OTOH Linux has some extremely useful syscalls that others just don't have, sometimes causing major performance regressions. Case in point: sync_file_range. But then Linux also has a history of screwing up and having a bunch of different syscalls on different platforms because somebody introducing a syscall didn't quite think it through. Case in point: sync_file_range. This "only" causes extra work for developers directly working with syscalls - so usually libc devs.
  - raverbashing 10y ago
    Yes, and this discussion makes perfect sense on user level code. Yes, Linux, Mac OSX and BSDs have their differences. But in the kernel, code is going to (or even has to) be less generic
    - dom0 10y ago
      Indeed
    - fithisux 10y ago
      Not if you choose a uKernel design and para virtualize the legacy OSes.
      - aseipp 10y ago
        That's a nice computer science project but ultimately irrelevant in the context of kernel mode drivers, for like 99.99% of people who use Linux. Not that tiny hypervisors and stuff aren't cool, though.
  - AsyncAwait 10y ago
    Linux is Linux. BSD is BSD Windows also has different sys calls than both Linux and BSD, that's because it's a different OS. Yes, there's POSIX in there, but generally it is its own OS and you need to treat is as such, same as Windows really.
  - jordigh 10y ago
    > because Linux has a history of being different for the sake of being different. Heh. I get the same feeling about git when I'm working with hg, the Canada[1] of git. For svn, darcs, bzr, and Mercurial, "revert" means to change the working directory to the repo state. Why did git use it to mean creating a new commit that undoes an old commit? There's no use rallying against the majority software when it doesn't follow the standard. When you're the majority, you just get to make your own standards because you are the standard. BSD being the Canada of Linux, it's a little funny to hear them complaining about things that Linux does. -- [1] http://itre.cis.upenn.edu/~myl/languagelog/archives/005497.html http://itre.cis.upenn.edu/~myl/languagelog/archives/005497.h...
aangjie 10y ago
I upvoted your comment because it is a real pain. But I don't agree with blaming the Linux kernel developers for it. Neither do I think it's analogous to this particular discussion either, because a, Linux kernel developers can optimize/prioritize their kernel code as they please. b, In this case, AMD is submitting a patch to make it easier for them to support linux for their GPU. So the "ball is in their court" to find a solution the community finds acceptable. Your case is about porting code between different OS kernels.
ionforce 10y ago
I don't understand what this means.
- bb611 10y ago
  I believe X86BSD is referencing the fact that Dave Airlie works on Red Hat Linux
  - solarengineer 10y ago
    Ah, I believe he is talking about the general pain all non-linux distros have faced over the years where we have to painfully keep replacing linuxisms in the code with portable code.
AsyncAwait 10y ago
So Linux is not allowed to demand quality code that is following their conventions and has to be satisfied with the minimum amount of effort for AMD's Windows code to run? Why should the Linux kernel include an abstraction layer for AMD's Windows code? Why would any sane person agree to that? > all sorts of "linux'isms" from code daily and deal with the pain of porting non portable Linux code to their platform. If you're developing for Linux, using Linux specific technology, then of course there would be porting effort required. Same as if you want to make you Windows stuff work on Linux, there should be porting required - after all, it's a different platform, What AMD wants to do is to sidestep as much of the porting as possible, by effectively shipping their Windows code inside the Linux kernel.
- wolfgke 10y ago
  > So Linux is not allowed to demand quality code that is following their conventions and has to be satisfied with the minimum amount of effort for AMD's Windows code to run? Why should the Linux kernel include an abstraction layer for AMD's Windows code? Why would any sane person agree to that? Linux is open source, so if the kernel developers desire better designed code, they are free to change the code up to their quality levels. If the kernel development team does not have the manpower for this, they should better think about a way to maintain the kernel that involves less work. One example (among many) would be to think about a way to keep the internal kernel interfaces typically stable over many years so that only rarely there is a lot work to be done for updating all the drivers to the new internal kernel interfaces. > If you're developing for Linux, using Linux specific technology, then of course there would be porting effort required. The released open source drivers seem to work quite well (as they do on Windows). The problem is that they don't fit the taste of the kernel developers.
  - AsyncAwait 10y ago
    > Linux is open source Open source does not mean, "any code accepted here!" > if the kernel developers desire better designed code, they are free to change the code up to their quality levels. They are also free to reject bad code and demand that if you want you code in, you should improve it. I don't get this mentality at all; why should the kernel developers accept inferior code and then improve it? Isn't that the responsibility of the vendor who designed the product? After all, AMD is a for profit company, not a charity. Why should the other developers provide charity to make AMD code better? So that AMD can sell more units or have better PR? What? >The problem is that they don't fit the taste of the kernel developers. That's not the problem. The problem is that the drivers were designed for Windows, not Linux and such code is not suitable for inclusion in the Linux kernel.
aseipp 10y ago
dave airlie forces people at gunpoint to only write software for Linux and nothing else, meaning HEROES like myself have to pick up the slack. fact-a-mundo. it's also perfectly well known that if you dump 100,000 lines of code on a project, they are MANDATED BY LAW to accept it and not have standards to abide by. who do these jerks think they are????????? i'm definitely not mad and bitter about Linux in any way, grasping at straws in an attempt for relevance. i promise you. pinky swear.
- throwaway3322 10y ago
  Austin, can you expand on the instances you reference where you've had to pick up the slack? Was it something in GHC?
  - lodi 10y ago
    Re-read it sarcastically...

wolfgke 10y ago

The problem is: Good driver developers are not always good politicians/diplomats and vice versa. What this followup demands is that developers are suddenly supposed to become politicians to get their implementation accepted. I mean: Lots of developers have a deep hate for "organizational politics" (IMHO rightfully so) - and this is suddenly something that should be accepted/loved when it is about Linux? I prefer to hold up the same standards to all kinds of organisations and don't make exceptions just because it is "for the good/open source/Linux".

tremon 10y ago
That's not how I read it. The driver developers are now acting as politicians, trying to merge their own AMD-specific worldview into an open structure and trying to convince the rest of the DRI world that that is a good thing. DA instead is saying to the developers that they need to play ball and work with the existing Linux DRI world and not silo themselves off.
- wolfgke 10y ago
  > That's not how I read it. The driver developers are now acting as politicians, trying to merge their own AMD-specific worldview into an open structure and trying to convince the rest of the DRI world that that is a good thing. If AMD decided to simply leave their driver as closed-source blob, they would not have this problem. But all the Linux fanboys that they want AMD to open source their graphics drivers. Just to state one thing clear: AMD already released specifications beforehand such that the kernel developers could have developed an independent graphics driver if they wanted. But it is better to shitstorm companies not to develop a driver than to sully one's hands. AMD was nice and did its job. But instead of being satisfied with the result they now want AMD to start playing the political game with them (for the protocol: IMHO the correct thing to do would be to bring the driver to the staging area and now it's part of the kernel developers to sully their hands to bring the part up to the standards they want). NVidia simply refuses to open source their drivers and does not get into this kind of trouble. Lesson learned: Never negotiate with terrorists.
  - 10y ago

fithisux 10y ago

I agree with Dave. If they need an HAL, that is why standards are for. USB does not need any HAL. It is standardized. And this is where Khronos group falls short. They provide a standard implemented by the driver and not the hardware. There is not even a standard to get performance metrics for GFX cards. Nothing. I agree with Dave. If you do not want to create the standard, leave others to do it. But having an HAL inside the driver is problematic. Shall we have a cross-platform standard for writing cross-platform drivers? Write once, run everywhere? Why not as long as it is open source. But it still needs someone to govern it, like linux kernel project and device companies do not seem interested. Which says a lot for their intentions.