Announcement

Collapse
No announcement yet.

It Looks Like AMDGPU DC (DAL) Will Not Be Accepted In The Linux Kernel

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by debianxfce

    What rules, linux kernel is chaotic. Just look the Nouveau driver. DAL is under compilation flag, so Dave and his fans can flag it out instead of blocking it totally.

    Communists wants you to work and Redhat really cause extra work to everyone. Dave wants that amd should have separate code for linux and windows. When installing Debian, you need to remove pulseaudio and avoid gnome stuff when you can.
    1. You're overusing the "Communist" label to the point where it has no meaning, whatsoever.
    2. Aren'T you from China or Russia? Fuck off, mate!

    Comment


    • #42
      Originally posted by airlied View Post
      A large company which has a number of highly skilled experienced kernel developers on their staff, who were well aware of the upstream position.
      Hi Dave,
      I perfectly understand your position as a maintainer, and now we are all aware of your "no" position However as Bridgman suggests, Harry was probably seeking more detailed comments than that. Could you possibly offer AMD some advise for how to change DC to the desirable form and maybe a minimum threshold to achieve in that direction before you would accept a merge of the code?
      Being blunt has the benefit of getting everyones attention, so now is probably a good time to take advantage on that attention

      Cheers

      Comment


      • #43
        Originally posted by airlied View Post

        A large company which has a number of highly skilled experienced kernel developers on their staff, who were well aware of the upstream position. Take from that what you will.

        I also look forward to hearing the plans for stable abstractions proposed on linux-kernel.

        Dave.
        No need to get all passive aggressive on me. As I said in the original post, I do understand your stance on the matter. All I am saying is that there is no reason to write good code twice - no matter how many skilled programmers are available. Then I gave an example of what might happen, if there is no way to find some common ground between closed and open source drivers (Nouveau). BTW I am pretty sure, the nouveau-guys are pretty skilled as well. They just have to keep reinventing the wheel giving them a hard time. Finding a reasonable way to make use cross-platform code seems like a good goal to me, especially giventhat most of the GPU-market takes place on Windows.

        Also, if some common abstraction was to be found, I am by no means qualified to come up with it. If anyone, it should probably be you due to your experience and qualification. I am relatively pessimistic that this will ever happen, though. The past of certain drivers requiring outdated kernels to work can also be seen as an argument pointing in this direction.

        Anyway, I do appreciate your work on all of this, in case this didn't come across in my original post. Peace

        Comment


        • #44
          It must be tough for both Dave and the Amd kernel team.
          I hope the Amd team can find a solution that makes everyone happy.

          Comment


          • #45
            Originally posted by bridgman View Post
            I don't believe APUs are officially supported with AMDGPU-PRO at this point...
            Hm on mine Kabini APU (desktop one, Athlon 5350), PRO worked since 9 month ago or something like that, basically it worked on any point since CIK was introduced. Of course if you wanna not to advertise what works, that is your choice

            Comment


            • #46
              Nvidia, smart company, ignores stupid politics of kernel devs and gives users best drivers and maximizing limited resources by not reinventing the wheel.

              AMD, dumb company, gives up everything and still gets treated like dirt by kernel devs and forced to reinvent the wheel.

              Comment


              • #47
                I love a bit of drama to move things along. I'm sure you guys will figure out a good solution that works for all.

                Comment


                • #48
                  Originally posted by bridgman View Post
                  Nobody was suggesting using the code in its current state for any hardware. That's why this feels like a disconnect.
                  ...
                  - Daniel responded but mostly talked about current (or recent) state of the code rather than the specifics of the RFC... wasn't necessarily against the idea of code sharing in principle but felt that DC in its current form would still be a problem because it internalized things that probably should be managed elsewhere
                  ...
                  Maybe the disconnect is about the amount of changes that are considered necessary before the code could be accepted in the kernel.
                  From your posts I get the impression that a solution is around the corner, while from Dave's messages/emails I get the impression that it may be a large amount of work and not necessarily expected to be ready if the new hardware comes out anytime soon.

                  Comment


                  • #49
                    Hi yall & Dave,

                    Michael thanks for the great article, pointing out the situation with AMD & how they have painted themselves into a corner. Observing this behaviour for 10 years, is .... #shakeshead.

                    Dave, thanks for all the amazing work you have done! I am on Devuan Linux now & benefit from your work.

                    Time and again, I have asked ATI/AMD (and purchased their dam cards.), to put more resources into Linux/FreeBSD, so that peeps can use there hardware. while it is true over the last decade they have, their game still needs to be lifted somewhat.

                    GreekGeek :-)

                    Comment


                    • #50
                      It makes sence, I would be surprised if someone merged such a code bomb.

                      Comment

                      Working...
                      X