Con APIs como Vulkan y DX12, ¿tiene sentido seguir desarrollando "Close To Metal"?

Cerrado
M$ y Sony han dejado atrás la carrera por la potencia con PS4 y ONE, apostando por arquitecturas estándar y sencillas, en lugar de chips personalizados y extravagantes a los que se tarda muchos años en sacar todo el jugo.

Desde que salió Mantle nos llevan diciendo que con las nuevas APIs los ports entre consola y PC son muy sencillos de realizar, incluso M$ ha ido un paso más allá y con DX12 los juegos para ONE y PC compartirán gran parte del código del renderer.

Con Nintendo recién incorporada al grupo Khronos, se me ha venido una idea a la cabeza. ¿Y si se dejara de desarrollar para una plataforma de hardware, se añadiera una capa de abstracción sobre el hardware y se utilizasen APIs estándar y multiplataforma?

Imaginemos que NX y PS5 utilizan este modelo, y las 2 implementan Vulkan.

Pros:
- Reducción al mínimo el coste de porteo entre plataformas, pudiendo destinar más dinero al propio juego.
- Mayor avance tecnológico al poder contribuir más miembros a la evolución de las APIs y sus herramientas.
- Mayor avance tecnológico al poder investigar con hardware de PC más potente sabiendo que será fácilmente adaptable a las nuevas consolas a medio plazo.
- Retrocompatibilidad "out of the box" e incluso con la posibilidad de mejorar la resolución y framerate inmediatamente al pasar de una plataforma a la sucesora.
- Emular una plataforma sería más fácil que nunca.

Contras:
- Ligera penalización de rendimiento(principalmente de drawcalls) causada por esta fina capa de abstracción.

Microsoft parece que es el camino que busca gracias a DX12, Valve busca algo parecido pero a la inversa con Vulkan. Nintendo no sabemos que hace en Khronos todavía, pero si el dueño de Phoronix tiene firmado un NDA que no le permite hablar de ello dudo mucho que sea una nimiedad.
Te olvidas de lo dijo que Carmack:

"Consoles run 2x or so better than equal PC hardware, but it isn’t just API in the way, focus a single spec also matters"

https://twitter.com/id_aa_carmack/status/50277106856370176

O sea, que usando DX11 mismamente, si desarrollas algo SOLO para tu PC, pensando en la arquitectura de tu CPU y GPU, sacaras bastante mas rendimiento que si haces algo genérico.

Vamos, que el paradigma de las consolas hasta ahora era "Close To Metal" + "Single Specs"

Microsoft es el camino que busca con DX12, pero luego sus exclusivos de ONE los optimiza a saco, los Forza de ONE petarderian en un PC de la misma potencia.
El sentido del close to metal es sacar más del mismo hardware conforme pasan los años. No es una obligación, es una posibilidad que te da el tener hardware cerrado.

Vulkan y DX12 lo que hacen es intentar acercar el nivel de aprovechamiento del hardware cerrado a PCs con configuraciones abiertas.

De hecho, ahora mismo yo creo que muy pocos desarrolladores intentan siquiera llegar al close to metal.
cercata escribió:Te olvidas de lo dijo que Carmack:

"Consoles run 2x or so better than equal PC hardware, but it isn’t just API in the way, focus a single spec also matters"

https://twitter.com/id_aa_carmack/status/50277106856370176

O sea, que usando DX11 mismamente, si desarrollas algo SOLO para tu PC, pensando en la arquitectura de tu CPU y GPU, sacaras bastante mas rendimiento que si haces algo genérico.

Vamos, que el paradigma de las consolas hasta ahora era "Close To Metal" + "Single Specs"

Microsoft es el camino que busca con DX12, pero luego sus exclusivos de ONE los optimiza a saco, los Forza de ONE petarderian en un PC de la misma potencia.

Lo que dijo Carmack está muy bien, pero no es lo que hemos estado viendo durante los últimos 2 años. Seguramente lo dijera en un contexto distinto al que tenemos hoy en día.

Pero vamos, que esto no quiere decir que no puedan optimizar para una plataforma concreta, simplemente que al trabajar sobre un determinado nivel de abstracción que compartiría con el resto de plataformas y siendo un arquitectura estándar no habría una versión única y exclusiva para una consola, sino más bien una "configuración" gráfica específica, como pasa en PC.

Y lo de que los Forza de ONE petardearían en un PC de la misma potencia está por demostrar.
josemurcia escribió:Pero vamos, que esto no quiere decir que no puedan optimizar para una plataforma concreta, simplemente que al trabajar sobre un determinado nivel de abstracción que compartiría con el resto de plataformas y siendo un arquitectura estándar no habría una versión única y exclusiva para una consola, sino más bien una "configuración" gráfica específica, como pasa en PC.

Si claro, evidentemente ahora hacer una versión de consola sin que importe mucho el rendimiento es mas fácil, mucho mas que con la PS3, que parece que se llevo la palma en ese sentido.

Para mi el close to metal en consola ahora tiene sentido sólo como segundo API, es decir, desarrollas tu juego genérico, y luego optimizas para cada plataforma, y dentro de esta optimización puedes cambiar algunas cosas del API generico al API de bajo nivel.
Curioso cuando menos, ahora resulta que las consolas no se programan a bajo nivel.
Obviamente cuando se hablaba de el impacto de DX12 en solo una de las consolas todas se programaban a bajo nivel.

Creo que @naxeras sabe de lo que hablo, xq tanto él como yo hemos compartido siempre la misma opinión.

En ese sentido, a estás alturas y cuando ya son viejas nuevas, podéis ecuchar la entrevista que hizo a Brad Wardell Inner Cicle, por aquel entonces por supuesto se dijo que era un montón de tonterías sin fundamento de un patan bocachancla. Quzá a día de hoy os cueste menos digerirla xq habla de esto.
papatuelo escribió:Curioso cuando menos, ahora resulta que las consolas no se programan a bajo nivel.
Obviamente cuando se hablaba de el impacto de DX12 en solo una de las consolas todas se programaban a bajo nivel.

Creo que @naxeras sabe de lo que hablo, xq tanto él como yo hemos compartido siempre la misma opinión.

En ese sentido, a estás alturas y cuando ya son viejas nuevas, podéis ecuchar la entrevista que hizo a Brad Wardell Inner Cicle, por aquel entonces por supuesto se dijo que era un montón de tonterías sin fundamento de un patan bocachancla. Quzá a día de hoy os cueste menos digerirla xq habla de esto.


Lo que yo veo es que los post los entiendes como te da la gana,para luego ir de victima o acusar de tener doble rasero a los demas de manera disimulada,en serio tio,si posteas de esta manera es dificil que se te tome en serio,y me jode por que posteas informacion interesante.

Yo entiendo que el post es mas un deseo que una realidad,basicamente quiere que mejoren el rendimiento en los juegos de PC.

@josemurcia durante estos 2 años que hemos estado viendo que contradice lo dicho por Carmack?Como una 750Ti da mejor rendimiento en juegos que desde el principio se anunciaron para pc y luego empezaron las version next-gen y que encima salian para 5 plataformas?Pero si precisamente eso es todo lo contrario a lo que dice carmack,como te vas a centrar en unas specs concretas si haces una version para hard abierto y 4 para distintos tipos de hard cerrado.

Un saludo.
Sé lo que he dicho y por que lo he dicho.

De victimismo nada, más bien es diría lo contrario.
Moraydron escribió:@josemurcia durante estos 2 años que hemos estado viendo que contradice lo dicho por Carmack?Como una 750Ti da mejor rendimiento en juegos que desde el principio se anunciaron para pc y luego empezaron las version next-gen y que encima salian para 5 plataformas?Pero si precisamente eso es todo lo contrario a lo que dice carmack,como te vas a centrar en unas specs concretas si haces una version para hard abierto y 4 para distintos tipos de hard cerrado.

+1

Carmack lo que dice es el limite a donde se puede llegar, pero en estos 2 años en los juegos multis no se han molestado en llegar a ese limite.
cercata escribió:
Moraydron escribió:@josemurcia durante estos 2 años que hemos estado viendo que contradice lo dicho por Carmack?Como una 750Ti da mejor rendimiento en juegos que desde el principio se anunciaron para pc y luego empezaron las version next-gen y que encima salian para 5 plataformas?Pero si precisamente eso es todo lo contrario a lo que dice carmack,como te vas a centrar en unas specs concretas si haces una version para hard abierto y 4 para distintos tipos de hard cerrado.

+1

Carmack lo que dice es el limite a donde se puede llegar, pero en estos 2 años en los juegos multis no se han molestado en llegar a ese limite.

También es verdad que esa cita de carmack era de cuando las consolas tenían procesadores powerpc y alguna cosa rara. Ahora llevan cpu x64 y gráfica AMD estándar, así que son más apropiadas para hacer un porteo rápido sin matarse a optimizar.
David Ricardo escribió:También es verdad que esa cita de carmack era de cuando las consolas tenían procesadores powerpc y alguna cosa rara. Ahora llevan cpu x64 y gráfica AMD estándar, así que son más apropiadas para hacer un porteo rápido sin matarse a optimizar.

Para mi sigue siendo valida, por lo menos a los que CPU se refiere. Si se cuantos cores va a haber disponibles, y que tamaño de cache tiene cada uno, puedo organizar las tareas de forma mucho mas eficiente, y que haya muchos mas aciertos de cache. Y eso dispara el rendimiento ...

Respecto a GPU no conozco, pero supongo que pasará lo mismo
cercata escribió:
David Ricardo escribió:También es verdad que esa cita de carmack era de cuando las consolas tenían procesadores powerpc y alguna cosa rara. Ahora llevan cpu x64 y gráfica AMD estándar, así que son más apropiadas para hacer un porteo rápido sin matarse a optimizar.

Para mi sigue siendo valida, por lo menos a los que CPU se refiere. Si se cuantos cores va a haber disponibles, y que tamaño de cache tiene cada uno, puedo organizar las tareas de forma mucho mas eficiente, y que haya muchos mas aciertos de cache. Y eso dispara el rendimiento ...

Respecto a GPU no conozco, pero supongo que pasará lo mismo

Sigues pudiendo optimizar para una sola spec, pero antes no es que pudieses si no que casi estabas obligado a optimizar porque si no el juego iba a ir como el culo.
Si se estuviera programando a bajo nivel tendríais la mayoría de los juegos usando shader asincronos por poner un ejemplo.

Se programa en DX11 y se aprovecha lo que que se puede en cada plataforma afinando solo un poco en cada caso particular.

Sin más.

Por qué PS4 se pone como un avión con algunos juegos, vease el second son, xq realmente exprimen el hardware.

La introducción de las nuevas APIs va a facilitar que esos recursos puedan utilizarse de una manera más sencilla teniendo así un boost importante en consolas y PC.

Las consolas de esta gen se han visto muy frenadas por la necesidad de los desarrolladores multi de sacar sus videojuegos en PC.

Habrá quien se lleve las amnos a la cabeza y diga, como puedes decir eso si mi 980ti es mucho más potente que las consolas, pero no hablo de potencia, hablo de optimización en un hardware cerrado.
Yo estoy de acuerdo con @cercata en que efectivamente incluso la CPU de las consolas se puede optimizar, ya se puede ver en el paper de naughty dog como optimizan para la CPU en concreto, aprovechando la caché al maximo, y como esquivan instrucciones que son costosas por tener que leer de caches distintas, esto efectivamente en PC no se hace, por eso se debería necesitar más potencia para contrarrestar.

@papatuelo, estoy totalmente de acuerdo contigo que ahora mismo los multis no se están aprovechando del close to metal, solo hay que ver que un PC con similares caracteristicas a PS4 da mejores resultados, incluso con esa tarjeta que es de gama baja y no dispone de ventajas de las consolas como la memoria unificada.

¿Los exclusivos?, pues depende, pero es de suponer que se hace algo más.

En cuanto a si el PC lastra la consola, eso nunca, la potencia de las consolas son las que lastran el PC, si PS4 o ONE tuvieran una 970 ahora mismo estariamos viendo juegos mejores, pero que saquen una 980ti no va a cambiar que el sistema base siga siendo la consola.

¿Porque llevamos 2 años sin que se note? no por que es necesario el port a PC..., sino por el aumento de costes que conlleva cuando realmente no va a hacer que el juego venda más, y aun así poco a poco las consolas irán rindiendo mejor que un PC equivalente ya que las secuelas y demás es trabajo echo que se puede aprovechar ese tiempo extra para optimizar.

Si cuando acabe la generación la ultima hornada de juegos multi sigue rindiendo mejor en una 750ti que en consolas la verdad es que esta gen nos la han dado con queso.

Un Saludo.
naxeras escribió:Yo estoy de acuerdo con @cercata en que efectivamente incluso la CPU de las consolas se puede optimizar, ya se puede ver en el paper de naughty dog como optimizan para la CPU en concreto, aprovechando la caché al maximo, y como esquivan instrucciones que son costosas por tener que leer de caches distintas, esto efectivamente en PC no se hace, por eso se debería necesitar más potencia para contrarrestar.

@papatuelo, estoy totalmente de acuerdo contigo que ahora mismo los multis no se están aprovechando del close to metal, solo hay que ver que un PC con similares caracteristicas a PS4 da mejores resultados, incluso con esa tarjeta que es de gama baja y no dispone de ventajas de las consolas como la memoria unificada.

¿Los exclusivos?, pues depende, pero es de suponer que se hace algo más.

En cuanto a si el PC lastra la consola, eso nunca, la potencia de las consolas son las que lastran el PC, si PS4 o ONE tuvieran una 970 ahora mismo estariamos viendo juegos mejores, pero que saquen una 980ti no va a cambiar que el sistema base siga siendo la consola.

¿Porque llevamos 2 años sin que se note? no por que es necesario el port a PC..., sino por el aumento de costes que conlleva cuando realmente no va a hacer que el juego venda más, y aun así poco a poco las consolas irán rindiendo mejor que un PC equivalente ya que las secuelas y demás es trabajo echo que se puede aprovechar ese tiempo extra para optimizar.

Si cuando acabe la generación la ultima hornada de juegos multi sigue rindiendo mejor en una 750ti que en consolas la verdad es que esta gen nos la han dado con queso.

Un Saludo.


Ps4 ha demostrado que puede usar los shader asincronos desde el día 1, xq no se han usado???

Porque no interesaban para el desarrollo de multis que iban a salir bajo DX11.

Asi que en cierto modo si se han lastrado las consolas.
naxeras escribió:Si cuando acabe la generación la ultima hornada de juegos multi sigue rindiendo mejor en una 750ti que en consolas la verdad es que esta gen nos la han dado con queso.

Cuando empiecen a hacer los juegos en DX12 y Vulkan con Async compute, la 750ti va a hacer chof, porque las gráficas Nvidia actuales no valen para eso. Entonces habrá otra gráfica de 4 duros pero de AMD que le dé pal pelo a las consolas.
papatuelo escribió:Ps4 ha demostrado que puede usar los shader asincronos desde el día 1, xq no se han usado???

Porque no interesaban para el desarrollo de multis que iban a salir bajo DX11.

Asi que en cierto modo si se han lastrado las consolas.


Pues esa no es la conclusión a la que yo llego viendo el rendimiento de la famosa demo de Brad Wardell bajo DX12 con shaders asincronos.

El juego funciona igual con ellos que sin ellos DX11, es verdad que rinde mejor con ellos, ok, pero si ellos funciona igual, es decir suponiendo un sistema optimizado pasariamos a la famosa 750ti en PC, y no creo que en consola se dejara de usar porque haya que subir los requisitos en PC.eto

Si no se han usado más es por tema de costes y san se acabó.

El port del Batman Arkam knight porque va mal en PC? (aparte porque los de iron galaxy tienen el talento que tienen y los recursos que les dieron), exacto, la técnica de streaming utilizada bebe de la memoria unificada, rediseñar eso lleva tiempo y talento ya que leer y escribir copiando memoria (como hizo iron) tiene una penalizacion de rendimiento... ¿Acaso roksteady dejo de aprovechar la memoria unificada porque sabia que complica el port a pc? pues no. Su unico error es no dedicar mas recursos al port y ahi es donde queria llegar.

El poco uso del close to metal o tecnicas especificas es debido unica y exclusivamente al COSTE.

Un Saludo.
naxeras escribió:
papatuelo escribió:Ps4 ha demostrado que puede usar los shader asincronos desde el día 1, xq no se han usado???

Porque no interesaban para el desarrollo de multis que iban a salir bajo DX11.

Asi que en cierto modo si se han lastrado las consolas.


Pues esa no es la conclusión a la que yo llego viendo el rendimiento de la famosa demo de Brad Wardell bajo DX12 con shaders asincronos.

El juego funciona igual con ellos que sin ellos DX11, es verdad que rinde mejor con ellos, ok, pero si ellos funciona igual, es decir suponiendo un sistema optimizado pasariamos a la famosa 750ti en PC, y no creo que en consola se dejara de usar porque haya que subir los requisitos en PC.eto

Si no se han usado más es por tema de costes y san se acabó.

El port del Batman Arkam knight porque va mal en PC? (aparte porque los de iron galaxy tienen el talento que tienen y los recursos que les dieron), exacto, la técnica de streaming utilizada bebe de la memoria unificada, rediseñar eso lleva tiempo y talento ya que leer y escribir copiando memoria (como hizo iron) tiene una penalizacion de rendimiento... ¿Acaso roksteady dejo de aprovechar la memoria unificada porque sabia que complica el port a pc? pues no. Su unico error es no dedicar mas recursos al port y ahi es donde queria llegar.

El poco uso del close to metal o tecnicas especificas es debido unica y exclusivamente al COSTE.

Un Saludo.


Los shader asincronos no se ha usado más porque había que hacerlo con GMN en PS4 y eso suponía hacer dos versiones totalmente diferentes, la versión DX11 y la GMN.
Por eso en second son sí se hizo.
El problema han sido los costes de desarrollo, claro, no se pueden permitir hacer versiones completamente diferentes.

Donde has visto tu el uso de shader asincronos en DX11???

Estás tu seguro de que has visto ese???

Te lo digo en serio, xq si es verdad quiero verlo.
En mi humilde opinión, la "magia" de las consolas no se basa únicamente en el tipo de arquitectura, sino en la programación a bajo nivel y las single specs.

Cualquier capa de abstracción, al utilizar una API genérica para toda una gama de productos de hardware, conlleva un desperdicio de rendimiento. Suponiendo que programemos para una API que abarque, qué se yo, los 10 modelos más populares de tarjeta gráfica, nunca vas a aprovechar al máximo el rendimiento de ninguna de ellas, a no ser que la API tuviera información exacta de cada modelo, el resto de equipo sobre el que está montado, etc., lo cual al fin y al cabo sería lo mismo que trabajar con el software por separado. Solo que el trabajo extra iría a la API para que pudiera "comunicarse bien" con todo ese hardware compatible.

Yo pienso que si los juegos de consola rinden bien con el hardware que llevan es porque están programados para una determinada gráfica, en conjunto con un determinado procesador, con una determinada memoria, montado sobre una determinada placa base con unos determinados medios de comunicación. Algo que debido a las infinitas combinaciones posibles no se hace en otras plataformas y que, de extenderse la API en todos los sistemas, sería una desventaja enorme, ya que las consolas serían tratadas como una configuración más posible de PC en lugar de como un hardware cerrado y único (al fin y al cabo, el ser tratado como único y centrarse en él de forma exclusiva, es la única ventaja de un hardware cerrado).

Habría que ver hasta qué punto se desaprovechaba potencia, pero estoy convencido de que, por ejemplo, un juego desarrollado directamente para DX12 de forma genérica rinde peor en One que un juego desarrollado para su gráfica, su procesador, etc.
papatuelo escribió:Donde has visto tu el uso de shader asincronos en DX11???


No, no, no se usan, yo no he dicho semejante burrada.

Lo que he dicho es que el juego funciona igual en DX11 que en DX12, es decir es igual, mismos efectos enemigos y demás.

En DX12 al aprovecharlo pues rinde mejor, esta claro, pero repito lo que he comentado, a ningún estudio le temblaria la mano para subir los requisitos, no veo que el PC lo lastre para nada.

Si Second Son se pasara a PC pues subirian los requisitos, pero el port es posible y no creo que los costes sean tan grandes de usarlos o no usarlos cuando un estudio pequeño con el de Brad tiene 2 versiones de la demo funcionando.

Un Saludo.
David Ricardo escribió:Cuando empiecen a hacer los juegos en DX12 y Vulkan con Async compute, la 750ti va a hacer chof, porque las gráficas Nvidia actuales no valen para eso. Entonces habrá otra gráfica de 4 duros pero de AMD que le dé pal pelo a las consolas.


Yo prefiero no adelantar acontecimientos y ser cauto.

Lo que tengo claro es que esta generación el modelo de negocio ha cambiado (lo que yo llamo el efecto Wii).

Antes te vendian un hard muy superior a precio mucho menor que el de coste, esto se compensaba con el dinero que gana Sony y MS por licencia de publicación de cada juego, por no hablar del online que se cobraba en el caso de MS.

Hoy en día te veden un hardware con precio igual o superior al de coste (el hard de la casa no es el PVP de un PC similar) y los juegos siguen estando igual de caros que siempre y te cobran el online tranquilamente.

El usuario ha perdido, y es lo malo de esta gen, solo espero que el efecto WiiU y el efecto XBOXONE hagan que la próxima generación sea similar a lo que vivimos con XBOX360.

Un Saludo.
naxeras escribió:
papatuelo escribió:Donde has visto tu el uso de shader asincronos en DX11???


No, no, no se usan, yo no he dicho semejante burrada.

Lo que he dicho es que el juego funciona igual en DX11 que en DX12, es decir es igual, mismos efectos enemigos y demás.

En DX12 al aprovecharlo pues rinde mejor, esta claro, pero repito lo que he comentado, a ningún estudio le temblaria la mano para subir los requisitos, no veo que el PC lo lastre para nada.

Si Second Son se pasara a PC pues subirian los requisitos, pero el port es posible y no creo que los costes sean tan grandes de usarlos o no usarlos cuando un estudio pequeño con el de Brad tiene 2 versiones de la demo funcionando.

Un Saludo.
David Ricardo escribió:Cuando empiecen a hacer los juegos en DX12 y Vulkan con Async compute, la 750ti va a hacer chof, porque las gráficas Nvidia actuales no valen para eso. Entonces habrá otra gráfica de 4 duros pero de AMD que le dé pal pelo a las consolas.


Yo prefiero no adelantar acontecimientos y ser cauto.

Lo que tengo claro es que esta generación el modelo de negocio ha cambiado (lo que yo llamo el efecto Wii).

Antes te vendian un hard muy superior a precio mucho menor que el de coste, esto se compensaba con el dinero que gana Sony y MS por licencia de publicación de cada juego, por no hablar del online que se cobraba en el caso de MS.

Hoy en día te veden un hardware con precio igual o superior al de coste (el hard de la casa no es el PVP de un PC similar) y los juegos siguen estando igual de caros que siempre y te cobran el online tranquilamente.

El usuario ha perdido, y es lo malo de esta gen, solo espero que el efecto WiiU y el efecto XBOXONE hagan que la próxima generación sea similar a lo que vivimos con XBOX360.

Un Saludo.


No me entiendes, xq estás diciendo que en PC por fuerza bruta se puede hacer cualquier cosa. Pues claro, eso ya lo dije yo.

A lo que yo me refiero es que hay ciertas cosas como shader asincronos que no se han estado usando en consolas por no tener equivalente en PC, hasta ahora claro.

En ningún caso he querido decir que en consolas se puedan conseguir resultados imposibles de conseguir en PC.
papatuelo escribió:Ps4 ha demostrado que puede usar los shader asincronos desde el día 1, xq no se han usado???

Porque no interesaban para el desarrollo de multis que iban a salir bajo DX11.

Asi que en cierto modo si se han lastrado las consolas.

+1, no en todos, pero en la mayoría de multis pasa eso.

Ya lo vaticinó Cerny, estaría él al corriente del desarrollo de DX12 y por eso lo dijo ?

Y también +1 con lo que dice @naxeras de la memoria unificada, aunque no veo pq eso no esta lastrando a las consolas.
Los shaders asíncronos se pueden utilizar desde hace 2 años en PC con Mantle, y no es que la situación vaya a cambiar mucho con DX12 y Vulkan, ya que en gráficas NVIDIA parece que no suponen ningún beneficio por su arquitectura.
En consolas lo veo viable, pero queda el lastre del PC. ¿Por qué?, sencillo, las consolas parece que han tirado a resultados similares usando soluciones distintas, pero todas van con:
- Memoria unificada.
- Async shaders.
- HSA.
Puede que me deje alguna otra cosa.

Con lo cual puedes centrarte en aprovechar todo lo que tienen en común, aunque luego internamente se hagan de forma diferente, supuestamente la API de cada máquina te lo abstrae.

Sabiendo lo que tienes, es mucho más sencillo. Imaginemos, por decir algo aleatorio, que la NX viene con 4GB y deja 3GB para juegos, pero que en todo lo demás es como las otras en versión algo menor. Fácil, usas el mismo código y reduces los assets para que entren y listo.

Vamos ahora al PC, ¿cuanta memoria tienes?, ¿y VRAM?, porque mientras use VRAM vale pero como me pase..., ¿puedo usar async shaders?, porque quien tenga una Nvidia se va a comer los mocos, ¿tienes HSA?, porque sólo las APU AMD lo llevan...

Precisamente de eso están siendo lastradas las consolas, al programarse los juegos en PC se hace de forma genérica pero para PC, y en consola al final es como si fueran PCs con Intel + Nvidia, o mejor dicho, como un PC con APU AMD al cual le eliminamos los cuellos de botella de los buses de esta arquitectura (imagina un PC con tecnología de buses propia sin los inconvenientes de la arquitectura PC). Lo que deja clara desventaja y les lastra.

Por cierto, DX12 e imagino que Vulkan son "close to the metal". Así que realmente no es que tenga sentido seguir, es que es como se hará quien quiera evolucionar.
josemurcia escribió:Los shaders asíncronos se pueden utilizar desde hace 2 años en PC con Mantle, y no es que la situación vaya a cambiar mucho con DX12 y Vulkan, ya que en gráficas NVIDIA parece que no suponen ningún beneficio por su arquitectura.


Es que presisamente era con Mantle (ni idea si tiene el mismo modo de operar el Shader). El cambio de verdad viene a que sera DX12 y muy probablemente Vulkan las que lo estandarizen (npi como escribir esta ultima palabra [+risas] ).

La cuota de mercado ue ocupaba mantle es de risa comparada con la futura version del DX.
josemurcia escribió:Los shaders asíncronos se pueden utilizar desde hace 2 años en PC con Mantle, y no es que la situación vaya a cambiar mucho con DX12 y Vulkan, ya que en gráficas NVIDIA parece que no suponen ningún beneficio por su arquitectura.


Por esa regla de tres, ¿para que van a saltar a Vulkan o DX12 si el rendimiento que saca Nvidia es el mismo que en DX11?
elneocs escribió:
josemurcia escribió:Los shaders asíncronos se pueden utilizar desde hace 2 años en PC con Mantle, y no es que la situación vaya a cambiar mucho con DX12 y Vulkan, ya que en gráficas NVIDIA parece que no suponen ningún beneficio por su arquitectura.


Es que presisamente era con Mantle (ni idea si tiene el mismo modo de operar el Shader). El cambio de verdad viene a que sera DX12 y muy probablemente Vulkan las que lo estandarizen (npi como escribir esta ultima palabra [+risas] ).

La cuota de mercado ue ocupaba mantle es de risa comparada con la futura version del DX.

La cuota de mercado en los que merece usar async compute es la misma con Mantle que con DX12 y con Vulkan.

papatuelo escribió:
josemurcia escribió:Los shaders asíncronos se pueden utilizar desde hace 2 años en PC con Mantle, y no es que la situación vaya a cambiar mucho con DX12 y Vulkan, ya que en gráficas NVIDIA parece que no suponen ningún beneficio por su arquitectura.


Por esa regla de tres, ¿para que van a saltar a Vulkan o DX12 si el rendimiento que saca Nvidia es el mismo que en DX11?

¿Quién ha dicho que el rendimiento en NVIDIA es el mismo? Es el mismo en el único benchmark real que hay, eso no es representativo de lo que se podrá hacer.
josemurcia escribió:
elneocs escribió:
josemurcia escribió:Los shaders asíncronos se pueden utilizar desde hace 2 años en PC con Mantle, y no es que la situación vaya a cambiar mucho con DX12 y Vulkan, ya que en gráficas NVIDIA parece que no suponen ningún beneficio por su arquitectura.


Es que presisamente era con Mantle (ni idea si tiene el mismo modo de operar el Shader). El cambio de verdad viene a que sera DX12 y muy probablemente Vulkan las que lo estandarizen (npi como escribir esta ultima palabra [+risas] ).

La cuota de mercado ue ocupaba mantle es de risa comparada con la futura version del DX.

La cuota de mercado en los que merece usar async compute es la misma con Mantle que con DX12 y con Vulkan.


Ahi ya tenemos que sacar la bola de cristal [+risas] Pero ciertamente podemos tener entre manos un caso parecido al revolucionario TressFX PANTENE APROVED, aunque a diferencia de este seran los devs quienes decidiran usarlo o no.
josemurcia escribió:
elneocs escribió:
josemurcia escribió:Los shaders asíncronos se pueden utilizar desde hace 2 años en PC con Mantle, y no es que la situación vaya a cambiar mucho con DX12 y Vulkan, ya que en gráficas NVIDIA parece que no suponen ningún beneficio por su arquitectura.


Es que presisamente era con Mantle (ni idea si tiene el mismo modo de operar el Shader). El cambio de verdad viene a que sera DX12 y muy probablemente Vulkan las que lo estandarizen (npi como escribir esta ultima palabra [+risas] ).

La cuota de mercado ue ocupaba mantle es de risa comparada con la futura version del DX.

La cuota de mercado en los que merece usar async compute es la misma con Mantle que con DX12 y con Vulkan.

papatuelo escribió:
josemurcia escribió:Los shaders asíncronos se pueden utilizar desde hace 2 años en PC con Mantle, y no es que la situación vaya a cambiar mucho con DX12 y Vulkan, ya que en gráficas NVIDIA parece que no suponen ningún beneficio por su arquitectura.


Por esa regla de tres, ¿para que van a saltar a Vulkan o DX12 si el rendimiento que saca Nvidia es el mismo que en DX11?

¿Quién ha dicho que el rendimiento en NVIDIA es el mismo? Es el mismo en el único benchmark real que hay, eso no es representativo de lo que se podrá hacer.


Por esa regla de tres, quién ha dicho que el rendimiento de Nvidia con Shader asincronos es malo... Eso también sale del único benchmark real que hay, eso no es representativo de lo que puede hacer.

Eres muy dado a contradecirte tu solo.
papatuelo escribió:Por esa regla de tres, quién ha dicho que el rendimiento de Nvidia con Shader asincronos es malo... Eso también sale del único benchmark real que hay, eso no es representativo de lo que puede hacer.

Eres muy dado a contradecirte tu solo.

El rendimiento de NVIDIA con los shaders asíncronos tiene una explicación detrás y está documentado, no mezcles churras con merinas.
josemurcia escribió:
papatuelo escribió:Por esa regla de tres, quién ha dicho que el rendimiento de Nvidia con Shader asincronos es malo... Eso también sale del único benchmark real que hay, eso no es representativo de lo que puede hacer.

Eres muy dado a contradecirte tu solo.

El rendimiento de NVIDIA con los shaders asíncronos tiene una explicación detrás y está documentado, no mezcles churras con merinas.


En serio, ¿serías tan amable de enlazarme a esa explicación?

No será la de Kollock, ¿no?
papatuelo escribió:En serio, ¿serías tan amable de enlazarme a esa explicación?

No será la de Kollock, ¿no?

En este hilo tienes mucha información al respecto:
https://forum.beyond3d.com/threads/dx12 ... ute.57188/

Como resumen:
TL;DR
AMDs and Nvidias architectures are fundamentally different when it comes to command handling.

What do they have in common?
Both AMD and Nvidia are supporting concurrent execution of compute shaders in addition to workload from the graphics queue at least since Ferm/GCN 1.0.

All architectures from Nvidia have a "Work Distributor" unit for this purpose, which can handle a number of concurrent (outgoing) command streams. The level of concurrency varies between 6 and 32 command streams, depending on the specific chip.

With AMD, the actual distribution is handled by the ACE (Asynchronous Compute Engine) units. Each ACE unit can handle 64 command streams, the HWS (Hardware Scheduler) can even handle up to 128 command streams each.

Where do they differ?
Since GCN 1.0, AMDs cards had dedicated command queues for compute and graphics commands. Both the GCP (Graphics Command Processor) and the ACE can communicate to handle global barriers and to synchronize queues. This feature is present on every single GCN card. All compute queues exposed by the driver are mapped 1:1 onto hardware queues and can be executed asynchronously, that means without any hardwired order, excluding explicit synchronization points.

With Nvidia, newer cards (GK110, GK208, GMXXX) have a (probably programmable) "Grid Management Unit" in front of the "Work Distributor" which can aggregate commands from multiple queues, including dynamic scheduling and alike, prior to dispatching the workload onto the "Work Distributor".

The "Work Distributor" can only handle a single source of commands, and therefore requires that all queues are mangled into a single queue first, either by the "Grid Management Unit" or by the driver.

This "Grid Management Unit" is currently used to provide a feature called "Hyper-Q" in addition to handling the primary command queue. This feature is similar to the compute queues handled by the ACEs in AMD GPUs in that it can handle a number of truly asynchronous queues, but it lacks certain features such as the support for synchronization points.

What is the result?
So the current state with Nvidia hardware is that all queues used in DX12 are mangled into a single into a single queue in software, whereby the driver has to be rather smart at interleaving commands to maximize the occupation of the "Work Distributor". Ultimately this means that concurrent shaders can finish out of order and new compute shaders can fill the gaps, but execution can only start in the order originally decided by the driver.

Overloading the queues or complex dependency graphs can cause a quite significant CPU load with Nvidia hardware, up to the point where the use of Async shaders even decreases utilization.

AMDs hardware is working as expected, all compute queues are executed fully independently, except for explicit synchronization points.

https://forum.beyond3d.com/posts/1872750/
josemurcia escribió:
papatuelo escribió:En serio, ¿serías tan amable de enlazarme a esa explicación?

No será la de Kollock, ¿no?

En este hilo tienes mucha información al respecto:
https://forum.beyond3d.com/threads/dx12 ... ute.57188/

Como resumen:
TL;DR
AMDs and Nvidias architectures are fundamentally different when it comes to command handling.

What do they have in common?
Both AMD and Nvidia are supporting concurrent execution of compute shaders in addition to workload from the graphics queue at least since Ferm/GCN 1.0.

All architectures from Nvidia have a "Work Distributor" unit for this purpose, which can handle a number of concurrent (outgoing) command streams. The level of concurrency varies between 6 and 32 command streams, depending on the specific chip.

With AMD, the actual distribution is handled by the ACE (Asynchronous Compute Engine) units. Each ACE unit can handle 64 command streams, the HWS (Hardware Scheduler) can even handle up to 128 command streams each.

Where do they differ?
Since GCN 1.0, AMDs cards had dedicated command queues for compute and graphics commands. Both the GCP (Graphics Command Processor) and the ACE can communicate to handle global barriers and to synchronize queues. This feature is present on every single GCN card. All compute queues exposed by the driver are mapped 1:1 onto hardware queues and can be executed asynchronously, that means without any hardwired order, excluding explicit synchronization points.

With Nvidia, newer cards (GK110, GK208, GMXXX) have a (probably programmable) "Grid Management Unit" in front of the "Work Distributor" which can aggregate commands from multiple queues, including dynamic scheduling and alike, prior to dispatching the workload onto the "Work Distributor".

The "Work Distributor" can only handle a single source of commands, and therefore requires that all queues are mangled into a single queue first, either by the "Grid Management Unit" or by the driver.

This "Grid Management Unit" is currently used to provide a feature called "Hyper-Q" in addition to handling the primary command queue. This feature is similar to the compute queues handled by the ACEs in AMD GPUs in that it can handle a number of truly asynchronous queues, but it lacks certain features such as the support for synchronization points.

What is the result?
So the current state with Nvidia hardware is that all queues used in DX12 are mangled into a single into a single queue in software, whereby the driver has to be rather smart at interleaving commands to maximize the occupation of the "Work Distributor". Ultimately this means that concurrent shaders can finish out of order and new compute shaders can fill the gaps, but execution can only start in the order originally decided by the driver.

Overloading the queues or complex dependency graphs can cause a quite significant CPU load with Nvidia hardware, up to the point where the use of Async shaders even decreases utilization.

AMDs hardware is working as expected, all compute queues are executed fully independently, except for explicit synchronization points.

https://forum.beyond3d.com/posts/1872750/


Hasta ahora Nvidia no ha demostrado mejorar con DX12 de la misma forma que no ha demostrado que pueda usar el computo asincrono de forma eficiente. Y supongo que existe una relación entre ambas cosas.

Tu te empeñas en decir que no existe relación entre la "falta de rendimiento" de Nvidia bajo DX12 y su incapacidad para manejar el computo asynchrono y yo por mi parte creo que lo uno es motivo, sino exclusivo sí importante, de lo otro.

No sé en que acabará todo esto, no me termino de creer lo de Nvidia. Nvidia ha estado trabajando hombro con hombro con microsoft, aunque parezca que no por el tema de que las consolas han salido con base GCN.

Microsoft ha estado trabajando muy duro en el tema de nuevas GPUs en el centro de investigación que tiene en Barcelona, centro en el que ha publicado trabajos relacionados con lo que las nuevas APIs requieren, y que han firmado tanto miembros de microsoft como miembros de Nvidia. Sin ir más lejos, ese centro es centro de excelencia CUDA.

Por poner un ejemplo despúes del Boom del tema del computo asincrono en Nvidia salto otro rumor que decía que Nvidia no puede usar el cambio de contexto de forma eficiente. Sobre ese tema hay trabajos de microsoft y nvidia juntos.

No os penséis, como tendemos a hacer, que por estar en España es un centro de mindundis.
Este es su director:

http://www.elmundo.es/ciencia/2015/09/23/56026902ca4741d25f8b4573.html

Casi nadie...
Vamos, que has ignorado la información que te he puesto para acabar hablándome de que no somos unos mindundis y pasar una noticia de elmundo que no tiene nada que ver con lo que estamos hablando, ok.
josemurcia escribió:Vamos, que has ignorado la información que te he puesto para acabar hablándome de que no somos unos mindundis y pasar una noticia de elmundo que no tiene nada que ver con lo que estamos hablando, ok.


No he ignorado la información que me has dado. Claro que la he leido.

Pero esa misma información son las conclusiones a las que llegan despúes de usar el Benchmark de marras.

Y solo digo que no me termino de creer los resultado xq Nvidia ha trabajado hombro con hombro con microsoft.

Yo no soy el que piensa que no se van a usar los shader asincronos xq a Nvidia no parecen irle bien y solo te he dicho que si por no irle bien a Nvidia piensas que no se van a usar en ese caso tampoco se usarán las nuevas API xq hasta ahora todo lo que se ha visto, aunque sea en un solo benchmark, es que tampoco le van bien.

Y si pongo la noticia es xq ese señor está muy relacionado con lo que las nuevas gpu son o van a ser y ha trabajado junto a Nvidia dandoles forma.

Por ponerte un ejemplo de otro de los elementos que dicen que son limitantes en Nvidia bajo DX12 tienes esta noticia:

Preemption Context Switching Allegedly Best on AMD, Pretty Good on Intel & Potentially Catastrophic on NVIDIA

http://wccftech.com/preemption-context-switching-allegedly-best-amd-pretty-good-intel-catastrophic-nvidia/

Recently, NVIDIA has been under a lot of pressure after the results of the first DirectX 12 benchmark clearly favored AMD. There have been reports that NVIDIA’s existing GPU architecture has problems with Async Compute, though our own Usman cleared up that it is indeed possible to use it.

Now, another report seems to condemn NVIDIA’s choices for Maxwell. Tech Report’s David Kanter said in a video podcast that people who work at Oculus have mentioned how preemption context switching, a very important feature especially in VR scenarios, can be really bad on NVIDIA cards.


Primero dijeron que los shacer asincronos no funcionan en Nvidia y luego que tampoco funcionaba el cambio de contexto. Pero:

http://isaac.gelado.cat/sites/isaac.gelado.cat/files/publications/tanasic-isca2014.pdf

Ahí tienes de donde sale la idea del preemtive context swtching y es un trabajo de Nvidia y el mindundi de la noticia, que según tu nada tiene que ver con el tema.

De la misma forma que creo que lo de que el context switching es raro que no funcione en Nvidia también considero que es raro que no funcione el computo asincrono. Y que como tu mismo has dicho, se ha utilizado un solo benchmark, se ha visto que no funciona y se ha generalizado e intentado darle una explicación.

Pero aun así, aunque realmente no pudiera utilizarse el computo asincrono en Nvidia, sigo sin estar de acuerdo contigo en cuanto a que en dicho caso fuese a desecharse su uso en el resto de plataformas.

No usarlo en DX11 y despúes pretender usarlo en GMN requería mucho trabajo. Ahora puedes programar en DX12 o Vulkan con esa característica y quien pueda que lo use.
y digo yo...no cerraron un hilo bien parecido a este, donde escribían los que escribís en este, diciendo lo que decís en este? :-?
Que nadie se líe. El rendimiento que están dando tanto AMD como Nvidia en DX12 es el que tienen que dar. Simplemente la forma de funcionar lo anterior le venía mejor a Nvidia y ahora con muchos núcleos comunicándose con las unidades de GPU y la falta de características nuevas en los chipset de Nvidia dan el resultado que dan, y no hay más. Hasta que Nvidia no saque algo nuevo que tenga en cuenta todo esto nuevo que ha cambiado, pues será así.
naxeras escribió:
David Ricardo escribió:Cuando empiecen a hacer los juegos en DX12 y Vulkan con Async compute, la 750ti va a hacer chof, porque las gráficas Nvidia actuales no valen para eso. Entonces habrá otra gráfica de 4 duros pero de AMD que le dé pal pelo a las consolas.


Yo prefiero no adelantar acontecimientos y ser cauto.

Lo que tengo claro es que esta generación el modelo de negocio ha cambiado (lo que yo llamo el efecto Wii).

Antes te vendian un hard muy superior a precio mucho menor que el de coste, esto se compensaba con el dinero que gana Sony y MS por licencia de publicación de cada juego, por no hablar del online que se cobraba en el caso de MS.

Hoy en día te veden un hardware con precio igual o superior al de coste (el hard de la casa no es el PVP de un PC similar) y los juegos siguen estando igual de caros que siempre y te cobran el online tranquilamente.

El usuario ha perdido, y es lo malo de esta gen, solo espero que el efecto WiiU y el efecto XBOXONE hagan que la próxima generación sea similar a lo que vivimos con XBOX360.

Un Saludo.

Estoy bastante de acuerdo con lo que dices. De todos modos esto que han sacado ahora yo no lo considero unas wiis, pero si lo considero un término medio entre una burrada en la que pierdan 200 ó 300€ por consola vendida y una wii.
Ahora ya ganan dinero por cada consola vendida, pero yo creo que deberían de bajar el precio a 300€ para estas navidades para ampliar la base de usuarios y recuperarlo, como bien dices, a base de suscripciones, ventas de juegos, etc.

Lo de ver el equivalente a una 360 en el futuro es bastante difícil. Nintendo quiere sacar algo barato y no suelen financiar hardware, así que descartados. Sony está ahora mismo en una situación económica delicada y no puede permitirse vender una consola con un déficit de 200€ por unidad como hicieron con la PS3.
Sólo nos queda Microsoft. Estos sí tienen dinero, si hiciesen una última locura como las que hicieron con Xbox OG y X360, perderían dinero en un primer momento, pero podrían comerse el mercado.
kxalvictor escribió:y digo yo...no cerraron un hilo bien parecido a este, donde escribían los que escribís en este, diciendo lo que decís en este? :-?

Pues si . pero aqui vamos con la version 2.0
papatuelo escribió:Por esa regla de tres, quién ha dicho que el rendimiento de Nvidia con Shader asincronos es malo... Eso también sale del único benchmark real que hay, eso no es representativo de lo que puede hacer.

A parte del benchmarck de Oxyde Games, luego también dijeron algo parecido los de Oculus ... a mi lo que mas preocupa es que NVIDIA respondió con milongas primero, y luego con silencio.

josemurcia escribió:Los shaders asíncronos se pueden utilizar desde hace 2 años en PC con Mantle, y no es que la situación vaya a cambiar mucho con DX12 y Vulkan, ya que en gráficas NVIDIA parece que no suponen ningún beneficio por su arquitectura.

No aporta beneficio, pero funciona, y en otras plataformas aporta un beneficio enorme. Yo si fuese DEV los usaría. El tiempo nos sacará de dudas.
cercata escribió:No aporta beneficio, pero funciona, y en otras plataformas aporta un beneficio enorme. Si fuese DEV los usaría. El tiempo nos sacará de dudas.

¿Dónde está ese beneficio enorme? No he visto todavía ningún benchmark con y sin shaders asíncronos.

Porque AMD lo vende como que se puede conseguir un 25% de mejora en sus GPUs en el mejor de los casos, que ya sabemos en lo que suele acabar.

EDIT: Veo que dicen un 46%, a ver cuando salga un benchmark comparativo en que queda.
josemurcia escribió:¿Dónde está ese beneficio enorme? No he visto todavía ningún benchmark con y sin shaders asíncronos.

Porque AMD lo vende como que se puede conseguir un 25% de mejora en sus GPUs en el mejor de los casos, que ya sabemos en lo que suele acabar.

Pues del Benchmarck de Oxyde, que en DX12 con AMD hay una mejora de rendimiento del 80%. A falta de otros benchmarks ...
cercata escribió:
josemurcia escribió:¿Dónde está ese beneficio enorme? No he visto todavía ningún benchmark con y sin shaders asíncronos.

Porque AMD lo vende como que se puede conseguir un 25% de mejora en sus GPUs en el mejor de los casos, que ya sabemos en lo que suele acabar.

Pues del Benchmarck de Oxyde, que en DX12 con AMD hay una mejora de rendimiento del 80%. A falta de otros benchmarks ...

Una mejora del 80% respecto a DX12 sin async shaders?
josemurcia escribió:Una mejora del 80% respecto a DX12 sin async shaders?

ja ja, no, respecto a DX11 ... pero el bacalao gordo de DX12 son los async shaders.

Por otra parte, NVIDIA estará trabajando duro para que los Async shaders vayan mejor en su siguiente arquitectura imagino.
cercata escribió:
papatuelo escribió:Por esa regla de tres, quién ha dicho que el rendimiento de Nvidia con Shader asincronos es malo... Eso también sale del único benchmark real que hay, eso no es representativo de lo que puede hacer.

A parte del benchmarck de Oxyde Games, luego también dijeron algo parecido los de Oculus ... a mi lo que mas preocupa es que NVIDIA respondió con milongas primero, y luego con silencio.

josemurcia escribió:Los shaders asíncronos se pueden utilizar desde hace 2 años en PC con Mantle, y no es que la situación vaya a cambiar mucho con DX12 y Vulkan, ya que en gráficas NVIDIA parece que no suponen ningún beneficio por su arquitectura.

No aporta beneficio, pero funciona, y en otras plataformas aporta un beneficio enorme. Yo si fuese DEV los usaría. El tiempo nos sacará de dudas.


Los de oculos hablaron del cambio de contexto, no de los shader asincronos.

Y en cuanto a lo del preemptive context switching que es lo que dijeron los de oculus ya he puesto un paper arriba de la propia Nvidia en colaboración con Microsoft, por eso es por lo que al menos esto me extraña.
Lionhead ha enviado a los medios un benchmark preview de Fable Legends con DX12, nos viene al pelo por el tema de los Async Shaders aunque no tenga mucho que ver con el debate planteado inicialmente.

El juego hace uso de computación asíncrona, y eso no ha servido para que las gráficas AMD rindan por encima de NVIDIA, la 980 Ti sigue a la cabeza por encima de la Fury X, el patrón se repite para las demás GPUs de potencia similar.

Imagen


Maxwell parece que es capaz de calcular la iluminación global muchísimo más rápido que GCN, por mucha computación asíncrona que haya.

There is a lot of data here but at least a handful of results that piqued my interest. First, the performance of the Global Illumination pass is consistently faster on the GeForce GTX GPUs when compared to the similar segment Radeon. The GTX 980 Ti is more than 2x faster than the Fury X in that particular step, for example, though AMD's Fiji GPU has the edge when we look at standard shadow mapping and direct lighting.


http://www.pcper.com/reviews/Graphics-C ... -Continues

Estaría bien una comparación con DX11, supongo que la versión final la tendrá.

La propia Microsoft ha dicho que Ashes of the Singularity muestra la ventaja de DX12 en un caso concreto, el de mostrar la mayor cantidad posible de elementos en pantalla, mientras que Fable Legends es más representativo del tipo de AAA que estamos acostumbrados a ver.

One of the key benefits of DirectX 12 is that it provides benefits to a wide variety of games constructed in different ways. Games such as Ashes were designed to showcase extremely high numbers of objects on the screen (and correspondingly exceedingly high draw calls). These are highly CPU bound and receive large FPS improvement from the massive reduction in CPU overhead and multi-threading, especially in the most demanding parts of the scene and with high-end hardware.

Fable Legends pushes the envelope of what is possible in graphics rendering. It is also particularly representative of most modern AAA titles in that performance typically scales with the power of the GPU. The CPU overhead in these games is typically less of a factor, and, because the rendering in the benchmark is multithreaded, it should scale reasonably well with the number of cores available. On a decent CPU with 4-8 cores @ ~3.5GHz, we expect you to be GPU-bound even on a high-end GPU.


Video del benchmark:
https://youtu.be/32frzahi0sc
Interesante.

Con DX11 la GTX 980 siempre estaba por delante de la R9 390X en benchmarks, pero con DX12 parece que es al reves. Si esto es representativo de los AAA, son buenas nuevas para AMD, aunque no tanto como con el otro.

https://www.youtube.com/watch?v=lYQT8udtuWM
Mismo hilo, temática idéntica, mismos protagonistas.
47 respuestas
Cerrado
Volver a General