Zokormazo escribió:Que virtualmente sea indistiguinble te esta diciendo implicitamente que no es un win8 al uso, que es distinto aunque en capas altas de soft pueda comportarse de manera identica.. Tampoco me creo que los calls de esos guest que funcionan sobre el host sean identicos a los de win8 normal donde la misma so pasa los calls al hard sin un host de por medio.
Que los SOs guests llevan kernel win8 no hay duda. Que a capa alta seran muy parecidos a win8 en muchos aspectos (la de gaming en APIs al menos, la otra en muchas mas cosas) tampoco hay duda.
Pero de ahi a que los Win8 que lleva xbox one sean identicos a los de PC, ejem. Ya puede decir misa ese articulo, que seguro que no lo son.
Y obviamente es far to metal. Very far. De hecho el guest SO donde los juegos estan jailbreakeados no tienen acceso directo al metal.
eloskuro escribió:Zokormazo escribió:Que virtualmente sea indistiguinble te esta diciendo implicitamente que no es un win8 al uso, que es distinto aunque en capas altas de soft pueda comportarse de manera identica.. Tampoco me creo que los calls de esos guest que funcionan sobre el host sean identicos a los de win8 normal donde la misma so pasa los calls al hard sin un host de por medio.
Que los SOs guests llevan kernel win8 no hay duda. Que a capa alta seran muy parecidos a win8 en muchos aspectos (la de gaming en APIs al menos, la otra en muchas mas cosas) tampoco hay duda.
Pero de ahi a que los Win8 que lleva xbox one sean identicos a los de PC, ejem. Ya puede decir misa ese articulo, que seguro que no lo son.
Y obviamente es far to metal. Very far. De hecho el guest SO donde los juegos estan jailbreakeados no tienen acceso directo al metal.
O_o
Tiene su sistema operativo y su version de DX12 creados ex profeso para Xbox One. Posiblemente hayan sacrificado algo de close to the metal, pero es el DX mas near to the metal que hay. Más aún en Xbox One al ser un hardware cerrado.
Es de lógica que pasar de PC a Xbox One es facil. Port con las mismas apis que en PC, pero si el desarrollador se lo quiere currar, teines todas las herramientas necesarias para ir todo lo near to the metal que quieras. Eso ya se explicó.
La API esta vez te dejaba esa ventana abierta.
papatuelo escribió:eloskuro escribió:Zokormazo escribió:Que virtualmente sea indistiguinble te esta diciendo implicitamente que no es un win8 al uso, que es distinto aunque en capas altas de soft pueda comportarse de manera identica.. Tampoco me creo que los calls de esos guest que funcionan sobre el host sean identicos a los de win8 normal donde la misma so pasa los calls al hard sin un host de por medio.
Que los SOs guests llevan kernel win8 no hay duda. Que a capa alta seran muy parecidos a win8 en muchos aspectos (la de gaming en APIs al menos, la otra en muchas mas cosas) tampoco hay duda.
Pero de ahi a que los Win8 que lleva xbox one sean identicos a los de PC, ejem. Ya puede decir misa ese articulo, que seguro que no lo son.
Y obviamente es far to metal. Very far. De hecho el guest SO donde los juegos estan jailbreakeados no tienen acceso directo al metal.
O_o
Tiene su sistema operativo y su version de DX12 creados ex profeso para Xbox One. Posiblemente hayan sacrificado algo de close to the metal, pero es el DX mas near to the metal que hay. Más aún en Xbox One al ser un hardware cerrado.
Es de lógica que pasar de PC a Xbox One es facil. Port con las mismas apis que en PC, pero si el desarrollador se lo quiere currar, teines todas las herramientas necesarias para ir todo lo near to the metal que quieras. Eso ya se explicó.
La API esta vez te dejaba esa ventana abierta.
Zocomarzo, dice que los calls lo hace un segundo Windows 8 centrado en solo ejecutar los juegos.
El primer tier, el Host OS. Presente en la Xbox One, este sistema es un RTOS (Real Time Operating System) y este tiene el control completo del hardware y recursos de la Xbox One. En las palabras de Frank Savage “…este es dueño de todo y de como funciona en la consola… es dueño del CPU, GPU, etc…”. Este OS es la base de como funciona Xbox One. Sin embargo, la cosa es la siguiente. Este sistema en particular, solo te encarga de tareas fijadas por el fabricante y de la capa de seguridad. Este no corre ningún juego o aplicación de por si. Lo que si hace es, contener (no en una forma de hipervisor) el OS y el OS Exclusivo, que serian en este caso, Windows 8 y una versión recortada de Windows 8.
El segundo tier, es una partición compartida (Shared Partition). Esta es ocupada por Windows 8. Este sistema operativo es virtualmente indistinguible del Windows 8 que conocemos, por el lado del código. Este particular Windows 8 se encarga de todas las funciones básicas de Xbox One incluyendo la shell o terminal. Las aplicaciones compartidas corren dentro de este. También maneja algunas de las características principales de los juegos como control de redes y algo de audio.
El tercer tier, es una partición exclusiva (Exclusive Partition). Este seria el Exclusive OS, que en palabras de Frank Savage es “un Windows 8 que ha entrado en una gran, pero gran dieta…. Windows 8 limpio y duro)”. Este OS ha sido tuneado y se han removido la gran mayoría, si es que no todas, las características que puedan producir algún cuello de botella así como también el Bloatware. Sin embargo esta es la parte que este se define como una partición y no una maquina virtual. Todas las peticiones de dibujo de DirectX van directamente desde el Exclusive OS hasta el Host OS. Estas no pasan por la partición compartida al Windows 8 completo.
Básicamente, la Xbox One es una maquina verdaderamente basada en X86, X86-64. Como dijo Frank Savage, “cualquiera de los juegos que yo haga correrán de igual forma en Windows 8 (escritorio) y en Xbox One”. La capacidad de portar juegos de una plataforma a otra es bastante probable, de hecho, se cree que Frank Savage dijo que el port-lag es algo inexistente (demora de parte de los desarrolladores en entregar una versión para otra plataforma que no sea la oficial). Solo faltaria convencer a los desarrolladores y deberiamos poder obtener el juego en nuestra plataforma favorita en muy poco tiempo.
The third tier ‘Exclusive Partition’ is the Exclusive OS, which in Frank Savage’s words is a “windows 8 that has gone on a massive massive diet…… lean and mean windows 8″. It has been hand tuned to remove any and all bottlenecks as well as bloatware. However this is the part which defines it as a ‘partition’ and not a virtual machine. All the Direct X draw calls go straight from the Exclusive OS down to the Host OS.
papatuelo escribió:Dicen esto:The third tier ‘Exclusive Partition’ is the Exclusive OS, which in Frank Savage’s words is a “windows 8 that has gone on a massive massive diet…… lean and mean windows 8″. It has been hand tuned to remove any and all bottlenecks as well as bloatware. However this is the part which defines it as a ‘partition’ and not a virtual machine. All the Direct X draw calls go straight from the Exclusive OS down to the Host OS.
papatuelo escribió:Dicen esto:The third tier ‘Exclusive Partition’ is the Exclusive OS, which in Frank Savage’s words is a “windows 8 that has gone on a massive massive diet…… lean and mean windows 8″. It has been hand tuned to remove any and all bottlenecks as well as bloatware. However this is the part which defines it as a ‘partition’ and not a virtual machine. All the Direct X draw calls go straight from the Exclusive OS down to the Host OS.
Zokormazo escribió:@papatueto: sobre los calls en gaming...
El juego, hace los calls al Win8 gamer que lleva la xbox one como SO para gaming. Esos calls que hace el juego, seran identicos a los de un win8 al uso. Pero la forma de gestionar la ejecucion de esos calls que hace el juego por el SO no va a ser el habitual. Esos calls que recibe el SO guest los pasa al SO host que es el que los ejecuta sobre el metal.
Ese pase del so guest al so host no es habitual en un win8 al uso (a no ser que lo tengamos virtualizado). Tampoco usaran pura virtualizacion porque supondria un overhead inmenso. Lo mas probable y eficiente es que el win8 guest pase esos calls al so host mediante algun passthrougth atipico sobre Win8. Por lo tanto, los win8 guest (ambos, tanto gaming como apps), aunque virtualmente y a nivel de apis puedan parecer identicos a un win8, tienen sendas modificaciones, probablemente en ring 0 y 1.
@eloskuro: Ya puede ser el DX mas near to the metal que hayan hecho nunca, pero con esa compatibilidad y ese modelo de SOs host-guest que usan sobre xbox one hay capas y capas de soft entre el dev de juegos y el metal. Por lo tanto, es mas far to the metal que close.papatuelo escribió:Dicen esto:The third tier ‘Exclusive Partition’ is the Exclusive OS, which in Frank Savage’s words is a “windows 8 that has gone on a massive massive diet…… lean and mean windows 8″. It has been hand tuned to remove any and all bottlenecks as well as bloatware. However this is the part which defines it as a ‘partition’ and not a virtual machine. All the Direct X draw calls go straight from the Exclusive OS down to the Host OS.
Vamos, todos los calls DX pasan del Win8 guest, al RTOS host, que es quien pasa los calls al hardware. En Win8 PC, el propio SO es quien pasa los calls DX al hard, sin pasarselos a ningun otro SO ni milongadas varias. Por lo tanto el win8 de Xbox one y el de un PC son distintos en sus internals.
Zokormazo escribió:Ofc, deberian de serlo al menos. Si eso no lo discuto xD
Pero desde luego los dos guest basados en Win8 distan mucho de ser identicos al Win8 PC
Zokormazo escribió:Que virtualmente sea indistiguinble te esta diciendo implicitamente que no es un win8 al uso, que es distinto aunque en capas altas de soft pueda comportarse de manera identica.. Tampoco me creo que los calls de esos guest que funcionan sobre el host sean identicos a los de win8 normal donde la misma so pasa los calls al hard sin un host de por medio.
Que los SOs guests llevan kernel win8 no hay duda. Que a capa alta seran muy parecidos a win8 en muchos aspectos (la de gaming en APIs al menos, la otra en muchas mas cosas) tampoco hay duda.
Pero de ahi a que los Win8 que lleva xbox one sean identicos a los de PC, ejem. Ya puede decir misa ese articulo, que seguro que no lo son.
Y obviamente es far to metal. Very far. De hecho el guest SO donde los juegos estan jailbreakeados no tienen acceso directo al metal.
Minus ES Plus en Nextgen GPU (extrapolemos face to face a nivel de eficiencia por área duplicada)
16 rops modificados = 64 rops antiguos
1 F32 ACE = 32 ACE antiguo
tratamiento por bloque del GPU
X1 son 4 bloques: 2 Gfx + 2 COmpute (en esquema. 2azul 2morado)
PS4 es 1 bloque (1 Gfx + 8 ACE)
Bueno, dicho esto vamos a aclarar lo siguiente:
Los ACE de XBox One no están en ACE's, es por eso que se le llaman "Compute CP" Haríais bien de mirar las diapositivas de Mike Mantor o la diapositiva "negra" que colgue yo de Bryan, para entender el concepto.
La nueva ACE está seleccionada en base al tratamiento del mapa HSA, hay que ver como el tratamiento del CU está dispuesto ahí puesto que la comunicación está dispuesta a través del thread, y no como parte grande del pool del CU, lo cual encaja con la visión e interpretación del hardware nativo DX12 a partir de las r9 300 y su encapsulado de datos.
Cada paquete de datos encapsulado son controlados por 1 hilo del CPU y el hilo de computo de XBox One para el CPU tal y como hemos dicho en otros post alcanza los 6 ops per core y puesto que son 8 Cores "modificados" AMD Jaguar x86-64, en 2 clusters de 4 cores con modificaciones en/y/hacia la memoria compartida y el ancho de banda, alcanzan 48 ops/c en total, 24 por hilo, 24 por cluster.
Entonces es sencillísimo extrapolar y estimar que el numero de CU eficiente es de al menos 24CU por cada unidad de Compute CP del CPU, 24 threads per Compute.
Así pues Bryan Negro & Mike Mantor sugieren la nueva forma de entender el ACE está a solo en 1 bloque llamado como F32 (hilo flotante 32)
No es solo optimizar las colas, no es solo optimizar el entendimiento per CU, no es tan sencillo y simple, XBox One tiene duplicados los CU, pero no toda la piscina, sólo dobla las áreas referentes al GPGPU y dejan la forma de calcular actualmente los cálculos de propósito general de lado y los ACE en XBox One ya no son ACE's propiamente dichos. Y es por eso por lo cual se necesitan 768 ALU's*2 y es por eso que MS sólo menciona 768 ALU's
En resumidas cuentas, DX12 demuestra que potencia de forma drástica el CPU. El CPU se ve apoyado con GPGPU que también puede ser potenciado
El GPGPU en XBox One es nativo DX12, paraleliza todos los CU
El GPGPU en PS4 es a través de solo 4CU dedicados fortalecidos por ACE's extra
X1 12GFX 12GPGPU se beneficia de la optimización por microcódigo sensible a nivel de hardware
PS4 14GFX 4GPGPU se beneficiará de cierta optimización por microcódigo sensible a nivel de software
KinderRey escribió:Respecto a lo señalado en negrita: las llamadas al hardware en el Game OS (el Win8 minimalista) son directas, sin pasar por el Host.
Lo del Win8 completo tampoco me lo creo, tendrá mucho en común pero muchos servicios es imposible que sean iguales, no tendría sentido. Sin duda tendrá mucho en común pero no todo. Lo interesante es que al estar todo el sistema virtualizado, en un futuro podrán desechar W8 y meterle W9 sin preocuparse por compatibilidades con los juegos lanzados hasta la fecha. Es más, el Game OS basado en W8 también podrán reescribirlo totalmente ya que cada juego se distribuye con su propia versión de GameOS incluida en el disco o en la descarga digital.
framed escribió:Por algunos comentarios, me da la sensación de que la gente imagina el mismo windows 8 (al completo) de sus ordenadores metido en la Xbox One.
Forzimbras escribió:El W8 de One es exactamente el mismo W8 de PC solo que sin las apps que son del todo prescindibles en One, porque por sus funciones, no servirían de nada (como es lógico, no le van a meter Word, PowerPoint, etc a un W8 enfocado al gaming). En resumidas cuentas: la arquitectura base es la misma, solo que desprovista deliberadamente de todo aquello que no le es de utilidad.
papatuelo escribió:Más trabajo:
FlashBackMan360:Minus ES Plus en Nextgen GPU (extrapolemos face to face a nivel de eficiencia por área duplicada)
16 rops modificados = 64 rops antiguos
1 F32 ACE = 32 ACE antiguo
tratamiento por bloque del GPU
X1 son 4 bloques: 2 Gfx + 2 COmpute (en esquema. 2azul 2morado)
PS4 es 1 bloque (1 Gfx + 8 ACE)
Bueno, dicho esto vamos a aclarar lo siguiente:
Los ACE de XBox One no están en ACE's, es por eso que se le llaman "Compute CP" Haríais bien de mirar las diapositivas de Mike Mantor o la diapositiva "negra" que colgue yo de Bryan, para entender el concepto.
La nueva ACE está seleccionada en base al tratamiento del mapa HSA, hay que ver como el tratamiento del CU está dispuesto ahí puesto que la comunicación está dispuesta a través del thread, y no como parte grande del pool del CU, lo cual encaja con la visión e interpretación del hardware nativo DX12 a partir de las r9 300 y su encapsulado de datos.
Cada paquete de datos encapsulado son controlados por 1 hilo del CPU y el hilo de computo de XBox One para el CPU tal y como hemos dicho en otros post alcanza los 6 ops per core y puesto que son 8 Cores "modificados" AMD Jaguar x86-64, en 2 clusters de 4 cores con modificaciones en/y/hacia la memoria compartida y el ancho de banda, alcanzan 48 ops/c en total, 24 por hilo, 24 por cluster.
Entonces es sencillísimo extrapolar y estimar que el numero de CU eficiente es de al menos 24CU por cada unidad de Compute CP del CPU, 24 threads per Compute.
Así pues Bryan Negro & Mike Mantor sugieren la nueva forma de entender el ACE está a solo en 1 bloque llamado como F32 (hilo flotante 32)
No es solo optimizar las colas, no es solo optimizar el entendimiento per CU, no es tan sencillo y simple, XBox One tiene duplicados los CU, pero no toda la piscina, sólo dobla las áreas referentes al GPGPU y dejan la forma de calcular actualmente los cálculos de propósito general de lado y los ACE en XBox One ya no son ACE's propiamente dichos. Y es por eso por lo cual se necesitan 768 ALU's*2 y es por eso que MS sólo menciona 768 ALU's
En resumidas cuentas, DX12 demuestra que potencia de forma drástica el CPU. El CPU se ve apoyado con GPGPU que también puede ser potenciado
El GPGPU en XBox One es nativo DX12, paraleliza todos los CU
El GPGPU en PS4 es a través de solo 4CU dedicados fortalecidos por ACE's extra
X1 12GFX 12GPGPU se beneficia de la optimización por microcódigo sensible a nivel de hardware
PS4 14GFX 4GPGPU se beneficiará de cierta optimización por microcódigo sensible a nivel de software
Zokormazo escribió:Forzimbras escribió:El W8 de One es exactamente el mismo W8 de PC solo que sin las apps que son del todo prescindibles en One, porque por sus funciones, no servirían de nada (como es lógico, no le van a meter Word, PowerPoint, etc a un W8 enfocado al gaming). En resumidas cuentas: la arquitectura base es la misma, solo que desprovista deliberadamente de todo aquello que no le es de utilidad.
Y como interactua un guest w8 normal y corriente con ese rtos que tiene de host? Como pasa los calls directamente al hardware?
Lo de que es un W8 de PC tal cual sin apps no cuadra con el resto del modelo de soft. Como va a ser la arquitectura de soft basica igual en PC y en xone si estamos hablando de un paradigma muy distinto?
Un SO que trabaja solo vs dos SO guest dentro de un host RTOS con acceso directo al hard por parte de los guests? Es esto posible con un W8 normal y corriente? NO.
Dudo mucho que un W8 vanilla traiga esas features.
Win 8 PC
=======
hard -> kernel y drivers win 8 -> userspace
Xbox one
========
/---> win 8 gaming guest -> userspace
hard -> RTOS
\---> win 8 apps guest -> userspace
chris76 escribió:Que en ps4 se utilice 14CUs para render y 4 CUs para gpgpu eso lo a dicho hasta el mismo marck Cerny arquitecto de ps4,de lo de one pues ni idea pero yo en los diagramas no veo aces y si los 4 modulos que dice flasbackman sin saber si llevara razon o que
KinderRey escribió:chris76 escribió:Que en ps4 se utilice 14CUs para render y 4 CUs para gpgpu eso lo a dicho hasta el mismo marck Cerny arquitecto de ps4,de lo de one pues ni idea pero yo en los diagramas no veo aces y si los 4 modulos que dice flasbackman sin saber si llevara razon o que
¿8 ACE con 64 colas en total para 4 CU dedicadas? No creo eh.
Lo que Cerny diría (que no lo sé) es que aconseja una configuración 14+4 dedicadas. Pero eso no quiere decir que las otras 14 nunca se usen para GPGPU.
Lo del Windows completo está claro que no, y la app o juego de turno tendrá que ser recompilado para correr bien en la Shared Partition, bien en la Exclusive Partition, Game OS o como queráis llamarlo. Pero el código apenas requerirá cambios (filosofía WOCA para las plataformas Msft)
Zokormazo escribió:Si han sido medianamente listos y con la experiencia que tienen sobre x86_64, probablemente se podra hacer un port rapido solo con decirle a vs que use xboxone como platform en vez de pc.
optoma escribió:Zokormazo escribió:Si han sido medianamente listos y con la experiencia que tienen sobre x86_64, probablemente se podra hacer un port rapido solo con decirle a vs que use xboxone como platform en vez de pc.
Pues conozco a mas de uno que con ryse en pc llorarian de alegria
KinderRey escribió:papatuelo escribió:Más trabajo:
FlashBackMan360:Minus ES Plus en Nextgen GPU (extrapolemos face to face a nivel de eficiencia por área duplicada)
16 rops modificados = 64 rops antiguos
1 F32 ACE = 32 ACE antiguo
tratamiento por bloque del GPU
X1 son 4 bloques: 2 Gfx + 2 COmpute (en esquema. 2azul 2morado)
PS4 es 1 bloque (1 Gfx + 8 ACE)
Bueno, dicho esto vamos a aclarar lo siguiente:
Los ACE de XBox One no están en ACE's, es por eso que se le llaman "Compute CP" Haríais bien de mirar las diapositivas de Mike Mantor o la diapositiva "negra" que colgue yo de Bryan, para entender el concepto.
La nueva ACE está seleccionada en base al tratamiento del mapa HSA, hay que ver como el tratamiento del CU está dispuesto ahí puesto que la comunicación está dispuesta a través del thread, y no como parte grande del pool del CU, lo cual encaja con la visión e interpretación del hardware nativo DX12 a partir de las r9 300 y su encapsulado de datos.
Cada paquete de datos encapsulado son controlados por 1 hilo del CPU y el hilo de computo de XBox One para el CPU tal y como hemos dicho en otros post alcanza los 6 ops per core y puesto que son 8 Cores "modificados" AMD Jaguar x86-64, en 2 clusters de 4 cores con modificaciones en/y/hacia la memoria compartida y el ancho de banda, alcanzan 48 ops/c en total, 24 por hilo, 24 por cluster.
Entonces es sencillísimo extrapolar y estimar que el numero de CU eficiente es de al menos 24CU por cada unidad de Compute CP del CPU, 24 threads per Compute.
Así pues Bryan Negro & Mike Mantor sugieren la nueva forma de entender el ACE está a solo en 1 bloque llamado como F32 (hilo flotante 32)
No es solo optimizar las colas, no es solo optimizar el entendimiento per CU, no es tan sencillo y simple, XBox One tiene duplicados los CU, pero no toda la piscina, sólo dobla las áreas referentes al GPGPU y dejan la forma de calcular actualmente los cálculos de propósito general de lado y los ACE en XBox One ya no son ACE's propiamente dichos. Y es por eso por lo cual se necesitan 768 ALU's*2 y es por eso que MS sólo menciona 768 ALU's
En resumidas cuentas, DX12 demuestra que potencia de forma drástica el CPU. El CPU se ve apoyado con GPGPU que también puede ser potenciado
El GPGPU en XBox One es nativo DX12, paraleliza todos los CU
El GPGPU en PS4 es a través de solo 4CU dedicados fortalecidos por ACE's extra
X1 12GFX 12GPGPU se beneficia de la optimización por microcódigo sensible a nivel de hardware
PS4 14GFX 4GPGPU se beneficiará de cierta optimización por microcódigo sensible a nivel de software
Si lo que dice tiene cierto sentido pero lo enrevesa mucho. Los CP están muy modificados (cómo exactamente es un misterio) y los ACE también. Pero son 2 ACE con 8 colas cada uno, y eso lo confirmaron los arquitectos de la One en la famosa entrevista de DF. Que son ACE más eficientes que el estándard GCN, seguro. Que los CU gestionan los ciclos de GPGPU de forma peculiar, seguro. Pero no son 64 ACE ni 24 CU como dice, ni tampoco es cierto que PS4 (perdón) sólo haga GPGPU en 4 CU, lo hace en todos.
También se le olvida que las tareas de GPGPU de Kinect se realizan en la GPU...
Por partes, para que se entiendan conceptos.
No sirve de nada extrapolar arquitectura actual con la de nuevo paradigma, evidentemente por un lado se requiere una optimización de ops/c pero eso es parte del actual GCN 1.0, son técnicas que se usan en C++ desde hace años y la optimización de microcódigo en GCN y a través de DX11.2 viene de ahí.
No deja de ser una mejora de la drawcall que aprovecha la optimización del CU dedicado a GPGPU en base a conceptos FPU. 12CU simples no son capaces de paralelizar nada sólo con optimización de ops.
Sería irreal y fantasioso lo que todo el mundo está diciendo que es capaz de hacer la XBox One con DX12, puesto que de ser así, la máquina solo daría un 25% más siendo generosos. Esto no tiene nada que ver con lo que yo explico en éstos documentos y agradecería que la gente "los leyera" antes de hacerse ideas.
Voy a intentar dejarlo claro de una vez.
papatuelo escribió:El foro está para eso, si no dice nada coherente explica por qué, eres libre de hacerlo. De hecho te lo agradeceríamos.
Polyteres escribió:Buenas gente. Me había impuesto a mi mismo no participar demasiado (nada) en este hilo, pero esto ya es tela fina. Con todos mis respetos, FlashBackMan360 no dice nada coherente.
Un saludo.
futuro mad max escribió:
futuro mad max escribió:
Me gustaria saber que mente enferma da vida a ese blog troll
papatuelo escribió:El foro está para eso, si no dice nada coherente explica por qué, eres libre de hacerlo. De hecho te lo agradeceríamos.
Con respecto al tema en sí. Pq no dice nada coherente?. Para empezar pq muchas de las cosas no tienen sentido ni siquiera a nivel léxico. En algunas ocasiones he tenido que leer varias veces alguna frase pq no tenía ni idea a lo que se estaba refiriendo, por la mezcla de conceptos... es como si leyeras una traducción de Google. Me da la sensación que se limita a traducir lo que dice mixstermedia. Y ya entrando en materia hay cosas mezcladas, cosas sacadas de la manga, otras que son un disparate...
Por ejemplo:No sirve de nada extrapolar arquitectura actual con la de nuevo paradigma, evidentemente por un lado se requiere una optimización de ops/c pero eso es parte del actual GCN 1.0, son técnicas que se usan en C++ desde hace años y la optimización de microcódigo en GCN y a través de DX11.2 viene de ahí.
es q no se quiere decir . Habla de compiladores?. De operaciones por ciclo?. Pq mete C++?. Las GPUs de la generación de Xbox360/Ps3 eran muy sensibles al como se ejecutaban las distintas tareas, como empaquetaras ciertos datos, como usaras el paso de varibles entre los shaders, cuando leer una textura para ocultar latencias... Pero todo eso ha quedado atrás, en la arquitectura GCN no es necesario ser tan "tiquismiquis" con las instrucciones debido a como están diseñadas (con arquitecturas anteriores de AMD por ejemplo basadas en VLIW el como y donde poner las instrucciones era VITAL). No obstante todo esto se hace a nivel de hardware y driver.No deja de ser una mejora de la drawcall que aprovecha la optimización del CU dedicado a GPGPU en base a conceptos FPU.
En todo caso sería: no deja de ser una mejora en los drawcall que aprovechan la optimización de las CUs dedicadas a GPGPU en base a conceptos FPU. Pero es q esto...FPU (flotating point unit), en base a conceptos de FPU??? CUs dedicadas a GPGPU exclusivamente?.12CU simples no son capaces de paralelizar nada sólo con optimización de ops.
. Solo con esa frase te das cuenta de que lo que dice no tiene ni pies ni cabeza. Que tiene que ver la optimización a nivel de operaciones con la paralelización de diferente granularidad???.16 rops modificados = 64 rops antiguos
Las ROPs son ROPs, no han cambiado mucho a lo largo de los años pq no hay mucho que cambiar. Es funcionalidad fija dentro de una GPU y tienen un trabajo muy específico que no varía de una generación a otra. Esto está ya muy trillado y no hay practicamente ningún margen de mejora. Les llegan fragmentos de los fragment/pixels shaders, Z Cull, resuelven las transparencias, resuelven el AA y escriben el pixel resultante en su caché o lo envían a traves de su controlador de memoria a donde corresponda. La cantidad de pixeles que son capaces de escribir por segundo es siempre el mismo: numero de ROPs x frecuencia, eso no cambia nunca. No hay cambios revolucionarios entre saltos generacionales pq todo está mas o menos inventado.
Las ROPs suelen ser un factor limitante y se están buscando formas de no usarlas (por ejemplo usando un compute shaders que escribe directamente en memoria y no usa las ROPs), siempre es preferible que te sobren y estés limitado por el ancho de banda que te falten y estés limitado por ROPs (tendrías que bajar la resolución del buffer por ejemplo).1 F32 ACE = 32 ACE antiguo
Esto se lo saca directamente de la manga pq el lo vale.tratamiento por bloque del GPU
no se q quiere decir con esto.X1 son 4 bloques: 2 Gfx + 2 COmpute (en esquema. 2azul 2morado)
PS4 es 1 bloque (1 Gfx + 8 ACE)
No. Otra cosa sin sentido. Bloques, que bloques?. XboxOne no es la única q tiene 2 Command Graphics, Ps4 tb tiene 2 (no solo 1 como dice, uno de ellos es capaz de despachar solo gráficos, y el otro tanto gráficos como GPGPU), de distinta prioridad, pero como dije en su momento hace ya tiempo, uno de ellos se usa para el juego en si y el otro para el SO.Los ACE de XBox One no están en ACE's, es por eso que se le llaman "Compute CP" Haríais bien de mirar las diapositivas de Mike Mantor o la diapositiva "negra" que colgue yo de Bryan, para entender el concepto.
La nueva ACE está seleccionada en base al tratamiento del mapa HSA, hay que ver como el tratamiento del CU está dispuesto ahí puesto que la comunicación está dispuesta a través del thread, y no como parte grande del pool del CU, lo cual encaja con la visión e interpretación del hardware nativo DX12 a partir de las r9 300 y su encapsulado de datos.
Cada paquete de datos encapsulado son controlados por 1 hilo del CPU y el hilo de computo de XBox One para el CPU tal y como hemos dicho en otros post alcanza los 6 ops per core y puesto que son 8 Cores "modificados" AMD Jaguar x86-64, en 2 clusters de 4 cores con modificaciones en/y/hacia la memoria compartida y el ancho de banda, alcanzan 48 ops/c en total, 24 por hilo, 24 por cluster.
Entonces es sencillísimo extrapolar y estimar que el numero de CU eficiente es de al menos 24CU por cada unidad de Compute CP del CPU, 24 threads per Compute.
Todo esto es q directamente no es posible. Está mezclando cosas de hardware y software, no sabe como funciona a nivel interno una GPU, ni una API de alto nivel, ni un driver. Las cosas no funcionan así. La CPU escribe comandos en un command buffer, estos se le pasan a la GPU y los ejecuta como una niña/o bueno. Que uno o varios núcleos puedan escribir sus propios command buffer y enviarselos a la GPU como pretende DirectX12 por ejemplo (o hacen actualmente otras APIs ya) es una cosa y otra es q tu manejes las CUs con cada hebra de tu CPU, esto es un disparate y no es ni posible ni viable ni lógico. La GPU es un procesador altamente pararelo y necesita de mecanismos específicos para manejar dicho paralelismo, no te los puedes saltar pq es hardware y son necesarios para funcionar.
Por otra parte los núcleos Jaguar de la CPU son capaces de retirar como máximo 2 instrucciones por ciclo, si tienes 8 núcleos tienes 16 instrucciones como máximo por ciclo. Cambiar el número de instrucciones que retiras por ciclo o IPC es jodidamente difícil y viene determinado por la arquitectura en sí de la CPU. Si es Jaguar, q lo es, retira 2 por ciclo no hay más.No es solo optimizar las colas, no es solo optimizar el entendimiento per CU, no es tan sencillo y simple, XBox One tiene duplicados los CU, pero no toda la piscina, sólo dobla las áreas referentes al GPGPU y dejan la forma de calcular actualmente los cálculos de propósito general de lado y los ACE en XBox One ya no son ACE's propiamente dichos. Y es por eso por lo cual se necesitan 768 ALU's*2 y es por eso que MS sólo menciona 768 ALU's
XboxOne no tiene duplicadas las CU ni tiene el doble de ALUs divididas en gráficos y GPGPU primero pq la familia es Sea Island (dicho por ellos) y segundo pq no es una solución correcta. La tendencia es dar cada vez mas flexibilidad a las CUs y para ello tienes q hacerlas cada vez mas generales. Que pasa si mi juego, o yo como desarrollador no quiero usar GPGPU?. O quiero usar toda la potencia de la GPU para procesar gráficos?. Desperdiciar espacio en unas ALUs que no tengan acceso al pipeline gráfico o q no se puedan usar para procesar gráficos es una tontería. Dame una ALU/CU q yo decida para q la quiero usar. Es mejor tener 12 CUs q yo decida balancear y usar como me plazca q estar limitado por una división 6+6 pq de esa forma solo podré usar 6 CUs para hacer gráficos. Es similar a lo q vimos con los shader unificados o los específicos q tenian Xbox360 y Ps3 respectivamente.El GPGPU en XBox One es nativo DX12, paraleliza todos los CU
El GPGPU en PS4 es a través de solo 4CU dedicados fortalecidos por ACE's extra
X1 12GFX 12GPGPU se beneficia de la optimización por microcódigo sensible a nivel de hardware
PS4 14GFX 4GPGPU se beneficiará de cierta optimización por microcódigo sensible a nivel de software
Los CUs se "parelelizan" solitos. Pocos kernels en CUDA, compute shaders o kernels en OpenCL ha escrito este hombre. El resto no tiene sentido.