Announcement

Collapse
No announcement yet.

Intel C for Metal Compiler 1.0.20 Released

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

  • Intel C for Metal Compiler 1.0.20 Released

    Phoronix: Intel C for Metal Compiler 1.0.20 Released

    Within Intel's vast open-source software ecosystem and much of the attention being on oneAPI as their preferred programming model for developers these days and there being multiple different open-source Intel graphics compiler back-ends, one that is often forgotten about is the Intel C for Metal Compiler that on Friday saw a new release...

    http://www.phoronix.com/scan.php?pag...r-Metal-1.0.20

  • #2
    Is this Intel's CUDA thing?

    Comment


    • #3
      I thought it was for Apple's Metal 😅

      Comment


      • #4
        Originally posted by andrei_me View Post
        I thought it was for Apple's Metal 😅
        You and me both 🍎

        Is Intel using C Standard or Drop C for their 🤘?

        Comment


        • #5
          From the 01.org link:

          C for Metal programming model is explicit SIMD which differs from other GPU programming languages such as CUDA or OpenCL that only allows defining a kernel that would operate on a single unit of the data space.

          Ah, now it all makes sense. Intel's GPUs are somewhat unique in their incorporation of a contingent of SSE-like horizontal vector operations, in addition to supporting a pure-SIMD programming model. The term SIMD has been thrown around so much, in reference to vector-processing, that it's easy to forget that most vector extensions for CPUs are not pure-SIMD. In contrast, AMD and Nvidia's GPUs are virtually pure SIMD - last time I looked, AMD had no cross-lane operations, and I think Nvidia only supported explicit lane swapping (but not things like dot-products). I think OpenCL only somewhat recently added support for horizontal operations, though I'm not familiar with the capabilities and limitations of that extension.

          So, I totally understand how one would want this for programming a GPU much more like a CPU with vector extensions. Especially if you're Intel and had large amount of SSE-optimized multimedia code you wanted to just port over to your GPUs.

          Comment


          • #6
            Originally posted by andrei_me View Post
            I thought it was for Apple's Metal 😅
            I also made that assumption, based on the headline. I think it pre-dated Apple's Metal by several years, at least.

            I wonder if it started out life as a "bare metal" compiler/API, and the "bare" part was simply dropped. That would be consistent with their stated goals.

            Comment


            • #7
              Originally posted by coder View Post
              I also made that assumption, based on the headline. I think it pre-dated Apple's Metal by several years, at least.

              I wonder if it started out life as a "bare metal" compiler/API, and the "bare" part was simply dropped. That would be consistent with their stated goals.
              When ATi released the R580 Radeon X1900 (r300g) it was capable of running CTM, Close to Metal, kinda like a instruction set level programming language for that hardware. Then AMD bought ATi and CTM was cancelled and replaced by AMD Stream... From there the whole saga of OpenCL failures at AMD began.

              Anyway, I think this is the precedence for using the term "metal" as it relates to low level GPU programming.

              https://en.wikipedia.org/wiki/Close_to_Metal
              https://en.wikipedia.org/wiki/AMD_Fi...evelopment_Kit
              Last edited by duby229; 22 November 2020, 12:29 AM.

              Comment


              • #8
                Originally posted by coder View Post
                From the 01.org link:


                Ah, now it all makes sense. Intel's GPUs are somewhat unique in their incorporation of a contingent of SSE-like horizontal vector operations, in addition to supporting a pure-SIMD programming model. The term SIMD has been thrown around so much, in reference to vector-processing, that it's easy to forget that most vector extensions for CPUs are not pure-SIMD. In contrast, AMD and Nvidia's GPUs are virtually pure SIMD - last time I looked, AMD had no cross-lane operations, and I think Nvidia only supported explicit lane swapping (but not things like dot-products). I think OpenCL only somewhat recently added support for horizontal operations, though I'm not familiar with the capabilities and limitations of that extension.

                So, I totally understand how one would want this for programming a GPU much more like a CPU with vector extensions. Especially if you're Intel and had large amount of SSE-optimized multimedia code you wanted to just port over to your GPUs.
                That's actually very interesting ! I wonder if there was some "cross pollination" in thinking about "SSE-like vector operations" vis a vis Intel GPUs since at one time with the Larrabee / Knights Landing, Xeon Phi Intel was desperately trying to convince the market that had already gone Full Tilt Boogie GPU for advance vector compute that no...really...you can do all the GPGPU magic on good ol Intel CPU's. Just nearly a 100 small Intel Atom CPUs with SSE vector extensions all working together as one big happy compute family. And the same ol Intel C Compiler you were already familiar with.

                Although that wasn't really true. It was dog shit hard to optimized actually and even then the perf was a bit lacking. But it seems from what you said, that Intel truly has SSE and AVX forever on their mind and is now taking that philosophy all the way over to their GPU's.

                Intel....always the CPU company. Even when they are now making GPUs.

                Comment


                • #9
                  Originally posted by Jumbotron View Post
                  That's actually very interesting ! I wonder if there was some "cross pollination" in thinking about "SSE-like vector operations" vis a vis Intel GPUs since at one time with the Larrabee / Knights Landing,
                  I spent a little time trying to figure out just how far back this aspect of the Intel GPU ISA goes, and found some references to a 128-bit FPU pipeline, as far back as the later GMA (chipset) graphics. So, perhaps around or slightly before the time of Larrabee (late 2000's), but well before Xeon Phi (2013).

                  Originally posted by Jumbotron View Post
                  Xeon Phi Intel was desperately trying to convince the market that had already gone Full Tilt Boogie GPU for advance vector compute that no...really...you can do all the GPGPU magic on good ol Intel CPU's. Just nearly a 100 small Intel Atom CPUs with SSE vector extensions all working together as one big happy compute family.
                  The first gen Xeon Phi was actually based on Pentium cores from the mid-1990's, with hyperthreading and custom 512-bit vector extensions bolted on. It wasn't until the second gen that they switched to Atom-derived cores with proper AVX-512 extensions. Just FYI.

                  Originally posted by Jumbotron View Post
                  it seems from what you said, that Intel truly has SSE and AVX forever on their mind and is now taking that philosophy all the way over to their GPU's.
                  In their defense, I think it was an entirely reasonable thing to do, in the mid-2000s. It's just that when you start looking at how to scale up further, the horizontal operations have to go away and you really want pure SIMD.

                  AMD recently took another big step by adding matrix primitives. Of course, Nvidia's Tensor cores get a nod, but those (and Intel's 1st gen AMX) are really tailored to deep learning, whereas AMD just went the whole way and added matrix support for all precisions.

                  Originally posted by Jumbotron View Post
                  Intel....always the CPU company. Even when they are now making GPUs.
                  True, but they've made lots of acquisitions in the past 5 years that would seem to recognize a need to move beyond the CPU-centric era. The PR around oneAPI seems to embrace this, talking about a seamless path from CPUs to GPUs, FPGAs, and even structured ASICs and purpose-built AI accelerators. I know firsthand that Intel is putting significant resources behind this effort, so I believe it's not merely PR spin.

                  Comment

                  Working...
                  X