nVidia, latest drivers (at the time of writing).
Forward-compatible 3.3 context.
glVertexAttribPointer throws GL_INVALID_OPERATION.
VAO is bound right after context creation.
All calls are wrapped with error testing functions, definitely the VAO calls (checked many times) - and they don’t fail.
That means the context is correct and VAO should be bound.
It isn’t unbound until the context is destroyed. Since other GL calls (except glDraw*** and glVertexAttribPointer) do not fail, the context isn’t destroyed.
Since I don’t own an nVidia graphics card myself, I can only guess what OS it’s been tested on (I’ve had many helpful testers, it only didn’t fail for 1 or 2 nVidia users). My guess is that between those, there was Win7.
Exactly 0 errors on ATI graphics cards (except for the GLEW ones, which I just ignore - there can only be glGetString errors, complaining about lack of an extensions string, glewExperimental = true).
Using multiple contexts, having function pointers set up for each context (although there’s probably no need because I don’t use multiple different contexts and I’ll remove that soon if it’s OK to do that).
What I need to know is: where could the bug be?
Due to 2 days spent testing without finding anything conclusive, I’m quite sure it’s a driver bug but I’d like to hear a 2nd opinion.
Anyway, looks like I’ve found the problem myself:
normalize = true fails with floats even though the spec doesn’t say it should.
EDIT: Scratch that, looks like it still doesn’t work… here’s the demo: http://ge.tt/8oPaWbB
The answer was actually quite simple once I’ve got to debug it on my PC - VAO was created on another context (by [flawed] design). Therefore it was shared in graphics card / driver combos which didn’t strictly follow the specification, which says: VAOs are not shareable.