2

Halide and OpenVX seem to have similar goals.

Can someone comment on where they differ and where they both stand with respect to adoption in the community today?

Lolo
  • 3,935
  • 5
  • 40
  • 50
  • A hopefully-helpful note: this sparked a few replies on the halide-dev mailing list, which didn't make it back here. See the thread of the same title here: https://lists.csail.mit.edu/pipermail/halide-dev/2017-February/thread.html – jrk Feb 03 '17 at 08:46
  • Thank you for mentioning this thread. The last comment still makes me think in the end that Halide and OpenVX (via the graph optimizer) offer the same functionality with the exception that OpenVX allows for nodes accelerated in hardware (as long as they comply to the node APIs) whereas Halide doesn't. Correct? If so, what prompted the creation of Halide though OpenVX already existed? Said differently: in what ways is Halide not a subset of the functionality provided by OpenVX? – Lolo Mar 03 '17 at 01:27

1 Answers1

1

OpenVX focuses on graph-building and algorithm API standardization – which are useful, but it doesn’t address the bigger problem (IMO) and time consuming task of mapping algorithms to heterogeneous architectures, which is addressed by Halide quite elegantly.
I had written down my thoughts some time ago that may be of interest: http://ks-dsp.blogspot.com/2016/09/halide-for-adas.html

KSampat
  • 11
  • 1
  • My understanding was that, when properly optimized for a given platform, the OpenVX graph scheduling does specifically address the task of mapping efficiently at runtime the processing blocks onto the appropriate components of the targeted heterogeneous architecture. Am I wrong? – Lolo Feb 02 '17 at 20:34
  • I don't know Haliide (yet). To my understanding, OpenVX does exactly what you describe. The only thing I could add is that everyone seems to emphasize that it is primarily targeting embedded hardware (smartphones etc.) – JPNotADragon Feb 02 '17 at 21:21