glDrawArrays asigna memory en cada cuadro

Recientemente encontré que glDrawArrays asigna y libera enormes cantidades de memory en cada fotogtwig. Sospecho que está relacionado con el problema "Sombreadores comstackdos fuera de la initialization" reportado por el desarrollador de openGL. ¡Eso ocurre en cada cuadro! ¿Debería ser solo una vez, y después de comstackr los sombreadores, desaparecer?

EDITAR: también comprobé que mi vértice esté correctamente alineado. Así que estoy realmente confundido qué controller de memory necesita asignar en cada fotogtwig.

EDITAR # 2: Estoy usando tiras triangulares degeneradas y VBO para hacer sprites y. Estoy pasando geometry en cada fotogtwig (GL_STREAM_DRAW).

introduzca la descripción de la imagen aquí

EDITAR # 3:

Creo que estoy cerca de emitir pero aún no puedo resolverlo. El problema desaparece si paso el mismo valor de id de textura al sombreador (ver el comentario del código fuente). De alguna forma, este problema se relaciona con el fragment sombreador, creo.

En mi lote de sprite tengo una list de sprites y los represento por ID de textura y queue FIFO.

Aquí está el código fuente de mi class de lote de sprite:

void spriteBatch::renderInRange(shader& prog, int start, int count){ int curTexture = textures[start]; int startFrom = start; //Looping through all vertexes and rendering them by texture id's for(int i=start;i<start+count;++i){ if(textures[i] != curTexture || i == (start + count) -1){ //Problem occurs after decommenting this line // prog.setUniform("texture", curTexture-1); prog.setUniform("texture", 0); // if I pass same texture id everything is OK int startVertex = startFrom * vertexesPerSprite; int cnt = ((i - startFrom) * vertexesPerSprite); //If last one has same texture we just adding it //to last render call if(i == (start + count) - 1 && textures[i] == curTexture) cnt = ((i + 1) - startFrom) * vertexesPerSprite; render(vbo, GL_TRIANGLE_STRIP, startVertex+1, cnt-1); //if last element has different texture //we need to render it separately if(i == (start + count) - 1 && textures[i] != curTexture){ // prog.setUniform("texture", textures[i]-1); render(vbo, GL_TRIANGLE_STRIP, (i * vertexesPerSprite) + 1, 5); } curTexture = textures[i]; startFrom = i; } } 

}

 inline GLint getUniformLocation(GLuint shaderID, const string& name) { GLint iLocation = glGetUniformLocation(shaderID, name.data()); if(iLocation == -1){ // shader variable not found stringstream errorText; errorText << "Uniform \"" << name << " was not found!"; throw logic_error(errorText.str()); } return iLocation; } void shader::setUniform(const string& name, const matrix& value) { GLint location = getUniformLocation(this->programID, name.data()); glUniformMatrix4fv(location, 1, GL_FALSE, &(value[0])); } void shader::setUniform(const string& name, int value) { GLint iLocation = getUniformLocation(this->programID, name.data()); //GLenum error = glGetError(); glUniform1i(iLocation, value); // error = glGetError(); } 

EDITAR # 4: Intenté perfilar la aplicación en IOS 6 e Iphone5 y las asignaciones son mucho más grandes. Pero los methods son diferentes en este caso. Estoy adjuntando una nueva captura de pantalla.

introduzca la descripción de la imagen aquí

El problema se resuelve creando shader por separado para cada textura . Parece un error en la implementación del controller que sucede en todos los dispositivos IOS (lo probé en IOS 5/6). Sin embargo, en models de iPhone más altos no es tan perceptible.

En iPhone4 el performance fue muy significativo desde 60 FPS hasta 38!

Más código ayudaría, pero ¿ha revisado para ver si la cantidad de memory involucrada es comparable a la cantidad de geometry que está actualizando? (¡aunque eso parecería ser una gran cantidad de geometry!) Parece que GL mantiene su actualización hasta glDrawArrays, liberándolo cuando se puede acceder al estado GL interno.

Si puede ejecutar el código en una aplicación MacOS, la herramienta OpenGL Profiler puede aislar aún más la condición. (busque en la documentation de XCode para get más información, si no está familiarizado con esta herramienta). También sugiero ver el uso de textura, dada la cantidad de memory involucrada.

Lo más fácil es dividir condicionalmente en malloc () por una asignación grande, anotar la dirección y examinar qué se ha cargado allí.

intente consultar el uniforme de la textura solo una vez (en la initialization) y caching. llamar a "glGetUniformLocation" demasiado en un solo cuadro afectará el performance (dependiendo del recuento de sprite).