Las librerías gráficas DirectX se actualizan cada cierto tiempo y, con ellas llegan una serie de mejoras en el rendimiento y la calidad gráfica de los títulos más punteros. Pero esta vez DirectX 12 no estará sola, ya que AMD ha creado su propia alternativa con Mantle, que asegura una mejor funcionalidad. ¿Qué ventajas tiene cada una? ¿Cómo se beneficiarán los PCs y las nuevas consolas de ello?
|
etiquetas: fukuy , futuro técnico y gráfico de los videojuegos , directx12 , api 
desinformación.
Luego para rematar, le echa la culpa del menor rendimiento de one respecto a play4 a las directx, cuando a una consola se la programa lo más a pelo posible, obviando directx y yendo al bajo nivel y sobre todo porque desde la mesa de diseño por componentes y demás ya se sabe que la play4 es más potente que la one (entre otras cosas porque el gran cuello de botella de las apus de amd es el ancho de banda de la memoria y ps4 tiene muchísimo más que one).
Xbox one contraataca la lentitud de la memoria poniendo una memoria intermedia ultrarápida que hace de caché (estrategia que se ha confirmado muy útil en otras consolas como gamecube, wii y xbox 360, y que se va a aplicar en futuras apus de amd para el mercado pc y servidores (eso si, con memorias más lentas y baratas, supongo que solo en el primer caso), pero la cantidad que han puesto no es suficiente para las necesidades de los programadores (también se quejaban de que era insuficiente en el caso de la 360, ojo, pero en aquel entonces la contienda era más pareja porque la play4 tenía un cuello de botella parecido en el acceso a los coprocesadores que integraba cell).
Una vez visto que técnicamente realmente la ps4 si que es más potente (lo único donde la xbox tendría ventaja real es que el chip de audio está separado y no consumiría recursos cpu, mientras que la ps4 lo tiene unificado con el resto, pero incluso así la ps4 tendría ancho de banda más que suficiente para que meter el audio no afecte al rendimiento), te digo que efectivamente, la capacidad de procesamiento es tal que salvo que hagan chapuzas programando se podrá conseguir prácticamente lo mismo en cuanto a cantidad y calidad con ambas consolas, pero que siempre va a ir un poquito más suave en la play. La baza de xbox one… » ver todo el comentario
Ahora... ¿qué información errónea he dado sobre mantle? ¿por qué no me corriges?
¿y por qué mezclas churras con merinas? ahora mismo estás comparando amd con mantle con nvidia con procesadores intel sin venir a cuento solo para (no) explicar que las últimas versiones de otras apis ya disponen de optimizaciones similares y/o que otro hardware por potencia bruta es superior (y desde que salieron las apus, cualquier dedicada y cualquier procesador de gama media ya las superaban holgadamente, desde que se anunciaron las consolas de nueva generación ya se sabía que tendrían la potencia de un portátil por el hardware que iban a llevar, desde antes de que se anunciara mantle ya existía un debate en la comunidad opengl sobre el overhead que llevaba la api encima y lo ineficiente que podía llegar a ser en algunos casos). ¿No es más justo, fácil y COMPARABLE algo así como amd con mantle vs sin mantle? (porque no podemos comparar nvidia sin mantle vs nvidia con mantle o un ganancias de nvidia con mantle vs ganancias de amd con mantle)
Todo esto es para decirte que si, que la gran mayoría de los programadores no usan hard a pelo por la sencilla razón de que usan middlewares que ya les solucionan la papeleta, ni siquiera tiran de apis, usan frameworks ya hechos y dedican sus esfuerzos al scriptado y programación de otras cosas mientras le dejan el trabajo de diseñar shaders, texturas y escenarios a diseñadores. Pero los que realmente trabajan en motores propios de algo de nivel si que lo hacen, por mucho que a ti te parezca una burrada, lo mismo con los ingenieros de gráficos que luego optimizan los shaders y descubren y liman los cuellos de botella existentes y demás.
Y si, tanto el HSLS como el GLSL (GL Shading Language, la contrapartida de openGL) son en realidad los compiladores que traducen ese lenguaje a código GPU genérico (cada versión de los shaders tienen sus peculiaridades, pero todas las familias de tarjetas gráficas que las soportan comparten el mismo código compilado, con optimizaciones por familias o modelos, igual que las cpus van optimizadas por familias o modelos), y ese compilador va en los drivers de tus amadas tarjetas gráficas (¿no has leído nunca en ninguno de los juegos a los que juegas cuando cargan un nivel alguna frase similar a "compilando shaders"?). También existen compiladores alternativos, dado que hay otros lenguajes de shading por ahí. Nvidia presentó originalmente cg con sus geforce3, el primer lenguaje de definición de shaders antes de que surgieran los estándares para directX y openGL. Renderman tiene un lenguaje de shaders propio, así como Blender y otros programas de modelado, etc.
Te pongo un extracto de un texto interesante (lukasz.dk/playstation-2-programming/an-introduction-to-ps2dev/). Es sobre la play2, pero es extrapolable a hardware más reciente:
"A funny thing about PS2DEV is that there probably is more source code for undocumented parts than there is for documented parts of the PS2. There is an ongoing joke among the most passionate PS2DEV developers, which is “We only to tools™”. What this refers to is that we only make low level tools for developers and not high level libraries which are easy to use. Since the core of PS2DEV (PS2SDK) developers has been more interested in low level programming, there have not been many graphics libraries for the PS2. I think the reason for this is that anyone who sat down and read the GS and VU manuals, would be able to do it and therefor it is not an interesting challenge, just hard work.
The really hardcore PS2 developers would write custom graphics libraries which are specialized for every part of their application, to get the maximum performance out of the PS2, especially the VUs. Since the PS2 is so flexible it is very difficult to make a powerful graphics library which works well for everything."
y sobre la play3, que ya tiene una GPU más parecida a los estándares actuales y sacado del primer enlace:
"And in fact, many games don’t even use PSGL all that much, but use the lower-level LibGCM or go down to the bare metal themselves (the advantage of a console: hardware is fixed)."
Entiendo que sobre la play4, que está más diseñada para que sea fácil programar para ella, en el inicio de ciclo se apoyen en apis del fabricante todo lo posible, pero según vayan conociendo las tripas, las compañías más gordas que quieran exprimir el hardware (y las que fabrican engines o middlewares ya lo están haciendo) van a ir a pelo en aquellas cosas que requieran un desempeño crítico.
¿Tu has leído los enlaces que te he pasado en serio? ¿dónde pone todo eso? ¿dónde están tus enlaces que corrigen lo que yo he puesto para hacer esas afirmaciones? ¿te has parado a pensar que todos esos datos erróneos, desactualizados y mentiras populares provienen de gente de la scene, que ha programado a pelo esas consolas y que conocen mejor sus tripas que tu y de gente que ha usado los sdks oficiales y sabe de lo que habla?
Sobre lo del SO, todas las consolas actuales tienen un sistema operativo para gestionar los recursos, antes de manera muy básica, ahora con las capacidades multimedia, los dashboard y demás, de manera bastante más compleja. Las muy viejas pasaban con una simple BIOS, porque no necesitaban más. La api glide era única y exclusiva para hardware 3dfx, que salvo en algunas recreativas no se usó más allá del pc.
No, no lo son. Las características extra que tienen respecto al estándar no son las mismas que hay en la siguiente generación, entre otras cosas porque están adaptadas a las consolas y su contexto, mientras que las que lleven las tarjetas gráficas de la siguiente generación han sido pulidas y adaptadas a los pcs. Y se usan de manera diferente, así que las apis tienen que cambiar para reflejarlo. Y los drivers son muy diferentes porque:
a) el hardware de consola es diferente. No es lo mismo hacer drivers para una arquitectura Intel de 32 bits que para una de 64 bits, que para una arquitectura IBM. Y no es lo mismo hacer drivers para una ps4 que para una xbox one, por el simple hecho de que tienen una arquitectura de memoria diferente (y seguro que más cosas, dado que es sabido que ambas tienen procesadores de apoyo y memorias extra que son diferentes entre ambas y que harán que la forma de acceder a los recursos varíe un tanto), aunque el resto de componentes sea prácticamente igual.
>No sabes de qué estás hablando.
Pasas de darme enlaces, pero no me dices en qué cosas estoy equivocado y por qué, simplemente sueltas el argumento de yo soy mejor que tu y tengo más conocimientos, sin siquiera demostrarlo con argumentos. Dame cualquier indicación de softwares que evitaban tener que hacer chapuzas a mano. Y luego dime cómo lo escribieron, porque antes de una librería o un lenguaje, hay que crearlos. Y luego asegúrame categóricamente que nadie ha tocado una línea de ensamblador en ps3 ni en xbox360, pero dándome datos. Ah, por cierto, aunque me vas a decir que nadie lo usa deberías mirar eprint.iacr.org/2012/137.pdf y renderingpipeline.com/graphics-literature/low-level-gpu-documentation/ pa hacerte una idea de cómo funciona la cosa de verdad.
>Las consolas de generaciones anteriores no tenían ningún SO
Si que ha habido máquinas anteriores a la play2 con SO ¿alguien ha dicho Dreamcast? querían incluírlo en la máquina, pero al final no viene en la máquina en si, sino en los discos de los juegos y aplicaciones (muchos traían una versión de windows ce preparada para usar directx). La xbox original también tenía SO, basado en win2000 antes de que apareciera la wii. Otras consolas tienen firmwares que hacen las veces de BIOS (que como sabrás son las rutinas básicas que permiten interactuar con el hardware y que realizan… » ver todo el comentario
¿La gente investiga porque le sale del alma o porque luego aplican esa investigación en el desarrollo de productos?
Sobre Dreamcast y wince: www.segasaturno.com/portal/viewtopic.php?t=5724. Como ves, hay muchos juegos desarrollados sobre wince, y además del runtime tiene que haber alguien que gestione los recursos por debajo para que el runtime funcione (si, un wince optimizado para dreamcast). Que solo ejecute una tarea no quiere decir que debajo no haya un SO (mira si no los primeros iOS). BIOS es del género que me de la gana, si tu quieres que sea macho, pues chachi. BIOS es acrónimo de las rutinas básicas de entrada salida, como ves todo femenino.
La BIOS son pequeñas rutinas tipo: activa el chip este, aplica configuración, ponlo en modo de… » ver todo el comentario
Otro asunto: windows, linux y bsd tienen maneras completamente diferentes de acceder a los recursos de la máquina. Coge un driver linux e intenta hacerlo funcionar en bsd y verás que no puede. Y eso que son primos hermanos, y que bsd consigue soportar hardware gracias a que portan los mismos de linux. Ahora piensa en todas las diferencias arquitecturales que hay entre los drivers linux y los drivers windows. Compara los tamaños, pesos y dependencias entre drivers de linux y windows. Respóndeme por qué no están funcionales todas las funcionalidades que tienen los drivers de windows en linux si los drivers son iguales o comparten la mayor parte. Podríamos decir que hay un backend diferente por arquitectura y un frontend igual para todos, hasta ahí podría concedértelo, pero meter una capa de abstracción para aislar la arquitectura subyacente en algo tan delicado y que afecte al rendimiento tanto como unos drivers gráficos es bastante duro y arriesgado. Sería viable si windows y linux fueran más similares pero son demasiado disparejos: la gestión de memoria es diferente, la gestión energética es diferente, la gestión de los buses es diferente, la comunicación con… » ver todo el comentario
Muchos cambios que a ti te parecen triviales, porque te empeñas en señalar que las unidades de cómputo son iguales (y que por lo tanto el soporte vía drivers tengan una o dos más o menos es el mismo), y obvias aquello que las diferencia (y que las diferencia de otros sistemas no hUMA) que es la gestión de memoria).