Introducing Hexagon backend

OK that makes sense and we might need a special target aware function for that

GetTempAllocaAlignment function maybe should be modified for special DSP target and return 128(kTempAllocAlignment) directly.

1 Like

I’m working on some changes and will have patches for review soon.

2 Likes

Patch #1 is ready. This is the runtime support for Hexagon: https://github.com/dmlc/tvm/pull/3163

1 Like

It seems the support for Hexagon CDSP is not ready now. Is there any plan, e.g. to add the support for Hexagon CDSP in the last release of TVM.
Another question, besides CDSP, there is also a dedicated NPU in SDM8150, will Qualcomm add the TVM support for NPU in the future?

2 Likes

There was a delay caused by the need for another legal review (since there were comments on the license headers in the patch).

I will post an updated patch within a few days.

Update: I posted an updated patch two day ago. See https://github.com/dmlc/tvm/pull/3163.

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

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)

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

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

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.

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

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)

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?

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.