¿Por qué los sombreadores de píxeles no nos permiten leer directamente desde el buffer de cuadros o el buffer de profundidad?


18

Permitirme probar el buffer de cuadros o el buffer de profundidad en el sombreador de píxeles sería una característica extremadamente útil. Incluso ser capaz de saber la profundidad o el color de lo que esté detrás del píxel actual sería útil.

¿Por qué tanto OpenGL como DirectX no me dejan hacer esto? Esperaba que hubiera algún tipo de limitación de hardware, pero la combinación alfa utiliza el color en el framebuffer para los cálculos de mezcla, y la prueba Z muestra el buffer de profundidad en la ubicación actual. ¿Por qué no simplemente exponernos estos valores directamente? ¿Puedo esperar ver esto en el futuro?

Respuestas:


20

Que es una limitación del hardware. El sombreador de fragmentos es parte de la canalización programable, pero la mezcla de color final con los búferes de destino no es programable en hardware ampliamente disponible / de productos básicos en este momento (es configurable a través de estados de mezcla, pero no puede escribir arbitrariamente código que reemplaza las operaciones de mezcla integradas de GPU).

La razón por la cual el hardware no está construido para esto probablemente tenga que ver con el hecho de que las GPU son masivamente paralelas; procesan muchos fragmentos a la vez. Algunos de esos fragmentos finalmente pueden interactuar entre sí dentro de los búferes de destino, pero debido a la naturaleza asincrónica del procesamiento de fragmentos, no es posible saber cómo hasta que el fragmento haya sido procesado y se haya emitido el color final ... lo que ganó No siempre sucede de manera determinista.

El hecho de que el píxel A esté detrás del píxel B en el cuadro final no significa que el píxel A siempre completará el procesamiento de fragmentos y se escribirá en el destino antes que B, especialmente en múltiples cuadros de renderizado. Por lo tanto, el valor leído del búfer de destino durante el procesamiento del píxel B no siempre será el píxel A, a veces serán los valores claros.

Por lo tanto, sospecho que rechazar las lecturas del búfer de destino directo durante la etapa de fragmentos tiene mucho más que ver con evitar que el programador del sombreador se dispare en el pie al obtener resultados potencialmente no deterministas de esa lectura que de cualquier limitación técnica real para hacer que la etapa de mezcla sea completa. programable. Al mantener las operaciones de lectura estrictamente controladas (la prueba de profundidad, por ejemplo), la GPU garantiza que las operaciones realizadas con el valor de lectura tengan algún tipo de sentido.

Dicho esto, también puede estar sucediendo algo de costo / beneficio. Hacer que ese aspecto de la canalización de GPU sea programable complicaría un poco el diseño del chip, y la necesidad / demanda de lecturas del búfer de destino ha sido relativamente baja en comparación con otras características.


Solo para ampliar esto, la razón histórica por la cual el acceso al framebuffer ha sido lento es porque las instrucciones están muy canalizadas. Obtener acceso a un píxel de framebuffer dado implicaría detener la tubería actual hasta que todas las otras tuberías se vacíen para completar cualquier representación relevante para el píxel consultado. Incluso en el extraño caso de una GPU completamente no paralela, todavía estaría vaciando toda la tubería para cada consulta, lo cual es una mala idea. Sin duda, las cosas son un poco diferentes en el mundo del hardware programable ahora, pero espero que se aplique un principio similar.
Kylotan

4

Aunque molesto, permite a los fabricantes de hardware la flexibilidad de optimizar el proceso de renderizado de numerosas y transparentes formas.

Por ejemplo, el hardware PowerVR (ciertamente usado en el pasado, no usado uno durante mucho tiempo) espera hasta que se envíe toda la escena a renderizar, luego realiza una clasificación automática de profundidad usando el algoritmo de pintores y no necesita generar un tampón de profundidad. Dividiría la pantalla en mosaicos y renderizaría cada uno a su vez.


4

El sombreador de píxeles no puede leer los búferes de color y profundidad porque:

Los píxeles A y B pueden estar sombreados exactamente en el mismo momento en el hardware, aunque B finalmente se representa sobre el píxel A ("después").

Si lo hizo de modo que se garantice que el hardware sombree A antes que B, entonces partes del hardware se quedarían sin hacer nada mientras A está sombreado, y luego partes del hardware se quedarían sin hacer nada mientras B está sombreado.

En el peor de los casos imaginables, todos los píxeles que sombrea se superponen y los miles y miles de hilos de GPU, todos excepto uno, permanecen inactivos. Este hilo sombrea pacientemente el píxel A, luego B, luego C ...

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.