Sobre el fsaa4x

Interesantisimo, muchas gracias.

Muy buena lectura, en cuanto termine de leerla opino.

muy interesante, gracias por el articulo.

ahora esta por ver que es lo que pasaran con los ports, no creo que las compañias se maten a reprogramar para 360 para que el juego lleve FSAA... esperemos aver que pasa.




ouuuu!!!

Muy interesante el artículo y clarificador (si todo es cierto claro).

Me quedo con esto:

ATI la calcula entre el 1 y el 5%. También hemos visto que esta penalización depende de un factor más o menos constante (el movimiento de los tiles no es exactamente constante porque Xenos tiene que acceder a memoria también para atender a la CPU, con lo que pueden afectarse) y otro más variable (el número de polígonos a reprocesar por tile). No hay que olvidar también que el desarrollador puede elegir trabajar con otros formatos, como con color en fp16, que dobla el espacio dedicado al back-buffer, y por tanto el número de tiles requeridos, aumentando el impacto en el rendimiento.

Según entiendo yo del 1 al 5 como mínimo no??

Pero vamos que la solución de ATI está muy bien ingeniada. Parece ser que no será tan fácil de aplicar si hacemos caso, que lo mejor vendrá con el tiempo (cosa lógica).

Un saludo

No es que sea dificil, lo que entiendo al leer el articulo es que en la 360 aplicar el fsaa x4 requiere un conocimiento de la maquina no es limitarse a activarlo hace falta implementar en el engine grafico del juego el uso "particular de la memoria embedida de la 360".
Lo cual si se hace correctamente no consume rendimiento (5%) gracias a las 10 megas de memoria embebida, tambien esplican que pueden parecer insuficiente para renderizar a 720p con fsaax4 pero con la tecnica de las tiles si es posbile, que buen truquito asi reducen coste y nos dan lo que queremos.

Bueno espero que los desarrolladores tambien sepan esto, y que los ports se los curren un poquito en el temeita de fsaax4

Saludos

Excelente el artículo.

Me quedo con esto:

Xenos incorpora numerosas medidas que ahora entran a funcionar para permitir este mecanismo. Pero como decíamos al principio, no es un simple parámetro que se activa y ya está, como en PC. Hay que tenerlo en cuenta en la creación del motor gráfico. Y con los títulos de salida siendo mayoritariamente ports de PC o de xbox1, donde no existe esta posibilidad, entendemos porqué no se ha aplicado, salvo en algún título exclusivo para 360. Y puede llevar cierto tiempo. Juegos como Gears Of War, tampoco están listos para este método. Por lo menos todavía no."

[...]

La solución, sobre el papel y según los datos suministrados por ATI, es correcta e ingeniosa. Pero requiere de ciertas medidas por parte del desarrollador en la creación de su motor gráfico. Medidas que en los títulos de salida, que como toda salida están luchando contra el reloj, no han sido aplicadas en la mayoría de los casos. Aunque no parece requerir de medidas de programación especialmente extrañas para los motores gráficos, especialmente viendo las últimas tendencias, conlleva cierto tiempo de adaptación. Es de esperar que muchos de los títulos que salgan durante el primer año de la consola no lleven ningún FSAA. Es incluso de esperar que algunos multiplataforma no lo hagan nunca, si consisten en ports rápidos que no entren en las características de cada consola.

Ahora entiendo el porqué apenas lo veremos en los títulos de primera generación. Ya me quedo más tranquilo


Saludos

si estoy metiendo la pata que alguien me corrija .... ( mientras voy buscando mas informacion )

sacado del articulo

articulo escribió: En nuestro caso:


Back-buffer = (1280x720) * (32 bits para el color + 32 bits para Z)
Back-buffer = (921.600) * (64 bits) = 7.372.800 bytes = 7.0 Mbytes.

Perfecto, entra perfectamente en los 10 MB. Pero si recordamos, con la aplicación del FSAA, el número de puntos sobre los que realizar las cuentas se multiplica tanto como el nivel de FSAA que aplicamos.
Así que a FSAA x2, tendremos más de 14 MB, y a FSAAx4, tendremos más de 28 MB.

Y tenemos sólo 10 MB de eDRAM.

a ver este hombre esta dando por hecho que se usa 4 veces la memoria para un FSAA 4x... de lo que deduzco que imagina que en lo que consiste el FSAA es renderizar una imagen de tamaño por cuatro y reescalarla .... ( atencion estoy especulando )

y para solucionar lo de que no quepa en la memoria segun su teoria se ha inventado lo de los tiles.... que si se divide la imagen en 3 trozos.... y los tiles no consisten en eso , lo de los tiles es otra cosa


realmente el antialising solo hace un renderizado de resolucion superior en las zonas en las que por asi decirlo hay un cambio brusco de color como puedan ser los bordes de un objeto , es decir en los rebordes de los objetos principalmente , para esto lo que hace es renderizar cuadraditos a mas resolucion que son los tiles ... que no trozear la imagen ...


a ver imaginaros en tonces como funcionan esos 10 mb... por un lado se ha renderizado como bien dice el fotograma y por otro lado se han renderizado una serie de cuadraditos a mayor resolucion que se usaran para combinar con ese fotograma y quitar las discontinuidades... con lo que al ser a una resolucion 4 veces superior la calidad de renderizado necesaria para esos cuadraditos se podria eliminar aproximadamente sin problema una frame con una zona de discontinuidad que ocupara un cuarto de la pantalla ...

esto podria significar que realmente falta un poco de memoria pero desde luego no por lo que dice el articulo

bueno he especulado sobre cosas que he leido pero vi a ir buscando mas informacion ....

Camtrack escribió:si estoy metiendo la pata que alguien me corrija .... ( mientras voy buscando mas informacion )

sacado del articulo



a ver este hombre esta dando por hecho que se usa 4 veces la memoria para un FSAA 4x... de lo que deduzco que imagina que en lo que consiste el FSAA es renderizar una imagen de tamaño por cuatro y reescalarla .... ( atencion estoy especulando )

y para solucionar lo de que no quepa en la memoria segun su teoria se ha inventado lo de los tiles.... que si se divide la imagen en 3 trozos.... y los tiles no consisten en eso , lo de los tiles es otra cosa


realmente el antialising solo hace un renderizado de resolucion superior en las zonas en las que por asi decirlo hay un cambio brusco de color como puedan ser los bordes de un objeto , es decir en los rebordes de los objetos principalmente , para esto lo que hace es renderizar cuadraditos a mas resolucion que son los tiles ... que no trozear la imagen ...


a ver imaginaros en tonces como funcionan esos 10 mb... por un lado se ha renderizado como bien dice el fotograma y por otro lado se han renderizado una serie de cuadraditos a mayor resolucion que se usaran para combinar con ese fotograma y quitar las discontinuidades... con lo que al ser a una resolucion 4 veces superior la calidad de renderizado necesaria para esos cuadraditos se podria eliminar aproximadamente sin problema una frame con una zona de discontinuidad que ocupara un cuarto de la pantalla ...

esto podria significar que realmente falta un poco de memoria pero desde luego no por lo que dice el articulo

bueno he especulado sobre cosas que he leido pero vi a ir buscando mas informacion ....

No se han inventado nada, es la info que existe, aqui mas datos (ya antiguos de Beyond3D):

Tiling mechanisms can operate in a number of ways. With immediate mode rendering (i.e. the pixels being rendered are for the same frame as the geometry being sent) it is never known what pixels the geometry is going to be mapped to when the commands begin processing. This is not known until all the vertex processing is complete, setup has occurred and each primitive is scan converted. So if you wanted to tile the screen with an immediate mode rendering system, the geometry may need to be processed, setup and then discarded if it is found not to relate to pixels that are to be rendered in the current buffer space. The net result here is that geometry needs to be recalculated multiple times for each of the buffers. Another method for tiling would be to use Tile Based Deferred Rendering which processes the geometry and "bins" it into graphics RAM, saving which render "tile" the geometry affects as it does so - these mechanisms have traditionally operated by deferring the actual rendering by a frame in order to parallelise the geometry processing / binning and the rendering (you may wish to take a refresher on PowerVR's tile based deferred rendering process in our article here).

http://www.beyond3d.com/articles/xenos/index.php?p=05#tiled

Al parecer, mucha de la info del articulo que postearon fue sacada de el articulo de Beyond3D, hasta la tabla de memoria requerida para cada resolucion y la formula para sacar la memoria necesaria...

lherre escribió:Muy interesante el artículo y clarificador (si todo es cierto claro).

Me quedo con esto:



Según entiendo yo del 1 al 5 como mínimo no??

Pero vamos que la solución de ATI está muy bien ingeniada. Parece ser que no será tan fácil de aplicar si hacemos caso, que lo mejor vendrá con el tiempo (cosa lógica).

Un saludo

Entre 1 y 5 quiere decir 1 como mínimo, 5 como máximo, vamos un intervalo del 1 al 5 .