AMD Open Sources the AMD Performance Library

bluephone writes "Today AMD announced that they're now opening the source to the AMD Performance Library (APL) under the Apache license. The newly opened code is now hosted at SourceForge (the corporate overlord of Slashdot) under its new name, Framewave. Phoronix says, "The AMD Performance Library / Framewave covers a multitude of operations from simple math operations to media processing and optimizations for multi-core environments." No word as to if it does your laundry. The SourceForge page says that while Framewave is 'sponsored' by AMD, it is "very much an open-source venture. While AMD will continue to participate in and contribute to the project, third-party developers are welcome and encouraged to implement all or part of the code base and/or to create derivative works." Being Apache licensed, it's quite open, so this doesn't seem to be mere lip service."

But wait, what's this tidbit about graphics docs?

[schwaang (667808)]

From the Phoronix article:

In other news, AMD's Graphics Product Group (GPG) will be having their next open-source document dump this week.

I don't know squat about the performance lib, but the graphics stuff, now *that* could be interesting if it helps the open-source graphics driver effort.

Re:

[Ed Avis (5917)]

It's good to see that they have overcome their open source constipation.

Re:

[beefsprocket (1152865)]

Read Bill Weinberg's post on Linux.com [linux.com] about why we shouldn't use open source as a verb. It is a fantastically well written piece and I recommend it to anyone with a passing interest in FOSS, and or anyone who has a basic grasp of the English language. OPEN SOURCE IS NOT A VERB thanyouverymuch.

Re:

[Ed Avis (5917)]

Thanks, but neither my post nor the grandparent used 'open source' as a verb.

Re:

[Haeleth (414428)]

You seem to be misreading him; he isn't arguing that "open source" should not be used as a verb, but that it shouldn't be used as a verb meaning "to make software available under an open source license". His argument is that something is not "real" open source software unless it has a thriving community around it, and therefore people should not say things like "we open sourced this code" when they have merely released the code, rather than creating a community.

It's a nice thought, but he's basically compl

My submission:

[wild_berry (448019)]

This is old news. My submission "APL under APL" was rejected...

Re:

[3.14159265 (644043)]

I actually like to have variables names that tell me something about the kind of stuff they represent.
Nothing wrong with having a class called... ColorMatchingPattern, and a variable called aColorMatchingPattern.
The compiler doesn't complain, for it it's pretty much the same as having a class called CMP and a variable called c.
I find it more readable for someone trying to get familiar with the code.
On the other hand, macros can suck.

Will it be shipped with Linux distributions?

[julie-h (530222)]

I hope Fedora, Ubuntu, Suse, and Gentoo will come with this library!

Re:

[pdusen (1146399)]

As far as I'm concerned, Open Source projects and Linux stand to do nothing but benefit enormously from these specs being opened. It's truly mind-boggling how negative the reaction on a place like Slashdot can get about AMD/ATI.

Re:

[hr.wien (986516)]

We already have liboil which does more or less the same thing, so it's not like this is a revolutionary development.

APL vs IPL

[ceroklis (1083863)]

Anyone knows how it compares with the Intel Performance libraries ? and especially how good IPL is on an AMD processor and vice versa ?

...strangely familiar

[Tenebrarum (887979)]

AMD Open Sources the AMD Performance Library ...and it looks strangely familiar [mplayerhq.hu]. Funnily enough, the licence doesn't.

Re:Is this that silly..

[tomhudson (43916)]

No. If you look, you'll see that H.264 video decoding is one of the included features of the libraries. I expect to see encoding added in the future.

Re:

[perlchild (582235)]

I just don't see this becoming a success, simply because they tried it as "amd branded" and it didn't work, rebranding it and saying it's not open source doesn't mean it's now magical and delicious. In fact, I suspect they have a hard road ahead.

Open-sourcing something that worked, will work even more(now that they don't own it so much). Disowning something they had, that had a lukewarm reception... might just convince everyone that it wasn't worth much...

Re:

[99BottlesOfBeerInMyF (813746)]

I just don't see this becoming a success, simply because they tried it as "amd branded" and it didn't work, rebranding it and saying it's not open source doesn't mean it's now magical and delicious. In fact, I suspect they have a hard road ahead.

I'm not sure what you're saying here. Previous to this announcement the libraries were provided as pre-compiled binaries for a subset of OS versions, right? Now they're actually letting people see and make derivatives of the code. If nothing else this might get people in the OSS community to fix compatibility and performance bugs if they're creating a product that uses one of the video codecs, for example. This is not the greatest thing since sliced bread, but neither is it just AMD saying something; they

Re:Is this that silly..

[Protonk (599901)]

Maybe. You are right in suggesting that visibly changing something from costly to free has negative signaling impacts. Some among us might get the impression that this is the 'lighter' version of some more powerful performance library out there, but I don't see it happening.

What I suspect will happen is that small firms using AMD processors for specific applications will have a tool to write better, lower level code. Larger software makers might not bite because this is another tailored portion o the codebase that would need to be checked but it is certainly possible (as has been mentioned here) that encoding/decoding of video could be made easier, at least for AMD.

I don't think it is magically a win-win. I think that it is likely to be a good thing for some, indifferent to others and an exceedingly small impact on the cache of AMD. All in all, we are better off.

Re:

[Protonk (599901)]

That's good to know. Even with that being the case, the release of these libraries is a marginally positive thing.

Re:

[Wesley Felter (138342)]

I disagree. These performance functions really should be integrated into system libraries like zlib, libjpeg and GStreamer, but the developers of those libraries wouldn't touch APL when it was proprietary. Now that it's open, at least open source developers will be willing to look at it. It won't guarantee success, but now it has a chance.

Re:

[Goaway (82658)]

zlib and libjpeg use much more permissive licenses than the Apache License, and thus are still excluded from using this code.

Re:

[TheRaven64 (641858)]

It's also incompatible with version 2 of the GPL, meaning it can't be used with any GPLv2 code that doesn't have the 'or later' clause. Neither the BSD or Apache licenses are viral, however, so you can call APL from something BSD licensed without affecting the BSDL code in any way. Things like zlib could use it for optional code paths.

Re:

[Goaway (82658)]

I'd imagine that libraries as widely deployed as zlib and libjpeg would be quite vary of using multiple licenses for different code paths, though.

Re:

[TheRaven64 (641858)]

Not really. The Apache license is not viral. The code that calls it can have whatever license it wants. It is quite easy to write code that calls different functions depending on how it is compiled / linked. The calling code would keep whatever license it wanted. If you install it on a platform where the user has already installed APL, then you get the fast version. If you are distributing it and want the fast code paths, you also have to distribute APL, but that's not a problem for most people since

Re:

[killmofasta (460565)]

AMD processor drivers are integral to both the support and performance of AMD processors. At least AMD does not hide their micro-instruction patches, like Intel Does.

"intel firmware patches the P4 micro instruction rom!" And VIA Centar C7 does also.

Would you rather they withhold the bugs? Or have you pay theough the nose to replace the chips?

On Intel boxes, I am not to carefull about the CPU drivers, but I had a Athlon w/ AGP, and the speed of video doubled after I installed something called 'AGP Miniport

Re:

[Brian Gordon (987471)]

That's ridiculous- Intel has a well-documented instruction set IA-32 that compilers compile to. They have instruction set extensions like MMX and SSE, but they're part of the instruction set. What would a CPU driver even do? How are you going to install it without using the processor? How does it even make sense to communicate with the driver without using the driver itself? Or can you even imagine how slow it would be to check a ROM for instruction updates every time you want to jmp or ld? How the heck wou

Re:Is this that silly..

[644bd346996 (1012333)]

Look up what microcode is. Microcode updates typically need to be reapplied every time the cpu is reset, ie. every time you boot your system. On windows, it is obviously easiest to apply these updates using a driver that gets loaded on boot.

These microcode updates are used to fix bugs in the original hard-coded microcode. Being able to update the microcode is a great feature, because it often means you get a bug fix without actually replacing the physical cpu.

Re:Is this that silly..

[setagllib (753300)]

Yes they are. Modern CPUs have microcode (think firmware) which can even be replaced at runtime to patch bugs (e.g. race conditions that fudge memory protection). Intel and AMD both release microcode updates for their CPUs, and in Linux in particular, you can replace the microcode at runtime with zero risk because it's reset again when the CPU powers off.

A processor "driver" would support non-standard features like non-ACPI advanced power management, runtime tuning, the aforementioned microcode update, and so on. For instance, AMD's driver interfaces with their "Cool'N'Quiet" power scaling system (Linux has a driver built into the kernel so you generally don't need to care, but in Windows you have to install it manually).

Re:

[by Anonymous Coward]

and in Linux in particular, you can replace the microcode at runtime with zero risk because it's reset again when the CPU powers off.

... because Linux has some special relationship with the CPU that nothing else does??? That's how it works for every OS.

Re:

[setagllib (753300)]

Linux has the drivers as part of its base system, meaning the distribution can do it for you and you won't even know it's happening. I've heard RedHat does that but I don't have proof, just hearsay.

Re:

[m50d (797211)]

Not every OS has the drivers to do it, and Linux might be the only one he knows about.

Re:Is this that silly..

[edwdig (47888)]

Modern x86 is a hybrid of CISC and RISC - the more complex instructions are translated into RISC like microcode. Sometimes there are bugs in this microcode. On powerup, the microcode is copied out of ROM and into a small amount of onboard RAM, which can be replaced by software. Obviously your load, jump, add type instructions don't go through the microcode, but instructions like divide, square root, or load page table most likely do.

The other big thing that CPU drivers do is handle advanced power management features. Modern processors are capable of scaling down the processor speed to save power and reduce heat when the processor is mostly idle. The CPU drivers handle this.

So, anyway, the drivers are completely optional. They're just a means of fixing bugs and providing support for advanced functionality.

Microcode for beginners... FYI

[killmofasta (460565)]

Actually NOT. That is not how dynamic recompliation works.
CISC instructions, that are not fully implemented in microcode, get dynamically recomplied into other intructions. Microcode is HOW those instructions get implemented.
Also: Jump/Load/Store instructions do go through microcode. All memory accesses do. It makes things faster and simpler.

Microcode is HOW CPU instructions get implemented. ADD is implemented in microcode, becuase it has to interface the data queues with the ALU.

The way Intel Does it, is that The microcode gets copied from a disk file, and then gets loaded into a special place on the CPU, that stores bug-fixed instructions. ROM does not contain microinstruction fixes, except on Intel Boards. (It does not get updated often enough.)

The CPU driver handles Multiple CPUs. ( Its called the HAL ). Cool and Quiet/ACPI is also handled here.

Refrence: http://support.microsoft.com/kb/234558 [microsoft.com]

and

Refrence: http://en.wikipedia.org/wiki/Microcode [wikipedia.org].

I cannot believe that I brough this up, and only got a 1, while others, in just adding a tiny explaination get a 4 or 5. PickyWicky

Re:

[killmofasta (460565)]

I stand corrected, Microcode updates for Intel or AMD processors can come from ROM BIOS or DISK Files:

Ref: http://support.microsoft.com/kb/936357/ [microsoft.com]

Nuff said. Get the update already!

Re:

[renoX (11677)]

>Modern x86 is a hybrid of CISC and RISC

Maybe you should learn to read acronyms: IS in CISC and RISC is 'instruction set', which instruction set?
The 'external one' seen by the compiler.

So x86 are CISC plain and simply.

Re:

[edwdig (47888)]

We're talking about the internal design of the chip here, not the externally visible part.

Over the past 15 years or so CISC & RISC have come to refer more to design principles than to instruction sets. Modern processors don't look much like they did when people started using the terms RISC and CISC, making the original meanings not very useful today.

Re:

[try_anything (880404)]

x86, RISC, and CISC aren't just kinds of instruction sets. Those names are also used to refer to the families of processor design that coevolved with the instruction sets.

RISC was invented because it allowed processors to be implemented in a much simpler and faster way than the current CISC processors. The performance downside of RISC was that certain CISC instructions had to be replaced by several RISC instructions, inflating binary code size a bit, which meant a few more cache misses. Still, it was a m

Re:

[somersault (912633)]

Isn't the AGP miniport driver more of a motherboard chipset driver than a processor driver? I was surprised that processors would even have 'drivers' exactly..

It's a north bridge feature

[r00t (33219)]

AMD happens to place the north bridge on the CPU die.

Re:

[gad_zuki! (70830)]

Fine, roll your eyes. Real geeks need microcode updates. I just dont like seeing negative numbers when i ping stuff, so I grab the latest driver from AMD's site.

Re:

[Random Q. Hacker (137687)]

Are you crazy? If your AMD chip enables your packets to travel back in time, you need to share that microcode, not replace it!!

Re:

[BobPaul (710574)]

AMD Processor Driver allows the computer to manage AMD Cool'n'Quiet to save electricity when the CPU is idle. You sure you have customers? Do they pay you?

Re:Cool it moderators!

[Protonk (599901)]

Eh. When I get mod points I am usually hesiant to mod outside my field of expertise and REALLY hesitant to mod up/down in an older story of about 100-200 posts. Who knows if a comment I modded insightful appears 1/2 dozen times a few inches below? I try to stick with newer stories and pick reasonably good comments that won't get +5 eventually, because those are going to get modded anyways.

Re:Dude, WTF does this even do?

[644bd346996 (1012333)]

Do you really not know what h.264 decoding is? Turn in your geek card.

This library has optimized implementations of a lot of mathematical algorithms, with stuff like the video and jpeg decoding being the most complex stuff. It also has some of the more fundamental operations for signal processing and the like.

Re:Dude, WTF does this even do?

[niteice (793961)]

I still don't really grasp what it's supposed to do.

Fast math.

It does math routines?

Yes.

Displays JPGs?

It includes various DCT operations, which have applications in video (and jpeg) decoding.

Does it do anything if I'm running an Intel chip?

Don't see why not.

Re:

[Tinyn (1100891)]

Well, Intels similar product, IPP, is restricted to Intel CPUs. Both libraries do a cpuid check to find out if SSE2 and SSE3 and such are supported, but the Intel library also checks for the Intel manufacturer string, and if the result is anything but Intel's, it uses the dumb i386 implementations, even on modern AMD chips that support SSE3 just fine.

Re:

[pdusen (1146399)]

Phenom performance is pretty far from abysmal, it just isn't fantastic, and is somewhat disappointing.

And with more and more AMD/ATI specs being made open, my next hardware upgrade is likely to have one anyway, because things like that are important to me.