Nice work! I have been messing with doing some radio DSP on the NPU in my laptop and found the Intel graph compiler to be rather unpredictable. Weird random mis-lowering to fp16 ops instead of int8, unpredictable throughput depending on tensor sizes, reshapes being sometimes extremely expensive and sometimes basically free etc.
Obviously I am mostly just driving the DPU, as the SHAVE cores are just not beefy enough, but maybe this will be useful at some point, at least to gain more insight into the architecture...
Thanks! I can observe similar behaviors on my laptop. FP32 operations are sometimes siliently lowered to a sequence of (FP32->FP16)->(FP16 OP)->(FP16->FP32), causing precision loss. It further frustrated me during npunlock development. Changing custom SHAVE OP from FP16 -> FP32 also changes the blob structure, and I have to explore different binary patching strategy.
As for the interesting cost variance for reshape you've mentioned, I guess surrounding context is the cause. The NPU compiler might adjust the data layout to match successive OPs' requirements. But, yes, that's annoying~
Studying DPU is not my current priority, but I may dig it up in the future to understand its invocation descriptor, and hopefully to discover more interesting stuff. I hope this project ends up being useful to you!
The main use is enabling developers to write their own NPU kernels according to their respective need, instead of picking workaround from what Intel provides in OpenVINO. I think the project would benefit three scenarios:
1. Implement uncommon NN operators.
2. Implement a high-precision (FP32, etc.) version of existing OpenVINO operators for numerically sensitive usage.
3. Implement a mega kernel that fuse several small kernels together to reduce SHAVE invocations, and potentially improve performance.
But most importantly, it gives you more control over the hardware you own. That control IMO should have been yours from day one you bought the machine.
I have no access to other environment setting, so, sadly, that's the best I can do for now.
But based on my understanding, playing this on Linux or newer NPU generations might be possible. I have recorded my hypotheses in [0]. Verifying the hypotheses would require additional utility tools, which I am stilling crafting.
Windows comes with the ability to do wsl so you somewhat have Linux as well even though it's limited in some ways. May be worth a shot cross compiling it.
Yes. But WSL doesn't come with NPU passthrough, so I still can't test the hardware-specific behavior. Cross-compiling the project with WSL is plausible. I will try it and leave for the community to do verification.
I failed a few days ago to use the npu with openvino and llama.cpp. I will try again with this and hopefully open source it. Thanks
Of course I will do everything on Linux. Might contribute back
Author here. Feel free to ask any questions :)
Nice work! I have been messing with doing some radio DSP on the NPU in my laptop and found the Intel graph compiler to be rather unpredictable. Weird random mis-lowering to fp16 ops instead of int8, unpredictable throughput depending on tensor sizes, reshapes being sometimes extremely expensive and sometimes basically free etc.
Obviously I am mostly just driving the DPU, as the SHAVE cores are just not beefy enough, but maybe this will be useful at some point, at least to gain more insight into the architecture...
Thanks! I can observe similar behaviors on my laptop. FP32 operations are sometimes siliently lowered to a sequence of (FP32->FP16)->(FP16 OP)->(FP16->FP32), causing precision loss. It further frustrated me during npunlock development. Changing custom SHAVE OP from FP16 -> FP32 also changes the blob structure, and I have to explore different binary patching strategy.
As for the interesting cost variance for reshape you've mentioned, I guess surrounding context is the cause. The NPU compiler might adjust the data layout to match successive OPs' requirements. But, yes, that's annoying~
Studying DPU is not my current priority, but I may dig it up in the future to understand its invocation descriptor, and hopefully to discover more interesting stuff. I hope this project ends up being useful to you!
Finally, bare-metal NPU programming! Immediately thought of those custom, weird inference tasks Intel won't ever officially support.
Let's play Doom on NPU!
Pls do hexagon next
What is this useful for?
The main use is enabling developers to write their own NPU kernels according to their respective need, instead of picking workaround from what Intel provides in OpenVINO. I think the project would benefit three scenarios:
1. Implement uncommon NN operators.
2. Implement a high-precision (FP32, etc.) version of existing OpenVINO operators for numerically sensitive usage.
3. Implement a mega kernel that fuse several small kernels together to reduce SHAVE invocations, and potentially improve performance.
But most importantly, it gives you more control over the hardware you own. That control IMO should have been yours from day one you bought the machine.
> Requirements Windows x64
plonk.
I have no access to other environment setting, so, sadly, that's the best I can do for now.
But based on my understanding, playing this on Linux or newer NPU generations might be possible. I have recorded my hypotheses in [0]. Verifying the hypotheses would require additional utility tools, which I am stilling crafting.
[0]: https://github.com/hsfzxjy/npunlock/blob/master/wiki/PORTING...
Windows comes with the ability to do wsl so you somewhat have Linux as well even though it's limited in some ways. May be worth a shot cross compiling it.
Yes. But WSL doesn't come with NPU passthrough, so I still can't test the hardware-specific behavior. Cross-compiling the project with WSL is plausible. I will try it and leave for the community to do verification.