Introducing Hexagon backend

Development pre-RFC
#15

hello ,I briefly looked at the code.I have a question.you use LLVM to generate Hexagon code from TVM IR.Why add a Hexagon target directly instead of adding it under LLVM like X86 or ARM?

1 Like
#16

This patch only contains runtime support for Hexagon. There is codegen also, but it’s not included here (and it is in src/codegen/llvm)

#17

My current problem is that I don’t see special X86 or ARM support in the runtime’s code.

#18

The special runtimes are mostly for offloading to extra devices from host. ARM and X86 are usually the hosts, so the runtime for them is fairly simple. It’s still there, look at cpu_device_api.cc for example.

2 Likes
#19

I think if adding copyonright within hexagon code or not will not be a problem cause that these code will only used on Qualcomm soc.

#20

Maybe a little bit later. But I think there is one slide is very good: http://pages.cs.wisc.edu/~danav/pubs/qcom/hexagon_hotchips2013.pdf
And Hexagon DSP has good support for fixed-int computation, but not be suitable for float arithmetic. Like hexagon has some instructions can be very useful for convolution, for example vrmpy, which could be used for dot.

And according to my test, SNPE on 8155 Hexagon could execute mobilenet v2 quant model in less than 5ms.

One more thing, thanks for the help and discussion of @kparzysz, based on his contributed runtime pr, I have completed TVM support of hexagon (LLVM hexagon CodeGen, schedule, hexagon parallel support and so on), but I must admit that we have big gap compared with SNPE, I am working on it. When time is suitable and follow up @kparzysz, I could contribute back to upstream.

4 Likes
Running inferences on Hexagon DSPs
#21

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

#22

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?

#23

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.

#24

@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.

#25

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.

#26

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)

https://source.codeaurora.org/quic/hexagon_nn/nnlib/tree/hexagon/src/prepare.c 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?

#27

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.

#28

@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.

incs/unsigned_pd.h

#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;
}
#29

Yes.

… (fulfilling the 20 character obligation)

#30

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.

#31

We’re back.

3 Likes
#32

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 tvm-hexagon.md how I did it. Could you look it and see if I got the process right?. Especially CXXFLAGS to build tvm runtime for Hexagon

#33

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.

#34

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?