¿Qué funciones de OpenGL no están aceleradas por GPU?

Chico, es este un gran tema.

Primero, comenzaré con lo obvio: Ya que estás llamando a la función (cualquier función) desde la CPU, tiene que ejecutarse al menos en parte en la CPU. Así que la pregunta realmente es, cuánto del trabajo se realiza en la CPU y cuánto en la GPU.

En segundo lugar, para que la GPU pueda ejecutar algún comando, la CPU tiene que preparar una descripción del comando para pasar. El conjunto mínimo aquí es un token de comando que describe qué hacer, así como los datos para la operación a ejecutar. La forma en que la CPU activa la GPU para hacer el comando también es algo importante. Dado que la mayoría de las veces, esto es costoso, la CPU no lo hace a menudo, sino que procesa comandos en búferes de comandos y simplemente envía un búfer completo para que la GPU lo maneje.

Todo esto para decir que pasar el trabajo a la GPU no es un ejercicio libre. Ese costo tiene que ser enfrentado con solo ejecutar la función en la CPU (no importa de lo que estemos hablando).

Tomando una un paso atrás, usted tiene que preguntarse por qué necesita una GPU en absoluto. El hecho es que una implementación de CPU pura hace el trabajo (como menciona AshleysBrain). El poder de la GPU proviene de su diseño para manejar:

• tareas especializadas (rasterización, mezcla, filtrado de texturas, blitting,...)
• cargas de trabajo muy paralelas (DeadMG apunta a eso en su respuesta), cuando una CPU está más diseñada para manejar el trabajo de un solo subproceso.

And those are the guiding principles to siga con el fin de decidir lo que va en el chip. Cualquier cosa que pueda beneficiarse de ellos debe ejecutarse en la GPU. Cualquier otra cosa debería estar en la CPU.

Es interesante, por cierto. Algunas funcionalidades del GL (antes de la obsolescencia, en su mayoría) no están claramente delineadas. Las listas de visualización son probablemente el mejor ejemplo de tal característica. Cada controlador es libre de empujar tanto como quiera de la secuencia de la lista de visualización a la GPU (por lo general en algún formulario de búfer de comandos) para su posterior ejecución, mientras se mantenga la semántica de las listas de visualización de GL (y eso es algo difícil en general). Por lo tanto, algunas implementaciones solo eligen empujar un subconjunto limitado de las llamadas en una lista de visualización a un formato calculado, y eligen simplemente reproducir el resto del flujo de comandos en la CPU.

La selección es otra en la que no está claro si hay valor para ejecutar en la GPU.

Por último, tengo que decir que, en general, hay poca correlación entre las llamadas a la API y la cantidad de trabajo en la CPU o la GPU. Una API de configuración de estado tiende a modificar solo una estructura en algún lugar de los datos del controlador. Su efecto solo es visible cuando se llama a un Sorteo o algo así.

Gran parte de la API de GL funciona así. En ese punto, preguntar si glEnable(GL_BLEND) se ejecuta en la CPU o GPU no tiene sentido. Lo que importa es si la fusión se realizará en la GPU cuando se llame a Draw. Así que, en ese sentido, La mayoría de puntos de entrada de LM no se aceleran en todo.

También podría ampliar un poco en la transferencia de datos, pero Danvil tocado en él.

Terminaré con la pequeña "ruta s/w". Históricamente, GL tuvo que trabajar para especular sin importar cuáles fueran los casos especiales de hardware. Lo que significaba que si el h/w no estaba manejando una característica específica de GL, entonces tenía que emularla, o implementarla completamente en software. Hay numerosos casos de esto, pero uno que golpeó a mucha gente es cuando GLSL comenzó a aparecer.

Puesto que no había práctica manera de estimar el tamaño de código de un sombreador GLSL, se decidió que el GL debía tomar cualquier longitud de sombreador como válida. La implicación era bastante clara: o bien implementar h/w que pudiera tomar sombreadores de longitud arbitraria-no realistas en ese momento-, o implementar una emulación de sombreador s/w (o, como algunos proveedores eligieron, simplemente no ser compatible). Por lo tanto, si activó esta condición en un sombreador de fragmentos, es probable que el completo de su GL terminara ejecutándose en la CPU, incluso cuando tenías una GPU inactiva, al menos para ese sorteo.