2012-06-14 14 views
25

¿Cuáles son las desventajas de usar siempre el algoritmo de 1?glPixelStorei (GL_UNPACK_ALIGNMENT, 1) ¿Desventajas?

glPixelStorei(GL_UNPACK_ALIGNMENT, 1) 
glPixelStorei(GL_PACK_ALIGNMENT, 1) 

¿Impactará el rendimiento en gpus moderno?

+0

¿Quiere decir, además del hecho de que algunos de sus datos pueden no tener filas alineadas de 1 byte? –

+0

Para texturas que no sean POTS, puede afectar la velocidad de carga/descarga. Para las texturas POTS no debería tener ningún efecto. –

+0

@DietrichEpp: ¿Qué es POTS-texturas? – ronag

Respuesta

39

¿Cómo pueden los datos no estar alineados en 1 byte?

Esto sugiere una gran falta de comprensión de lo que es row alignment in pixel transfer operations means.

Se espera que los datos de la imagen que pase a OpenGL se agrupen en filas. Cada fila contiene width número de píxeles, siendo cada píxel el tamaño definido por el formato y los parámetros de tipo. Por lo tanto, un formato de GL_RGB con un tipo de GL_UNSIGNED_BYTE dará como resultado un píxel de 24 bits de tamaño. De lo contrario, se espera que los píxeles estén empaquetados, por lo que una fila de 16 de estos píxeles ocupará 48 bytes.

Se espera que cada fila se alinee en un valor específico, como se define en GL_PACK/UNPACK_ALIGNMENT. Esto significa que el valor que agrega al puntero para llegar a la siguiente fila es: align(pixel_size * width, GL_*_ALIGNMENT). Si el tamaño del píxel es 3 bytes, el ancho es 2 y la alineación es 1, el tamaño del byte fila es 6. Si la alineación es 4, el tamaño del byte fila es ocho.

Ver el problema?

Los datos de las imágenes, que pueden provenir de algún formato de archivo de imagen cargado con algún cargador de imágenes, tienen una alineación de filas. Algunas veces esto está alineado con 1 byte, y algunas veces no es. Las imágenes DDS tienen una alineación especificada como parte del formato. En muchos casos, las imágenes tienen alineaciones de filas de 4 bytes; Los tamaños de píxel de menos de 32 bits tendrán, por lo tanto, relleno al final de las filas con ciertos anchos. Si la alineación que le da a OpenGL no coincide con eso, entonces obtendrá una textura malformada.

Establece la alineación para que coincida con la alineación del formato de imagen. Si sabe o puede asegurarse de que su alineación de filas siempre es 1 (y eso es poco probable a menos que haya escrito su propio formato de imagen o escritor DDS), debe configurar la alineación de filas para que sea exactamente lo que usa su formato de imagen.

+0

Sí, eso tiene sentido, no estaba pensando en términos de filas. Entonces, si puedo controlar los "bytes de líneas/filas" (que puedo, ya que tengo que copiar los datos a un PBO de todos modos), ¿qué alineamiento sería más óptimo? ¿Hay alguna mejora en el rendimiento con el uso de la alineación de 8 bytes? – ronag

+0

Si tengo datos GL_RGB, ¿debería convertirlos yo mismo a GL_RGBA mientras los copio en PBO? – ronag

+2

@ronag: es poco probable que supere el rendimiento del desempaquetador, y esa es una función notoriamente complicada de escribir utilizando SIMD. Suena como un montón de trabajo, que tendría que justificarse con los puntos de referencia que muestran que su aplicación está limitada por la velocidad de carga * y * que la velocidad de carga se ve afectada negativamente por el desempaquetador. –

9

¿Impactará el rendimiento en gpus moderno?

No, porque la configuración del almacenamiento de píxeles solo es relevante para la transferencia de datos desde o hacia la GPU, es decir, la alineación de sus datos. Una vez que está en la memoria de la GPU, se alinea de la manera que desee la GPU y el controlador.

+2

Creo que está preguntando si una o más GPU requerirían que las CPU modifiquen los datos antes de cargarlos. Es decir, si la GPU no puede manejar las filas alineadas por byte. –

+4

Pregunto si y cuándo podría afectar las cargas/descargas de gpu y si hay algún otro aspecto en el que deba pensar. – ronag

+2

@ronag: Bueno, si la GPU no puede tratar con el formato de datos de sus datos originales, primero el convertidor debe convertir el formato de datos. Sin embargo, dado que cargará datos de textura ocasionalmente en general, consumirá muy poco tiempo de CPU. Sin embargo, las transferencias de datos no son lo que consideraría un problema de rendimiento de la GPU. El cuello de botella es claramente la CPU y el bus de datos allí. – datenwolf