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.

    Comment


    • #32
      Dave and Lennart are siblings and this topic reminds me this:



      Do not use Redhat or Fedora if you are for open source and freedom.
      Last edited by debianxfce; 12-08-2016, 11:27 PM.

      Comment


      • #33
        debianxfce You are comparing someone being criticized to break the rules with someone who protects the rules. That's absolutely incomparable.

        Comment


        • #34
          Originally posted by Qaridarium View Post
          It is a hard lesson for you to learn and i told you this in the past that in the F(L)OSS world the commercial bullshit code is not allowed. you just did not listen and you pushed your own theory out of a anti-opensource theorie of F(L)OSS is as bad as commercial code and only with much more effort the code come to FLOSS standard.
          I think you are wrong! FLOSS is better from the start one and there is no way to lower this standards to commercial bullshit style code standards.
          I have no idea what all the "you did / you pushed / you are wrong" comments mean - when you say "you" do you mean me or AMD in general ?

          When you say "I think you are wrong" what statement of ours/mine are you disagreeing with ?
          Last edited by bridgman; 12-08-2016, 11:47 PM.

          Comment


          • #35
            Originally posted by c2h5oh View Post
            bridgman There definitely is a disconnect. Reading your posts, Harry's and Dave's messages I have an impression that you and Harry have and still are severely underestimating the amount of pushback there is against an effective extra abstraction layer between HAL and DRM. Anything that is more than a very thin HAL to a standardized common interface got a hard no.

            DC seems to be a common HAL for Linux and Windows + OS specific abstraction layer wiring it into DRM and what Dave keeps telling you is that is the opposite of what is acceptable. He even provides your with an example why: it's mac80211 all over again.

            My recommendation: get on Skype, Google Hangout or whatever. Something that gives both "sides" more ques than email, because clearly the disconnect is huge.
            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.
            Last edited by bridgman; 12-09-2016, 12:01 AM.

            Comment


            • #36
              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-08-2016, 11:53 PM.

              Comment


              • #37
                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, 12:25 AM.

                Comment


                • #38
                  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, 12:46 AM.

                  Comment


                  • #39
                    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


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

                      Comment

                      Working...
                      X