3 ms·

> However, the Hexagon DSPs are notoriously hard to program. While the Snapdragon CPU and GPU can be targeted using OpenMP and OpenCL, respectively, no such mod

> However, the Hexagon DSPs are notoriously hard to program. While the Snapdragon CPU and GPU can be targeted using OpenMP and OpenCL, respectively, no such model exists for the DSP. It's true, this is a big drawback. Something like OpenCL would be really nice. I haven't used OpenCL for a while but way back when the design seemed to consider that the memory used by the accelerator device was a separate destination to be copied to. For the SoCs where Hexagon shows up, that's generally not the case. But hopefully there's already some tweaks to OpenCL to enable different SMMU contexts instead of copies.

my123 3y ago
It has a quite nice high level programming model tbh. FastRPC is quite nice. And there's Halide support too.
- verditelabs 3y ago
  I used to work with the Halide guys from 2019-2021; I was on the TVM team. The compilers group was very proud of Halide's success in the early pixel phones. That was the library behind HDR+ on the Pixel 3. Hexagon is a difficult architecture to write code for but the benefits are worth it: it's the secret sauce for why Qualcomm's modems are so good. I see people getting all excited over AVX512 and I just think "well we had 2048 bit vectors years ago"
  - nimish 3y ago
    It is? And not any esoteric analog design? That explains the secrecy.
  - jjtheblunt 3y ago
    ex qualcomm qct compiler person here: qualcomm RF was so good even when Hexagon was being developed. if they moved their advantage onto Hexagon thereafter, that's cool.
dsharlet 3y ago
I don't think it's true at all, you can just write C/C++ with SIMD intrinsics, just like you can on ARM or x86, and the instruction set is mostly awesome. OpenCL would just be an extra layer to get in the way. If you want to just run some existing OpenCL code, I guess that would be nice, but I doubt any OpenCL code written for a GPU would actually run well on Hexagon anyways. The article also complains about VLIW in the same paragraph, but I don't think VLIW makes things harder, it just makes problems more obvious. If you write ARM or x86 code that has dependencies between every instruction, that's going to suck too, you just won't know it until you run it, but VLIW will make it obvious if you just look at the generated code. For the kinds of programs that make sense to run on a processor like Hexagon, VLIW is fine. The whole Hexagon environment is just so much better than any of the other similar DSPs I'm aware of: you can use open source LLVM to compile code for it (so you aren't stuck with an old version of GCC), and the OS is much closer to standard (e.g. thread synchronization is just pthreads). I did a bunch of work on Hexagon and I like it a lot. It is my favorite in its class.

my123 3y ago

It has a quite nice high level programming model tbh. FastRPC is quite nice. And there's Halide support too.

verditelabs 3y ago
I used to work with the Halide guys from 2019-2021; I was on the TVM team. The compilers group was very proud of Halide's success in the early pixel phones. That was the library behind HDR+ on the Pixel 3. Hexagon is a difficult architecture to write code for but the benefits are worth it: it's the secret sauce for why Qualcomm's modems are so good. I see people getting all excited over AVX512 and I just think "well we had 2048 bit vectors years ago"
- nimish 3y ago
  It is? And not any esoteric analog design? That explains the secrecy.
- jjtheblunt 3y ago
  ex qualcomm qct compiler person here: qualcomm RF was so good even when Hexagon was being developed. if they moved their advantage onto Hexagon thereafter, that's cool.

dsharlet 3y ago

I don't think it's true at all, you can just write C/C++ with SIMD intrinsics, just like you can on ARM or x86, and the instruction set is mostly awesome. OpenCL would just be an extra layer to get in the way. If you want to just run some existing OpenCL code, I guess that would be nice, but I doubt any OpenCL code written for a GPU would actually run well on Hexagon anyways. The article also complains about VLIW in the same paragraph, but I don't think VLIW makes things harder, it just makes problems more obvious. If you write ARM or x86 code that has dependencies between every instruction, that's going to suck too, you just won't know it until you run it, but VLIW will make it obvious if you just look at the generated code. For the kinds of programs that make sense to run on a processor like Hexagon, VLIW is fine. The whole Hexagon environment is just so much better than any of the other similar DSPs I'm aware of: you can use open source LLVM to compile code for it (so you aren't stuck with an old version of GCC), and the OS is much closer to standard (e.g. thread synchronization is just pthreads). I did a bunch of work on Hexagon and I like it a lot. It is my favorite in its class.