Intel Meteor Lake "-march=meteorlake" Support Lands In GCC 13

[phoronix]

Phoronix: Intel Meteor Lake "-march=meteorlake" Support Lands In GCC 13

After Intel posted a set of patches last week for the GNU Compiler Collection around Raptor Lake, Meteor Lake, and Sierra Forest, the two more basic patches have already been merged into the GCC 13 code-base while the Sierra Forest Xeon E-core patches and the various new instructions presented there are still undergoing review...

https://www.phoronix.com/news/GCC-13-Lands-Meteor-Lake

[brucethemoose]

Oof, no AVX512 on meteor lake. I missed that earlier post.

With how hard getting AVX2 to be a "baseline" for x86 has been, AVX512 is basically dead on the desktop. There will be plenty of niche specialized codepaths, but no targeting it en masse.

This is gonna hurt AMD too, as some day SVE2 will be "standard" while x86 is still stuck on AVX2.

[birdie]

For context:

diff --git a/gcc/common/config/i386/i386-common.cc b/gcc/common/config/i386/i386-common.cc
index 8d346245ddd1fe88e7e3ce0344a1639d16194d70..d6a68dc9b1df9dd75431a26dbe933b31a216bb74 100644 (file)
--- a/gcc/common/config/i386/i386-common.cc
+++ b/gcc/common/config/i386/i386-common.cc
@@ -1931,6 +1931,8 @@ const pta processor_alias_table[] =
     M_CPU_SUBTYPE (INTEL_COREI7_ALDERLAKE), P_PROC_AVX2},
   {"raptorlake", PROCESSOR_ALDERLAKE, CPU_HASWELL, PTA_ALDERLAKE,
     M_CPU_SUBTYPE (INTEL_COREI7_ALDERLAKE), P_PROC_AVX2},
+  {"meteorlake", PROCESSOR_ALDERLAKE, CPU_HASWELL, PTA_ALDERLAKE,
+    M_CPU_SUBTYPE (INTEL_COREI7_ALDERLAKE), P_PROC_AVX2},
   {"bonnell", PROCESSOR_BONNELL, CPU_ATOM, PTA_BONNELL,
     M_CPU_TYPE (INTEL_BONNELL), P_PROC_SSSE3},
   {"atom", PROCESSOR_BONNELL, CPU_ATOM, PTA_BONNELL,

[coder]

With how hard getting AVX2 to be a "baseline" for x86 has been, AVX512 is basically dead on the desktop. There will be plenty of niche specialized codepaths, but no targeting it en masse.

This is gonna hurt AMD too, as some day SVE2 will be "standard" while x86 is still stuck on AVX2.

Yeah, good point about the competition from ARM.

Sticking with the AMD vs. Intel race, at least AMD has (near) ISA parity on server CPUs, which is probably their main reason for adding AVX-512.

[jayN]

Oof, no AVX512 on meteor lake. I missed that earlier post.

With how hard getting AVX2 to be a "baseline" for x86 has been, AVX512 is basically dead on the desktop. There will be plenty of niche specialized codepaths, but no targeting it en masse.

This is gonna hurt AMD too, as some day SVE2 will be "standard" while x86 is still stuck on AVX2.

The most recent MLID video says Intel will launch a mainstream workstation within the next few months... so I wouldn't call avx512 dead for the desktop, just more choices.

They also have a 2k width bus to the Meteor Lake tGPU, with all its simd and matrix units, so perhaps Intel's plans are to reduce the overhead of using the GPU for math acceleration.

[coder]

The most recent MLID video says Intel will launch a mainstream workstation within the next few months... so I wouldn't call avx512 dead for the desktop, just more choices.

Mainstream laptops and desktop != workstation. Especially, if you look at what has happened with pricing of workstation motherboards and CPUs, over the past decade.

I've effectively been priced out of the workstation market, although the mainstream desktop platform now offers enough to meet my needs. I don't really mind not having a proper workstation, by this point, since PCIe lane-counts have risen from their low ebb in the LGA 1150 and 1151 platforms (basically from Haswell to Coffee Lake-R), and I can get enough cores in a mainstream socket.

Platform-wise, I'm currently more interested in having a hybrid CPU than AVX-512. So, that's another reason I'm eying Raptor Lake. If I had a near-term need of AVX-512, for the sake of mere ISA capability (i.e. as a software development vehicle), I'd try to find a good deal on a Tiger Lake NUC or SFF mini-PC.

I'll admit that I did splurge on a 400GB P5800X, but there's no way I'd have done it if they hadn't been discontinued. It's kind of like the same reason I bought a Radeon VII, after having decided $400 was probably the most I'd ever spend on a dGPU - because you simply can't get that kind of fp64 horsepower in a desktop card, any more (luckily, I turned around and sold it last year, for enough profit to pay for the P5800X - I was depressed about the ROCm situation... all the fp64 horsepower in the world is useless if it lacks good software support).

They also have a 2k width bus to the Meteor Lake tGPU,

I take it you meant to say they doubled the datapath to the tGPU? That's good news.

[brucethemoose]

The most recent MLID video says Intel will launch a mainstream workstation within the next few months... so I wouldn't call avx512 dead for the desktop, just more choices.

They also have a 2k width bus to the Meteor Lake tGPU, with all its simd and matrix units, so perhaps Intel's plans are to reduce the overhead of using the GPU for math acceleration.

Sure, you can get the hardware for it, but it will never be "standard" in common software because 3+ gens of Intel consumer hardware are skipping it. Meteor Lake will be circulate around the hardware pool for the next decade or more, just like Sandy Bridge and Ivy Bridge (which are only AVX1 capable) did.


GPU acceleration is a whole different animal, and not really a substitute for CPU vector instructions.

[coder]

Sure, you can get the hardware for it, but it will never be "standard" in common software because 3+ gens of Intel consumer hardware are skipping it. Meteor Lake will be circulate around the hardware pool for the next decade or more, just like Sandy Bridge and Ivy Bridge (which are only AVX1 capable) did.

Well, thank goodness we now have HWCAPS !!

GPU acceleration is a whole different animal, and not really a substitute for CPU vector instructions.

Yes and no. If you have a vector-heavy workload, then it's often a good fit for GPU acceleration and worth the overhead of shipping the data over to it, especially if you can do so without the data ever leaving L3 or L4 cache. However, if you have a vector-light workload, then the benefit of AVX-512 vs. AVX2 is going to be relatively small, making the lack of AVX-512 less of an issue.

So, I actually think there's a decent case for trying to lean more heavily on GPU-compute. I think there are a few key reasons why this isn't already the reality:

• GPU compute is far from ubiquitous. The driver & userspace situation is probably somewhat like where OpenGL acceleration was, 15 years ago. Especially when you take virtualization into account.
• We haven't had cache-coherent, shared virtual memory for all that long, nor is it ubiquitous.

I think it's both ironic and unfortunate that AMD took their foot off the gas pedal on the whole "heterogeneous compute" idea, just before they started producing APUs that you'd really want to buy.