| ▲ | Show HN: Npunlock – Run custom C kernels for Intel NPUs(github.com) |
| 50 points by hsfzxjy a day ago | 12 comments |
| |
|
| ▲ | Bayard_ne 3 hours ago | parent | next [-] |
| Finally, bare-metal NPU programming! Immediately thought of those custom, weird inference tasks Intel won't ever officially support. |
| |
|
| ▲ | hsfzxjy 6 hours ago | parent | prev | next [-] |
| Author here. Feel free to ask any questions :) |
| |
| ▲ | __atx__ 5 hours ago | parent [-] | | 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... | | |
| ▲ | hsfzxjy 4 hours ago | parent [-] | | 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! |
|
|
|
| ▲ | alex7o 2 hours ago | parent | prev | next [-] |
| Pls do hexagon next |
|
| ▲ | Gigachad 8 hours ago | parent | prev | next [-] |
| What is this useful for? |
| |
| ▲ | hsfzxjy 7 hours ago | parent [-] | | 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. |
|
|
| ▲ | ur-whale 4 hours ago | parent | prev [-] |
| > Requirements Windows x64 plonk. |
| |
| ▲ | hsfzxjy 4 hours ago | parent [-] | | 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... | | |
| ▲ | hypercube33 3 hours ago | parent [-] | | 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. | | |
| ▲ | hsfzxjy 3 hours ago | parent [-] | | 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. |
|
|
|
