Announcement

Collapse
No announcement yet.

AMD Seeking Comments On DC/DAL Code, Wants To Land It Soon For Future GPU Support

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

  • #21
    Originally posted by newwen View Post
    Unless AMD changes its strategy and removes the abstraction layer
    unless you pay the same as windows customers, amd will finish this in next century. but you could sit on tree and give advice nevertheless

    Comment


    • #22
      Ouch, I feel very sad for AMD here, it seems they have invested a lot of resources into this. But it also shows some communication problems: It seems that they should have contacted the maintainers waaay earlier about their design.

      I still see a few possibilities for them to scrap their HALs and produce (almost) nice idiomatic Linux code. But this could require some adjustment of their toolchain/other internal tools that they use for validation and packaging on other OSes. Since I don't know precisely how they do it, I won't risk any guesses. Either way, it does not seem to be easy.

      On the up side, since the code is already opened, we will clearly benefit from it in the long run, but I also want to see AMD succeed at reducing their workload.

      Comment


      • #23
        But it also shows some communication problems: It seems that they should have contacted the maintainers waaay earlier about their design.
        Probably true. We're also talking about a rather huge amount of code here which has been rejected over and over for almost a year now, enough reason to doubt that this will *ever* make it into the kernel. And then everyone will be blaming AMD for not supporting Freesync etc. in the open driver stack...

        pal666 jesus christ, did those guys do any harm to you to deserve this amount of arrogance from your part? I know we're on the internet but some *basic* level of politeness shouldn't be too much to ask.

        Comment


        • #24
          Originally posted by VikingGe View Post
          Probably true. We're also talking about a rather huge amount of code here which has been rejected over and over for almost a year now, enough reason to doubt that this will *ever* make it into the kernel. And then everyone will be blaming AMD for not supporting Freesync etc. in the open driver stack...
          And it would be AMD who got thing wrong. We've no idea what the DAL3 team were asked to come up with, but what they didn't come up with was an upstreamable driver, if that was on the goal sheet, it either wasn't far enough up it, or nobody had any idea what it meant.

          Dave.

          Comment


          • #25
            Originally posted by VikingGe View Post
            I know we're on the internet but some *basic* level of politeness shouldn't be too much to ask.
            like "don't give advice without understanding subject matter"?

            Comment


            • #26
              Originally posted by M@yeulC View Post
              I still see a few possibilities for them to scrap their HALs and produce (almost) nice idiomatic Linux code.
              you see amd increasing linux marketshare? you are optimist

              Comment


              • #27
                Originally posted by airlied View Post

                And it would be AMD who got thing wrong. We've no idea what the DAL3 team were asked to come up with, but what they didn't come up with was an upstreamable driver, if that was on the goal sheet, it either wasn't far enough up it, or nobody had any idea what it meant.

                Dave.
                The professional and the end-user struggle inside me as I read your replies on the list. The end-user says "shut up and merge it" as this is a way to not have to compile my own kernel with the patches as I can't install the PRO version because - due to AMDs fault - is supporting only "old" kernels and specific distros without patching.

                The professional says "you've got a very valid point" to ensure quality and standards in your product (gfx part of the kernel) but still you handled it very unprofessional in the first email, very emotional, so I can be emotional here.

                What you and the Linux community be missing if you don't merge is pretty obvious at this time: the change for a MAJOR open source driver in the linux kernel thus out of the box superior graphics support for your end users. End users is the key here, is what creates word of mouth, especially gamers, what will make it possible to indeed have the "Year of Linux Desktop". And this is something you need to put into perspective when you write that there have been other vendors trying to do the same, hell the only major vendor for graphics is nvidia and I highly doubt they tried to have such a good open source support - Intel doesn't count for gaming hardware plus they care mostly for their server support. So I don't believe that you'll create a precedent here if you merge it and I'm pretty sure you can find a way by discussing it with AMD *directly* that will leverage for this.

                Your other major point that Linus will be displeased is from my point of view moot. This is a high profile merge - have him openly make a statement here. He might say "fuck you AMD" but he might also understand what are the trade-offs here and what Linux will gain. Pretty simple situation to be honest, you are not sure, discuss it with +1 - Linus in this case - no point writing oh he will be displeased etc.

                Bottom line, further discuss this with all parties, don't shut the door in 2 emails.

                thanks

                Comment


                • #28
                  Originally posted by gbil View Post
                  ...
                  Your other major point that Linus will be displeased is from my point of view moot.
                  ...
                  I think his only major point is this one: That "100,000 lines of abstracted HAL code" is not a good thing to have in the kernel.

                  The two points you mentioned only point out that 1) it is not directed jsut at AMD, but applies generally, and 2) it is not just his personal point of view.

                  Comment


                  • #29
                    Originally posted by indepe View Post

                    I think his only major point is this one: That "100,000 lines of abstracted HAL code" is not a good thing to have in the kernel.

                    The two points you mentioned only point out that 1) it is not directed jsut at AMD, but applies generally, and 2) it is not just his personal point of view.
                    Couldn't AMD do something liek this? :
                    1. Kernel with bare minimum HAL code
                    2. Real HAL code independent from kernel and drivers
                    3. Drivers

                    Then they just package their HAL code with the drivers.
                    Or is it not that simple?

                    Comment


                    • #30
                      Originally posted by nomadewolf View Post

                      Couldn't AMD do something liek this? :
                      1. Kernel with bare minimum HAL code
                      2. Real HAL code independent from kernel and drivers
                      3. Drivers


                      Then they just package their HAL code with the drivers.
                      Or is it not that simple?
                      I think they'd loose KMS and go back to UMS. Also, I don't think Linux DRM maintainers would accept such HAL in the kernel.

                      Comment

                      Working...
                      X