Actualizar un área de memoria en el dispositivo gráfico (una textura, búfer y similares) no es lo mismo que cambiar un estado de representación.
Lo que hace que un cambio de estado de procesamiento sea costoso es la cantidad de trabajo que el controlador tiene que hacer para validar los nuevos estados y reordenar la tubería. Lo más probable es que también incurra en alguna sincronización entre la CPU y el dispositivo gráfico. Sin embargo, la cantidad de datos transferidos entre los dispositivos debe ser pequeña para un cambio de estado (probablemente solo unos pocos comandos).
Por otro lado, para una actualización de textura / búfer, el costo principal radica en la transferencia de datos en sí. En teoría, a menos que esté leyendo los datos de textura en la CPU después de la actualización, no debería haber sincronización ni paradas de canalización. Sin embargo, se debe considerar otro aspecto: la sobrecarga API. Incluso si la cantidad de datos que está enviando al dispositivo gráfico es pequeña, si lo hace con la frecuencia suficiente, eventualmente el costo de comunicarse con el controlador / dispositivo será mayor que el costo de la transferencia de datos. Esa es otra razón por la que el procesamiento por lotes es tan importante al optimizar un renderizador.
Entonces, en mi caso, el mejor enfoque, me parece, sería mantener una copia de la textura de la memoria del sistema que actualice cada vez que lleguen nuevos datos. Establezca una bandera sucia y consolide tantas actualizaciones como sea posible en una glTexSubImagepara toda la textura (o una gran parte secuencial de la misma). También puedes jugar con Pixel Buffer Objects e intentar hacer una transferencia de datos asincrónica para reducir las paradas de canalización tanto como sea posible. Si puede implementar algún tipo de almacenamiento en búfer doble, puede escribir en una copia de la textura mientras se procesa la otra. Este tutorialexplora ese escenario. Ese es mi enfoque intuitivo, trataría de reducir el número de llamadas a la API y "actualizar" las actualizaciones de textura. Dicho esto, esto es muy especulativo, y tendría que hacer un perfil y compararlo con otros enfoques, como hacer varias actualizaciones pequeñas, para saber con certeza cuál es el más eficiente en su caso de uso.
Como nota al margen, esta presentación de NVidia también es relevante y proporciona muchas buenas ideas: acercarse a Zero Driver Overhead en OpenGL .