Ashtyr escribió:wwwendigo escribió:Si hasta ahora no se ha extraido más paralelismo de juegos durante tantos años, lustros, de XBOX360/PS3, es porque no se puede o la mejora es mínima. Y no hay más, después están el "yo creo", "yo pienso" pero los hechos son hechos. Y comprar un FX por "los ports de las futuras consolas" es un disparate. Porque las consolas anteriores eran y son de hecho consolas tan o más multihilo que las nuevas.
Y lo repito, esto es un hecho.
Cierto ,
pero las consolas actuales son basicamente un PC casi al 100%, si ya tienes el juego para 6 /7 hilos para la consola de turno adaptarlo al PC te costara muy muy poco, y con
mantle ya directamente aunque no lo tengas hecho en consola.Dicho esto que se compre el que le permita meter mejor grafica, ya que cualquiera de esas CPU va sobrado
1.- El usar o no eficientemente X cores con programación multihilo es TOTALMENTE independiente de la arquitectura de la cpu, da igual si es x86 SPARC o PowerPC. Las técnicas de programación y lenguajes usados son los mismos entre plataformas, y sólo el tema del uso de los SPUs del CELL se puede tratar con cierto "cuidado diferencial". Aún así, en el port de cualquier "miniprograma" que corra en paralelo en un SPU para PS3, su traducción lógica es a un hilo independiente tanto para XBOX 360 como para PC.
Esto es, el argumento de "aunque no sea por cores, por similitud de arquitectura será más fácil explotar el multihilo en ports", no se sostiene. Insisto, XBOX 360 es básicamente una consola cuya programación es 100% idéntica que en un PC (dudo que se baje a ensamblador en la mayoría de proyectos, y si se baja, el portado de ensamblador entre plataformas tampoco es una cosa tan difícil), usa hasta APIs similares a Windows/x86, es más fácil portar entre PC y XBOX 360 que de cualquiera de estos dos a PS3.
Y la XBOX 360 maneja justo 6 hilos de forma concurrente, 3 cores físicos con 6 cores lógicos (SMT), su modelo de programación es justo el mismo que con las nuevas consolas (con 6 cores para la aplicación, y otros 2 cores reservados por el sistema).
Si no se ha usado a "plena carga" cpus de más de 4 cores hasta hoy en día, no es por las consolas anteriores, ni las actuales van a mejorar la situación. Será más fácil el portado de un programa (dudoso mirando a la XBOX 360), pero NO será facilitado el uso del multihilo, ya que esto es agnóstico de la plataforma hard.
2.- Segunda parte que recalco, eso es propaganda de AMD, y no tiene mucha base, que un API sea más o menos cercana al metal (gpu) no quiere decir en absoluto que se mejore el uso de un multicore en juegos.
Verás, la principal razón por la que Mantle en este punto es una farsa, es porque AMD ha intentado hacernos creer varios puntos como "verdades universales", problemas a los que se enfrentan los desarrolladores, los cuales no son ciertos, éstos son:
A.- "En PC con las APIs tradicionales NO se usan los sistemas multicores, y esto mete además de un límite del número de llamadas al API realizables, una ineficiencia en su funcionamiento (monohilo)". Esto sólo es una media verdad, primero porque no se aplica con OpenGL, donde desde hace tiempo existen mecanismos y extensiones para realizar llamadas en paralelo entre distintos cores, y segundo, porque ni siquiera es cierto con DirectX, donde existe un mecanismo llamado "Command list" por la cual se pueden realizar un grupo de llamadas al API en paralelo usando varios cores de la cpu (tantos como se desee o se pueda).
Esto es, hay una forma de "empaquetar" las llamadas a realizar para renderizar un frame (o parte de él), que curiosamente AMD "olvida" a la hora de hablar de este problema. Lo cierto es que esta capacidad de DX11 está muy infrautilizada por una razón:
SOPORTE PÉSIMO por parte de los fabricantes de gpus, y voy a señalar, qué coño, por culpa de AMD: Con AMD el uso de dicha característica da lugar, aunque sea compatible con ésta, a una bajada de rendimiento en vez de una subida. Sólo nvidia ha implementado correctamente "command list", y por tanto, los beneficios que pueda tener el uso de dicha capacidad no la vemos en aplicaciones... porque usarlo implica lastrar el rendimiento si tienes una gráfica AMD.
http://msdn.microsoft.com/en-us/library/windows/desktop/ff476342%28v=vs.85%29.aspxSobre el tema de OpenGL, ya es de cojón de mico que AMD suelte lo que dice, con su mal soporte crónico de las características más avanzadas (mismamente, sólo soporta OpenGL 4.3 e incluso no lo soporta demasiado bien, dado que los compute shaders de 4.3 van mucho más lentos en AMD que en nvidia, hablo de OpenGL, no de OpenCL).
B.- "Las cpus están saturadas con las llamadas al API y su sobrecarga, y por eso no pueden hacer otra cosa, Mantle las liberará". Otra falsedad. Primero si fuera cierto lo que dicen en el punto anterior, el API sólo crearía sobrecarga de uso en un único core y por tanto quedarían los demás cores al uso de la aplicación sin problema, por muy sobrecargada que estuviera el API.
Pero aún aceptando esa "liberación" como posible (puede bajarse realmente la sobrecarga de las llamadas al API y repartir mejor entre cores, eso puede ser cierto), lo que realmente SI es cierto es que los juegos actuales, en cuanto a cpu, realmente no se están limitando su rendimiento por las llamadas al API. En realidad se están haciendo mil historias más en un motor de un juego que nada tienen que ver con el API gráfico con el que finalmente se envie a renderizar las escenas del juego.
Pretender transmitir una premisa en la que el uso de la cpu, en juegos, sería igual a uso por el API gráfico, es un disparate. Pero es lo que tratan intentar destilar en su propaganda. Evidentemente se cuidan mucho de las afirmaciones rotundas, pero ya he visto cómo llevan a ese engaño.
Es como el tema todo que llevan con lo de las drawcalls como 1 drawcall mínima para cada objeto enviado a renderizar (o como mínimo evaluar si se renderiza) en un frame. Esto es mentira, y de hecho los ejemplos que ellos han puesto en funcionamiento son los típicos que se usarían para hacer demostraciones de técnicas que se usan en DX/OpenGL desde hace lustros, INSTANCING, una forma de conseguir "dibujar" varios objetos, iguales, similares pero distintos, o incluso muy diferentes entre sí, con una única llamada al API.
El tema de Mantle en cuanto a cpu presupone muchas cosas, una, que los programadores no saben hacer su trabajo a la hora de generar X objetos en pantalla (se debe optimizar con instanciado todo lo posible), y otra, que los juegos no hacen otra cosa que "pintar cosas en pantalla", sin otras tareas pesadas de cpu, que son las que realmente cargan de verdad a la cpu (temas como física, IA, etc).
Conclusión:
AMD nos quiere vender el invento de la rueda, más de 7000 años después de su invención. El tema de la explotación de un sistema multicore no es un problema de ahora, en los juegos, ni está ligado realmente ni a la plataforma x86 ni tampoco a las APIs gráficas, aunque esas últimas usaran mal la parte que les toca de un sistema multicore, el problema principal de un videojuego es dividir las tareas de trabajo en hilos y que estén bien balanceados estos hilos. Ése es el auténtico problema, y sólo se puede solucionar con programación muy depurada.
Pero 100% agnóstica de arquitecturas como x86 o del uso del API (repito, puede ayudar que el API use mejor sistemas multicore, pero esto nada tiene que ver con la programación de un juego y sus distintos subsistemas e hilos).
. ![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
