Chico, es este un gran tema.
En primer lugar, comenzaré con lo obvio: Dado que está llamando a la función (cualquier función) de la CPU, tiene que funcionar al menos parcialmente en la CPU. Entonces la pregunta realmente es, ¿cuánto del trabajo se hace en la CPU y cuánto en la GPU?
En segundo lugar, para que la GPU pueda ejecutar algún comando, la CPU debe preparar una descripción de 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 que se ejecutará. Cómo la CPU activa la GPU para hacer el comando también es algo importante. Como la mayoría de las veces, esto es costoso, la CPU no lo hace a menudo, sino que agrupa los comandos en búferes de comando y simplemente envía un búfer completo para que lo maneje la GPU.
Todo esto para decir que pasar trabajo a la GPU no es un ejercicio libre. Ese costo tiene que ser comparado con solo ejecutar la función en la CPU (no importa de lo que estamos hablando).
Dando un paso atrás, debes preguntarte por qué necesitas una GPU. El hecho es que una implementación de CPU pura hace el trabajo (como menciona AshleysBrain). La potencia de la GPU se debe a su diseño para manejar:
- tareas especializadas (rasterización, mezcla, filtrado de texturas, blitting, ...)
cargas de trabajo
- en gran medida paralelas (DeadMG está apuntando a que en su respuesta) , cuando una CPU está más diseñada para trabajar con un solo subproceso.
Y esos son los principios rectores a seguir para decidir qué incluye 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 depreciación, en su mayoría) en realidad no están claramente delineadas. Las listas de visualización son probablemente el mejor ejemplo de dicha función. Cada controlador es libre de enviar todo lo que desee de la secuencia de la lista de visualización a la GPU (generalmente en forma de búfer de comando) para su posterior ejecución, siempre que se mantenga la semántica de las listas de visualización GL (y eso es un poco en general). Por lo tanto, algunas implementaciones solo eligen enviar un subconjunto limitado de las llamadas en una lista de visualización a un formato calculado y elegir simplemente reproducir el resto de la secuencia de comandos en la CPU.
La selección es otra donde no está claro si la ejecución de la GPU tiene algún valor.
Por último, tengo que decir que, en general, hay poca correlación entre las llamadas 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 un Draw, o algo así.
Gran parte de la API GL funciona así. En ese punto, preguntar si glEnable(GL_BLEND) se ejecuta en la CPU o GPU es bastante insignificante. Lo que importa es si la fusión ocurrirá en la GPU cuando se llame a Draw. Entonces, en ese sentido, La mayoría de los puntos de entrada de GL no se aceleran en absoluto.
También podría ampliar un poco la transferencia de datos, pero Danvil lo tocó.
Terminaré con el pequeño "camino s/w". Históricamente, GL tuvo que trabajar para especificar sin importar cuáles eran los casos especiales de hardware.Lo que significaba que si el h/w no manejaba una función GL específica, entonces tenía que emularla o implementarla completamente en el software. Hay numerosos casos de esto, pero uno que golpeó a mucha gente es cuando GLSL comenzó a aparecer.
Como no había una manera práctica de estimar el tamaño del código de un sombreador GLSL, se decidió que el GL debía tomar cualquier longitud de sombreado como válida. La implicación fue bastante clara: implementamos h/w que podría tomar sombreadores de longitud arbitrarios -no realistas en ese momento-, o implementar una emulación de sombreado s/w (o, como algunos proveedores eligen, simplemente no cumplen). Entonces, si activó esta condición en un sombreador de fragmentos, era probable que el entero de su GL terminara ejecutándose en la CPU, incluso cuando tenía una GPU emplazada inactiva, al menos para ese sorteo.
No hay nada de qué sorprenderse. No llama a 'glTranslate' para cada vértice o fragmento, y de todos modos solo es una multiplicación de matriz, por lo que normalmente no se ejecuta ningún rendimiento al ejecutarlo en la CPU. – Thomas
@Thomas: Estás en lo cierto. Pero al principio, es difícil que la gente piense en el canal de renderizado de gráficos, y donde el sombreador de vértices se encuentra con 'glTranslate()'. Después de un tiempo se vuelve más claro, pero al principio pensé "Oh, esto debe ser acelerado por GPU", de ahí la pregunta. –
Pensé que T & L significaba Transformación e iluminación, que es (¿fue?) Acelerada por la tarjeta gráfica. –