Digamos que quiero renderizar un cuadrado; su textura es "square.png".
¿Es más fácil para la computadora renderizarlo si la textura es solo un color normal?
¿Y qué pasa si es una textura muy ruidosa con colores completamente al azar aquí y allá?
¿O qué pasa si esa textura es ruidosa en el sentido de que cada píxel es diferente de uno a otro, pero solo un poquito?
Respuestas:
Como la mayoría de las cosas en el desarrollo de juegos, y especialmente en los gráficos de juegos, la respuesta es "depende"
La resolución de su textura puede tener un impacto en la velocidad de renderizado. Cuantos más píxeles contenga, más datos brutos hay para cargar en la GPU, y menor es la textura que podemos caber en la memoria caché a la vez, por lo que el sombreador puede encontrar más pausas mientras espera la parte correcta de la textura ser arrastrado al caché.
Usar mipmapping puede reducir el impacto de esto. Con mipmaps, almacenamos una cadena de versiones reducidas de la textura, que al principio suena como aún más memoria para esquivar. Pero nos permite leer de las versiones más pequeñas cuando la textura se muestra en un tamaño pequeño en la pantalla (como un objeto distante en perspectiva), por lo que nuestras muestras hacen un mejor uso del caché de textura, en lugar de saltar de un lado a otro. Esto también reduce el aliasing.
El contenido de sus texturas no tiene un impacto en la eficiencia de representación la mayor parte del tiempo.
Un color es solo un montón de números en lo que respecta a la GPU, por lo que no le importa mucho cuáles son esos números, simplemente los canaliza a través de sus matemáticas de la misma manera. No hace nada lujoso como recordar "Oh, he visto un píxel en este verde antes, simplemente reutilizaré la misma salida que calculé la última vez que vi esta entrada", así que si tu textura es de un solo color o destellos aleatorios, su GPU está haciendo el mismo trabajo.
A diferencia de los formatos como PNG y JPG, que se comprimen de manera más eficiente en áreas predecibles de la imagen y consumen más bits en regiones complejas, los formatos de textura de GPU como BTC, ETC, PVRTC o incluso RGBA sin procesar usan un número fijo de bits por bloque de píxeles Por lo tanto, hacer que su textura sea más o menos detallada y mantener el mismo formato de compresión no cambiará su tamaño de datos ni afectará la transferencia de datos y la eficiencia relacionada con la caché.
Pero, si usa un tipo particular de detalle que su compresión anterior no conserva bien, puede verse obligado a cambiar toda su imagen para usar un formato diferente, lo que podría cambiar nuevamente su tamaño de datos.
Este es el asterisco más grande en la situación: es posible que esté utilizando esta entrada de color de textura para tomar decisiones, como una if()rama. Aquí, los detalles son importantes para la velocidad.
Las unidades de sombreado de GPU funcionan en bloques de píxeles en lotes, ejecutando las mismas instrucciones en paralelo en múltiples flujos de datos. Entonces, cuando algunos píxeles en el bloque toman una rama de la ify otros píxeles toman la otra, todo el lote tiene que pasar por ambas ramas (enmascarando los resultados que no se aplican a un conjunto de píxeles u otro)
Si su entrada cambia de manera suave / predecible, es probable que tenga muchos bloques que solo necesitan tomar una sola rama, y estos casos de ambas ramas se limitarán a bandas estrechas alrededor del borde de transición. Pero si su entrada es aleatoria, esperamos que la mayoría de los bloques tomen ambas ramas y ralenticen el renderizado.
Esto también puede suceder si está utilizando una textura para controlar las búsquedas en una segunda textura, como una distorsión o un mapa de índice. Si la primera textura salta al azar, entonces tomaremos muestras de puntos dispersos y aleatorios de la segunda textura, haciendo un uso menos consistente de nuestro caché de texturas y esperando más tiempo para obtener los datos que necesitamos, en promedio.
Entonces, en general: no, el contenido de la textura no tiene mucho impacto en la velocidad de renderizado, excepto en los casos en que sí. ;)
npíxel th, tendría que pasar por cada píxel antes de él. Con un ancho constante de bytes de píxeles, es justo start_of_buffer + width * n, que es mucho más rápido, especialmente para grandes n.
Junto con la excelente respuesta anterior de DMGregory , hay, quizás, un caso en el que la complejidad de una "textura" puede afectar el rendimiento de representación y es donde los resultados de una representación anterior se utilizan como fuente en una posterior, por ejemplo, mapas de sombra / reflexiones / mapas ambientales.
Algunos hardware modernos pueden aplicar compresión sin pérdidas a estos búferes: por ejemplo, PowerVR tiene PVRIC , AMD, Delta Color Compression y ARM tiene algo similar. El objetivo de estas técnicas de compresión es reducir el ancho de banda general que, a su vez, puede mejorar el rendimiento del renderizado.
Cuanto más simples sean los datos, ya sea profundidad o color (entero o coma flotante), mejor funcionarán estos esquemas. Por supuesto, no sugeriría simplificar deliberadamente su salida de renderizado solo para que funcionen mejor, pero evitar el uso de datos ruidosos podría ayudar en algunas circunstancias.
Además, hacer un muestreo escaso de los buffers de trama / profundidad que usan estos esquemas, en un vano intento de reducir el ancho de banda, no ayudará porque es muy probable que estén basados en bloques.
Además, puede encontrar estas dos preguntas y respuestas de SE Computer Graphics interesantes: