Relacción FPS--Tamaño de texturas

[fiero]

                                Hola,
Yo no utilizo ninguna función de Directx ni de las aceleradoras, solo ensamblador, así que mi problema creo que se debe a los accesos a memoria. El problema es que guardo las texturas un un buffer de memoria, pero a la hora de renderizar, cuanto mayor es la textura más lenta es la renderización. Un ejemplo con una esfera:

Textura de 512x256:   43 FPS
Textura de 4064x2032: 31 FPS

La alineación de los buffers donde guardo las texturas no tiene que ver, tambien lo he probado.

Lo que me imagino es que los accesos a memoria ram serán más rápidos cuando las posiciones son más cercanas, y que si la textura es pequeña se la cargará el sistema en caché, si este es el problema no se me ocurre ninguna forma de arreglarlo, ley de vida :triste:

un saludo

[ Este Mensaje fue editado por: fiero el 2002-05-04 18:08 ]                                

[Ithaqua]

                                Es problema de cache, cuanto mas pequeña la textura, mas cache hits. Cuanto mas grande, mas cache misses.
¿Has implementado mip mapping por software? El mipmapping es una buena forma de solucionar tanto problemas de calidad de imagen, como acelerar el render por lo que te comenté antes.

                               

[fiero]

                                Entiendo..., entonces lo mejor va a ser meter las texturas más pequeñas como hacen las aceleradoras y ganar FPS con eso.

Es que lo de las texturas grandes era para poner panoramas, como el cielo por ejemplo, poniendo una gran semiesfera encima de la escena, con una textura grande de cielo. Así que tendré que partir la semiesfera en trocitos con texturas mas petites.

Lo del mipmaping no lo he implementado todavia, ya veremos en un futuro, con el filtro bilinear se ve bastante bien por ahora...

gracias y un saludo
                               

[Ithaqua]

                                Me refiero a mipmapping sin mas, usar un tamaño de textura dependiendo del tamaño del área que vayas a texturar. Luego puedes incluir el mipmapping dentro de la fórmula de filtrado, claro.

                               

[fiero]

                                si claro, con eso se aceleraria todo el render, ya que los objetos lejanos pillarian texturillas pequeñas. Lo que pasa es que en este caso, para renderizar un cielo, la semiesfera es siempre del mismo tamaño, no le afecta la posición de la cámara (el movimiento del  cielo es inapreciable), así que la única forma es partirlo en cachos, creo...

saludos                                

[Emotion]

                                Como el problema que yo veo es por la cache, y estas utilizando ensamblador porque no partes la textura a la hora de mandarla en trozos?

Has de utilizar (supongo que para este caso podria venir bien, aunque no me atrevo a firmarlo :sonriendo:) la regla de la cache: el nivel 2 de cache tiene 256K, pero el nivel 1, que es donde al final van los datos para ser procesados, solo tiene creo que eran 8 o 16K (segun el micro, creo que mi 486 tenia 8 y el pentium tiene o 16 o 32, no lo recuerdo ahora mismo)

Luego, en el bucle para gestionar la textura, podrias mandarla en trozos de 16/32K. De esa manera, no solo minimizas los cache miss, sino que consigues que la cache este siempre procesando de manera efectiva la textura.

En cuanto a lo que dice Ithaqua, si.. no lo habia pensado... muy buena :sonriendo:

En fin, prueba el metodo que mas te guste y ya me cuentas :sonriendo:
                               

[fiero]

                                Bueno, ya he hecho las pruebas. He dividido la esfera en 32 cachos y la textura empleada en sus respectivos 32 bmp.
Resultados renderizado de 1 esfera:

1 textura de 364 x 364 pixels, 62 FPS
1 textura de 2912 x 1456 pixels, 45 FPS
32 texturas de 364 x 364 pixels, 43 FPS

Los resultados que interesan son los dos de abajo, ya que lo que quiero es renderizar una esfera con una textura grande (de 2912x1456 por ejemplo). La conclusión que saco de todo esto es que da igual el tamaño de la textura empleado en este caso, ya que poner una grande no agiliza la caché y con texturas más pequeñas también se pierde la caché al ir cambiando de una a otra.

Estoy hablando en el caso de que se visualicen todos los texels de la textura. Otra cosa muy diferente es que se visualicen solamente un porcentaje pequeño de los texels, entonces vendria muy bien implementar mipmaping como dice Ithaqua. Pero en el caso de renderizar el cielo, en el que el objeto siempre es del mismo tamaño creo que no hay na que hacer....

Hola Emotion: Resulta que la textura de 2912x1456 ocupa 12 megas, partir eso en cuadraditos de 32k me parece inviable. Además segun el test, esto resultaria tremendamente pesado a nivel de cálculos, ya que el número de objetos aumentaria considerablemente. Fíjate que solo con aumentar de 1 a 32 objetos en el render ya me ha bajado 2 FPS.

saludos                                

[Emotion]

                                12 megas?? ufff... eso duele :sonriendo:

Bueno, la verdad es que con una textura tan grande puede que te convenga mas el metodo de Ithaqua... mi caso supongo que esta bien para texturas de hasta, digamos, 512x512 o algo asi :sonriendo:

En fin, siento que no te haya servido de mucho... mejor suerte la proxima vez :sonriendo:

Un Saludo
                               

[mallrat]

                                Aunque parezca una locura, porque no pruebas con texturas de 128x128 y 8 bpp? esas si cabrían en la caché de datos y quizá termines ganando en FPS aunque tengas que pintar muchísimos mas objetos. Yo usaba ese tamaño como máximo en los tiempos del mapeado de texturas por software, ya que de 256x256 se enlentecía mucho (sobre todo a medida que la ibas viendo "girada" 90 grados, al aumentar considerablemente el número de accesos a texels que no estaban en la caché).
                               

[fiero]

                                Es que necesito que sean fotos de 24 bits, y aunque las parta, como se ven todos los texels se pierde toda la caché de frame a frame, al pasar por todas las texturas...

Creo que es inevitable...

un saludo                                

[mallrat]

                                cierto, se pierde la textura de frame a frame... pero se consigue que mientras pintas un poligono con esa textura, todos sus texels esten en la cache. Piensa en que texels se van direccionando cada vez que pintas un pixel y como si estaría o no en la caché, verás que al ser una textura grande solo va bien si lees (0,0) (1,0) (2,0) etc o sea direcciones de memoria consecutivas, pero si lees (0,0) (0,1) (0,2).. etc hasta (0,1455) y luego (1,0) (1,1) (1,2) etc, entonces los 8 bytes que tenias en caché al leer (0,0) los has perdido. Sin embargo si es de 128x128 no los pierdes. Esto es si usas 8 bpp. Yo lo que hacia era que tenia un paleta de 256 entradas que convertía un byte de la textura en un color de 16 bits ya preparado para que se vea con el formato RGB de 16 bits (565 o 555) que tuviera la tarjeta, ya que usaba un framebuffer de 16 bits (de hecho usaba lo de la paleta para todo, de forma que cambiando entre distintas paletas tenia grafiquillos de distintos colores, efectos de oscurecimiento, etc y todo esto "casi" gratis, solo un acceso mas a memoria que afortunadamente se cacheaba muy bien al ser solamente 512 bytes). Si pese a todo usas 24 bpp, supongo que 64x64x3 sigue entrando en caché (aunque ya me parecen demasiado pequeñas las texturas, pero quiza siga mereciendo la pena)
venga a ver si algo de esto resulta es util
saludos