Khronos public bugtracker – Bug 1394
glClearNamedFramebufferfi is wrong in XML spec files.
Last modified: 2015-10-22 20:35:58 PDT
The OpenGL specification (and the quick reference card) gives this function 5 parameters. The XML spec dropped the `int drawbuffer` parameter.
This obviously propagated into the header, but also found its way into the reference documentation. So you should probably notify whomever is responsible for that.
I've also discovered that the extension specification for ARB_direct_state_access got this wrong too (in the list of functions). That's probably the original source of the mistake. Someone probably corrected the inline text (which got copied into the OpenGL 4.5 spec), but the list of functions was used to generate the XML spec files.
And every extension loader is based on those.
Created attachment 228 [details]
So, you have a critical bug that makes an important GL 4.5 function completely unusable for virtually every OpenGL loader on the web. And the bug hasn't even been acknowledged, let alone fixed.
I know you guys are busy with Vulkan and such, but keeping OpenGL up to date and functional alongside Vulkan was supposed to be important.
I'll make it even easier to fix: here's a patch for it.
(In reply to Alfonse from comment #2)
> Created attachment 228 [details]
> Patch fix
> So, you have a critical bug that makes an important GL 4.5 function
> completely unusable for virtually every OpenGL loader on the web. And the
> bug hasn't even been acknowledged, let alone fixed.
> I know you guys are busy with Vulkan and such, but keeping OpenGL up to date
> and functional alongside Vulkan was supposed to be important.
> I'll make it even easier to fix: here's a patch for it.
You're quite right. We actually identified this internally more than a month
ago, but I've been so focused on Vulkan stuff it didn't get done then,
either. Should be fixed in registry / headers / extension / ref pages now,
though it may take a bit to propagate.
FWIW, we're trying to adopt some different processes that will make accepting
public feedback easier, which will include moving at least the man pages and
registry sources into Khronos' github, but that's still probably a few months
away unless I get really motivated in between Vulkan teleconferences and
spec work. We hope to get to the point where it's barely more complicated than
hitting accept on a github MR rather than the current system, which involves
a lot of tedious manual steps on everyone's part between bug report and
changes becoming visible. We do really appreciate that you're making such
an effort to report and fix problems, despite the often seeming lack of
anyone responding to them. Even managed to spend an hour of the F2F meeting
today on the public bug list, which rarely happens - although that was barely
enough to once-over the open spec bugs lightly and didn't get to the ref
page bugs at all.