Announcement

Collapse
No announcement yet.

AMD To Open-Source Its Linux Execution & Compilation Stack

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • AMD To Open-Source Its Linux Execution & Compilation Stack

    Phoronix: AMD To Open-Source Its Linux Execution & Compilation Stack

    In the discussion last night about AMD not having any plans to suspend their proprietary Linux driver, John Bridgman of AMD shared some interesting information about AMD planning to provide a full execution stack in open-source form...

    http://www.phoronix.com/vr.php?view=MTEyMzQ

  • elanthis
    replied
    Originally posted by ldesnogu View Post
    They probably used what is considered in the industry as the best C++ front-end: Edison Design Group C++. It's used by almost all larger companies that produce their own compilers (TI, Intel to name a few).
    Note that this opinion has not been re-evaluated in recent years. That is, everyone uses EDG because everyone uses EDG and there weren't any alternatives (GCC's frontend is not only GPL'd, it's also a ****ing nightmare to integrate into anything else, GPL'd or not). Clang has sprung into existence just a few years ago and is already at the same level of C++11 support as GCC. One can expect that in the coming years, a lot of tools may well migrate from EDG to Clang. The ones that don't will mostly be those monstrous clunking behemoths for which replacing the frontend would be far too much work, or those that have invested too heavily in modifying the EDG-based frontend (like Microsoft's compiler, which lags in C++11 because it's essentially a fork of an ancient version of EDG, but all of the crazy Microsoft extensions like C++/CLi and C++/Cx only exist in that frontend).

    Leave a comment:


  • bridgman
    replied
    Whoops, my bad too... I completely forgot about that. We actually had docco in a third place -- the Stream (now APP) SDK web pages, so agd5f built a list to wrap them all. Apologies if it was someone else than agd5f

    Leave a comment:


  • entropy
    replied
    Originally posted by bridgman View Post
    We post info to the xorg wiki first then update amd.com later. Looks like we need another sync there.

    The 3D programming docco on the xorg wiki covers from 6xx through NI pretty well since they all use the same core architecture. It wouldn't hurt to add delta docs for things like attribute interpolation in the shaders, although the ISA docs and driver code also cover the changes. SI needs an all new docco set and that should probably be highest priority.
    A sync would be nice but as I see now it's all properly linked at
    http://www.x.org/wiki/RadeonFeature#Documentation

    My bad!

    Leave a comment:


  • artivision
    replied
    Well CISC is not RISC and does not decode anything in RISC (that is recompiling), decoding is another thing. RISC means relative instructions (one is little the other, or, continuation of another), CISC is the opposite (complex relations between instructions). CISC cannot execute directly many instructions, so executes them in Micro-Ops (frames in space or in time), its the only way for a CISC because 20-30 different units is not possible, instead 7 units are good wille RISC can have only 1 (vector registers). Micro-Ops are not RISC because are not relative and are not instructions. RISC is 20 times smaller for the same general processing power and 40 times smaller for stream processing like gaming, and thats because you cant find any game with static compiled graphics in order to use the complexity.

    Leave a comment:


  • bridgman
    replied
    Originally posted by entropy View Post
    Thanks! Still, information seems a bit scattered all over the place.
    We post info to the xorg wiki first then update amd.com later. Looks like we need another sync there.

    The 3D programming docco on the xorg wiki covers from 6xx through NI pretty well since they all use the same core architecture. It wouldn't hurt to add delta docs for things like attribute interpolation in the shaders, although the ISA docs and driver code also cover the changes. SI needs an all new docco set and that should probably be highest priority.

    Leave a comment:


  • drag
    replied
    Originally posted by rrohbeck
    Now if they could explain what they plan in a way that a simple computer scientist like myself understands what they're going to do...
    GPGPU + CPU + Possibly other stuff == New multicore computer architecture.

    So AMD is releasing software that will help people develop compilers and libraries to take advantage of it.

    Leave a comment:


  • entropy
    replied
    Thanks!

    Still, information seems a bit scattered all over the place.

    Leave a comment:


  • Drago
    replied
    http://developer.amd.com/SDKS/AMDAPP...s/default.aspx

    Originally posted by entropy View Post
    [Slightly offtopic]

    Good point.

    Are the documents found at http://www.x.org/docs/AMD/ complete, by means of released docs?
    If so - that means there's no specific documentation available for Evergreen (HD 5000) and newer. I wasn't aware of that. :/
    Otherwise, can someone in charge please dump the newer stuff in there?
    Is there another location for the docs that I'm overlooking?

    Leave a comment:


  • entropy
    replied
    Originally posted by jvillain View Post
    Certainly powerful stuff and the future. But I would rather see a proper spec for the new AMD GPU's any day of the week.
    [Slightly offtopic]

    Good point.

    Are the documents found at http://www.x.org/docs/AMD/ complete, by means of released docs?
    If so - that means there's no specific documentation available for Evergreen (HD 5000) and newer. I wasn't aware of that. :/
    Otherwise, can someone in charge please dump the newer stuff in there?
    Is there another location for the docs that I'm overlooking?
    Last edited by entropy; 06-20-2012, 04:24 PM.

    Leave a comment:

Working...
X