I'll just leave this here...

...just in case anybody here has answers for me.

http://stackoverflow.com/questions/24990637/opengl-radeon-driver-seems-to-mess-with-depth-testing

I encountered a similar scenario with Barony recently. We were feeding too many elements to drawArrays(), and while nvidia cards handled this mistake fine (apparently they don't render uninitialized vertex data...), AMD cards would not (free polygons ahoy!). So it seems likely to me you're making a similar mistake here.

Well turns out it's most likely a bug in the AMD driver, explicitely setting the correct stride value in glVertexAttribPointer() has solved the issue. Seems like the NVidia driver correctly calculates the stride with the parameter set to 0, as it should according to specification, but the Radeon driver seems to have an issue with that.

How about that! I wouldn't have guessed so, but my experience with openGL and therefore the big wide world of graphics vendors is quite limited as I honestly only sat down to build my first openGL application 5 or 6 months ago. As mentioned though it has become clear to me just how rough around the edges AMD drivers can be when it comes to anything like this. :\ The sad part is just how hard it is to debug since the OGL functions usually won't return anything useful in these cases and more often than not a crash will land you with a stack full of untraceable calls inside the kernel and graphics drivers.

It's just a bad idea to develop OpenGL applications on NVidia only, their drivers will happily work with code that sets any AMD card on fire.
I always have 5 or 6 browser windows opened with different pages from the OpenGL specification, just to make sure I follow every single practice by word so my code won't implode as soon as I try it on Radeon.