Announcement

Collapse
No announcement yet.

AMD Posts Open-Source Driver Patches For Vega 12

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

  • #11
    Originally posted by Drago View Post
    What a Vega MESS. Couldn't AMD come up with something less confusing, kinda Ryzen-Zen.
    What mess? vega12 and Vega 10 etc are not the product names. It's the codename for the architecture, of which there will be multiple products. The public doesn't have to worry about architecture code names. When the actual SKUs come out they will have proper names.

    the current products are Vega56 and Vega64. Named after the number of compute units. Not confusing at all. Perfectly logical. Bigger number is more powerful.

    So this new one may be called something like Vega32 which puts it underneath the current lineup.
    Last edited by humbug; 21 March 2018, 12:20 PM.

    Comment


    • #12
      Originally posted by Drago View Post
      What a Vega MESS. Couldn't AMD come up with something less confusing, kinda Ryzen-Zen.
      The challenge is that if we are going to make open source drivers work as well as possible then we need to be up-streaming code long before launch; that's why we use code names rather than the marketing names.

      Of course if things are still confusing AFTER launch that's a different problem

      Originally posted by Drago View Post
      In any case 60 000 lines of code for just one variant for just one chip. I wonder when Linux developers will say enough is enough. I guess in the future there will be different git repos for each kernel sub tree, and make install will download selectively depending on the kernel compile configuration.
      It's 60,000 lines of register header information, not 60,000 lines of code. Michael made this clear in the article:

      The actual new code additions to AMDGPU DRM is relatively small and is mostly re-using existing Vega 10 and Raven Ridge code paths.
      Register headers do not generate code, and do not increase kernel/driver size.
      Last edited by bridgman; 21 March 2018, 12:47 PM.
      Test signature

      Comment


      • #13
        Originally posted by bridgman View Post
        ....
        Oi, Bridgman!

        Any news on ROCm support for RavenRidge?

        Keep up the great work!!

        Comment


        • #14
          Originally posted by bridgman View Post

          The challenge is that if we are going to make open source drivers work as well as possible then we need to be up-streaming code long before launch; that's why we use code names rather than the marketing names.

          Of course if things are still confusing AFTER launch that's a different problem
          I think the Vega has had the best naming ever.
          Vega tells the architecture and the number is the number of the compute units so one can estimate how powerful the chip is.
          Like Vega 12 puts it between RX550 and RX560 so i guess i will see this in an laptop, integrated to a motherboard or in an APU.

          Comment


          • #15
            Originally posted by bridgman View Post

            It's 60,000 lines of register header information, not 60,000 lines of code. Michael made this clear in the article:



            Register headers do not generate code, and do not increase kernel/driver size.
            I wonder though; can't those generated headers be generated at kernel make/compile time? Seems kinda stupid to put generated code in the tree, esp. when it's that large.

            otoh: I love overengineering build systems, so it might just be an itch I'm having.

            Comment


            • #16
              Originally posted by rubdos View Post
              I wonder though; can't those generated headers be generated at kernel make/compile time? Seems kinda stupid to put generated code in the tree, esp. when it's that large.
              We could limit the registers defines to just those that are used in the driver, but if we expose all of them, it makes it much easier to add features or for people outside AMD to debug or work on the driver since the defines are all there ready to go.

              Comment


              • #17
                Originally posted by rubdos View Post
                I wonder though; can't those generated headers be generated at kernel make/compile time? Seems kinda stupid to put generated code in the tree, esp. when it's that large.
                The headers are generated from our internal HW design database - a normal build system is not going to have access to that information.
                Test signature

                Comment


                • #18
                  Originally posted by FirstPersonBSOD View Post

                  It's probably for the successor to Polaris 10/RX580.
                  This is what I hope, been meaning to get one since a year now, but I won't submit to the cryptocurrency bubble and pay 400€ for one.

                  Comment


                  • #19
                    Eureka! What is the next AMD chip to be launched? It was already demoed BUT not by AMD and will need Linux support?
                    And COINCIDENTALLY has exactly 5 SKUs? And the realease date is supposed to be late March?

                    Yes, Vega chip inside the Intel Kaby Lake G. It will probably also be release separately by AMD as Vega Mobile but later.
                    My bet the AMD chip inside Kaby Lake G is Vega 12 and it will have 24 CU.





                    Comment


                    • #20
                      Originally posted by hoohoo View Post
                      Any news on ROCm support for RavenRidge?
                      Making pretty good progress testing & bug fixing, not sure about release plans yet though.
                      Test signature

                      Comment

                      Working...
                      X