title: Can Vertex Array Objects (VAOs) be shared across EAGLContexts in OpenGL ES?
body: <p>Spoiler: I'm fairly confident that the answer is <code>NO</code>, but that's only after a day of very frustrated debugging. Now I would like to know if that is indeed the case (and if so, how I might have known), or if I'm just doing something completely wrong.</p>
  
  <p>Here's the situation. I'm using OpenGL ES 2.0 to render some meshes that I load from various files (.obj, .md2, etc.). For the sake of performance and User Experience, I delegate the actual loading of these meshes and their associated textures to a background thread using GCD.</p>
  
  <p>Per <a href="http://developer.apple.com/library/ios/#qa/qa1612/_index.html" rel="noreferrer">Apple's</a> <a href="http://developer.apple.com/library/ios/#documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/WorkingwithOpenGLESContexts/WorkingwithOpenGLESContexts.html" rel="noreferrer">instructions</a>, on each background thread, I create and set a new EAGLContext with the same <code>shareGroup</code> as the main rendering context. This allows OpenGL objects, like texture and buffer objects, that were created on the background thread to be immediately used by the context on the main thread.</p>
  
  <p>This has been working out splendidly. Now, I recently learned about <a href="http://www.opengl.org/wiki/Vertex_Array_Object" rel="noreferrer">Vertex Array Objects</a> as a way to cache the OpenGL state associated with rendering the contents of certain buffers. It looks nice, and reduces the boilerplate state checking and setting code required to render each mesh. On top of it all, Apple also recommends using them in their <a href="http://developer.apple.com/library/ios/#documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/TechniquesforWorkingwithVertexData/TechniquesforWorkingwithVertexData.html" rel="noreferrer">Best Practices for Working with Vertex Data</a> guide.</p>
  
  <p>But I was having serious issues getting the VAOs to work for me at all. Like I do with all loading, I would load the mesh from a file into memory on a background thread, and then generate all associated OpenGL objects. Without fail, the first time I tried to call <code>glDrawElements()</code> using a VAO, the app crashes with <code>EXC_BAD_ACCESS</code>. Without the VAO, it renders fine.</p>
  
  <p>Debugging <code>EXC_BAD_ACCESS</code> is a pain, especially when NSZombies won't help (which they obviously won't), but after some time of analyzing captured OpenGL frames, I realized that, while the creation of the VAO on the background thread went fine (no <code>GL_ERROR</code>, and a non-zero id), when the time came to bind to the VAO on the main thread, I would get a <code>GL_INVALID_OPERATION</code>, which <a href="http://www.opengl.org/sdk/docs/man4/xhtml/glBindVertexArray.xml" rel="noreferrer">the docs</a> state will happen when attempting to bind to a non-existent VAO. And sure enough, when looking at all the objects in the current context at the time of rendering, there isn't a single VAO to be seen, <em>but all of the VBOs that were generated with the VAO <strong>AT THE SAME TIME</strong> are present</em>. If I load the VAO on the main thread it works fine. Very frustrating. </p>
  
  <p>I distilled the loading code to a more atomic form:</p>
  
  <pre><code>- (void)generate {
  
      glGenVertexArraysOES(1, &amp;_vao);
      glBindVertexArrayOES(_vao);
  
      _vbos = malloc(sizeof(GLuint) * 4);
      glGenBuffers(4, vbos);
  }
  </code></pre>
  
  <p>When the above is executed on a background thread, with a valid <code>EAGLContext</code> with the same <code>shareGroup</code>as the main context, the main context will have 4 VBOs, but no VAO. If I execute it on the main thread, with the main context, it will have 4 VBOs, and the VAO. This leads me to the conclusion that there is some weird exception to the object-sharing nature of <code>EAGLContext</code>s when dealing with VAOs. If that were actually the case, I would have really expected the Apple docs to note that somewhere. It's very inconvenient to have to discover little tidbits like that by hand. Is this the case, or am I missing something?</p>