Hello OpenVX Authors:
I’ve just finished reading over most of the OpenVX material that I could find. It is a very elegant and appropriate data-flow approach to the CPU intensive domain of image processing. Also, I would welcome a significant rewrite to the OpenCV API. Don’t get me wrong, OpenCV is awesome and very successful, but its history as an experimental and research platform show through compared to other more well thought out industry API libraries and packages. This is just inherent due to its early entry into the field and lack of a rigorous governing body, but absolutely no fault of any of the developers or those involved.
In my reading of OpenVX, it seems like the intended deployment model is analogous to that of OpenGL: where each device manufacture will develop and release a driver. Is this true? I would like to put fourth that this is an unrealistic strategy to achieve sufficient critical mass and market acceptance for the following reasons:
[ul]
[li]General application developers who target multiple devices won’t even consider using OpenVX until it is available on at least 95%+ of target devices. Hardware manufacturers will be reluctant to commit resources to develop these drivers until there is sufficient demand: i.e., applications. This is chick-and-the-egg type problem.
[/li][li]OpenCV (and other image processing libraries) already exists and offers an immediate and free production-worthy solution backed significantly by Apple (i.e., lots of resources). Also it appears that OpenCV accelerated by GPU is nearly available although I haven’t tried it myself, yet should provide good performance.
[/li][/ul]
This being said, there can and will be certain hardware dedicated markets like smart glass and autonomous vehicles which can move forward with OpenVX drivers released only on specific hardware. But a platform independent solution would really be preferred and needed to achieve significant market penetration.
Therefore, I would like to put fourth an alternative strategy:
[ul]
[li]Develop only a single common implementation of OpenVX.
[/li][li]Use and leverage OpenCL for the heavy computational tasks.
[/li][li]Use and leverage OpenCL’s interrogation capabilities of GPUs and Accelerators hardware to guide OpenVX data-flow algorithms.
[/li][li]Evolve OpenCL’s hardware interrogation capabilities to support the full vision of OpenVX’s graph processing.
[/li][/ul]
The benefits are:
[ul]
[li]OpenCL already exists and is fairly widely available.
[/li][li]Consolidated OpenVX’s engineering efforts on one single solution instead of may hardware specific devices creates enormous efficiency.
[/li][li]Less device specific behavior/bugs and better consistency.
[/li][li]Market acceptance would be a lot greater and earlier than the current approach.
[/li][li]OpenCL would probably welcome further enhancements to support the OpenVX’s agenda and needs.
[/li][li]Vendors could still offer customized (device specific) versions of OpenVX if doing so provides them advantages.
[/li][li]Apple would potentially be more supportive of this direction since is already supports OpenCL.
[/li][/ul]
While this strategy may not produce, right out of the gate, as optimized performance as device specific solutions could, there is no reason that, in time, the hardware introspection capabilities will evolve and allow a common single solution to achieve the end goals. It’s all a matter of good abstractions.
In closing, the benefits of a single solution are enormous and hard to ignore.
PS: I am not an employee of Apple nor do I own or program any Apple products.