10/12/2011 Contribute to The OpenGL Community, report your bugs

In a world at its birth relativily to others sciences, everything remain to be done in computer graphics and it will take everyone to develop it. OpenGL being based on a community, what benefit to one benefit to everyone and this is true at the level of every one of us, members of The OpenGL Community.

What anyone who cares can do at its level is to report bugs, either from implementations or even from the specifications. The OpenGL implementers and the ARB are unfortunately but realisticcally limited in time this is why to contribute, an OpenGL Community member is required to back it up so that bug reports will raise interest and effectively be useful to fix an eventual problem.

Report your drivers bugs

Quick guidelines

When sending a bug report, "it doesn't work" doesn't give to much chance for a bug to reach interest of the people which will fixe them: Screenshots, platform, drivers version, a description to reproduce the bug and ultimately a code sample that build, run and reproduce the bug.

On AMD

On AMD, the best approach is to post a message on the AMD Graphics Programming sub-forum. Many OpenGL team members are monitoring this forum. There is also an unofficial bugzilla maintained by the Linux guys at AMD. It is still possible to file Windows bugs on this Bugzilla, they will reach the OpenGL team.

On NVIDIA

On NVIDIA to report a bug, one must become an NVIDIA registered developer http://developer.nvidia.com/join-nvidia-registered-developer-program. The place looks pretty much dead but it is still possible to submit bug reports.

OpenGL.org and Khornos.org forums

Two others fine place to report the bugs are the OpenGL.org forums and Khornos.org forums. Many OpenGL teams of IHV are monitoring these forums and your bugs should be notified.

Report to the Khronos Group

Not only IHV needs bug reports, also the Khronos Group does. For this purpose, the Khronos Group provides a public Bugzilla which can be used to report specification bugs or even man pages issues. For man pages issues, there is also an email address "manpages (at) opengl {dot} org".

When reporting a specification bug on Bugzilla, I think it is necessary to understand the process implied by a bug report. If it is just a typo, the bug could be really quickly fixed (even is released only at the next release). However, if the bug involves a proper bug, this bug will need to be discuss by the ARB but before that the bug will have to raise the interest of someone who will suggest it for discussion: Submitting a specification bug better have to be done seriously.

Moreover, we are living with a 20 years old specification and the least we could say is that the specification is complex. What could be seen as a bug might be just specify or clarify somewhere else. It is necessary to search beyond the expected scope for a language description and include both OpenGL and GLSL specification.

When reporting a bug I think it is mandatory to "quote" the specification, the parts of the language that requires to be clarified or which are contradictory.

I personnaly use a bug report strategy which looks like this: 1. Sumarize the problem; 2. Detail and quote the specification; 3. Submit a solution or multiple options.

  • A typo error.
  • A language clarification.
  • Contradictory language.
  • Missing commands, values in a table.
  • Unspecified OpenGL error.
  • And many more!

Conclusion

Getting OpenGL implementations better is not only the duties of implementers but also of the one of the OpenGL programmers. There is something worse than a bug: there is an unknowned bug. Contribute to the OpenGL community and report your bugs!

GLM 0.9.3.B released >
< November 2011 OpenGL drivers status
Copyright Christophe Riccio 2002-2014 all rights reserved
Designed for Chrome 9, Firefox 4, Opera 11 and Safari 5