Announcement

Collapse
No announcement yet.

AMD Publishes Open-Source Linux HSA Kernel Driver

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

  • phoronix
    started a topic AMD Publishes Open-Source Linux HSA Kernel Driver

    AMD Publishes Open-Source Linux HSA Kernel Driver

    Phoronix: AMD Publishes Open-Source Linux HSA Kernel Driver

    AMD has just published a massive patch-set for the Linux kernel that finally implements a HSA (Heterogeneous System Architecture) in open-source. The set of 83 patches implement a Linux HSA driver for Radeon family GPUs and serves too as a sample driver for other HSA-compatible devices. This big driver in part is what well known Phoronix contributor John Bridgman has been working on at AMD. Heterogeneous System Architecture has been talked up for a while now by AMD as well as ARM vendors and now finally for open-source enthusiasts we can finally start seeing the advantages of the CPU and GPU on the same bus. Oded Gabbay of AMD announced the big HSA kernel patch-set:..

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

  • fteoOpty64
    replied
    Originally posted by seandarcy View Post
    So, once the HSA commits go into the kernel, x264 will use HSA through OpenCL?
    Yes, your x264 app would have to be OpenCL aware in the first place. It is the OpenCL primitives that calls the HSA abstraction driver to perform the hardware/software function. In terms of dedicating specific HSA cores, it could be manual or automatic. Either explicitly specified or defaulted. This is great progress for APU users of Linux.

    Leave a comment:


  • Jammyamerica
    replied
    AMD APU generations always Rocks

    Leave a comment:


  • Jedibeeftrix
    replied
    3.17?

    Leave a comment:


  • seandarcy
    replied
    Originally posted by bridgman View Post
    .... As examples, a C++ AMP app would need a rebuild while a OpenCL app would probably not.
    So, once the HSA commits go into the kernel, x264 will use HSA through OpenCL?

    Leave a comment:


  • bridgman
    replied
    Not expecting benefits to the kernel directly -- the kernel driver exposes functionality to userspace that toolchains can call on to let apps more-or-less invisibly run faster. The app may or may not need to be rebuilt in order to take advantage of the new functionality depending on the JIT-iness of the language & APIs already in use. As examples, a C++ AMP app would need a rebuild while a OpenCL app would probably not.

    Leave a comment:


  • seandarcy
    replied
    HSA requires application update ??

    Will HSA provide benefits to the kernel itself ? In other words, if I use existing applications will I see any benefit ? Or is this an API, where applications must be modified to see _any_ benefit. I understand that if applications are modified they can take advantage of HSA. The question is, are kernel level operations helped, even without application modification.

    Leave a comment:


  • GreatEmerald
    replied
    So, will earlier AMD APU generations (Bobcat and whatnot) be able to make use of any of this? They probably don't have the Youmu, err, IOMMU to make full use of it, but maybe there could be some minor gains out of this anyway?

    Leave a comment:


  • edgar_wibeau
    replied
    A10-7800 has 3500 MHz base and 3900 MHz max turbo frequency at 65 Watts, that was published when it was introduced on 3dr July.

    http://www.cpu-world.com/CPUs/Bulldo...0A10-7800.html
    http://www.planet3dnow.de/cms/10505-...offiziell-vor/

    As apposed to when A8-7600 was introduced in January, they decided to this time not communicate the speeds for the 45 Watt mode. Same for the desktop "Pro" models, some of which come at 65/45W and 65/35W TDP, with only the speds for the higher TDP having been communicated. Sadly. AMD marketing often is a little questionable. To say it the sugarsweet way.

    And almost nobody seems to have delivered those news. Even more sadly.
    http://www.3dcenter.org/news/amd-bri...elle-den-start

    Leave a comment:


  • bridgman
    replied
    Originally posted by ObiWan View Post
    The upper (and higher) are turbo clocks,
    the lower ones are the standard non turbo clock.
    That made sense for parts with a single power dissipation rating, but for parts with two ratings (eg 65W/45W) where I *think* the clock speeds are different at different ratings it's less clear how to interpret the numbers. I guess for now I'll stay with the cynic's view that the numbers represent the highest power rating

    Leave a comment:

Working...
X