Live data from Hacker News

SIMD in the 90s: Programming Intel's Pentium MMX

pikuma.com

21–30 of 74 posts

Re: SIMD in the 90s: Programming Intel's Pentium MMX

#21

> Each MMX register is 64 bits wide. Internally, the MMX registers were aliases of the x87 floating-point registers. Due to the way the first Pentium 3 CPUs (Katmai) were built, they likewise aliased the x87 (and thus, MMX) registers to the XMM SSE registers, but this was hidden from programs. It wasn't until at least the Coppermine revision that they were separate registers again.

It makes it easier to save and restore state when it's basically the same registers used differently.

Re: SIMD in the 90s: Programming Intel's Pentium MMX

#22
post #11

Earlier quoted context omitted.

Take a look at the micro-architecture levels. x86-64-v1 contains all the instructions that the original AMD64 and compatible Intel CPUs supported. v2 is all the SSE levels, v3 is AVX and AVX2, v4 is AVX-512. https://en.wikipedia.org/wiki/X86-64#Microarchitecture_level...

The wiki says: "Additional XMM (SSE) registers: Similarly, the number of 128-bit XMM registers (used for Streaming SIMD instructions) is also increased from 8 to 16... "The original AMD64 architecture adopted Intel's SSE and SSE2 as core instructions." https://en.wikipedia.org/wiki/X86-64 This wansn't v2?

Not sure what your question is. I dont see any contradiction with the parent comment. SSE went to version 4.2 (it gets complicated in the numbering and even naming). Only 1 and 2 were included in the base 64-bit ISA.

Re: SIMD in the 90s: Programming Intel's Pentium MMX

#24
When MMX first came out and there were games that supported it, many reviewers were convinced that it improved 3D performance. As far as I could tell, it wasn't really used for 3D and that the only enhancement was to the audio system. But the placebo effect of "If has MMX thus its better" did stick around for a long while.

An aside, but when SSE came a long that was a real big leap in 3D performance, just as GPU's started to gain some independence. So in about 2010, I tried to fire up Turok 2 just to see how fast it would run on a then modern CPU/GPU setup. It couldn't crack 200fps, however games only a year or two later would fly way past that. Turok 2 came out just before SSE and thus basically ran in purely x86/x87 space, thus the performance gap.

Re: SIMD in the 90s: Programming Intel's Pentium MMX

#25

What’s often overlooked is that adoption of MMX was slooooow. Intel compiler were the only intrinsic data types for years. The big win was DirectX 3 audio drivers that used premade Intel libraries. It took at least five to ten years for SIMD to catch on, but the never stopped Intel from evolving it. Then they lost the GPU wars lol rip larabeee.

MMX had heavy adoption in image and video processing. IDCT, motion prediction/compensation, YUV/RGB conversion, and alpha blending all benefited from it.

Thanks for the reminder. Yes Intel was touting high bit rates in software compared to the matrox millennium hardware 2d accelerator.

Re: SIMD in the 90s: Programming Intel's Pentium MMX

#26

Earlier quoted context omitted.

> Additionally, some CPUs at the time only had a 64-bit data path and had to split SSE2 ops, but because of their 4-1-1 decode template, could only decode one such instruction per cycle. I believe that only the first Pentium 3 core, Katmai, did this. > This caused some confusion with the 64-bit version of Windows since Microsoft tried to say that x87/MMX shouldn't be used in long mode, but after queries from video pr…

> I believe that only the first Pentium 3 core, Katmai, did this. No, all Pentium 3s as well as the Pentium M. Pentium 4 notably didn't suffer from it, but it of course had many, many, MANY other performance issues. > I have some faint memories of hearing somewhere that Long Mode didn't support x87. I wonder if it is related to this early info you mention and it being Microsoft specific. It was VM86 mode that Long Mo…

> which was one of the rumored reasons for removing 16-bit NTVDM support

They already had a 16-bit software emulator for running NTVDM on other archs.

Apparently the real reason was they wanted to drop some software compatibility restrictions, like the small max size of HANDLE tables needed for 16-bit compat.

Re: SIMD in the 90s: Programming Intel's Pentium MMX

#27

Earlier quoted context omitted.

MMX in did not become irrelevant with the GeForce 256. Hardware video decoding was only in its infancy at the time and even the highest end GPUs only supported motion compensation acceleration for decoding only at best. Non-display image processing on the GPU was heavily bottlenecked by very slow read-back speeds from the GPU to the CPU across the AGP bus.

Well, GPUs in a modern understanding didn't came till GF4/GF4MX, when you could get something for less than $50.. at this moment MMX wasn't anywhere because SSE was. At this point you had an overlay display for the DivX/XviD and your average CPU could display the realtime video.

It came from GF3, which had full vertex and pixel shaders.

Also, the GF4MX was just a GeForce256 in a trenchcoat, and didn't have vertex shaders (at least exposed to software, the T&L engine was still a vertex shader like engine, only the code was all written by nvidia and loaded from ROM).

Re: SIMD in the 90s: Programming Intel's Pentium MMX

#28
post #11

Earlier quoted context omitted.

Take a look at the micro-architecture levels. x86-64-v1 contains all the instructions that the original AMD64 and compatible Intel CPUs supported. v2 is all the SSE levels, v3 is AVX and AVX2, v4 is AVX-512. https://en.wikipedia.org/wiki/X86-64#Microarchitecture_level...

The wiki says: "Additional XMM (SSE) registers: Similarly, the number of 128-bit XMM registers (used for Streaming SIMD instructions) is also increased from 8 to 16... "The original AMD64 architecture adopted Intel's SSE and SSE2 as core instructions." https://en.wikipedia.org/wiki/X86-64 This wansn't v2?

x86-64 mandates SSE2 as a minimum requirement because it uses the SSE registers in the ABI for implementing float (which requires SSE) and double (which requires SSE2) arithmetic. (The x87 unit, which is what the 32-bit x86 ABI uses, can only do extended-precision arithmetic, which causes a whole heap of problems). Because it's so thoroughly integrated in the ABI, v1 has to have a min-SSE2 requirement.

Subsequently, there were additional instructions added in SSE3, SSSE3, SSE4.1 and SSE4.2, which are all incorporated into the v2 ISA level (along with a few other instructions). Then all of these instructions were given 256-bit variants in AVX, and AVX2 adds some more vector instructions; these are incorporated into the v3 ISA level. And then along comes AVX-512 and naming just becomes a podge at that point...

Re: SIMD in the 90s: Programming Intel's Pentium MMX

#29
post #2

I would add than SSE1 and SSE2 are now required parts of AMD64 instruction set. All 64-bit PC processors are required to support them both. For that reason, modern compilers are ignoring x87 FPU when building 64-bit binaries. Instead, they compile all float and double arithmetic into SSE1 and SSE2 instructions, respectively.

Extended double has some niche and quite useful for its application properties. You can for instance simulate 128 bit floats more easily with it.

Re: SIMD in the 90s: Programming Intel's Pentium MMX

#30

What’s often overlooked is that adoption of MMX was slooooow. Intel compiler were the only intrinsic data types for years. The big win was DirectX 3 audio drivers that used premade Intel libraries. It took at least five to ten years for SIMD to catch on, but the never stopped Intel from evolving it. Then they lost the GPU wars lol rip larabeee.

And now the legacy of Larrabee, AVX-512, is only properly available on AMD for consumers :D
Post reply on HN