Announcement

Collapse
No announcement yet.

Google Engineers Have Been Working On An AMD SB-TSI Temperature Driver

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

  • #21
    Originally posted by Space Heater View Post
    It sounds like AMD legal is the roadblock once again, same reason Navi support was delayed for months.
    Legal is usually not the the road block when releasing code. navi code was released close to launch for competitive reasons. The gaming dGPU market is highly competitive and Linux is not a big enough percentage of it justify the risks in many cases.

    Comment


    • #22
      Originally posted by agd5f View Post
      Legal is usually not the the road block when releasing code. navi code was released close to launch for competitive reasons.
      That's a bit disappointing to hear.

      But just to show I wasn't hallucinating about IP review, Bridgman mentioned a while back (regarding the Navi delay):
      Seriously though, we were targeting 5.2 but the last few parts of IP review and approvals took quite a bit longer than expected... which was actually a bit of a surprise because it has been fairly predictable for the last few years.

      Originally posted by agd5f View Post
      The gaming dGPU market is highly competitive and Linux is not a big enough percentage of it justify the risks in many cases.
      Polaris and Vega support was added more quickly from what I recall, was this a change in policy for Navi?

      Also, does this mean we should not expect to have day-1 support for new AMD graphics cards going forward?

      Comment


      • #23
        It was a combination of things... Navi was significantly new hardware aimed at the (Windows-centric) gaming market rather than embedded or data center, so there was business pressure to hold off on releasing open source driver support until closer to launch than normal.

        Polaris hardware was different from earlier GFX8 GPUs but the driver-visible changes were quite small. Vega was aimed at both gaming and data center, so we had at least one business unit calling for early upstreaming.

        Add an IP review cycle that took longer than expected and we ended up releasing code closer to launch than usual, although for was still out before launch (~3 weeks for kernel, ~2 weeks for Mesa IIRC). Normally we like to get code out earlier than that so it can be pulled into upstream and available in packaged builds before launch.

        In general I think it's safe to say that Navi10 was the exception rather than the rule.
        Last edited by bridgman; 23 March 2020, 10:39 PM.
        Test signature

        Comment


        • #24
          Originally posted by M@GOid View Post
          As a AMD fanboy, I find it shameful that it took outsiders to write code for this important feature, especially on the high lucrative enterprise sector.

          Yeah AMD, people gots to know if the temp is 55C or 66C.
          Yep. I complained that AMD didn't bother adding support for reading temp sensors for some of their CPUs and that it was bad strategy since most od the server world uses Linux.

          Some idiot AMD fanboys said there was no problem because they used BMCs in the server space, so temperature reporting would work fine.

          Except now we see that third parties are once again the ones adding actual support for Linux.

          AMDs support for Linux is just crap compared to Intel's. I used to be an AMD fanboy, but their attitude towards Linux has dissuaded me.

          Comment


          • #25
            So idiotic fears and concerns led to slow open source AMD support? Ugh.

            Intel doesn't seem to have this problem. They released code for Gen 12 which will power their Xe dGPUs way ahead of launch. They don't seem to be paranoid about people seeing that code.

            Because they understand that their customers being able to use their hardware is more important than crazy, paranoia about releasing code that's specific to their hardware.

            Comment


            • #26
              Originally posted by sandy8925 View Post
              So idiotic fears and concerns led to slow open source AMD support? Ugh.

              Intel doesn't seem to have this problem. They released code for Gen 12 which will power their Xe dGPUs way ahead of launch. They don't seem to be paranoid about people seeing that code.

              Because they understand that their customers being able to use their hardware is more important than crazy, paranoia about releasing code that's specific to their hardware.
              Yep... However, AMD has got my support, as it's currently only manufacturer of competitive (dedicated) GPU(s), which is open source friendly... Nvidia tries to make it impossible to make open source drivers...

              Comment


              • #27
                Originally posted by kravemir View Post

                Yep... However, AMD has got my support, as it's currently only manufacturer of competitive (dedicated) GPU(s), which is open source friendly... Nvidia tries to make it impossible to make open source drivers...
                True, that's the only reason I bought an R9 390 a fee years ago. But now with Intel planning to sell dGPUs, I can finally say bye bye to AMD.

                Comment


                • #28
                  Originally posted by Space Heater View Post
                  Polaris and Vega support was added more quickly from what I recall, was this a change in policy for Navi?

                  Also, does this mean we should not expect to have day-1 support for new AMD graphics cards going forward?
                  IP review is not legal review. All recent asic support was released prior to product launch. Even if we released the code as soon as we had some that would work on real silicon, it would be mostly useless when parts actually launched because there are constant tweaks and bug fixes all the way up until launch. Intel flags their early asic support with experimental flags so the driver won't load by default on early versions of the driver just like we do. The kernel release cycle is not a good match for fast moving hardware like GPUs. I'm not the only person that thinks so:
                  Unlike the tradition of my past few talks at Linux Plumbers or Kernelconferences, this time around in Lisboa I did not start out with a rant proposingto chan...

                  This is part of why we create packaged drivers (both open source and closed source addons) even though we upstream everything as well.

                  Comment


                  • #29
                    Originally posted by agd5f View Post
                    The kernel release cycle is not a good match for fast moving hardware like GPUs. I'm not the only person that thinks so:
                    Unlike the tradition of my past few talks at Linux Plumbers or Kernelconferences, this time around in Lisboa I did not start out with a rant proposingto chan...

                    This is part of why we create packaged drivers (both open source and closed source addons) even though we upstream everything as well.
                    What about micro-kernels like Redox OS? Is it better suited for shipping GPU drivers? And, what about performance, as micro-kernel needs multiple mode switches?

                    Comment


                    • #30
                      Originally posted by kravemir View Post

                      What about micro-kernels like Redox OS? Is it better suited for shipping GPU drivers? And, what about performance, as micro-kernel needs multiple mode switches?
                      The kernel itself it fine technically. It's the process that is not a good fit. The release cycles are too slow. There is not a good process to get new features into stable kernels. Pretty much all distros define their own stable kernels. Etc.
                      Last edited by agd5f; 24 March 2020, 02:04 PM.

                      Comment

                      Working...
                      X