Spoiler: Estou bastante confiante de que a resposta éNO, mas isso é apenas após um dia de depuração muito frustrada. Agora eu gostaria de saber se esse é realmente o caso (e se sim, como eu poderia saber) ou se estou apenas fazendo algo completamente errad

Aqui está a situação. Estou usando o OpenGL ES 2.0 para renderizar algumas malhas que carrego de vários arquivos (.obj, .md2, etc.). Por uma questão de desempenho e experiência do usuário, delegar o carregamento real dessas malhas e suas texturas associadas a um encadeamento em segundo plano usando o GCD.

Per Apple instruções, em cada thread de segundo plano, crio e defino um novo EAGLContext com o mesmoshareGroup como o principal contexto de renderização. Isso permite que objetos OpenGL, como objetos de textura e buffer, criados no segmento de segundo plano, sejam imediatamente usados pelo contexto no segmento principa

Isto tem funcionado esplendidamente. Agora, eu aprendi recentemente sobrebjetos de matriz de vertex como uma maneira de armazenar em cache o estado OpenGL associado à renderização do conteúdo de determinados buffers. Parece bom e reduz o código de verificação e configuração do estado padrão, necessário para renderizar cada malha. Além de tudo, a Apple também recomenda usá-los em seuselhores práticas para trabalhar com dados de vértic guia

Mas eu estava tendo problemas sérios para conseguir que os VAOs trabalhassem para mim. Como faço com todo o carregamento, eu carregava a malha de um arquivo na memória em um encadeamento em segundo plano e depois gerava todos os objetos OpenGL associados. Sem falhar, a primeira vez que tentei ligar paraglDrawElements() usando um VAO, o aplicativo trava comEXC_BAD_ACCESS. Sem o VAO, ele fica bem.

DebuggingEXC_BAD_ACCESS é uma dor, especialmente quando o NSZombies não ajuda (o que obviamente não ajuda), mas depois de algum tempo analisando os quadros OpenGL capturados, percebi que, enquanto a criação do VAO no segmento de segundo plano funcionava bem (nãoGL_ERROR e um ID diferente de zero), quando chegasse a hora de vincular o VAO no thread principal, eu obteria umGL_INVALID_OPERATION, qualthe docs state acontecerá ao tentar se conectar a um VAO inexistente. E, com certeza, ao observar todos os objetos no contexto atual no momento da renderização, não há um único VAO a ser visto,mas todos os VBOs que foram gerados com o VAOAO MESMO TEMP estão presente. Se eu carregar o VAO no thread principal, ele funcionará bem. Muito frustrante

Destilei o código de carregamento para uma forma mais atômica:

- (void)generate {

    glGenVertexArraysOES(1, &_vao);
    glBindVertexArrayOES(_vao);

    _vbos = malloc(sizeof(GLuint) * 4);
    glGenBuffers(4, vbos);
}

Quando o acima é executado em um encadeamento em segundo plano, com umEAGLContext com o mesmoshareGroup como o contexto principal, o contexto principal terá 4 VBOs, mas nenhum VAO. Se eu executá-lo no thread principal, com o contexto principal, ele terá 4 VBOs e o VAO. Isso me leva à conclusão de que há uma exceção estranha à natureza de compartilhamento de objetos deEAGLContexts ao lidar com VAOs. Se esse fosse realmente o caso, eu realmente esperaria que os documentos da Apple notassem isso em algum lugar. É muito inconveniente ter que descobrir pequenos petiscos como esse à mão. É esse o caso ou estou faltando alguma coisa?