Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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."

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).

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.

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.

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.