Introducing Hexagon backend

Can you show me the code implementation of Hexgon’s Codegen?

I have a question about Licensing. PR 3163 (Initial implementation of Hexagon runtime support) proposes to add new build option USE_HEXAGON_SDK which is required for Hexagon DSP support

tvm_option(USE_HEXAGON_SDK "Path to the Hexagon SDK root (required for Hexagon support)" /path/to/sdk)

Hexagon SDK is not open-source software. It has particular License

Question is: Can a company use TVM which is built with HEXAGON_SDK in a commercial publicly available web service?

That’s more of a legal question than technical. I took a look at the license and it seems that the exact terms of use depend on various conditions, but I can’t say that I understand it completely. Aside from not knowing the answer, I’m not qualified or authorized to answer such questions… Sorry.

@kparzysz Thank you for your reply. Can I ask you another question. Technical one. I’m trying to use haxagon_nnlib on unlocked Xiaomi Mi 9 phone (sm8150 aka SM855).

Hegaxon SDK docs says that “Unsigned PD” allows to load unsigned libs to CDSP startng from sm8150 SoC.

I’m trying to execute Hexagon_SDK/3.4.3/examples/hexagon_nn/tutorials example 001-nop. I added #pragma weak remote_session_control and call remote_session_control as a first line in main().

hexagon_nn_config, hexagon_nn_init, hexagon_nn_append_node, hexagon_nn_prepare work fine but the execution fails on hexagon_nn_execute.

Xiaomi/mace developer told me that it might be SDM855 SoC firmware bug and hexagon_nn lib may use some APIs that unsigned PD happens to reject to access.

Have you tried Hexagon_SDK/3.4.3/examples/hexagon_nn/tutorials with Unsigned PD on production sm8150 (SDM855) devices (not on dev kits)?

Other examples such as calculator , rpcperf and cornerApp are working fine with Unsigned PD.

I only have a test 8150 device, but I can run unsigned PDs on it, and if there is any “prohibited” call, it should fail there as well. I’m on vacation until the beginning of January, I’ll take a look when I go back to work.

Hi Krzysztof

Did you have a chance to try nexagon_nn on sm8150?

The issue might be related to multithreading and qurt. logcat with farf shows

01-12 23:22:52.896 13125 13128 V adsprpc : log.c:95:0x30d7:11: Arch_Version: 00000000
01-12 23:22:52.896 13125 13128 V adsprpc : log.c:107:0x30d7:11: WARN: ARCH-MISMATCH (compiled for v60 != actual v0) line 4796

I also tried queuetest from examples/common/asyncdspq_sample - it hangs as well.

Related discussion How to use hexagon_nn with unsigned PD?

Hi, Yes, I tried it, but I ran into issues much earlier than you did. The first call to NN (I think it was hexagon_nn_config) failed. I sent the link to your question above to some people around here, hopefully I’ll get some reply.

@kparzysz Did you add the call to hexnn_controller_request_unsigned_pd() to main()? It should be the first line in main() function of 001-nop.c.


#pragma weak remote_session_control

int hexnn_controller_request_unsigned_pd() {
  int ret = -1;
  if (remote_session_control) {
    fprintf(stderr, "***************** remote_session_control is TRUE ****************\n");
    struct remote_rpc_control_unsigned_module data;
    data.enable = 1;
    data.domain = CDSP_DOMAIN_ID;
    ret = remote_session_control(DSPRPC_CONTROL_UNSIGNED_MODULE, (void *) &data, sizeof(data));
    fprintf(stderr, "***************** remote_session_control returned %d ****************\n", ret);
  } else {
    fprintf(stderr, "***************** remote_session_control is FALSE ****************\n");
  return ret;


… (fulfilling the 20 character obligation)

Ok, we found the workaround. The problem was in qurt_thread_set_priority which is called inside nn_os_set_current_thread_priority in file libs/hexagon_nn/2.6/hexagon/src/nn_os_qurt.c

Decided to just comment out qurt_thread_set_priority line.

We’re back.


Hi Krzysztof

I read your article explaining how to run test TVM Hexagon python program.

Once I was able to run the test program on the simulator I decided to create a step-by-step instructions how I did it. Could you look it and see if I got the process right?. Especially CXXFLAGS to build tvm runtime for Hexagon

Hi Alex, Yes, it looks good. There is one thing, though. When building the TVM runtime for Hexagon, your instructions explicitly set CXXFLAGS. Was it necessary for you? The cmake configuration should be able to pick up the correct options, including the header file locations. If that didn’t work for you, that would be something we could try to fix.

Otherwise it looks good! Thanks for putting it together.

Hi, it’s really an old thread, but still want to check were you able to reproduce the SNPE perf results using TVM in the end?

Yep, also curious about the followup. Is the Hexagon backend fully supported now? Or SNPE is still the only toolchain we can use to compile models to Qualcomm GPU.

It is supported in the sense that you should be able to compile and execute any model. There is still a lot of work we need to do to make it perform well. Right now we’re working on many infrastructural changes in TVM, and the actual code generated for Hexagon is still far from optimal.

1 Like

How about now ?Do you have more perf result about the generated codes for Hexagon ? :thinking: