Announcement

Collapse
No announcement yet.

A Heterogeneous Execution Engine Might Make Its Way To LLVM

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

  • A Heterogeneous Execution Engine Might Make Its Way To LLVM

    Phoronix: A Heterogeneous Execution Engine Might Make Its Way To LLVM

    An intern from Qualcomm's Innovation Center has been designing a heterogeneous execution engine for LLVM that he's hoping to eventually upstream within the LLVM project...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    HSA support, please!!!

    Comment


    • #3
      Originally posted by fuzz View Post
      HSA support, please!!!
      HSA is orthogonal to this work.
      The QC effort consists of a few moving parts but essentially it
      - scans your code for loops/functions that it thinks are good targets for running on an accelerator/DSP/GPU. (You can augment this automatic scanning with manual annotation.)
      - it separately compiles that selected code for the target accelerator, and includes stubs in the mainline code to a runtime
      - the runtime handles loading the accelerator code and whatever copying/coherency is necessary to handle the memory the code will work on

      All this has nothing to do with HSA. The system, when running on HSA, can be much simpler because neither the copying nor the coherency steps are necessary. But QC wants this to work with Hexagon so they have this more general framework.

      [IMHO trying for this more general framework is a waste of resources. They should just make future versions of Hexagon HSA compliant and say their framework will ONLY handle accelerators with a shared address space. Trying to be general is the mark of a naive youngster, not someone who's actually shipped anything. I suspect this, in part, is a reason for the lukewarm enthusiasm shown by the rest of the LLVM community (or at least the part I care about most, namely Apple). They're happy to work on the parts that make sense --- detecting good candidate code for accelerators, and compiling such code --- but I suspect they consider the current runtime model to be too ambitious, and too much time wasted on solving last year's problem, so that by the time the copying/coherency stuff is actually robust enough and fast enough to ship, no-one will care because the hardware that needs it will already be obsolete.]

      Comment

      Working...
      X