Linux Kernel Set To Finally Retire AMD 3DNow!

[damonlynch]

Whoever came up with the name Pop!_OS was probably a K6-2 fan back in the day. Subconscious memories and all that, right?

[torsionbar28]

I'll chime in here as I have several K6 class PC's in active use. To be clear, they are all retro computing rigs running OS and software from 1997-2001 time frame. They've all been upgraded to the "plus" mobile variant of K6 i.e. K6-2+ and K6-3+ which performs well and is competitive with Pentium II. These make for great Win95/98 rigs for playing those late 1990's games where the full stack is 3D Now! enabled. There were actually a good number of games from that era that had 3D Now! support where that resulted in a nice performance boost, up to 20% more fps in some games. Combine with a 3DFX Voodoo card for good times!

As for 3D Now! in the current Linux kernel, seems silly to have kept it in this long, as the list of modern distros with latest kernel that will run on a K6 with 256 MB is few to none.

[ntropy]

Probably a faulty chip or defekt RAM. The dies where exactly the same just different clocks.

Ah good to know, yes that could be it. I was pretty much into low budget gaming back then and seldom got lucky. Most often the rig died on a LAN session, when the overall room temperature was so high. I have no idea how we won that one session once .

[torsionbar28]

MP3 playback on Pentium (1) class CPUs was a delicate job. I remember a P1 "mobile" CPU in an early laptop that could play only mono MP3s at 100% utilisation with the ocasional cack in sound.

This was only true on Winblows OS. I was running a Pentium 133 Mhz in 1997-1998 and happily playing 128k MP3 files on it - under Slackware Linux of course. Yes it was CPU heavy, but could play with no problems. I distinctly remember my friends running Win95/98 on similar hardware experiencing much frustration with the "delicate job" you describe.

[jabl]

This was only true on Winblows OS. I was running a Pentium 133 Mhz in 1997-1998 and happily playing 128k MP3 files on it - under Slackware Linux of course. Yes it was CPU heavy, but could play with no problems. I distinctly remember my friends running Win95/98 on similar hardware experiencing much frustration with the "delicate job" you describe.

I vaguely recall being able to play MP3's on my 486DX2-66 running the mpg123 console application in an xterm. It did however use something like 80% of the CPU, so trying to do anything else beyond simple text editing lead to stuttering.

[stormcrow]

Do you need 3DNow? Does anything use it, really?

Not really. That's why AMD dropped it. I don't get why some people are complaining about it in the forum here. It was almost never used by much of anything. It's not like the kernel is completely dropping supporting AMD Athlon class CPUs. It's an obscure, rarely used feature of those CPUs.

[jabl]

It is, unfortunately, possible only for a single instruction set _extension_ to dominate x86 CPUs (other CPU architectures as well) because of how Linux and Windows are architected. That is: targeting a universal instruction set and JIT-compiling the universal code to the target CPU is extremely unusual in the Linux&Windows worlds and can only be seen in scientific research articles/projects.

Well, in such a hypothetical scenario you'd need somebody interested in maintaining the 3dnow code generation for the JIT compiler. So the end result would probably be the same anyway, with the code being removed due to bitrotting and nobody interesting and/or having suitable HW for maintaining it.

Likely this would have happened even sooner, since compilers tend to be complicated beasts with lots of wide-ranging changes going on all the time. Not like some memcpy routine whose interface has been basically frozen since the 1970'ies.

[mitch074]

For a while, 3DNow! was referenced as "Integer SSE", eventhough it's false - both SSE and 3DNow! could process 64-bit FP values. SSE could do pretty much the same, but also added the ability to process 128-bit values.
So, I do agree with the general assessments : the only people affected by this proposal are the ones running multimedia code on 20 years old processors - AMD added SSE support to the Athlon with the Palomino core AKA "Athlon XP". It came out in 2001.
Most people will agree that if you're running a 20+ old machine, you're probably not running a modern OS on it. Back then , standard RAM capacity was 128 Mb - I was one of the lucky ones running a machine with 320 Mb of RAM. Even Puppy Linux has trouble running on such a system, nevermind a full-fledged Linux kernel.

[mitch074]

No it is not. At this point, and with energy prices skyrocketing, it makes no sense to use such an old and power hungry system for that role. The money you are going to save just on electricity alone can pay for even a new budget system.....

Debatable - these operations are not that CPU intensive, and an undervolted, underclocked Athlon II or Phenom II won't use that much power over a newer system. I have one that I use as a media center : it generates very little heat while under use, as the CPU is only used to manage the network, decompress the audio and stream the video to the graphics card (which is the one actually doing the h.264 decompression). True, it uses up 50-60W/h while doing this - a modern system would probably do the same with half as much, especially while using an IGP, and support more formats.
It would also mean buying a new system : nowadays, that's at the very least $400.
Let's consider the worst use case : a NAS, so it's up 24/7, and due to an oversight, it never idles : that's 40Wh * 24 *365 = 350 kWh extra power usage per year. Now, let's consider the average price of electricity in the US : it's 12.52 cents per kWh, totalling $43.87 a year.
You'd need 8 years to recoup the cost of buying a newer machine in that exact case. Let's say energy prices double, it's still 4 years.
Cleaning your dryer's condensing unit regularly would save you more power than changing your K10-based NAS, nevermind a media center that's switched on 4-5 hours a day.

[bridgman]

My recollection is that 3DNow! was designed for and initially used for vertex processing in geometry pipelines, since most of the early graphics cards only had pixel processing hardware.

It made a big difference with the graphics cards of the time and IIRC also with software 3D renderers, but as graphics cards started to include vertex processing (~12 years after introducing 3DNow!) the use cases for vector instructions changed from 3D to multimedia and general compute.

3DNow! evolved as well but my impression is that the real architectural advantages of 3DNow! were for the 3D use cases.