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

  • #31
    Originally posted by debianxfce
    Dave is a wannabee driver programmer, vulkan coding proves it. He would rather work in amd, but because his code quality is poor, amd will not hire him and this way he has his revenge.
    Actually Dave was the first person I called to ask for advice when I volunteered to set up the open source graphics initiative back in 2007, and you are probably running quite a bit of his code on your system today.

    Dave had already accepted an offer from Red Hat by the time we first talked.
    Last edited by bridgman; 12-09-2016, 12:53 AM.

    Comment


    • #32
      Originally posted by bridgman View Post

      Did anyone actually READ the RFC ? Harry was proposing precisely one thing for comment - using DC initially for as-yet-unreleased hardware rather than trying to cut over all of the currently supported chips at the same time.
      I read it, but I'm not sure why you think that matters. Nothing in Dave's response left me thinking he was ok with using that code for new hardware as long as the old hardware wasn't switched over. He seemed to be pretty clear it wasn't acceptable at all, for ANY hardware.

      I think that's the disconnect people are seeing here.

      Dave says "NO! NEVER!" and you say, "but we're only using it for new hardware, so maybe it's ok after all," and meanwhile Dave is still yelling NO at the top of his lungs.
      Last edited by smitty3268; 12-09-2016, 01:25 AM.

      Comment


      • #33
        I guess on this point that DAL (i wouldn't call that AC nor DC, when it is DAL) is not high priority for AMD , opensource driver customers seems don't wanna HDMI 2.0, HDMI Audio, FreeSync... and that Michael's Hawaii which fail on open is still not high priority

        Soon people would be better to forget this year and happy new year What about APUs with PRO bridgman? Those still point out to unbreakable FGLRX year later

        Happy 2020.
        Last edited by dungeon; 12-09-2016, 01:46 AM.

        Comment


        • #34
          Originally posted by bridgman View Post
          Did anyone actually READ the RFC ? Harry was proposing precisely one thing for comment - using DC initially for as-yet-unreleased hardware rather than trying to cut over all of the currently supported chips at the same time. He also said that we couldn't publish the "new GPU" code yet but in the meantime we would continue to work away in public on the changes that had been identified in the initial review.
          And Dave's response is: no, that's not OK. we've accepted a similar (but closer to what we want) code once for Exynos and based on that experience we're not doing it again.

          Comment


          • #35
            Well this suddenly makes Nvidia's choice to stick with the blob make a lot more sense.

            Comment


            • #36
              This is pretty sad. Whatever peoples' opinions towards this issue are it highlights one thing: even a relatively big company that has arguably put a lot of effort into Linux and open source drivers is having trouble to get large state of the art code merged. While I understand that a large piece of software such as the graphics stack and the kernel need to adhere to a fixed set of conventions, I am leaning somewhat towards AMDs point of view. It is simply wasteful to develop the same display code twice so a thin layer which connects all the real functionality to the OS-specifics seems reasonable to me. If that is not allowed, we will see a NVIDIA-like situation for AMD as well. NV have a great closed source driver that works across all platforms but it's not open source and most likely, it is full of abstractions. Nouveau on the other hand cannot benefit from anything in there so they are lagging behind. I fear, AMD's attempt to be very open source friendly will end up the same. Maybe, it is time to think about a stable abstraction within the Linux kernel which can be targeted by drivers.

              Comment


              • #37


                Originally posted by smitty3268 View Post
                I read it, but I'm not sure why you think that matters. Nothing in Dave's response left me thinking he was ok with using that code for new hardware as long as the old hardware wasn't switched over. He seemed to be pretty clear it wasn't acceptable at all, for ANY hardware.
                Nobody was suggesting using the code in its current state for any hardware. That's why this feels like a disconnect.

                Originally posted by smitty3268 View Post
                Dave says "NO! NEVER!" and you say, "but we're only using it for new hardware, so maybe it's ok after all," and meanwhile Dave is still yelling NO at the top of his lungs.
                Except that's not what was said.

                We said "when it's ready, ie not in its current state, we propose to start using it first for new hardware". If Harry had asked to upstream the code in its current statue, or if Dave had gained access to a time machine so he could inspect future code, then I would agree with your interpretation.

                What I think happened is:

                - Harry wrote a fairly long email that talked about work in process but which only explicitly proposed one thing - going upstream first with one future part, written as an RFC because we need to know if the direction generally makes sense so we can structure our internal branches accordingly

                - 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

                - Dave responded partially to Harry and partially to Daniel (which had the probably-unintended effect of shifting the discussion even further away from the original RFC topic) saying basically the same thing but more emphatically, just so there was no misunderstanding (ie doing his job)

                All seemed reasonable to me other than maybe (AFAICS) nobody actually responding to the core question in the RFC.
                Last edited by bridgman; 12-09-2016, 02:19 AM.

                Comment


                • #38
                  Originally posted by GruenSein View Post
                  This is pretty sad. Whatever peoples' opinions towards this issue are it highlights one thing: even a relatively big company that has arguably put a lot of effort into Linux and open source drivers is having trouble to get large state of the art code merged. While I understand that a large piece of software such as the graphics stack and the kernel need to adhere to a fixed set of conventions, I am leaning somewhat towards AMDs point of view. It is simply wasteful to develop the same display code twice so a thin layer which connects all the real functionality to the OS-specifics seems reasonable to me. If that is not allowed, we will see a NVIDIA-like situation for AMD as well. NV have a great closed source driver that works across all platforms but it's not open source and most likely, it is full of abstractions. Nouveau on the other hand cannot benefit from anything in there so they are lagging behind. I fear, AMD's attempt to be very open source friendly will end up the same. Maybe, it is time to think about a stable abstraction within the Linux kernel which can be targeted by drivers.
                  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.

                  Comment


                  • #39
                    Originally posted by dungeon View Post
                    I guess on this point that DAL (i wouldn't call that AC nor DC, when it is DAL) is not high priority for AMD , opensource driver customers seems don't wanna HDMI 2.0, HDMI Audio, FreeSync... and that Michael's Hawaii which fail on open is still not high priority

                    Soon people would be better to forget this year and happy new year What about APUs with PRO bridgman? Those still point out to unbreakable FGLRX year later

                    Happy 2020.
                    AFAIK we still have not been able to duplicate what Michael is seeing on Hawaii. I think we are going to have to either swap cards with him or remote into his system to find out what is going on.

                    I don't understand your comment about open source driver customers not wanting features, can you reword ?

                    I don't believe APUs are officially supported with AMDGPU-PRO at this point (aiming more at dGPU) but we probably need to make a clearer statement re: recommendations for systems with APU+dGPU, particularly now that we have SI support (since so many of the dGPUs in laptops are low-end SI).

                    I run the all-open stack on mine, for what it's worth, but the dGPU is slower than the APU so I represent a fairly simple use case.
                    Last edited by bridgman; 12-09-2016, 02:22 AM.

                    Comment


                    • #40
                      I mean it _seems_

                      Reading bugzilla, seems Marek nailed 9 year old bug and making TF2 stable finnaly. Michael should advertise End of PITA - that takes only one year to be found

                      https://bugs.freedesktop.org/show_bug.cgi?id=93649#c64
                      Last edited by dungeon; 12-09-2016, 02:48 AM.

                      Comment

                      Working...
                      X