Announcement

Collapse
No announcement yet.

AMD Sends In Navi Support & Other Remaining AMDGPU Changes For Linux 5.3

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

  • #21
    Originally posted by ThoreauHD View Post
    Navi 10 is GCN with patches to make it less constrained. Navi 2x is RDNA. What we have here is a cheaper GDDR6 card to fill in the gap for a ridiculous price.
    Navi which is already RDNA can execute GCN style instructions but isn't binary compatible with previous GCN instructions. To run optimally it will need changes to switch to wave32 instead of wave64.... but it can run both styles. So software writen with GCN in mind can be executed directly on Navi since the architecture makes that easy for the compiler to handle. But Code written for Navi will perform better. Navi 20 if it is called that will just be a bigger Navi GPU with more bandwidth... most all the changes are already in Navi 10.

    Read the architecture slides you have no excuse for making ignorant statments like that:
    https://gpureport.cz/info/Graphics_A...e_06102019.pdf
    Last edited by cb88; 23 June 2019, 10:44 PM.

    Comment


    • #22
      Originally posted by bridgman View Post

      I probably don't need to say this, but it's not just a matter of "releasing"... we would have to *implement* it first.

      Yes the GUI is supposed to be cross-platform but a big chunk of the work is on the driver side.
      Then I hoped too much.
      I hoped that Linux would not be so much behind Windows when it comes to the power of GPU configuration that it gives to its users.
      Hopefully the decision making guys will decide sooner than later to dedicate also some of the resources to "implement" this.
      I'm getting tired of dual-booting.
      Also, in case in the case of mining, dual-booting is out of the question and Linux is for sure the recommended option.
      I haven't got into this yet, but from what I understand, the one that can configure even the lowest detail the GPU, wins.
      Anyway, thanks for the reply!

      Comment


      • #23
        Originally posted by Danny3 View Post

        Then I hoped too much.
        I hoped that Linux would not be so much behind Windows when it comes to the power of GPU configuration that it gives to its users.
        Hopefully the decision making guys will decide sooner than later to dedicate also some of the resources to "implement" this.
        I'm getting tired of dual-booting.
        Also, in case in the case of mining, dual-booting is out of the question and Linux is for sure the recommended option.
        I haven't got into this yet, but from what I understand, the one that can configure even the lowest detail the GPU, wins.
        Anyway, thanks for the reply!
        Most of the functionality is implemented in Linux. The problem is every desktop environment handles modesetting and configuration persistence differently. The kernel KMS interface is the same across all drm drivers, but each desktop environment implements their own stuff on top of that. One of the big problems we ran into with catalyst was that the tool broke every time the desktop environments changed their configuration interfaces. Also some people like gtk, some people like Qt, etc.

        We currently expose pretty much everything via standard Linux interfaces: KMS for modesetting, hwmon for fans, voltages, power, etc. Really the only thing that is AMD specific is the overclocking interface. There are several GUIs already floating around for overclocking.

        Comment


        • #24
          phoronix Marek Olsak just posted initial NAVI support in MESA.

          Comment


          • #25
            Originally posted by agd5f View Post

            Most of the functionality is implemented in Linux. The problem is every desktop environment handles modesetting and configuration persistence differently. The kernel KMS interface is the same across all drm drivers, but each desktop environment implements their own stuff on top of that. One of the big problems we ran into with catalyst was that the tool broke every time the desktop environments changed their configuration interfaces. Also some people like gtk, some people like Qt, etc.

            We currently expose pretty much everything via standard Linux interfaces: KMS for modesetting, hwmon for fans, voltages, power, etc. Really the only thing that is AMD specific is the overclocking interface. There are several GUIs already floating around for overclocking.
            Then I hope that My favorite desktop environment (KDE Plasma) will have a look also on this and try to reduce the differences or changes to the the configuration interface.
            Being in my opinion the most Windows - like, configurable and recently having some backing from Valve might help.
            Or they can talk with the Gnome guys to use some middle ground if possible.
            I wish they would start collaborating more and reduce the fragmentation so we can have these normal things on Linux too!

            Anyway, thanks for the reply. It was really appreciated!

            Comment

            Working...
            X