This on it's own is cause for joy. Any chance of mandatory full certification being brought back to earlier versions as time goes by and drivers mature?

No. Khronos can't require certification for specifications that have already gone through ratification and have shipping implementations. Mandatory starts with GL 4.4 implementations. But some vendors who are shipping earlier versions are likely to choose to make conformance submissions on those drivers. All the major desktop IHVs (and one IV who isn't on desktop at the moment) have been actively contributing to the conformance tests and running them against their drivers during the test development process.

The conformance tests are not going to solve every behavior difference or address every bug - that level of testing is far out of scope relative to the resources Khronos can put into developing tests - but they should be a significant improvement over SGI's OpenGL CTS,l which was last updated about 14 years ago.

You don't get it, do you? Aside from there being principle to adhere to here (yeah I know, stupid principle, duh), Mesa is an important entity to pretty much any open-source driver on Linux as it is an OpenGL reference implementation. But the project is open-source, maintained by various people of various companies and independent developers and not by a single, loaded corporation. One might consider that a problem.

This could be something that could be improved, the OpenCL 2.0 announcement has a mention of a 6 months feedback window. Too bad the OpenGL 4.4 does not seem to mention such a thing. Could be a good thing to do this for OpenGL too.

Couldn't agree more...

Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
Technical Blog: http://www.rastergrid.com/blog/

such things as image load\store, ssbo's, atomic operations and texture views.
30% of the question is actual things you do with this functionality in real projects(except for texture views, it's kinda obvious). and 70% is what kind of projects and why did you decide to invest your time to implement functionality using those extensions.

The GL tests share a codebase with the OpenGL ES 2/3 tests, which a bunch of stuff added for GL-specific features. So there are API coverage and functional tests, in some cases quite comprehensive and in other cases not, and a bunch of shading language tests. There is work underway to integrate a more comprehensive set of GLSL tests contributed by drawElements. We're still light on tests for the most recently added GL features, but making progress.

No. Khronos can't require certification for specifications that have already gone through ratification and have shipping implementations. Mandatory starts with GL 4.4 implementations. But some vendors who are shipping earlier versions are likely to choose to make conformance submissions on those drivers. All the major desktop IHVs (and one IV who isn't on desktop at the moment) have been actively contributing to the conformance tests and running them against their drivers during the test development process.

That's reasonable and understandable (particularly in light of vendors who may have 3.x hardware that they no longer ship drivers for), if regrettable. The fear is that some vendors may freeze their implementations at pre-4.4 level in order to avoid the certification requirement, but given your last sentence it seems a lot more positive.

Originally Posted by Jon Leech (oddhack)

The conformance tests are not going to solve every behavior difference or address every bug - that level of testing is far out of scope relative to the resources Khronos can put into developing tests - but they should be a significant improvement over SGI's OpenGL CTS,l which was last updated about 14 years ago.

I don't think many people expect every behaviour difference or bug to be fixed (even D3D with WHQL can't do that); it's a good thing to push them in the direction of more consistent and predictable behaviour though (and also good to hear that they're all on-board with this). I think everyone wants to avoid another Rage, and this is a solid step in the right direction.

You don't get it, do you? Aside from there being principle to adhere to here (yeah I know, stupid principle, duh), Mesa is an important entity to pretty much any open-source driver on Linux as it is an OpenGL reference implementation. But the project is open-source, maintained by various people of various companies and independent developers and not by a single, loaded corporation. One might consider that a problem.

Khronos is committed to the creation of royalty-free specifications for use by the entire industry. It is our stated committed mission, and our actions over our history demonstrate that commitment.

We achieve that goal in a number of reasoned legal steps that also protect the IP of the Khronos membership. If we are not careful to create a structure that protects members IP, as well as the use of the specification in the industry, many of the members would not be able to participate in the creation of these standards for the good of the industry.

The wording in the Khronos IP framework grants reciprocal royalty-free license to other members. This is not exclude non-members as a goal, but because it is not acceptable to grant a valuable IP license to an unknown entity or entities (e.g. 'the whole world') that do not explicitly agree to reciprocal terms. So, the Khronos IP framework establishes the largest 'raft' of written reciprocal contractual obligations possible - i.e. between the entire Khronos membership.

Behind this is the stated commitment that anyone can implement a Khronos spec royalty free. In practice this means that if a non-member is tacitly following the terms of the written reciprocal agreement between the members, i.e. not suing Khronos members over the use of a Khronos specification, then Khronos welcomes their using the specification. Now, this stated commitment is not a written contract, but if a non-member requires a written contract between itself and the entire Khronos membership for implementing any Khronos specification, it just has to join Khronos. As Khronos membership is guaranteed (by our bylaws) to be open to any company that wishes to join, any implementer may gain access to a written reciprocal license for the cost of a Khronos membership - $10K.

For companies implementing a complete specification, $10K is very inexpensive (and we do need membership fees to keep the lights on). But the good point was made that open source communities cannot afford a Khronos membership. To address this, Khronos has a proud history of waiving membership fees to open source practitioners who are undertaking bona fide efforts to construct open source implementations of Khronos specifications. This enables them to enjoy the same protection as other Khronos members for free.

Finally, a comment was made that a member possessing a patent on a Khronos specification was a bad thing. The reverse is true. Under the Khronos IP Framework all members with patents that are essential to a ratified Khronos specification reciprocally license that patent royalty-free. Importantly, the more patents that Khronos members posses that are reciprocally licensed, the larger and stronger the patent 'raft' that protects implementers of the specification against non-members asserting patents against the spec. Patents that are licensed to you for your protection are a very good thing.

@Jon: first of all, that's definitely a very good start. I wonder, would it be possible to open up the test descriptions and let the community participate? I guess we got enough man-power around here to at least fill some of the gaps with suggestions for viable tests. In general, an open conformance test-suite would be awesome - one would probably need one to n people signing off on contributions.