Hablemos del interior de Xbox One

D3D es todo lo que consume la CPU? Y la vez solo funciona en un core ahora mismo. Entonces la IA, los game mechanics, las IAs, la maquina de estado, el control de los inputs etc no existen o como va el tema? Todo lo que no sea D3D donde va si todo lo que consume la CPU es D3D? xDD

EDIT: No dejo de mezclar DX11 y DX12 porque siguen siendo DX ambos.

Si lo que dices fuera asi en cuanto a la transparencia, porque nos dicen que el mayor cambio de DX12 y su focus esta en los overheads y un mejor uso de los hilos? Si lo que dices es una revolucion a nivel de programacion/compiladores! Una maquina que practicamente hace solas las tareas mas criticas de programacion.

D3D es todo lo que consume la CPU? Y la vez solo funciona en un core ahora mismo. Entonces la IA, los game mechanics, las IAs, la maquina de estado, el control de los inputs etc no existen o como va el tema?

Pues todo eso va fuera de DX. Me parece que estás bastante confundido.

Si eres tu el que me dice que la api original de la Xone, DX, es capaz de coger cualquier computo y enviarlo donde sea no yo!

Yo te respondo a tus palabras xDD

darksch escribió:Si lo mejor es que ya es así, en las API de computación no existen núcleos ni CUs, existen unidades de computación (dependiendo de tu hardware). La idea de M$ es que sobre XOne se programe con un modelo de computación desde el principio, así que su API original, DX12, está pensada para eso.

Eres tu quien engloba dentro de la api original de one, que la llamas DX12, toda esa capacidad de abstraccion y transparencia sobre el hardware!

Eso lo dice M$. Y además que tiene que ver esto ahora con los 4 últimos mensajes. A mí no me metas en tus cosas oye. Yo lo voy a dejar ya, es como si 2 discuten sobre un partido y uno habla de baloncesto y otro de criquet.

Mira esto es de AMD:

o.O

Donde dice microsoft que DX12 sea capaz de hacer todas esas abstracciones? Creo que tenemos un problema de entendimiento entre ambos.

Una cosa es que tu no te preocupes de paralelizar los procesados en DirectCompute, los envias, y el sistema los envia a todos los CUs o lo que sea paralelamente. En eso no hay problema. Se hace en mil sistemas distintos.

Otra cosa muy distinta es que tu programes sea lo que sea de la misma manera y que el sistema se encargue de computarlo donde toque. Eso lo veo imposible.

Si es a lo primero a lo que te refieres, no hay ningun problema con ello, pero el desarrollador ya ha tomado la decision de enviar ese computo en concreto a DirectCompute porque cree que es lo mas efectivo. Despues ya lo que haga la gpu y como lo reparta entre sus distintos componentes se la sopla mientras le llegue el resultado.

Yo te habia entendido que te referias a lo segundo: sea cual sea el proceso de computacion lo programo y lo mando de la misma forma a la maquina, y la maquina decide si lo envia a la cpu o la gpu (directcompute). Esto, lo veo imposible, al menos de manera eficiente

EDIT: Esas fotos hablan de paralelismo, no de toma de decisiones.

http://stackoverflow.com/questions/22513177/gpu-compute-units

I think most current devices map a single ALU to a processing element, and an ALU is a single SIMD core. Indeed, CPUs that don't support SIMD are not OpenCL compatible.

The thing about OpenCL is that you don't need to be concerned about the exact underlying architecture unless you are writing a kernel for very specific hardware. Devices in the future could use as many schedulers/ALUs/memory controllers/etc as the manufacturer chooses to implement the SIMD architecture.

Incrédulo

Siempre tienes la posibilidad (es bueno que la dejen) de elegir tú mismo a donde enviarlo, pero si quieres tú haces el programa para la API de computación y ale, a correr.

El problema es que la API DX11 adaptada a XOne lo tira todo al mismo núcleo, y si ya lo ocupa con draw-calls, como para tirarle más tareas, como las de DirectCompute. Por eso de usarse DirectCompute en DX11 lo más seguro es que todo vaya a la GPU.

Los compiladores hacen maravillas, como por ejemplo predicción de ramificación (¿cómo puede predecir la más probable?), no sé como lo harán pero funciona. Así que un poco de fé.

Estamos hablando de cosas distintas. xDDD

Una cosa es que tengas una forma comun de programar la paralelizacion del proceso, dando igual sobre que hardware lo ejecutes.

Yo doi orden de paralelizar un ++ a todos los valores de una matriz de 100000000x100000000 . Me da igual si el sistema tiene 4 unidades de computo o 40. El driver/api se encargara de paralelizarlo como tenga que hacerlo sobre ese hardware, sin que el programador tenga que hacerlo. Si en total son 2 billones de operaciones y tenemos 4 procesadores, tendra que encolar 500000000 procesos en cada procesador. En cambio si tiene un billon de procesadores solo encolara 2 por procesador. Tampoco me importa si tiene una unica pool de memoria o tiene cells dentro de ella por grupos de procesadores. El sistema se encargara de pasar los datos de la matriz tocha a las pools que corresponda. En eso no hay problema.

Otra cosa bien distinta es que todo lo programemos igual, tengamos 40 procesadores distintos que son mas eficientes en A o B, todo lo programemos exactamente igual y que el sistema sea capaz de mandar cada cosa donde toque de manera totalmente eficiente y sin interaccion del programador. En esto ultimo es en lo que soy incredulo xDD

En teoría todo lo que hacemos en un juego debería poder programarse en el modelo de computación y correr bien.

https://software.intel.com/en-us/articles/microsoft-directcompute-on-intel-ivy-bridge-processor-graphics/

Si lo dice Intel...

Claro. Y en teoria una cpu tambien puede hacer todo lo que haga un juego, pero no es eficiente.

A las gpus les pasa lo mismo. Podrian computar cualquier cosa que les des de comer. Con algunos computos es mucho mas eficiente que una cpu, en otras mucho peor.

El programador debe ver que es lo que manda a donde.

DirectCompute Applications
...
Typical use cases include:
•Game physics and artificial intelligence
...

Ahora si me dices que ya sabes más tú que Intel y has hecho las pruebas suficientes para decir eso, pues ahí ya no me meto

Todo depende del tipo de codigo.

Cuanto mas condiciones logicas haya, menos eficiente sera el uso de una gpu. En fisicas e IA puede haber muchos procesos que sean puro procesado con pocas condiciones. En ese codigo el compute shader sera eficiente.

En cambio en un proceso en el que haya mucha condicion logica no lo sera tanto.

No estoy diciendo que X codigo tenga que ir en un sitio o en otro, sino que estara en manos del programador ver que naturaleza tiene su procesado y en base a ello decidir donde conviene mas enviarlo.

Zokormazo escribió:Claro. Y en teoria una cpu tambien puede hacer todo lo que haga un juego, pero no es eficiente.

A las gpus les pasa lo mismo. Podrian computar cualquier cosa que les des de comer. Con algunos computos es mucho mas eficiente que una cpu, en otras mucho peor.

El programador debe ver que es lo que manda a donde.

Al final los genios de los graficos dicen lo contrario. Que la CPU es la clave para avanzar en esta generacion

AMD gaming scientist Richard Huddy

"We’ve got to the stage where very high-end PC graphics are really getting impressively close to photo-real," he told PCR.

"Not that they actually fool you all of the time, but they are astonishing compared to where they were four years ago. We’ll close that gap.

"So probably in five years time we’ll be able to produce games that are photo-real, probably in limited scenarios. And that’s nice, because historically whenever I’ve been asked about photorealism and where it’s going to be, I’ve always said it’d be a bit more than ten years. I think that’s coming down now quite nicely."

"I think one of the interesting things we’ve seen over the last ten years has been the introduction of multi-core CPUs," he added. "As we got to the early 2000s there were ambitions to produce 10GHz processors. And here we are in 2014 and still the fastest processors stock speeds around 4GHz or so. We don’t go much faster, but we do go wider.

"Game developers over the last 10 years have had to tackle the transition from one core to two, and then to four. They struggled with using up six or eight cores on a PC typically, but I do think the artificial breaks that were there in the way, and things like the single core dependency of Open GL and DX 11, having that out of the way is great news for game developers. It means that they really can open up their CPU cores more.

"So I think not only does [AMD's API] Mantle deliver better capabilities on the graphics side, clearly unleashing some of the power being held back there, but perhaps most surprisingly the benefit for Mantle and the new low level APIs will be more CPU horse power available to games.

"So instead of the artificial bottlenecks and trying to unload the CPU as much as possible, it turns out that if the software is well designed, you’ve actually got a lot of CPU use as well. So we also expect the interesting use of that to increase over the next handful of years."

Los programadores se amoldarán a la tecnologia que tengan entre manos. Si algo es más eficiente, normalmente tirarán hacia ese lado.

Lo que esta diciendo practicamente es que con un buen diseño de paralelizacion a nivel global y sin cuellos de botella debido a procesos monocore podemos sacar mucho mas provecho al mismo hardware multicore.

Es bastante obvio no? Y en medio mete el cuello de botella generado por los render calls en monothread.

Si administramos mejor y de manera mas eficientes todo el hardware que tenemos y nos deshacemos de los cuellos de botella artificiales que tenemos en la cpu por el hecho de usar diseños no horientados al multi-hilo (Hello DX11/OpenGL) podremos sacar mucho mas provecho a la cpu.

Es obvio lo que dice.

Pero no dice que el futuro este en usar la CPU para todo eh. Lo que dice es que con el modelo software adecuado para multihreading sera posible sacar mucho mas provecho al mismo procesador multicore de ahora, que esta desaprovechado por los cuellos de botella generados por software anticuado.

La CPU para todo?

Dudo que alguien haya dicho eso... Lo que habran dicho es que un uso mucho mas eficiente de la CPU puede mejorar el rendimiento.

Nuhar escribió:La CPU para todo?

Dudo que alguien haya dicho eso... Lo que habran dicho es que un uso mucho mas eficiente de la CPU puede mejorar el rendimiento.

Yo desde luego no he dicho que la CPU para todo

Y lo que está diciendo ahora zokor y lo que decia antes darksch es practicamente lo mismo. Solo que se pierden en la semantica y los CP Units

Nuhar escribió:La CPU para todo?

Dudo que alguien haya dicho eso... Lo que habran dicho es que un uso mucho mas eficiente de la CPU puede mejorar el rendimiento.

Exacto.

Lo que dice AMD en ese escrito es que en los ultimos 10 años ha habido muchos dolores de cabeza en ir de cpus de un unico hilo de ejecucion a multihilo, que se han hecho mil chapuzas y se han generado cuellos de botella artificiales debido a software diseñado para ir en un unico hilo. Vamos, que el soft ha ido un paso atras en gaming que el hardware en cuanto a multihilo se refiere.

Si reemplazamos ese diseño de soft arcaico por uno mas moderno y eficiente en multihilo, se liberara mucha capacidad de computo en cpu, porque este estaba limitado por el software mal diseñado.

Es obvio lo que dice.

@eloskuro: pues no le entenderia bien, porque yo desde luego a darksch no le habia entendido que lo que decia fuera eso. Mas bien un sistema de transparencia total que me parece utopico, tanto ahora como dentro de 10 años

Zokormazo escribió:Mas bien un sistema de transparencia total que me parece utopico, tanto ahora como dentro de 10 años

Algo así debió pensar la gente cuando se hablaba de hacer un teléfono móvil.

mitardo escribió:

Zokormazo escribió:Mas bien un sistema de transparencia total que me parece utopico, tanto ahora como dentro de 10 años

Algo así debió pensar la gente cuando se hablaba de hacer un teléfono móvil.

Seria si se hablase de que el telefono movil lo diseñase y crease un ente artificial sin interaccion humana.

Mirad un par de cosas interesantes.

Device Fission: esto es poder sub-dividir unidades de computación para aprovecharlas mejor.
https://software.intel.com/en-us/articles/opencl-device-fission-for-cpu-performance

Y bueno, ahora el plato gordo. Parece que M$ lleva trabajando en esto desde hace tiempo, y están muy adelantados, basta ver lo siguiente:
- Su C++ AMP:
http://msdn.microsoft.com/en-us/library/hh265137.aspx

- Lo que comenta un programador en sus pruebas:
http://devgurus.amd.com/thread/158489
Cito:

The results of the program indicate that C++ AMP typically computes the result of the multiplication of single precision floating point of input matrices A[450 rows, 640 cols] and B[640 rows, 960 cols] in 58 ms. In comparison, the OpenCL implementation solves the problem at best in 600 ms on the GPU. A CPU OpenCL device is enumerated in the program, and does surprisingly better than the GPU, running in 240 ms.

On another machine which has an NVIDIA card, there is neglible difference between OpenCL and C++ AMP, and CUDA (both runtime and driver implementations) for the NVIDIA GPU. However, that machine also has an AMD graphics card, which exhibits the same problem there as on the Llano machine: OpenCL for AMD GPU targets perform poorly compared to C++ AMP implementations that target the GPU.

I suspect that the reason for the poor performance is because C++ AMP targets DirectX11 which is implemented by the card itself, whereas OpenCL is translated into VLIW code. But, I don't know any details of how OpenCL is implemented for AMD GPU's. Or, it could be something simple that I've overlooked in the installation of the AMD APP SDK. I just don't know.

Bueno, sea como sea la solución de M$ siempre corre bien.

Parece que M$ es la más interesada en acercar la computación heterogénea.

Que raro, drivers de AMD que lastran el rendimiento...

Zokormazo escribió:Seria si se hablase de que el telefono movil lo diseñase y crease un ente artificial sin interaccion humana.

No creas. La gente estaba reacia a pensar que el invento fuese posible y tu eres reacio a supuestos avances del software que parecen ser bastante plausibles.

Buenas gente. Como os estáis liando . Hay varios temas y conceptos a tratar aquí, asiq vamos a ir por partes.

Con respecto al overhead que se produce en las APIs y mas concretamente con respecto a DirectX12, su paralelización y el aprovechamiento de los cores, es un tema complicado de explicar pq hay q saber como funciona una API, el driver y como se maneja todo esto a nivel de sistema operativo. Como digo no es fácil de explicar de manera sencilla (y no lo voy a hacer jejeje).



Con respecto a los los trabajos de GPGPU y su metodología de la programación. @darsk ese mensaje es del 24 de enero de 2012...ha llovido ya desde entonces xD.

Por otro lado el software mágico no existe (y menos mal, siempre preferiré tener el control de las cosas). C++ AMP, RenderScript, nuevas versiones de OpenCL con capacidad de computación heterogénea... lo q hacen realmente es que puedas escribir a alto nivel programas que se ejecuten en cualquier unidad de computo disponible en el sistema ya sea una CPU una GPU o incluso un DSP. Pero esto no significa que tu le envies las tareas y el solito decida donde meterlas. Tu escribres un programa (kernel) que se ejecutarán en TODOS los procesadores disponibles en ese momento. Esto tiene una serie de requisistos y características (un lenguaje intermedio interpretado común, comparticiones de memoria, colas a nivel de usuario...) muy complejas de explicar y entender si no se tiene una buena base.

Un saludo.

Es que desde DX11 está todo como muy parado (en cuanto a M$ se refiere), por eso no hay mensajes nuevos más allá de simples actualizaciones de versión.

Por poner algo más:
http://blogs.msdn.com/b/nativeconcurrency/archive/2012/03/10/cpu-accelerator-in-c-amp.aspx
http://www.danielmoth.com/Blog/Running-C-AMP-Kernels-On-The-CPU.aspx

Por lo que tienes un código único, y con sólo cambiar una línea de código ya cambias entre CPU y GPU (y suponemos que en DX12 la nube). Esto simplifica bastante, un mero benchmark para ver donde enviarlo. Incluso en tiempo real puede cambiarse, con un mero "if...else" basado en lo que sea (como por ejemplo el número de elementos a procesar). El condicional debería formar parte de esto simplemente porque respecto a la nube ya hay que ver si está disponible o no. Tampoco es matarse vamos.
Lo bueno es que al usar CPU:

will run your code on the CPU, taking advantage of multi-core and SSE2 (depending on the CPU capabilities WARP also uses SSE3 and SSE 4.1

Y esto hablando sólo de como estaba con DX11, en DX12 la verdad aparte de la nube nadie sabe que otras cosas puede tener.

Respecto al CPU-overhead, sí con la API exclusiva te quitas el problema, pero la verdad creo que pocos lo usarán por no ser reutilizable. Sabemos que Forza y Ryse lo usaban pero más allá más bien poco, y los multis casi seguro que ninguno. La idea es no tener que usar esa API exclusiva, entre otras porque casi nadie la usaría.

The Division Technical Director: DirectX 12 Will Improve Performance & Visuals Of Xbox One/PC Games

http://gamingbolt.com/the-division-tech ... nepc-games

Pero hay alguna fecha para la salida del dx12? aunque sea aprox

¿Y como es posible que Xbox One con 32 MB de eSRAM consiga meter 1080p 4xMSAA ?



Amra78, yo entendí que verano del 2015, pero que las primeras betas irían dandoselas a varias desarrolladoras antes.

eloskuro escribió:¿Y como es posible que Xbox One con 32 MB de eSRAM consiga meter 1080p 4xMSAA ?

BRUJERÍA

eloskuro escribió:¿Y como es posible que Xbox One con 32 MB de eSRAM consiga meter 1080p 4xMSAA ?

Ahora que @Zokormazo me ha enseñado a dar avisos sin quotear, podemos preguntarselo a @Polyteres o a @papatuelo.

Que guay es esto de mencionar jajaja

eloskuro escribió:¿Y como es posible que Xbox One con 32 MB de eSRAM consiga meter 1080p 4xMSAA ?

Buenas gente. Pues si sigues el hilo deberías saber la respuesta pq se ha hablado aquí ya unas cuantas veces:

hilo_hablemos-del-interior-de-xbox-one_1992540_s4520?hilit=+forward+#p1736660751
hilo_hablemos-del-interior-de-xbox-one_1992540_s4520?hilit=+forward+#p1736663743

Ya nombré esta técnica en un mensaje del 17 de Septiembre de 2013.

Lo dije cuando salieron las informaciones q para un deferred era escaso pq no cogía a 1080p, hay mas opciones para tener muchas luces simultáneas como por ejemplo un Forward+ que me da a mi en la nariz q lo veremos bastante y tb sacarán nuevas formas q ahora mismo ni imaginamos.

Un saludo.

darksch escribió: @

eloskuro escribió:¿Y como es posible que Xbox One con 32 MB de eSRAM consiga meter 1080p 4xMSAA ?

BRUJERÍA

@Polyteres , tu si que has estado mas o menos en medio, no todo lo que se escribe es una puya contra ti

Sabes que se ha dicho de todo, al igual que hay gente que ha exagerado hacia un lado, ha habido otros que han exagerado al contrario y ha habido medios "reputados" que se han hecho eco.

Poco a poco ira empezando a verse cosas nuevas.

Nuhar escribió:@Polyteres , tu si que has estado mas o menos en medio, no todo lo que se escribe es una puya contra ti

Sabes que se ha dicho de todo, al igual que hay gente que ha exagerado hacia un lado, ha habido otros que han exagerado al contrario y ha habido medios "reputados" que se han hecho eco.

Poco a poco ira empezando a verse cosas nuevas.

Buenas gente. No me lo he tomado como una puya contra mi , tan solo cito cosas q se han dicho en este mismo hilo hace un año, y q hace un mes escaso se han vuelto a repetir. Venir con esa pregunta y hablar de brujería como si fuera algo imposible o desconocido cuando, vuelvo a repetir, ya se había comentado por aquí...

Me he limitado a contestar la pregunta: como se ha conseguido?. Con un Forward+ .

Un saludo.

Si la parte de la contestación esta genial, aunque desconozca si es por eso o por otra cosa

Lo que pasa es que en este hilo, por no hablar de los de fuera, se han dicho taaaaaaaantas cosas, que normal que la gente se lo tome todo irónico.

Por no decir del super comentario de que era imposible alcanzar 1080p en Xbox one... que no cabía en la memoria, igual que se dijo que no se podría alcanzar un 4xMSAA...

Y al igual que hace poco se ha dicho que la juana tiene 16 gigas y 32 megas de memoria ram xDDD

Hay barbaridades para todos

¿Como le sienta el forward + a nuestros ordenadores? la demo de Leo va genial en mi 7850 pero no deja de ser una demo muy encorsetada.

Lo digo por que la mayoria de las thirds trabajan con desarrollos multiplataforma.

Ayer estube jugando la demo de Horizon 2 y aunque el juego ni fu ni fa la verdad es que los graficos estan muy logrados, las texturas no tanto aunque se entiende por la naturaleza de mundo abierto pero la iluminacion ajustando el brillo tiene cambios muy sutiles y realistas, la camara interior del coche es de lo mejor que he visto, buen motor me gustaria verlo en un shooter en primera persona, como defecto lo poco que se puede ver tiene pinta de ser demasiado saturado de colores y poco realista, muy dibujitos, Sunset, Leo y Horizon son muestras de ello, una delicia de todos modos.

Nuhar escribió:

eloskuro escribió:¿Y como es posible que Xbox One con 32 MB de eSRAM consiga meter 1080p 4xMSAA ?

Ahora que @Zokormazo me ha enseñado a dar avisos sin quotear, podemos preguntarselo a @Polyteres o a @papatuelo.

Que guay es esto de mencionar jajaja

papatuelo?

Si yo no tengo pajolera idea de tecnología, de hecho mi discurso casi siempre es dejemos que las cosas pasen y no seamos tajantes, poco más.

Lo de ¿Y como es posible que Xbox One con 32 MB de eSRAM consiga meter 1080p 4xMSAA ?

A mi entender es un mensaje sarcastico a todos esos que con los numeros en la mano decian que dificilmente esta consola podria mostrar juegos a mas de 900p con un nivel de detalle decente, es mas leyendolos casi que se podria pensar que la consola era un autentico fracaso a nivel tecnico, cuando los juegos estan demostrando que es muy capaz.

Leer por ejemplo a Herebus en los foros que frecuenta y creerlo era como pensar que Xbox One era poco mas que una Ds que iba rascar jugando a Minecraft, Urain de Disruptive Sketchbook a quien felicito por su pagina y a quien tambien leo habla del sistema de memoria como un parche para salvar el bajo ancho de banda de la ddr3 pero ni de lejos es tan radical, en Beyond 3d hay muchos que opinan que la consola es una autentica castaña tecnica.

No digo que la consola sea la repanocha tecnicamente pero obviamente tiene potencial.

De la noche a la mañana a pasado a ser del XBodrio a la XBurra.

Es lo q pasa cuando uno se cree más listo q ingenieros reputados q han trabajado día y noche en el diseño de una consola de nueva generación.

Es muy fácil criticar el trabajo de otros a través de una pantalla.

Esto no ha hecho más q empezar. Hay cosas muy interesantes en el hardware de One q pueden dar algunas sorpresas.

A ver si dejamos atrás de una vez los motores intergeneracionales y vemos lo q es capaz de hacer.

Halo 5, te espero....

En apoyo a lo que comenta @Szasz y de algo que ya vio @Polyteres:

http://www.tomshardware.com/reviews/amd-ama-toms-hardware,3672-4.html

Q. I remember there was something on the GPU 14 event that mentioned anti-aliasing support with deferred rendering / lighting. Does this include super sampling anti-aliasing as well?

A. You're referring to Forward+. I want to give some background on Forward+ so other people know what it is:

Forward+ not only allows for the efficient utilization of thousands of light sources, but also performs an accurate simulation of their interactions with objects in the world. Forward+ also resolves the developer’s choice between a “forward” or “deferred” rendering engine for their game, which can have serious implications for the look, feel and features of a title.

For example, a “forward” rendering engine supports anti-aliasing, texture transparencies (like leaves and chainlink fences), and a wide variety of texture types (e.g. cloth and metal). Meanwhile, a “deferred” engine supports a large number of light sources, efficient rendering effects (“shaders”), and works well on game consoles. Thanks to Forward+, all of these technologies can efficiently coexist.

Forward+ further extends its leadership over forward and deferred engines by substantially increasing the diversity in the material types that a game may render. Whereas lighting on cloth and metal textures might look very similar on a game with a deferred engine (e.g. old gen consoles or console ports), Forward+ can render the distinct and realistic lighting differences between them. Because of the way Forward+ is designed, it's suitable for use with both MSAA and SSAA.

Es decir, que la XOne se diseñó mirando al futuro y no para adaptarse a motores viejunos como pueda ser el deferred que tanto les ha gustado a muchos usar para mofarse de la XOne y su eSRAM insuficiente para ello. "oh mira es que la pobre XOne no va bien con motores del año de Cristo...", bueno, pero los nuevos le encajan como un guante

ZASCA xD

Debo añadir que era previsible, hace ya mucho John Carmack pedía algo similar, vamos que se veía que los motores pasarían por usar menos memoria en buffers y usarlos de forma más dinámica.

darksch escribió:Debo añadir que era previsible, hace ya mucho John Carmack pedía algo similar, vamos que se veía que los motores pasarían por usar menos memoria en buffers y usarlos de forma más dinámica.

Carmack es un tío con la cabeza bien amueblada. La gente se reía de lo mal que lucia el rage por culpa del megatexture y ahora son alabanzas ^^

No tiene que ver directamente con xbox, pero si indirectamente.

http://www.anandtech.com/show/8544/micr ... w-features

En realidad nadie ha dicho que forward+ sea la forma optima de hacer los juegos para Xbox One, de hecho nadie dice que el sistema tradicional de Gpu con su gran ancho de banda y memoria dedicada no pueda hacerlo o lo hagan incluso mejor.

Leo corre en mi Hd7850 y The Order corre en Ps4.

El forward+ por lo que cuentan es una maravilla en el tratamiento de multiples luces que normalmente es algo que con los otros motores consume muchos recursos.

Pada escribió:No tiene que ver directamente con xbox, pero si indirectamente.

http://www.anandtech.com/show/8544/micr ... w-features

Bueno, algo puede tener q ver. Ya hay confirmadas nuevas características. Veremos q tarjetas lo aceptan, yo apostaría a q One es compatible

"Wrapping things up, today’s announcement of Direct3D 11.3 and its new features offers a solid roadmap for both the evolution of Direct3D and the hardware that will support it. By confirming that they are continuing to work on Direct3D 11 Microsoft has answered one of the lingering questions surrounding Direct3D 12 – what happens to Direct3D 11 – and at the same time this highlights the hardware features that the next generation of hardware will need to support in order to be compliant with the latest D3D feature level. And with Direct3D 12 set to be released sometime next year, these new features won’t be too far off either."

Para el q todavía no se crea q una tarjeta dx11.2 no es 100% compatible por hardware con Dx12:

Empezando con las principales novedades de Maxwell de segunda generación, tenemos un nuevo y actualizado motor gráfico compatible por hardware con el API gráfica Microsoft DirectX 11.2 (Maxwell de primera generación es tan sólo compatible con DirectX 11.0), y parcialmente compatible con DirectX 12 (Hardware Level 1 y 2) ofreciendo 2 de los adelantos que estarán presentes en esta futura API:
•Conservative Raster (ahorro de recursos al ocultar/mostrar los pixels que se ubican dentro o fuera del triángulo).
•Raster Ordered Views (control del ordenamiento de las operaciones pixel shader).

DirectX 12 también ofrecerá tecnologías como Typed UAV Load, Volume Tiled Resources y OTRAS que Microsoft revelará en un futuro evento; las que de momento no son soportadas en hardware por ningún GPU existente (aunque pueden ser soportadas por software vía DirectX hardware level 11.0, 11.1 y 11.2).

http://www.chw.net/2014/09/la-arquitect ... ion-gm20x/

¿Aseguras que el hardware de Xbox One es 100% directx 12?
¿Lo asegura alguien de Microsoft?

Seria algo bueno de ser asi, pero que sea con fuentes y no actos de fe y esperanzas.

jose1024 escribió:¿Aseguras que el hardware de Xbox One es 100% directx 12?
¿Lo asegura alguien de Microsoft?

Seria algo bueno de ser asi, pero que sea con fuentes y no actos de fe y esperanzas.

21 de marzo del 2014. Twitter de Phil Spencer:

"DX12 will have impact on XBOX One games written for DX12. Some DX12 features are already in XBOX One but full DX12 coming."

¿Confirmación oficial? No.
¿Opinión personal? Los cambios en el hardware de la GPU de Xbox One no son casualidad.

Es lo que tienen los mensajes ambiguos, que no estan del todo claros.
100% No es nada ambiguo.
Mi opinion es que no son claros por que no es 100% compatible, no cuesta decirlo cuando es verdad.

Buenas gente. El problema que veo es q empezáis bien pero luego poco a poco se van tergiversando cosas y al final se llegan a conclusiones equivocadas o erróneas. @jose1024 lo ha expuesto muy bien en su mensaje anterior.

Forward Rendering, Deferred Rendering, Light Prepass, Tile-based deferred rendering, Forward+...no son mas que formas diferentes de sacar un render. Unas pueden partir de la misma raíz pero tener pequeños cambios, otras son aproximaciones híbridas...y por supuesto cada una tiene sus ventajas y sus inconvenientes. La elección de una u otra viene dada por las necesidades artísticas del juego que se está desarrollando y obviamente por las "limitaciones" (todas las máquinas lo tienen) que tenga el hardware objetivo (hasta hace poco no podía meter un deferred rendering en un smathphone pero ahora si ). No se debe hablar de técnicas de render antiguas u obsoletos sino de técnicas más apropiadas para un juego determinado.

Forward+ no es un "motor" nuevo y que demuestra la potencia de XboxOne. Forward+ es una técnica de render q tiene ya su tiempo, q tiene una serie de ventajas e inconvenientes y q funciona igual de bien en un PC, en una Ps4 o en una XboxOne.

XboxOne no es ni más ni menos que hace 2 días, 1 semana o 1 año. Es la misma máquina con sus puntos fuertes y con sus carencias, pero los ingenieros estamos para eso, para solucionar los problemas que se nos van presentando.

El tamaño de la eSRAM sigue siendo el mismo, y tienes q buscar formas de saltarte esa limitación. Sabes que como mucho puedes meter 4 buffers a 1080p de 4 bytes (por ejemplo RGBA8 q es lo estándar). Forward+ es una técnica q se hace en 3 pasos, y cuyo primer y segundo pase puede residir perfectamente en DDR3. En el primer pase renderizas solo el Z-Buffer, por lo que debido a la simpleza del shader q estás usando, sabes que vas a estar limitado por las ROPs y no por el ancho de banda, por lo que puedes renderizar perfectamente a la DDR3 este pase sin que el "escaso" ancho de banda sea un problema demasiado grave. Luego usas un Compute Shader para calcular las luces que afectan a cada pixel y metes esa información en un buffer. El tercer paso es un forward normal y corriente usando como información los pases 1º y 2º.

Con respecto a las nuevas características de DirectX12, en la línea de anunciado, nada demasiado significativo...lo q se espera.

Un saludo.

Polyteres escribió:Buenas gente. El problema que veo es q empezáis bien pero luego poco a poco se van tergiversando cosas y al final se llegan a conclusiones equivocadas o erróneas. @jose1024 lo ha expuesto muy bien en su mensaje anterior.

Forward Rendering, Deferred Rendering, Light Prepass, Tile-based deferred rendering, Forward+...no son mas que formas diferentes de sacar un render. Unas pueden partir de la misma raíz pero tener pequeños cambios, otras son aproximaciones híbridas...y por supuesto cada una tiene sus ventajas y sus inconvenientes. La elección de una u otra viene dada por las necesidades artísticas del juego que se está desarrollando y obviamente por las "limitaciones" (todas las máquinas lo tienen) que tenga el hardware objetivo (hasta hace poco no podía meter un deferred rendering en un smathphone pero ahora si ). No se debe hablar de técnicas de render antiguas u obsoletos sino de técnicas más apropiadas para un juego determinado.

Forward+ no es un "motor" nuevo y que demuestra la potencia de XboxOne. Forward+ es una técnica de render q tiene ya su tiempo, q tiene una serie de ventajas e inconvenientes y q funciona igual de bien en un PC, en una Ps4 o en una XboxOne.

XboxOne no es ni más ni menos que hace 2 días, 1 semana o 1 año. Es la misma máquina con sus puntos fuertes y con sus carencias, pero los ingenieros estamos para eso, para solucionar los problemas que se nos van presentando.

El tamaño de la eSRAM sigue siendo el mismo, y tienes q buscar formas de saltarte esa limitación. Sabes que como mucho puedes meter 4 buffers a 1080p de 4 bytes (por ejemplo RGBA8 q es lo estándar). Forward+ es una técnica q se hace en 3 pasos, y cuyo primer y segundo pase puede residir perfectamente en DDR3. En el primer pase renderizas solo el Z-Buffer, por lo que debido a la simpleza del shader q estás usando, sabes que vas a estar limitado por las ROPs y no por el ancho de banda, por lo que puedes renderizar perfectamente a la DDR3 este pase sin que el "escaso" ancho de banda sea un problema demasiado grave. Luego usas un Compute Shader para calcular las luces que afectan a cada pixel y metes esa información en un buffer. El tercer paso es un forward normal y corriente usando como información los pases 1º y 2º.

Con respecto a las nuevas características de DirectX12, en la línea de anunciado, nada demasiado significativo...lo q se espera.

Un saludo.

No se ni la milesima parte de hardware que tu, por lo que tecnicamente jamas te podría rebatir nada. Pero hay cosas que son de sentido comun, mira la parte roja que te cito.

Tienes que buscar formas de saltarte los limites del hardware???

O sea que los ingenieros diseñaron el hardware sin saber para que, una vez más tendríamos que suponer entonces que no estaban pensando en Directx 12 y sus recursos. Y cuando acabaron dijeron: "Vaya puta mierda que hemos hecho, ¿ahora como lo arreglamos?"

No me cuadra.

Los ingenieros de hardware hacen graficas y sistemas programables, dinamicos y versatiles, en algunos casos son tremendamente especificios pero en el caso de las gpus cada vez tienden mas a ser usada para otras funciones distintas a la representacion de graficos.

Los ingenieros de software hacen programas para utilizar el hardware del que disponen adaptandose la maximo a el para obtener el maximo rendimiento y la maxima compatibilidad.

Hay muchas formas de poner a trabajar a la maquina de renderizado y las nuevas caracteristicas de Directx forman parte de ellas y en algunos casos necesitan hardware especifico para simplemente ser posible o para realizar el trabajo con mejor rendimiento.

Nadie ha dicho que los ingenieros de Microsoft sean idiotas ni muchisimo menos, ni tampoco han dicho ellos con total rotundidad que sea Directx12 por hardware, tambien es posible, muy posible que muchas de las decisiones tomadas por los ingenieros de Microsoft tubieran muy en consideracion el Kinect siempre conectado y que algunas partes del hardware de Xbox One solo tubieran como objetivo funcionar para un hardware al que en mayor o menor medida han dado de lado.

De todos modos cualquier motor de renderizado a priori debe de funcionar con un minimo de retrocompatibilidad por que entonces por ejemplo, nadie sacaria un juego que solo corriera en las nuevas Nvidia ya que esto lastraria las ventas, en estos casos suelen sacar demos tecnicas y luego cuando hay un buen parque de graficas que soportan la caracteristica sacar motores que la aprovechen.

Igual en una hd6850 o una gtx260 el demo de Leo va como el culo o no corre, algo asi no valdria hasta pasado un tiempo.