abadams
commented
5 years ago Please talk to the Halide devs before forking Halide! We're friendly and would like to avoid another fork if at all possible. Some of the reasons behind TVM's fork were based on misunderstandings of what was there, and if they had reached out to us we might have avoided the duplicated effort that has resulted. I worry something similar might be happening in this case, because I don't understand several of your reasons for a fork. We do have explicit loops over pixels (RDom) with conditionals (RDom::where), and Halide is used for color processing all the time in performance-critical code, such as Photoshop and the Google Pixel camera pipeline, so there may be a scheduling idiom you're not aware of or something (.reorder(c, x, y).bound(c, 0, 3).unroll(c)?). Drop by the Halide gitter or open an issue on our github repo with an example that's not producing a good inner loop. Some of your other points would be good feature requests or PRs. Current users mostly use AOT compilation, so the JIT interface has been comparatively neglected. There are almost certainly ways to improve it. The 50MB comes mostly from the inclusion of llvm, so a lighter-weight x86 JIT would trim that down substantially (and may also help with the gemm/conv inner loops that llvm has trouble register-allocating). In general we'd like to break up libHalide into smaller pieces so people can take just the parts of it they need. Carving off the llvm-using parts would be the a good first step.
the feature request about evolution proposal OE-16