Slashdot Mirror
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."
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.
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.
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.
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.
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.
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).
Sam ty sig.
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.
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.
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.
ROMANES EUNT DOMUS
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
and
Refrence: http://en.wikipedia.org/wiki/Microcode.
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
This is old news. My submission "APL under APL" was rejected...
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 distributing Apache licensed code doesn't impose any arduous requirements.
I am TheRaven on Soylent News
We already have liboil which does more or less the same thing, so it's not like this is a revolutionary development.
Anyone knows how it compares with the Intel Performance libraries ? and especially how good IPL is on an AMD processor and vice versa ?