Slashdot Mirror

← Back to Stories (view on slashdot.org)

AMD Open Sources the AMD Performance Library

Posted by samzenpus on from the let-my-library-go dept.

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

59 comments

  1. Fuck yeah! by poopdeville · · Score: -1, Offtopic

    OMG First post!

    --
    After all, I am strangely colored.
    1. Re:Fuck yeah! by byteframe · · Score: -1

      Nice one.

  2. Is this that silly.. by Brian+Gordon · · Score: -1

    .."AMD Processor Driver" that I see installed on so many customers' machines? I roll my eyes every time I see it

    1. Re:Is this that silly.. by tomhudson · · Score: 5, Informative

      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.

    2. Re:Is this that silly.. by perlchild · · Score: 1

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

    3. Re:Is this that silly.. by 99BottlesOfBeerInMyF · · Score: 1

      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've opened the code and it will likely get some small amount of reuse.

    4. Re:Is this that silly.. by Protonk · · Score: 3, Interesting

      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.

    5. Re:Is this that silly.. by killmofasta · · Score: 1, Offtopic

      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 driver" ! Yes! Thanks AMD! Keep those tiny patches coming!

      You dont want the latest and greatest? Ok.

    6. Re:Is this that silly.. by Brian+Gordon · · Score: 0

      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 would that even work, x86 processors aren't exactly field programmable..

    7. Re:Is this that silly.. by 644bd346996 · · Score: 4, Informative

      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.

    8. Re:Is this that silly.. by setagllib · · Score: 4, Informative

      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.
    9. Re:Is this that silly.. by Wesley+Felter · · Score: 2, Interesting

      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.

    10. Re:Is this that silly.. by Anonymous Coward · · Score: 1, Insightful

      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.

    11. Re:Is this that silly.. by edwdig · · Score: 3, Informative

      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.

    12. Re:Is this that silly.. by Anonymous Coward · · Score: 0

      RISC chips are simple but fast chips in which you program directly in the chips instruction set - the existence of a microcode layer by definition makes them the opposite of RISC, regardless of what the microcode instruction set looks like. They are NOT hybrids, they are CISC.
      Also, since the x86 ISA is a CISC instruction set anyway, it's absurd to claim that a chip with a CISC instruction set, that uses a microcode layer has anything RISC like about it at all.
      If it at least had a RISC like ISA, but still had a microcode layer, then maybe the claim would have some merit.

    13. Re:Is this that silly.. by gad_zuki! · · Score: 1

      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.

    14. Re:Is this that silly.. by setagllib · · Score: 1

      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.

      --
      Sam ty sig.
    15. Re:Is this that silly.. by m50d · · Score: 1

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

      --
      I am trolling
    16. Re:Is this that silly.. by somersault · · Score: 1

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

      --
      which is totally what she said
    17. Re:Is this that silly.. by Goaway · · Score: 1

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

    18. Re:Is this that silly.. by TheRaven64 · · Score: 1

      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.

      --
      I am TheRaven on Soylent News
    19. Re:Is this that silly.. by Goaway · · Score: 1

      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.

    20. Re:Is this that silly.. by renoX · · Score: 1

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

    21. Re:Is this that silly.. by TheRaven64 · · Score: 2, Informative

      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
    22. Re:Is this that silly.. by Random+Q.+Hacker · · Score: 1

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

    23. Re:Is this that silly.. by BobPaul · · Score: 1

      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?

    24. Re:Is this that silly.. by edwdig · · Score: 1

      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.

    25. Re:Is this that silly.. by try_anything · · Score: 1

      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 massive performance win at the time. As chip technology advanced, the austerity of RISC processors became less important, and the complex CISC instruction decoders started to look less costly. There was more room on the chips to implement complex operations that could not be expressed in minimalistic "true RISC" instruction sets, and memory became a more frequent bottleneck than CPU. This allowed the performance pendulum to swing back towards x86.

      Meanwhile, the x86 chip designs assimilated the wisdom of RISC. Current x86 processors have an essentially RISC core hidden behind the instruction decoder. This allows them to have fast RISC internals while programs and libraries can be expressed in a featureful, compact, backwords-compatible CISC instruction set. It is a hybrid.

    26. Re:Is this that silly.. by Anonymous Coward · · Score: 0

      Let us understand something. There is a free (public domain) set of software that does this very thing. This library is basically a reimplementation of some the same APIs that optimizes it for the AMD processor. Note that Intel has a similar offering already called Intel Math Kernel Library. The APL has always been a free download for evaluation purposes. Now, companies like The Mathworks can use the library for free.

    27. Re:Is this that silly.. by Protonk · · Score: 1

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

  3. Cool it moderators! by qmaqdk · · Score: -1, Offtopic

    Four comments and about 7 moderator points have been used?!?! Cool it guys!

    Now use one Offtopic on me :)

    --
    My UID is prime. Hah!
    1. Re:Cool it moderators! by Protonk · · Score: 4, Interesting

      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.

  4. Meh. by urcreepyneighbor · · Score: -1, Offtopic

    Thankyoucomeagain.

    --
    "The fight for freedom has only just begun." - Geert Wilders
  5. But wait, what's this tidbit about graphics docs? by schwaang · · Score: 2, Interesting
    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.
  6. Desperation by snarfies · · Score: -1, Troll

    Could it be they are offering this framework due to the ABYSMAL performance of their new Phenom processors? And will it be enough to save them, now that their stock has taken a sharp nosedive?

    1. Re:Desperation by pdusen · · Score: 1

      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.

  7. Dude, WTF does this even do? by Anonymous Coward · · Score: -1

    So I read TFAs and followed up on sourceforge, but I still don't really grasp what it's supposed to do. It does math routines? Displays JPGs? Does it do anything if I'm running an Intel chip?

    It sounds more like a clusterfuck of marketing spew more than an actual library.

    1. Re:Dude, WTF does this even do? by 644bd346996 · · Score: 3, Informative

      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.

    2. Re:Dude, WTF does this even do? by niteice · · Score: 4, Informative

      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.
      --
      ROMANES EUNT DOMUS
    3. Re:Dude, WTF does this even do? by nguy · · Score: -1, Troll

      Since when have facts, logic, and rationality been part of a good anti-Microsoft argument?

      Since anti-trust investigations, leaked memos, and careful code analysis revealed the extent of Microsoft's anti-competitive and anti-user practices.

      Start here if you need to come up to speed:

      http://en.wikipedia.org/wiki/Halloween_Documents

      http://en.wikipedia.org/wiki/Microsoft_antitrust

    4. Re:Dude, WTF does this even do? by RiotingPacifist · · Score: 0, Offtopic

      well this is all OT but its not even careful code analysis, microsoft java was just blatent copy+paste, shame on sun for not going for the kill!

      --
      IranAir Flight 655 never forget!
    5. Re:Dude, WTF does this even do? by Tinyn · · Score: 1

      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.

  8. Comment on your sig: by Futurepower(R) · · Score: -1, Troll

    Comment on your sig: Since when have facts, logic, and rationality been part of Microsoft's management policies?

    For example, things are so bad with Windows Vista that InfoWorld, one of the most respected IT publications, is running a Save Windows XP campaign.

  9. Microcode for beginners... FYI by killmofasta · · Score: 5, Informative

    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

    1. Re:Microcode for beginners... FYI by killmofasta · · Score: 1

      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/

      Nuff said. Get the update already!

  10. My submission: by wild_berry · · Score: 4, Funny

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

  11. Better look at liboil by Anonymous Coward · · Score: 0

    If you love MACROS and variablesWithIdentifiersAroundThisSizeLong look no further.
    I will stick to liboil, good old C and understandable by mere mortals.

    1. Re:Better look at liboil by 3.14159265 · · Score: 1

      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.

  12. Will it be shipped with Linux distributions? by julie-h · · Score: 1

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

    1. Re:Will it be shipped with Linux distributions? by pdusen · · Score: 1

      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.

    2. Re:Will it be shipped with Linux distributions? by hr.wien · · Score: 2, Informative

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

  13. Re:But wait, what's this tidbit about graphics doc by Ed+Avis · · Score: 1

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

    --
    -- Ed Avis ed@membled.com
  14. Re:But wait, what's this tidbit about graphics doc by beefsprocket · · Score: 1

    Read Bill Weinberg's post on 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.

  15. Re:But wait, what's this tidbit about graphics doc by Ed+Avis · · Score: 1

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

    --
    -- Ed Avis ed@membled.com
  16. APL vs IPL by ceroklis · · Score: 2, Interesting

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

  17. Re:But wait, what's this tidbit about graphics doc by Haeleth · · Score: 1

    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 completely wrong, because his highly restrictive definition does not match the way the term "open source" is actually used in the real world. Most people who actually use it do not use popularity as a criterion. If you accept that fact, his argument collapses rather.

  18. ...strangely familiar by Tenebrarum · · Score: 1

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

  19. Framewave constructive criticisms by Anonymous Coward · · Score: 0

    It has been said by some other developers that the malloc/fwMalloc is being used from within the actual processing functions.

    Memory allocation calls are expensive performance-wise. Please consider to create a few other house-keeping calls to be used before using the actual processing functions:
    The house-keeping calls would be responsible for:
    1)creating an object_pool which is a memory pool that can hold only objects of the same type as specified by ElementType
    allocating the memory in the respective memory pool to hold an initial number of same-type objects
    2)The actual number of pools to initially create would map to the number of types used in the library.
    The actual number of objects to create in each type would depend on the average maximum number of elements used in each of the framewave API calls.
    Here are the types I have identified for candidate pools:
    Fw16s Fw16sc Fw16u Fw32f Fw32fc Fw32s Fw32sc Fw32u Fw64f Fw64fc Fw64s Fw64sc Fw64u Fw8s Fw8u
    FwStatus FwLibraryVersion FwRoundMode FwWinType FwBool FwCmpOp FwCpuType FwHintAlgorithm

    3)Single-Threaded and Multi-threaded should follow the same strategy because for each thread there should be a unique pools of memory for all of the above types anyways.
    To make all of this easier, one could write a new class/template holding all the above with your initial respective pool sizes and just pass this one higher-level object to all the other api's and grab the respective thread's pools/elements when you need them with indirection.

    The c++ memory pool api already exists:
    http://www.boost.org/libs/pool/doc/index.html

    I do hope this helps.

  20. It's a north bridge feature by r00t · · Score: 1

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