Announcement

Collapse
No announcement yet.

More Details On The AMD GCN Back-End For GCC That's Expected To Merge For GCC 9

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

  • More Details On The AMD GCN Back-End For GCC That's Expected To Merge For GCC 9

    Phoronix: More Details On The AMD GCN Back-End For GCC That's Expected To Merge For GCC 9

    Last week I reported on Code Sourcery / Mentor Graphics posting their new AMD GCN port to the GNU Compiler Collection (GCC). This GPU back-end for the widely-used GCC compiler is hoped for merging ahead of the GCC 9 stable release expected in early 2019. At this past weekend's GNU Tools Cauldron 2018 conference was a briefing by Mentor Graphics on undertaking funded by AMD...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Originally posted by phoronix View Post
    How To Use The GCN Toolchain
    ...
    3) Install the ROCm drivers, and HSA runtime libraries.
    Isn't HSA runtime is obsolete and only ROCm should be required?

    Brigman, is there plans to make ROCm packaged and distributed via upstream Fedora (so it will get to RHEL and CentOS) and Debian (so it will get to Ubuntu, Mint and others) repositories? This is not requirement since packages is available for installation from AMD repository, but this would make life a little bit easier.

    I still hope for more broad usage of GPU computing in user-facing applications.

    Comment


    • #3
      Can this be used as a backend for RadeonSI/RADV/AMDVLK?

      Comment


      • #4
        Originally posted by M@yeulC View Post
        Can this be used as a backend for RadeonSI/RADV/AMDVLK?
        Certainly not at this stage given the state of the backend, but even if the Mesa code was adapted to the GCC interfaces, would probably be a lot more painful especially given just one major GCC release per year, among other possible issues.
        Michael Larabel
        https://www.michaellarabel.com/

        Comment


        • #5
          Originally posted by M@yeulC View Post
          Can this be used as a backend for RadeonSI/RADV/AMDVLK?
          i'll go out on a limb here and say no, since nothing seems to indicate there is graphical support in that backend. This seems 100% OpenMP/ACC/Sylk offload related for compute code.

          In theory some wizard could implement the missing bits on gcc JIT library and then integrate it to Mesa but i don't see that happening for a long long while and unless that wizard dude can prove GCC is like 50% faster than LLVM i don't honestly see Mesa developers accepting happily such port and having to maintain 2 compiler engines outside having to rewrite(or at least abstract a lot of it) the NIR and TGSI translation layers

          Comment


          • #6
            Thanks both!
            I really need to read more on this, as I didn't see the "graphical support" as being something that substantial. As for plugging in NIR/TGSI, I would have thought a LLVM IR to GIMPLE would already exist

            Comment


            • #7
              Originally posted by M@yeulC View Post
              Thanks both!
              I really need to read more on this, as I didn't see the "graphical support" as being something that substantial. As for plugging in NIR/TGSI, I would have thought a LLVM IR to GIMPLE would already exist
              Well graphical support is very substantial since most of the heavy memory allocation scheme prolly happen from OpenGL side due to its very high level approach compared to compute where you have more room(as time) to resolve allocations on the compiler side since latency on compute code is less vital than with graphics code.

              Not that i know of and I'm not sure LLVM IR -> Gimple would be so easy to "plug up" since is very likely LLVM IR have expanded support for GPU specifics where Gimple has always been 100% focused on CPU operations and is very unlikely this could be done without some dark magic and extra latency plus the main problem would be not so much to "plug" but the fact NIR and TGSI call LLVM directly quite often and this could require them to abstract a bunch of code in a layer that will choose with IR/compiler to use at runtime.

              But the main problem would be this would make absolutely no sense practically unless GCC proves to be measurably overall hands down way faster than LLVM in a way that cannot be fundamentally replicated with LLVM due to some massive design defect because otherwise would be a looooot simpler to simply fix LLVM than hookup GCC

              Comment


              • #8
                Originally posted by RussianNeuroMancer View Post
                Isn't HSA runtime is obsolete and only ROCm should be required?
                We renamed it to ROC runtime for consistency, but it's pretty much the same code and even the readme still calls it HSA Runtime:

                ROCm Platform Runtime: ROCr a HPC market enhanced HSA based runtime - GitHub - ROCm/ROCR-Runtime at roc-1.8.x


                Originally posted by RussianNeuroMancer View Post
                Brigman, is there plans to make ROCm packaged and distributed via upstream Fedora (so it will get to RHEL and CentOS) and Debian (so it will get to Ubuntu, Mint and others) repositories? This is not requirement since packages is available for installation from AMD repository, but this would make life a little bit easier.
                The hard work has been getting dGPU support for KFD upstream and then re-aligning the userspace components around the upstream user/kernel interface. That work has pretty much been done, so now it becomes possible to start working with distros to have them include more of the userspace packages.

                The open question is where to draw the line between what gets built into the distro and what remains as optional packages... my guess is that the line will end up being somewhere around top of ROCR or top of thunk/ROCT/libhsakmt, with everything above that being part of an optional package or package set.
                Test signature

                Comment


                • #9
                  There is no Mentor Graphics anymore, it's Siemens...

                  Comment


                  • #10
                    This seems like a big investment in an ISA that should soon be superseded. Of course, GNC-flavored GPUs will be kicking around for a long time, so... no complaints, here.

                    Comment

                    Working...
                    X