OpenCL 2.0 Feedback Series:
- OpenCL Standardization Issues (this article)
- My OpenCL Vision and Philosophy
- OpenCL 1.3: My Proposal For a Final 1.x Release
- OpenCL 2.0: SPIR Feedback and Vision
OpenCL 2.0 was recently released as a provisional specification, and developers have been given an opportunity to provide feedback. I am writing a series of articles to address technical issues with the specification, but this particular article is going to focus on issues with the standardization process itself. Sometimes, technical people focus on technical issues rather than the non-technical ones that might be causing even bigger problems for a project or group. I would like to address all of the non-technical issues here, so that I can move on to focus on the more interesting technical aspects of OpenCL.
The Standardization Process
The first and most critical issue is about the OpenCL standardization process itself. In particular, much of the development has happened behind closed doors. I am not privy to the debates which inevitably occurred when committee members disagreed. I am not aware of the discussions which lead to new features, or the use cases envisioned by the proposer. I have no idea what proposals were rejected and accepted, and on which grounds. These are not historical artifacts or gossips, instead they shape my own understanding of the inevitable trade-offs decided by the committee. These deep insights help me write better OpenCL code. I am a developer, which means that I use OpenCL to deliver something of value. It also means that I spend a lot of time with OpenCL, referencing the standard and writing software. We developers outnumber the standards committee members, and we are the group most likely to find issues with the specification. Our job is to really push OpenCL to its limits, and to use it in ways that have never been envisioned by the standards group. As a precedent for this, consider that C++ template metaprogramming was discovered and presented to the C++ standards committee. This discovery really changed the way C++ development was done! Developers are out there selling OpenCL to clients, and hardware vendors benefit from the marketplace enabled by software portability. As a developer, I view our role as critical to the success of new technologies and standards. However, the closed standardization process has severely limited our ability to provide critical feedback.
Suppose that I have an issue with the OpenCL standard. I do not have an option to address the standards committee directly without paying at least $10,000 USD. The only cost-effective option available to me is to post to forums and hope that busy committee members find my post. I have posted specification problems to the forum before with unsatisfactory results, so it doesn’t appear that this model works very well. Worse, since standardization happens behind closed doors I do not have an opportunity to point out potential errors until after the specification has been ratified. As we all know, the cost of removing a defect increases substantially after shipment, and standards are no different. The OpenCL standards have been handed down to developers without prior notice, with OpenCL 2.0 being the exception. There is a diagram from Khronos which really demonstrates my problem with how OpenCL standardization is proceeding.
You will notice that developers are handed down specifications without much opportunity for feedback. This is simply unacceptable for a general purpose tool like OpenCL, which has the potential to become a critical component of many software projects. If the C++ standards group had operated this way, I doubt C++ would be a very good language. Consider that C++ developers were provided ample opportunity to give feedback on new features in C++11. Although not many developers participated in the debates, we had a good understanding of what was coming, and how current and future projects would be affected. We were able to incorporate the future of C++ into our software designs.
Developers absolutely must have an opportunity to provide feedback without the substantial fees apparently required by Khronos for participation. Standardization must become increasingly open, and experts should have an opportunity to present findings and opinions to the standardization committee. It takes substantial effort for a developer to prepare a detailed case for modification of the standard and present it, and Khronos must encourage this type of participation. The provisional nature of OpenCL 2.0 is a first step, but not nearly enough!
I strongly suggest that the OpenCL standards group begin use a public mailing list for discussions regarding the standard. Developers should be provided with a clear mechanism to provide feedback. I really like this ISO C++ website, and the clear directions provided for feedback. This website conveys to me that my suggestions are welcome, and that problems will be attended to.
OpenCL Philosophy and Vision
I do not see that OpenCL has a publicly shared vision or philosophy which motivates it. What is the overall purpose of OpenCL? If we take a step back, what role does it play in software development? What are the guiding principles that steer the standards committee, and which are implicitly relied upon by developers? Where is OpenCL going and how far are we from the ideal implementation? I personally refer to these types of matters as OpenCL philosophy.
I have inferred my own OpenCL philosophy from close study of the standard, and programming guides from vendors. Ultimately, I have no idea if my OpenCL philosophy matches that of the standards committee, and this means that software I write might be unsound. OpenCL must have a clearly defined vision or philosophy which unifies members of the standards committee and developers. The point of OpenCL philosophy is to act as a litmus test for new features and overall evolution of the standard. If a new feature is nice, but breaks the OpenCL philosophy, it should be discarded. OpenCL philosophy is critical to developers (like myself) who are building tools that help other developers use OpenCL in their projects. Our job is to provide a conceptual bridge between OpenCL and another domain, and if we do not have a solid understanding of OpenCL’s raison-d’être we cannot do that.
Concretely, the OpenCL standard has provided an introduction which outlines what OpenCL can do, and an architecture model that shows how it accomplishes it. But the standard does not mention why OpenCL is doing these things, instead it provides examples of usage. OpenCL is an evolving standard, and developers must rely upon a fixed philosophy that does not change as frequently. We must design our software according to a philosophy, acknowledging that the implementation is subject to change. For a concrete example, what guarantees do we have that devices are going to remain in OpenCL 2.1? Is the device model a philosophical underpinning of OpenCL, or is it just a stopgap measure? We don’t really know, and the private discussions that formed the standard are unavailable to provide insight.
Deprecations Are Bad!
I have been frustrated by the number of deprecations in the OpenCL standard. Each new standard version deprecates something, often without good reason. Deprecations should be taken very seriously by the standards committee, and the cost of a deprecation should be so prohibitive that new features are carefully scrutinized before inclusion. When a feature is deprecated, developers are provided a brief warning that something is about to go away. It means that perfectly good programs are going to stop working, eventually, simply because the standard has changed! This is very frustrating for developers, and leads them to believe that OpenCL isn’t quite ready for prime-time. If developers had a voice in the standardization process, deprecations would happen very, very rarely.
It is very hard for developers to properly support OpenCL right now, due to the number of versions of OpenCL standard implementations in the wild. Developers must restrict themselves to a subset of features that are common to all versions, or add logic to handle different versions. It becomes very expensive for companies to support OpenCL in this environment. Ultimately, the whole point of a standard is to avoid this mess!
The OpenCL committee must stop deprecating features, and they must stop yesterday! The standard can grow and adopt without such frequent deprecations.
Standard Layout and Presentation
It’s not just what you say, it’s how you say it. The OpenCL standard is a bit hard to read, or reference. The standard provides several sections, and developers must very carefully read the standard (and search the PDF of the text for keywords) to understand behavior. The standard combines examples with behaviors and use-cases. Although this makes the standard interesting to read, it also makes it hard to reference. I strongly suggest that the standard should be rewritten in a clear and precise style. The C++ standard is fairly simple to reference, and to look up behavior when needed.
This would be a lot of work, but the final standard would be easier to use, and likely more concise. It might be best if the OpenCL standard had two parts, one part to informally motivate the philosophy of OpenCL and provide use cases, and another part to provide a concise technical standard.
Design and Features
Good design isn’t about adding features, it’s about deciding which features should be added with a mindset of minimalism. Features should be added to a standard like OpenCL not as a matter of course, but as required to enable new functionality within the conceptual framework provided by the OpenCL philosophy. OpenCL has become an ad-hoc collection of features which are becoming too device-specific to be portable. For instance, images are a core part of the OpenCL standard but not all devices support them. Devices have varying capabilities, support varying versions of the OpenCL standard, and have vendor extensions on top of that. What a mess!
The OpenCL standards committee must become conservative about the features added to the standard to ensure OpenCL has maximum portability and utility. Developers must be able to decide themselves whether or not they wish to break portability by using device or vendor-specific extensions. Developers write OpenCL code for portability, and might decide to use vendor-specific operations in critical areas for performance. I have some technical suggestions for how everybody might be satisfied with a slight change to the standard. However, the core problem here is that it appears that features are just being shoved into the standard without a coherent vision or long-term strategy.
Conclusion
Addressing non-technical issues can be hard. In this case, I hope that my criticism leads to positive changes in the OpenCL standardization process that enables cooperation with the developer community. I really like OpenCL, and would be more than happy to participate in the standardization process as a volunteer. I’d also like to mention that any standard is going to have a shaky beginning. It’s hard to discuss a blank page, and it’s hard to imagine how people are going to use something without having a first version. With this in mind, OpenCL 1.x should be given some allowance for the inevitable growing pains of a new and sophisticated standard. However, I believe that the developer community, standards committee, and vendors now have sufficient experience to fix the OpenCL standard and to really ensure that OpenCL 2.0 is ready for prime-time.