Announcement

Collapse
No announcement yet.

AMD To Open-Source Its Linux Execution & Compilation Stack

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

  • AMD To Open-Source Its Linux Execution & Compilation Stack

    Phoronix: AMD To Open-Source Its Linux Execution & Compilation Stack

    In the discussion last night about AMD not having any plans to suspend their proprietary Linux driver, John Bridgman of AMD shared some interesting information about AMD planning to provide a full execution stack in open-source form...

    http://www.phoronix.com/vr.php?view=MTEyMzQ

  • #2
    HSA

    I don't really understand what this HSA is, and what its good for, and what it does, and why I should care.

    Comment


    • #3
      Thanks Michael for reacting so quickly!
      So it really seems not many people in the open source scene have recognized this?
      Originally posted by uid313 View Post
      I don't really understand what this HSA is, and what its good for, and what it does, and why I should care.
      It's abou fully integrating the computing capabilities of the GPU into the CPU, including preemption, cache coherency etc. Plus standardization, so it can be handled by different CPU (even GPU?) manufacturers and designers through a common API and toolset. Even if they use different (CPU) instruction sets like ARM vs. AMD. Binary code will still be different on different platforms of course. At least that's how I, as a non-programmer, understand it.

      Comment


      • #4
        "the C++ parser front end"

        That sounds like the most important part....

        Comment


        • #5
          Why C++ parser front-end will be proprietary? Couldn't they have used `clang`?

          Comment


          • #6
            Does this mean that the flgrx is in the future half open source? And only need an Closed Source Userspace?

            Comment


            • #7
              Originally posted by Nille View Post
              Does this mean that the flgrx is in the future half open source? And only need an Closed Source Userspace?
              As far as the graphics driver is involved, my guess is more like it will be based on radeon (drm part) and Gallium. Or something new. But surely not fglrx. This also means that APUs including their graphics part will have to be supported in open source drivers from the day of release. Otherwise the server APUs that have already been announced for 2013 won't make sense. Still, that's not so hard because the APUs' gfx are one year behind discrete gfx cards and still will be in 2013. Different question here is HSA support for discrete cards of course.

              Comment


              • #8
                Originally posted by Drago View Post
                Why C++ parser front-end will be proprietary? Couldn't they have used `clang`?
                They probably used what is considered in the industry as the best C++ front-end: Edison Design Group C++. It's used by almost all larger companies that produce their own compilers (TI, Intel to name a few).

                Comment


                • #9
                  HSA

                  Looking at slide 29 of the HSA presentation, it looks like the Khronos APIs ( OpenGL, EGL, OpenVG, OpenGL ES, OpenCL etc.) will be implemented in terms of HSA. If that's true, I would take that to mean that a programmer might also be able to program directly with the HSA "language" as well... Or will it be a nice protocol similar to OpenGL et al. The mind runs wild.

                  As a person who enjoys programming more with memory-managed languages ( Common Lisp!), slide 26 is also very intriguing. I hope some other-than-Java languages can get some HSA love too. Especially, I hope that other languages aren't forced to try to make bindings for a C++ lib.

                  Looking forward to it.

                  Comment


                  • #10
                    This is great news! I can't wait to see what comes of this. I was just telling my brother that "fixed-function" hardware is slowly loosing ground to programmable architectures like OpenCL even in the gaming world (with modern AAA game engines using voxel based lighting for real-time radiosity, etc), and that eventually we'll need a more common Open Source API to interface with than what OpenGL/DirectX HLSL/GLSL pipes provide. It looks like AMD has been thinking along this same line, and I'm excited to see what the future holds for AMD and Linux.

                    I was a bit disappointed with the latest AMD news about dropping Catalyst driver support for my 4870 before 12.4 worked with XOrg 1.12 (and beyond), I was planning on switching over to nVidia with my next computer, but I think AMD's just won back my support for a good long while ;-D

                    Comment


                    • #11
                      Looking at slide 29 of the HSA presentation, it looks like the Khronos APIs ( OpenGL, EGL, OpenVG, OpenGL ES, OpenCL etc.) will be implemented in terms of HSA. If that's true, I would take that to mean that a programmer might also be able to program directly with the HSA "language" as well... Or will it be a nice protocol similar to OpenGL et al. The mind runs wild.
                      Well the thing to keep in mind is that all 'code' is, well 'code'.

                      C code, python code, machine code... all these things are software code that can be programmed and modified.

                      With x86 you have what is called the ISA.

                      ISA can be seen the API for your CPU. You may have heard of the CISC versus RISC processors and which is better or whatever. While x86 is a CISC instruction set, but all modern processors are in fact RISC processors. Even your x86-64 CPUs are all RISC processor cores.

                      How it works is that Intel and AMD have a hardware-based abstraction layer that takes the CISC instructions and transforms them into RISC code that is what is actually executed. The so-called 'x86-tax' in the ARM versus x86 wars refers to the complex set of transistors that perform this function. This is just about the only reason the Atom processor hasn't displaced ARM on phones yet.

                      Well this ISA is very important. This why code compiled for ancient 486 processors can be made to still work today.

                      But we have a problem......

                      Modern processors, due to Moore's Law, is ever increasing in complexity. Every 18 months or so they can double in complexity while not increasing in price.

                      Unfortunately there is a limit on useful it is to increase the complexity of a single processor core to make it faster. We saw this with the Pentium-4 netburst architecture. It tried to use long pipelines to go faster, but it ended up being beaten by AMD who took a different approach.

                      So now instead of making the processor more complex we just add more processor cores. 2 cores. 4 cores. 8 cores. 16 cores. That means we can do more and more work on a single machine.

                      But we still have a problem....

                      There is a limit on how useful this approach is. On servers people have taken advantage of this through virtualization and such things, but on desktops and laptops a 32 core system isn't really going to be much faster then a 4 or 6 core system running the same type of cores at the same clock speeds. There just isn't a whole lot going on except for the main thing that the person is paying attention too. And threaded programming isn't the panacea that most people seem to think it is.


                      What is the solution to making things go faster/more efficient then?

                      Well you use different types of cores for different things. Different processors are better at different things. So if you have multiple processors of different types then you can go faster and save more battery.

                      This is why closed source drivers and non-disclosing GPU designs are such shit when it comes to general computing. The GPU is ceasing to be a separate entity. It's not something you just add on to make games go faster or to make video smooth.

                      The GPU is one of those 'different cores' that you can integrate into your processor to make everything go faster.

                      But to be used on the GPU the software needs to be able to use it.

                      I think that this is what a big part of AMD's HSA is about.

                      Comment


                      • #12
                        Too much marketingspeak

                        Now if they could explain what they plan in a way that a simple computer scientist like myself understands what they're going to do...

                        Comment


                        • #13
                          Originally posted by rrohbeck View Post
                          Now if they could explain what they plan in a way that a simple computer scientist like myself understands what they're going to do...
                          You use their lib (sorts etc other basic operations), and they then run on the cpu or gpu if available.

                          Comment


                          • #14
                            strip away all the ingrained bullshit PR and its fun to finally see the "Co-Processor" make a comeback into the popular market place mindset , and make no mistake about it that's exactly what they mean by Heterogeneous System Architecture (HSA) and how you might collect up all the separate API's re badge it and call it something new.

                            personally iv always preferred May's Law that states "Software efficiency halves every 18 months, compensating Moore's Law"

                            http://en.wikipedia.org/wiki/David_M...ter_scientist) the original inventor and lead architect of the so called Heterogeneous System Architecture with his http://en.wikipedia.org/wiki/Transputer chips and now founder and Chief Technology Officer of XMOS Semiconductor.

                            Last edited by popper; 06-20-2012, 02:26 PM.

                            Comment


                            • #15
                              You are probably right. In the end, what AMD want is to remove FPU part from the CPU, and use the highly parallel GPU part for that. This means they will have to have GPU<->CPU shared memory pointers, context switch awareness, and all that fancy stuff mentioned in the slides.

                              Originally posted by popper View Post
                              strip away all the ingrained bullshit PR and its fun to finally see the "Co-Processor" make a comeback into the popular market place mindset , and make no mistake about it that's exactly what they mean by Heterogeneous System Architecture (HSA) and how you might collect up all the separate API's re badge it and call it something new.

                              personally iv always preferred May's Law that states "Software efficiency halves every 18 months, compensating Moore's Law"

                              http://en.wikipedia.org/wiki/David_M...ter_scientist) the original inventor and lead architect of the so the called Heterogeneous System Architecture with his http://en.wikipedia.org/wiki/Transputer chips and now founder and Chief Technology Officer of XMOS Semiconductor.

                              Comment

                              Working...
                              X