Hablemos del interior de Xbox One

Darkcaptain escribió:

David Ricardo escribió:

mapla escribió:...
No obstante, yo no creo que estén tan parejas, parejas estaban PS3 y 360 por ejemplo. Aunque tampoco es un caso PS2 y Xbox como muchos se empeñan. No quiero desviar esto a PS4, no obstante.

A causa de multitud de trolleos y flameos ya no se puede hablar de la consola contraria en los subforos de Xbox One y PS4. Yo lo entiendo y lo acepto como un mal menor, pero echo en falta un sitio en EOL donde poder hacer comparativas técnicas entre máquinas.

Creo que para ello tienes un Foro Multiplataforma en el que poder hablar, opinar y comparar cualquier plataforma, pero como ya he dicho es un "creo".

Si se ha llegado a este punto es por que los usuarios no saben medir correctamente sus palabras a la hora de comparar u opinar y todo debate/comparación siempre lleva al mal rollo etc..

Vamos a ceñirnos al tema del Hilo (Xbox One) y dejar el resto de plataformas.

Darkcaptain escribió:Microsoft to Optimize Xbox One’s Power Management, Performance and Engineering Practices

Cito la parte que a mi entender es bastante interesante

While the ad mentions all the Xbox products, responsibilities definitely focus on Xbox One, not only because it’s Microsoft’s recent poster child, but because it’s the only Xbox Device based on the x86 architecture (the Xbox 360 is based on Power PC) and on Windows 8.
Power management is an issue often overlooked issue in the design of consoles (and computers) by the general public, as the attention of most is drawn more towards the numbers and data about CPUs and GPUs, but power efficiency normally leads to sensible improvements in performance as well, and in the ability to push the hardware harder without incurring into problems like overheating.
It’s also worth mentioning that the planned use of the DirectX 12 API will optimize multithreading and allow the CPU to feed the GPU with more commands, more often. This could definitely push the GPU closer to its hardware and heat management limits, and an optimization of its power consumption would definitely help in juicing it further.
Improving engineering practices also has a relevant indirect effect on performance, as it leads to better build quality and higher resilience to fault under stress.
How far can Microsoft push the Xbox One? That we cannot know yet, and it’ll be interesting to see what the one that will grab this job and the rest of the team will achieve.

Fuente y noticia completa: http://www.dualshockers.com/2014/05/08/ ... practices/

skitnett escribió:Traducciones google presenta...

Mientras que el anuncio menciona todos los productos Xbox , responsabilidades definitivamente se centran en Xbox Uno, no sólo porque es más reciente niño del cartel de Microsoft , sino porque es el único dispositivo de Xbox basado en la arquitectura x86 ( la Xbox 360 está basado en Power PC ) y en Windows 8 .
La administración de energía es una cuestión a menudo pasado por alto problema en el diseño de las consolas (y ordenadores ) por parte del público en general , ya que la atención de la mayoría se dibuja más hacia los números y los datos acerca de CPU y GPU , pero la eficiencia de energía que normalmente se traduce en mejoras sensibles en el rendimiento así , y en la capacidad de empujar el hardware más difícil sin incurrir en problemas tales como el sobrecalentamiento .
También vale la pena mencionar que el uso previsto de la API DirectX 12 optimizará el multithreading y de permitir que la CPU para alimentar a la GPU con más órdenes , más a menudo. Esto definitivamente podría empujar la GPU más cerca de sus límites de hardware y de gestión de calor , y una optimización de su consumo de energía sin duda ayudará a extraer el jugo aún más.
La mejora de las prácticas de ingeniería también tiene un efecto indirecto relevante en el rendimiento, ya que lleva a construir una mejor calidad y una mayor capacidad de resistencia al fallo bajo estrés.
¿Hasta dónde puede empujar el Microsoft Xbox One? Que no podemos saber , sin embargo, y va a ser interesante ver lo que el que va a coger este trabajo y el resto del equipo va a lograr .


Editado , solo la traduccion lo otra era ... otra cosa

Talk to me about the advantages of developing on the Xbox One.
This is a big game. There’s a giant city. There’s a lot to explore. We’re pushing things further visually than on any of our games previously, so you need powerful hardware for that. That’s the obvious answer. And I know a lot of Xbox One owners out there will tell you it’s a powerful machine. There are other aspects of it that I can’t get into right now, but we can talk about them at a later date that would be beneficial for us as a developer.

Szasz escribió:Hablando del dx12....¿Creéis q Sunset Overdrive hace uso de una versión beta de dx12?

papatuelo escribió:Lo que dice es que sin directX 12 la CPU hace cuello de botella a la GPU, cuando la nueva api mejore el uso de todos los nucleos dará más chicha a la gráfica y con ello la temperatura se debe elevar bastante.

Zokormazo escribió:No, me refiero a que el entorno de ejecucion de los juegos es un sandbox, un entorno controlado donde el ejecutable del juego no accede a todo, solo a lo que el jail del sandbox le permite. Entiendo que una modificacion de DX11.2 para que sea multihilo necesitara accesos que el sandbox no deberia de permitir a la ejecucion en su interior. Por lo tanto una modificacion como la que se sugeria para titanfall no seria posible sin tocar el sandbox. Y como el sandbox es parte del SO, lo que habria que parchear primero seria la consola, no el juego.

eloskuro escribió:Entonces. Si antes(por poner un ejemplo. Se que no es exactamente asi)

Si antes un juego conseguia hacer 50 draw calls al core 1 de la cpu y 10 al resto= 120
Ahora se podria hacer 45 draw calls a los 8 cores=360

Flashbackman360 escribió:XBox One:
2 CP(Procesadores de comando) para GFX
2 CP(Procesadores de comando para) GPGPU

Los Render Back Ends, (RBE) Raster Operation Pipeline ()NO son necesarios en la parte de computación general (GPGPU) El next gen GPU tiene desdobladas ciertas áreas del pool de forma física (como las Unidades Logicas Aritméticas). El aumento de las drawcall entre otras cosas...(no todo es drawcall, palabra de moda), junto a la posibilidad de eficiencia en DP y la superioridad de las op/c de CPU y GPU crean un sistema sin cuellos de botella y una máquina ultra eficiente con una GPU discreta. Ésta visión de Microsoft en conjunción con AMD sobre el futuro de las GPU era el paso lógico en consolas de sobremesa, por los problemas que acarrea el poner dentro de una máquina de salón una GPU que consuma 500w.

Una GPU Next Gen eficiente, de 1.3TF puede rendir 4 veces por encima que una GPU moderna. En 2 años, todas las vga estarán en el entorno de 1.3-3.0Tf DP

PS4:
1 CP para GFX + ACE's extra, para intentar gestionar la parte balanceada de GPGPU.

Si Msoft no necesita más de 16 ACE para gestionar de base los 1.34tf por que Sony pone en PS4 más de los 22 que necesitaría para gestionar los 1.8Tf hasta un total de 32? Pues porque es un acercamiento para dotar a la máquina de una capacidad extra en GPGPU ha consecuencia de ciertos bottlenecks que se han visto en Infamous.

Como ya hemos explicado en otras ocasiones, GPGPU en XBox One no se ejecuta con más y más ACE's...el concepto cambia. Mientras el proposito general se ejecuta de manera asincrónica en PS4, en XBox One tenemos sincronismo en el hilo de ejecución.

Sumado al hecho de que DX12 es compatible con multiples procesadores de comando de manera nativa por hardware de manera eficiente y no por software como hacen las API modernas. No es lo mismo tener un GPU o un CPU que a través de software te desdobla los hilos, que tener 2 hilos físicos que a su vez se desdoblan por hardware añadiendo físicamente las partes necesarias para tal propósito.

Hay un montón de espacio/tiempo para las tareas de paralelismo en una CPU y en una GPU, pero la idea de presentar múltiples hilos desde varios subprocesos en paralelo, simplemente no tiene ningún sentido de las arquitecturas de GPU modernas, básicamente porque no están pensadas para ello, no hay API's que pudieran ver el desdoblamiento si lo tuvieran. DP no tiene sentido ahí.

Para facilitar esta tarea, la GPU Next Gen de XBox One, además de las colas de cómputo asincrónicas, admite dos render pipes concurrentes. Las dos render pipe permitien que el hardware pueda representar el contenido del juego en la prioridad alta, mientras que al mismo tiempo puede representar el contenido del sistema de baja prioridad. El programador de hardware GPU está diseñado para maximizar el rendimiento y rellena automáticamente "agujeros" en las tareas de processing. La alta prioridad puede permitir la prestación del sistema para hacer uso de los programas operativos regionales para el llenado, por ejemplo, mientras que el título está haciendo simultáneamente las operaciones de cómputo sincrónicos en las unidades de cálculo puede estar manejando al mismo tiempo el SO+APP sin problemas. Dicho fácil, las 2 render pipes son para juegos y es trabajo de la gestión de la doble cola de trabajo el gestionar los recursos. DX12 APPROVED

Un buen ejemplo práctico a la hora de traspasarlo a un juego sería por ejemplo cuando procesas shadow map rendering. El shadow map rendering está limitado por el hardware de función fija (ROP y motores primitivos) además, utiliza una pequeña cantidad de (ALU's )unidades aritméticas sencillas para vertex shader, además de una muy pequeña cantidad de ancho de banda. (la salida del compressed depth buffer solo lee el tamaño de los vértices optimizados que no tienen UV'S o tangentes) Esto significa que todas las TMU y la enorme mayoría de las ALU's y gran parte del ancho de banda, están practicamente al Ralentí, mientras se ejecuta el sombreado. Ahora, imaginaros que la iluminación del juego basada en GPGPU (Ryse Son of Rome Global illuminatión physicall based) pudiera escribirse al mismo tiempo y de manera simultanea a la de la sombra de un mapa. Tachán! recursos gratis. Estás usando de manera mucho más eficiente tus Teraflops de base.

Volvemos a lo mismo, next gen GPU y XBox One no va de Teraflops en bruto, va de como los utilizas de manera eficiente y ordenada. Paraleliced Optimiced Multiple Queue Multiple Thread 2 Heads best than One.

1.84------------->


---------->
---------->
1.34
---------->
---------->

Strife 117 escribió:

Flashbackman360 escribió:XBox One:
2 CP(Procesadores de comando) para GFX
2 CP(Procesadores de comando para) GPGPU

Los Render Back Ends, (RBE) Raster Operation Pipeline ()NO son necesarios en la parte de computación general (GPGPU) El next gen GPU tiene desdobladas ciertas áreas del pool de forma física (como las Unidades Logicas Aritméticas). El aumento de las drawcall entre otras cosas...(no todo es drawcall, palabra de moda), junto a la posibilidad de eficiencia en DP y la superioridad de las op/c de CPU y GPU crean un sistema sin cuellos de botella y una máquina ultra eficiente con una GPU discreta. Ésta visión de Microsoft en conjunción con AMD sobre el futuro de las GPU era el paso lógico en consolas de sobremesa, por los problemas que acarrea el poner dentro de una máquina de salón una GPU que consuma 500w.

Una GPU Next Gen eficiente, de 1.3TF puede rendir 4 veces por encima que una GPU moderna. En 2 años, todas las vga estarán en el entorno de 1.3-3.0Tf DP

PS4:
1 CP para GFX + ACE's extra, para intentar gestionar la parte balanceada de GPGPU.

Si Msoft no necesita más de 16 ACE para gestionar de base los 1.34tf por que Sony pone en PS4 más de los 22 que necesitaría para gestionar los 1.8Tf hasta un total de 32? Pues porque es un acercamiento para dotar a la máquina de una capacidad extra en GPGPU ha consecuencia de ciertos bottlenecks que se han visto en Infamous.

Como ya hemos explicado en otras ocasiones, GPGPU en XBox One no se ejecuta con más y más ACE's...el concepto cambia. Mientras el proposito general se ejecuta de manera asincrónica en PS4, en XBox One tenemos sincronismo en el hilo de ejecución.

Sumado al hecho de que DX12 es compatible con multiples procesadores de comando de manera nativa por hardware de manera eficiente y no por software como hacen las API modernas. No es lo mismo tener un GPU o un CPU que a través de software te desdobla los hilos, que tener 2 hilos físicos que a su vez se desdoblan por hardware añadiendo físicamente las partes necesarias para tal propósito.

Hay un montón de espacio/tiempo para las tareas de paralelismo en una CPU y en una GPU, pero la idea de presentar múltiples hilos desde varios subprocesos en paralelo, simplemente no tiene ningún sentido de las arquitecturas de GPU modernas, básicamente porque no están pensadas para ello, no hay API's que pudieran ver el desdoblamiento si lo tuvieran. DP no tiene sentido ahí.

Para facilitar esta tarea, la GPU Next Gen de XBox One, además de las colas de cómputo asincrónicas, admite dos render pipes concurrentes. Las dos render pipe permitien que el hardware pueda representar el contenido del juego en la prioridad alta, mientras que al mismo tiempo puede representar el contenido del sistema de baja prioridad. El programador de hardware GPU está diseñado para maximizar el rendimiento y rellena automáticamente "agujeros" en las tareas de processing. La alta prioridad puede permitir la prestación del sistema para hacer uso de los programas operativos regionales para el llenado, por ejemplo, mientras que el título está haciendo simultáneamente las operaciones de cómputo sincrónicos en las unidades de cálculo puede estar manejando al mismo tiempo el SO+APP sin problemas. Dicho fácil, las 2 render pipes son para juegos y es trabajo de la gestión de la doble cola de trabajo el gestionar los recursos. DX12 APPROVED

Un buen ejemplo práctico a la hora de traspasarlo a un juego sería por ejemplo cuando procesas shadow map rendering. El shadow map rendering está limitado por el hardware de función fija (ROP y motores primitivos) además, utiliza una pequeña cantidad de (ALU's )unidades aritméticas sencillas para vertex shader, además de una muy pequeña cantidad de ancho de banda. (la salida del compressed depth buffer solo lee el tamaño de los vértices optimizados que no tienen UV'S o tangentes) Esto significa que todas las TMU y la enorme mayoría de las ALU's y gran parte del ancho de banda, están practicamente al Ralentí, mientras se ejecuta el sombreado. Ahora, imaginaros que la iluminación del juego basada en GPGPU (Ryse Son of Rome Global illuminatión physicall based) pudiera escribirse al mismo tiempo y de manera simultanea a la de la sombra de un mapa. Tachán! recursos gratis. Estás usando de manera mucho más eficiente tus Teraflops de base.

Volvemos a lo mismo, next gen GPU y XBox One no va de Teraflops en bruto, va de como los utilizas de manera eficiente y ordenada. Paraleliced Optimiced Multiple Queue Multiple Thread 2 Heads best than One.

1.84------------->


---------->
---------->
1.34
---------->
---------->

Strife 117 escribió:

Flashbackman360 escribió:XBox One:
2 CP(Procesadores de comando) para GFX
2 CP(Procesadores de comando para) GPGPU

Los Render Back Ends, (RBE) Raster Operation Pipeline ()NO son necesarios en la parte de computación general (GPGPU) El next gen GPU tiene desdobladas ciertas áreas del pool de forma física (como las Unidades Logicas Aritméticas). El aumento de las drawcall entre otras cosas...(no todo es drawcall, palabra de moda), junto a la posibilidad de eficiencia en DP y la superioridad de las op/c de CPU y GPU crean un sistema sin cuellos de botella y una máquina ultra eficiente con una GPU discreta. Ésta visión de Microsoft en conjunción con AMD sobre el futuro de las GPU era el paso lógico en consolas de sobremesa, por los problemas que acarrea el poner dentro de una máquina de salón una GPU que consuma 500w.

Una GPU Next Gen eficiente, de 1.3TF puede rendir 4 veces por encima que una GPU moderna. En 2 años, todas las vga estarán en el entorno de 1.3-3.0Tf DP

PS4:
1 CP para GFX + ACE's extra, para intentar gestionar la parte balanceada de GPGPU.

Si Msoft no necesita más de 16 ACE para gestionar de base los 1.34tf por que Sony pone en PS4 más de los 22 que necesitaría para gestionar los 1.8Tf hasta un total de 32? Pues porque es un acercamiento para dotar a la máquina de una capacidad extra en GPGPU ha consecuencia de ciertos bottlenecks que se han visto en Infamous.

Como ya hemos explicado en otras ocasiones, GPGPU en XBox One no se ejecuta con más y más ACE's...el concepto cambia. Mientras el proposito general se ejecuta de manera asincrónica en PS4, en XBox One tenemos sincronismo en el hilo de ejecución.

Sumado al hecho de que DX12 es compatible con multiples procesadores de comando de manera nativa por hardware de manera eficiente y no por software como hacen las API modernas. No es lo mismo tener un GPU o un CPU que a través de software te desdobla los hilos, que tener 2 hilos físicos que a su vez se desdoblan por hardware añadiendo físicamente las partes necesarias para tal propósito.

Hay un montón de espacio/tiempo para las tareas de paralelismo en una CPU y en una GPU, pero la idea de presentar múltiples hilos desde varios subprocesos en paralelo, simplemente no tiene ningún sentido de las arquitecturas de GPU modernas, básicamente porque no están pensadas para ello, no hay API's que pudieran ver el desdoblamiento si lo tuvieran. DP no tiene sentido ahí.

Para facilitar esta tarea, la GPU Next Gen de XBox One, además de las colas de cómputo asincrónicas, admite dos render pipes concurrentes. Las dos render pipe permitien que el hardware pueda representar el contenido del juego en la prioridad alta, mientras que al mismo tiempo puede representar el contenido del sistema de baja prioridad. El programador de hardware GPU está diseñado para maximizar el rendimiento y rellena automáticamente "agujeros" en las tareas de processing. La alta prioridad puede permitir la prestación del sistema para hacer uso de los programas operativos regionales para el llenado, por ejemplo, mientras que el título está haciendo simultáneamente las operaciones de cómputo sincrónicos en las unidades de cálculo puede estar manejando al mismo tiempo el SO+APP sin problemas. Dicho fácil, las 2 render pipes son para juegos y es trabajo de la gestión de la doble cola de trabajo el gestionar los recursos. DX12 APPROVED

Un buen ejemplo práctico a la hora de traspasarlo a un juego sería por ejemplo cuando procesas shadow map rendering. El shadow map rendering está limitado por el hardware de función fija (ROP y motores primitivos) además, utiliza una pequeña cantidad de (ALU's )unidades aritméticas sencillas para vertex shader, además de una muy pequeña cantidad de ancho de banda. (la salida del compressed depth buffer solo lee el tamaño de los vértices optimizados que no tienen UV'S o tangentes) Esto significa que todas las TMU y la enorme mayoría de las ALU's y gran parte del ancho de banda, están practicamente al Ralentí, mientras se ejecuta el sombreado. Ahora, imaginaros que la iluminación del juego basada en GPGPU (Ryse Son of Rome Global illuminatión physicall based) pudiera escribirse al mismo tiempo y de manera simultanea a la de la sombra de un mapa. Tachán! recursos gratis. Estás usando de manera mucho más eficiente tus Teraflops de base.

Volvemos a lo mismo, next gen GPU y XBox One no va de Teraflops en bruto, va de como los utilizas de manera eficiente y ordenada. Paraleliced Optimiced Multiple Queue Multiple Thread 2 Heads best than One.

1.84------------->


---------->
---------->
1.34
---------->
---------->

Vamos a hacer un mantra todos juntos por que creo que hay cosas que no quedan claras. Eh @papatuelo

Forzimbras escribió:Este hombre participó en el diseño de la arquitectura del main SoC. No es de extrañar que sepa tanto.

Polyteres escribió:Buenas gente. Es q eso de que solo se está usando un solo core para dibujar...no es totalmente correcto. Actualmente ya existen funciones en DirectX 11 para que varias hebras puedan hacer drawcall. Mediante los Deferred Context varios cores pueden escribir command list dnd se almacenan estas drawcalls, cambios de estado, manejo de recursos... q posteriormente se ejecutan. Ya se está usando en muchos engines. Lo que traerá DirectX 12 (se supone pq esto se ha ido escuchando desde DirectX 10) será mucho mas control sobre esto, menos overhead por parte del driver, un paralelismo más real, más libertad para poder usar los recursos como quieras...

A parte existen técnicas y funciones para no tener que hacer tantas llamadas a la API (batching, instancing, indirect draw...), que se usan intensivamente.

@Zokormazo, no será transparente al programador, lo tendrás que hacer tú como ya se hace en otras APIs.

Un saludo.

Un buen ejemplo práctico a la hora de traspasarlo a un juego sería por ejemplo cuando procesas shadow map rendering. El shadow map rendering está limitado por el hardware de función fija (ROP y motores primitivos) además, utiliza una pequeña cantidad de (ALU's )unidades aritméticas sencillas para vertex shader, además de una muy pequeña cantidad de ancho de banda. (la salida del compressed depth buffer solo lee el tamaño de los vértices optimizados que no tienen UV'S o tangentes) Esto significa que todas las TMU y la enorme mayoría de las ALU's y gran parte del ancho de banda, están practicamente al Ralentí, mientras se ejecuta el sombreado. Ahora, imaginaros que la iluminación del juego basada en GPGPU (Ryse Son of Rome Global illuminatión physicall based) pudiera escribirse al mismo tiempo y de manera simultanea a la de la sombra de un mapa. Tachán! recursos gratis. Estás usando de manera mucho más eficiente tus Teraflops de base.

Good example of this is shadow map rendering. It is bound by fixed function hardware (ROPs and primitive engines) and uses very small amount of ALUs (simple vertex shader) and very small amount of bandwidth (compressed depth buffer output only, reads size optimized vertices that don't have UVs or tangents). This means that all TMUs and huge majority of the ALUs and bandwidth is just idling around while shadows get rendered. If you for example execute your compute shader based lighting simultaneously to shadow map rendering, you get it practically for free. Funny thing is that if this gets common, we will see games that are throttling more than Furmark, since the current GPU cooling designs just haven't been designed for constant near 100% GPU usage (all units doing productive work all the time).

Szasz escribió:Polyteres, ¿Crees q dx12 es únicamente una API "close to metal"? El mantle de Microsoft.

Si es así, entiendo q no debería tener mayor importancia en Xbox One, ya q es un sistema cerrado.

Un saludo

Polyteres escribió:Buenas gente. @Forzimbras Flashbackman360 es el ingeniero del que hablabas?. El q ha participado en el desarrollo del SoC de XboxOne?.

Forzimbras escribió:

Polyteres escribió:Buenas gente. @Forzimbras Flashbackman360 es el ingeniero del que hablabas?. El q ha participado en el desarrollo del SoC de XboxOne?.

¿FlasBackMan360? Ni lo conozco ni he hablado jamás con él. Pero que participó en el diseño del SoC es tan real como que escribe en varios lugares donde también lo hacen ex compañeros suyos, que sí son los que me han explicado del tema (él ya no trabaja ni en su mismo departamento) y me han hablado de él.

En definitiva, que es voz más que autorizada para hablar del tema (haya cogido para ello datos de beyond3d o no para dar su explicación, en lo que ya no entro). P

Pero Polyteres por lo que has comentado o insinuado alguna vez, has sido developer de One o al menos tenido acceso al devkit de la consola (o eso has dejado entrever alguna vez) pero a nivel externo ¿no? Por lo que quizás podrías darnos una explicación con información detallada de cómo funciona el asunto (por contrastar más que nada a posteriori lo que digas con los compañeros de Xbox). Lo digo por dejarnos de misterios de una vez y ser claros en lugar de dar simples "teorías" de cómo crees que funciona y no de cómo lo hace realmente.

Polyteres escribió:Buenas gente. @Forzimbras Flashbackman360 es el ingeniero del que hablabas?. El q ha participado en el desarrollo del SoC de XboxOne?. Si es así mal muy muy muy mal vamos, y al resto que le dais credibilidad, en mi tierra hay un dicho que dice así: se coge antes a un mentiroso q a un cojo (con todos mis respetos a la gente coja).

Y es que ya decía yo q las cosas q decía me sonaban sin sentido, mezclando cosas, y como si algunas fueran una cutre traducción...hasta que he leido este parrafo:

Un buen ejemplo práctico a la hora de traspasarlo a un juego sería por ejemplo cuando procesas shadow map rendering. El shadow map rendering está limitado por el hardware de función fija (ROP y motores primitivos) además, utiliza una pequeña cantidad de (ALU's )unidades aritméticas sencillas para vertex shader, además de una muy pequeña cantidad de ancho de banda. (la salida del compressed depth buffer solo lee el tamaño de los vértices optimizados que no tienen UV'S o tangentes) Esto significa que todas las TMU y la enorme mayoría de las ALU's y gran parte del ancho de banda, están practicamente al Ralentí, mientras se ejecuta el sombreado. Ahora, imaginaros que la iluminación del juego basada en GPGPU (Ryse Son of Rome Global illuminatión physicall based) pudiera escribirse al mismo tiempo y de manera simultanea a la de la sombra de un mapa. Tachán! recursos gratis. Estás usando de manera mucho más eficiente tus Teraflops de base.

Coger lo q ha dicho una persona en un foro y ponerlo en otra como si fuera una idea propia se le llama PLAGIAR, y si encima solo copias lo q te interesa para intentar darle sentido para q se amolde a lo q quieres...se llama MENTIR. Párrafo de sebbi, ilustre usuario del foro beyond3D (Lead Programmer de RedLynx, q hace poco por cierto le han hecho una entrevista en Digital Foundry):

Good example of this is shadow map rendering. It is bound by fixed function hardware (ROPs and primitive engines) and uses very small amount of ALUs (simple vertex shader) and very small amount of bandwidth (compressed depth buffer output only, reads size optimized vertices that don't have UVs or tangents). This means that all TMUs and huge majority of the ALUs and bandwidth is just idling around while shadows get rendered. If you for example execute your compute shader based lighting simultaneously to shadow map rendering, you get it practically for free. Funny thing is that if this gets common, we will see games that are throttling more than Furmark, since the current GPU cooling designs just haven't been designed for constant near 100% GPU usage (all units doing productive work all the time).

Palabra por palabra, pero es q en ese caso no se está refiriendo a XboxOne en concreto, la conversación viene de la computación asíncrona GPGPU y de las tareas gráficas. Seguid dándole bola y haciéndole caso... A parte lo q dice es precisamente lo q hacen los ACEs.

Szasz escribió:Polyteres, ¿Crees q dx12 es únicamente una API "close to metal"? El mantle de Microsoft.

Si es así, entiendo q no debería tener mayor importancia en Xbox One, ya q es un sistema cerrado.

Un saludo

Algo así, si. El problema es q hacer algo a más bajo nivel tb acarrea problemas, las cosas se vuelven bastante mas complejas pq tienes q gestionar muchos mas recursos de forma manual. Las gallinas q entran por las q salen xD. De hecho en la famosa entrevista con los ingenieros de XboxOne de Digital Foundry dejan alguna pinceladas al respecto.

@Zokormazo y aunq parezca mas complicado es mejor q sea así y sea el propio programador quien lo maneje .

Un saludo.

Forzimbras escribió:

Polyteres escribió:Buenas gente. @Forzimbras Flashbackman360 es el ingeniero del que hablabas?. El q ha participado en el desarrollo del SoC de XboxOne?.

¿FlasBackMan360? Ni lo conozco ni he hablado jamás con él. Pero que participó en el diseño del SoC es tan real como que escribe en varios lugares donde también lo hacen ex compañeros suyos, que sí son los que me han explicado del tema (él ya no trabaja ni en su mismo departamento) y me han hablado de él.

Romcol escribió:

Forzimbras escribió:

Polyteres escribió:Buenas gente. @Forzimbras Flashbackman360 es el ingeniero del que hablabas?. El q ha participado en el desarrollo del SoC de XboxOne?.

¿FlasBackMan360? Ni lo conozco ni he hablado jamás con él. Pero que participó en el diseño del SoC es tan real como que escribe en varios lugares donde también lo hacen ex compañeros suyos, que sí son los que me han explicado del tema (él ya no trabaja ni en su mismo departamento) y me han hablado de él.

¿O sea que segun tu, FlashBackMan360 participo en el diseño de la One?

NDAs aparte, se supone que todo aquel que participo en el desarrolo de la consola tiene en su casa una de estas, no?



¿Y que habra cobrado y cobra un buen sueldo por ello?

Entonces explicame esto:

viewtopic.php?p=1735441261
viewtopic.php?p=1735331725

Y para el que no crea que se trate del mismo usuario:

http://www.3djuegos.com/comunidad-foros ... je29834712
viewtopic.php?p=1706093080

Vamos, que estas diciendo que, FlashBackMan360 participo en el diseño del main soc de la One, que Microsoft se olvido de darle su I MADE THIS edition y encima, el pobre tiene que ir rebuscando por los foros de compra-venta una One y un carga y juega de segunda mano por que le pagan una mierda?

Szasz escribió:¿Por que hay tanta gente diciendo que tiene un impacto notable en el rendimiento de Xbox One?

Szasz escribió:¿Por que tantas alabanzas de Nvidia, AMD e intel si hace lo mismo que Mantle?

Polyteres escribió:Buenas gente.

Szasz escribió:¿Por que hay tanta gente diciendo que tiene un impacto notable en el rendimiento de Xbox One?

Pues pq habrá una mejora en el rendimiento como es lógico, es decir, cada nueva versión del SDK de cualquier máquina DEBE mejorar la gestión de la misma, por lo q si sigues mejorando el SDK de tu máquina el rendimiento de está mejorará proporcionalmente con ellos. Pero para eso no habrá q esperar a q salga DirectX 12, cada nueva iteración sobre los kits de desarrollo será mejor q la anterior.

Szasz escribió:¿Por que tantas alabanzas de Nvidia, AMD e intel si hace lo mismo que Mantle?

Pq Mantle es exclusiva para arquitecturas GCN de AMD. Las mejoras de DirectX tienen mucho mucho q ver con cómo maneja el SO y el driver los recursos, por lo q el trabajo "debe" recaer sobre todo en esa parte y de esa parte se encarga Ms. No me extrañaría mucho q DirectX 12 solo fuera compatible con una nueva versión de Windows por cambiar la forma de trabajar del driver...

Un saludo.

Polyteres escribió:Buenas gente.

Szasz escribió:¿Por que hay tanta gente diciendo que tiene un impacto notable en el rendimiento de Xbox One?

Pues pq habrá una mejora en el rendimiento como es lógico, es decir, cada nueva versión del SDK de cualquier máquina DEBE mejorar la gestión de la misma, por lo q si sigues mejorando el SDK de tu máquina el rendimiento de está mejorará proporcionalmente con ellos. Pero para eso no habrá q esperar a q salga DirectX 12, cada nueva iteración sobre los kits de desarrollo será mejor q la anterior.

Szasz escribió:¿Por que tantas alabanzas de Nvidia, AMD e intel si hace lo mismo que Mantle?

Pq Mantle es exclusiva para arquitecturas GCN de AMD. Las mejoras de DirectX tienen mucho mucho q ver con cómo maneja el SO y el driver los recursos, por lo q el trabajo "debe" recaer sobre todo en esa parte y de esa parte se encarga Ms. No me extrañaría mucho q DirectX 12 solo fuera compatible con una nueva versión de Windows por cambiar la forma de trabajar del driver...

Un saludo.