Dfx escribió:wwwendigo escribió:Menudo circo está montando AMD con Mantle, eso y la calidad DISTINTA que hay realmente en BF4 entre versiones Mantle y DX, que no son moco de pavo.
Me gustaria que de tener fuente ilustrases esta parte, ya que yo al menos no he tenido la oportunidad de ver ambas versiones aun.
El tema de StarWarm es fácil de comprobar por uno mismo, si ves las diapositivas y vídeos que hay de promoción de Mantle/Star Warm, verás que dicen literalmente que se necesita usar una o varias drawcalls por cada objeto que hay en el escenario. Sobre el instancing, técncica con distintas variantes y ya vieja, se pueden renderizar con una única llamada cientos de objetos:
http://en.wikipedia.org/wiki/Geometry_instancingPodrás comprobar, por las gpus soportadas, que la técnica es vieja, ahora mismo en sus últimas iteraciones es más potente que nunca.
Sobre comprobar alguna demo que tenga instancing, hay muchísimas, pero pongo aquí unas pocas:
http://www.geeks3d.com/20100210/opengl-3-2-geometry-instancing-culling-on-gpu-demo/http://www.humus.name/index.php?page=3D&ID=52http://developer.download.nvidia.com/SDK/10.5/direct3d/samples.htmlAquí puedes encontrar varias demos del uso de instancing, las mejores y más modernas, que no con las últimas técnicas, la de nvidia en el último link y sobre todo la demo skinned instancing, que es el más parecido a un juego real por complejidad de modelos usados y variedad de animaciones y variaciones de las instancias generadas (enanos).
Fuera de esto, tanto en esta demo como en la demo del primer link (la del anillo de asteroides), se puede tanto activar como desactivar el instancing, y comprobar cuántas instancias se pueden generar, cuántas llamadas al API hacen falta, y las mejoras de rendimiento provocados por esto.
El tema del trampeo de Star Warm más allá del cero uso de instancing (donde llegan a afirmar burradas, en alguna diapositiva, como que el instancing es "pobre" para sus usos), es que es fácilmente comprobable con el propio benchmark, en su versión DX11, y en modo de "vuelo libre" (sin activar la casilla de benchmark), que técnicas como el AA temporal multiplica entre 3x y 5x el número de drawcalls (en Star Warm las llamadas al API para enviar un modelo a renderizar aparece como un "batch", sinónimo en este caso a drawcall).
Si deshabilitas el AA temporal, verás reducido el número de drawcalls a la cuarta parte, más o menos. Si miras a una zona sin naves espaciales, verás que hay una relación directa entre número de estrellas vistas, aproximadamente, con drawcalls. También que el AA temporal multiplica en tan trivial detalle (fuera de las naves que sería en parte justificable) el número de drawcalls.
En serio, es fácilmente comprobable esto, es cuestión de verse los vídeos y diapositivas relacionadas con la promoción de dicho test, y leer algo sobre el uso de instancing para darse cuenta de dicha falacia argumental. Sobre los trucos tramposos de dicho bench, son también comprobables, si tras ver las demos que he enlazado sobre instancing, piensas que es estrictamente necesario usar miles de drawcalls para una escena (por frame, hasta decenas de miles) espacial como la de Star Warms... bueno, sinceramente no creo que pienses esto tras ver estas demos de instancing, si entiendes la técnica, y ves el bench tras esto. Y el tema del AA temporal y las estrellas, es muy cantoso, son efectos que multiplican enormemente el número de drawcalls para un beneficio más que cuestionable (sobre todo las estrellas).
Sobre BF4, yo mismo lo he comprobado con las capturas oficiales que colgó hace 2 días DICE en su blog sobre este tema, pero para que sea más fácilmente comprobable, un versus de áreas especialmente significativas:
Esta imagen se centra en varios detalles, pero el más significativo e importante es cómo se resuelve el antialiasing en ambas imágenes. La imagen de la izquierda es con DX11, la de la derecha con Mantle, la mira del arma en la izquierda tiene los bordes perfectamente suavizados, formando un círculo casi perfecto (existe una muesca en ambos casos en la mira). En el caso de Mantle, NO se ve que se aplique AA en la mira, o si se aplica, es netamente inferior al caso de DX11.
Otro caso:
Aquí el caso va al revés que antes, la vesión Mantle es la de la izquierda, la versión DX11 la de la derecha. Se puede comprobar que la zona del suelo justo a la izquierda del arma en el caso de Mantle tiene una falta de detalle impresionante frente a la versión DX11. El efecto blur podría justificar parte de esta falta de detalle, pero lo hay en ambas imágenes, y.... ¿tanto?
También aunque en menor medida, más difícil de apreciar, existe una mejor definición de los "palos" del barco que se hunde enfrente del jugador, los más lejanos son donde más se nota una mejor definición. Este detalle podría debatirse por diferencias en el efecto blur y tal, pero el tema de las texturas del suelo... la pérdida, insisto, es muy grande.
Por último, del blog de DICE este par de imágenes más:
Detalles a apreciar, DX11 imagen de arriba, Mantle imagen de abajo:
1.- La mancha de sangre en la roca donde te parapetas no aparece en la versión Mantle.
2.- Efecto masivo de "neblina-brillo" que no deja ver en absoluto bien el detalle en objetos lejanos.
3.- No es que haya sólo un nivel de brillo más alto, es que además hay una falta de contraste muy curiosa en la versión Mantle, y podría estar relacionado en parte con el sombreado que también se ve menos intenso.
4.- Detalle muy importante, la escena tiene lugar en un escenario donde se produce un huracán, y como es lógico, en la versión DX 11 se ve que todos los árboles están zarandeados por el viento. En la versión Mantle sin embargo los árboles lejanos NO. Están todos perfectamente rectos, excepto los árboles que están en primer plano. También parece haber una cierta diferencia en cómo se aplican los efectos de textura transparente, no necesariamente "peor" un efecto que otro, pero me da la impresión de que la técnica para resolver los frondes de las palmeras no son la misma en ambas imágenes.
Estas imágenes no está más manipuladas que en el recorte de las áreas a destacar, por mi parte, los originales se pueden encontrar en:
http://battlelog.battlefield.com/bf4/news/view/bf4-mantle-live/La entrada del blog que mantiene DICE sobre su port a Mantle.
Puedes encontrar más imágenes de usuarios donde se ven estos problemas, algunas muestras:
Problemas con "neblina brillante":
http://foro.noticias3d.com/vbulletin/showthread.php?t=418855&p=5069497&viewfull=1#post5069497Más:
http://foro.noticias3d.com/vbulletin/showthread.php?t=418855&p=5069286&viewfull=1#post5069286Además de neblina, hay una pérdida general de detalle fino y contraste, que no se sabe si es producido por la neblina brillante en sí, o si al revés, la neblina brillante sirve para "tapar" esas diferencias visuales. Pero que se ve distinto... creo que eso es obvio.
Nachoyazid escribió:Veo algo de eNvidia por tu parte wwwendigo jeje
Envidia ninguna, a día de hoy es un disparate meter un API gráfica propietaria porque sea como sea, hace más mal al mercado que bien. Cuando las alternativas abiertas (openGL) o "propietarias pero neutrales" (DX) son extensas y con gran base de aplicaciones.
Si estuviéramos hablando de una necesidad por carencia de APIs para dicha cuestión, como de hecho fue el caso del comienzo de las aceleradoras 3D, donde cada una tenía su propia API, o incluso el caso de PhysX, donde no hay nada parecido para físicas por gpu, sería distinto.
Pero que se saque un API propietaria y totalmente bloqueado (y lo digo yo, pero con pruebas, busca en la web DE AMD documentación sobre el API para descargar o un SDK para portar o crear un programa 3D en Mantle, ¿lo encuentras, no?, pues eso, los "beneficios" de usar un API que de abierta no tiene nada, hasta PhysX tiene documentación técnica y SDK y herramientas a punta pala disponibles para el desarrollador NO VINCULADO con nvidia, hoy en día para Mantle sólo puede desarrollar aquellos que han ido a besar el anillo del Papa AMD).
Dfx escribió:He estado haciendo pruebas con star swarm con DX11 se usan 8 hilos mas o menos en estos porcentajes de uso 95, 60, 25, 25, 25, 25, 25, 25 y en la version mantle se usan de esta manera 70 (con picos a 90 que corresponden con las caidas de frames) y el resto se mantiene entre 40~50%, obviamente el cuello de botella que habia en el caso de DX11 desaparece, pero me da la sensacion de que no esta demasiado bien optimizada la version de DX11 para el multi-hio, de ahi que la de mantle brille tanto, la de DX11 tiene caidas a menos de 10fps en mi configuracion en extreme, la de mantle muy pocas veces cae por debajo de los 20fps y nunca por debajo de los 15fps.
La de mantle va generalmente mejor y almenos en este test no se aprecian diferencias graficas, la lastima es no tener BF4 para hacer pruebas.
Lo que muestra Star Warm es justo cómo el API DirectX se satura a nivel de drawcalls al usar un único hilo para manejar el API, mientras que Mantle lo que hace es repartir estas llamadas a enviar a la gráfica via API entre varios hilos.
De ahí que haya una ocupación de casi el 100% en un core con DX11, que limita el número de frames mientras la gráfica se rasca la barriga (por lo menos en mi caso, literalmente), y en el caso de Mantle lo que hace es repartir la carga entre cores pudiendo procesar muchas más llamadas, cargando por tanto más la cpu, y subiendo al final el número de drawcalls y fps generados.
El problema de dicho test es que, mientras que sí es cierto que muestra una debilidad concreta de DX11 (su tendencia al uso de un único core en el uso del API y su mayor sobrecarga por llamada), no lo hace honestamente, por lo menos no cuando el desarrollador dice que lo que nos muestran es un caso "práctico", siendo como es el caso que no usan instancing, y deberían estar usándolo, y que tanto el tema de las estrellas como el tema del AA temporal están ahí, en el test, sólo para multiplicar exageradamente el número de drawcalls generadas (y habiendo alternativas perfectamente válidas de menos gasto de proceso tanto para AA como para hacer las estrellas en el entorno 3D).
Esto es, si especificaran que pretenden sólo mostrar un límite teórico y no una situación de uso práctico en un juego, tendría cabida. Pero como están afirmando que el diseño de dicho test es una fiel representación del uso de un motor de juego, es ahí donde discrepo, porque hay varios disparates técnicos en lo que están haciendo.
De todas formas, en casos así incluso DX es capaz de paralelizar llamadas al API, por lo menos en DX11, usando las "command lists" que permiten aglutinar un lote de llamadas para que se envíen en paralelo a la gráfica usando varios hilos contra el API. Esta técnica no se usa. Aunque esto es pecata minuta dado que la implementación de "command list" es aparentemente no trivial y funciona bastante mal, coincidencias de la vida, en el driver de AMD (sí, parece un chiste, pero la única vez donde he oído que esta técnica era útil, y no para tirar cohetes pero sí algo útil, era en el caso de usar una nvidia, pero entre dificultad de implementación y variabilidad de funcionamiento, no se usa).
Aún así, el mayor pecado de Star Warm es uno usar masivamente instancing, dado que podría resolver toda la escena consumiendo como mucho un centenar de drawcalls, digamos que dos centenares. En absoluto hacen falta para lo que nos muestran en este caso concreto gastar la barbaridad de llamadas (además que el tema de las estrellas es especialmente doloso).