Intel C for Metal Compiler 1.0.20 Released

[phoronix]

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?page=news_item&px=Intel-C-For-Metal-1.0.20

[tildearrow]

Is this Intel's CUDA thing?

[andrei_me]

I thought it was for Apple's Metal 😅

[skeevy420]

I thought it was for Apple's Metal 😅

You and me both 🍎

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

[coder]

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.

[coder]

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.

[duby229]

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

[Jumbotron]

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.

[coder]

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).

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.

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.

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.