Hablemos del interior de Xbox One

En serio, los astroturfers y su secta descerebrada da bastante asco, ignorar a esta gente y no les respondaís, que al final nos tenemos que tragar todos sus mierdas sectarias.
KinderRey escribió:Este hilo molaba. Ahora es otra mierda de Multi


+ [El poder de la nube]

[qmparto]
KinderRey escribió:Este hilo molaba. Ahora es otra mierda de Multi

estoy de acuerdo.
Para los q les guste atar cabos:

"At this year’s Game Developer Conference, Microsoft announced the next version of DirectX, namely DirectX 12, will be hitting next year across mobiles, Xbox One and PC. DirectX 12 will supposedly reduce CPU overload by 50% and aims to remove bottlenecks, especially for dual GPU configurations. Aljosha believes that this could definitely have a positive impact on the SDK’s performance."

http://gamingbolt.com/granite-sdk-inter ... middleware

¿2x más de potencia?!

http://www.gamepur.com/news/14235-devel ... signi.html
Buenas a todos!

Yo solo quiero decir que también existe la posibilidad de que XBOX ONE sea una "cagada".

De hecho es la historia que más se repite en la historia de las consolas, muy amenudo la cagan bien cagada jejeje.

SNES VS MEGADRIVE ==> Snes salió bastante después y podía haber machacado a MEGADRIVE pero el BUS de 8 bits del procesador hizo que MEGADRIVE pudiera plantarle cara durante casi toda su vida.

MEGACD ==> Sí en lugar de incluir otro procesador hubiera incluido una gráfica, podría haberle dado más colores/efectos a MEGADRIVE y los juegos se podrían haber diferenciado más a parte del SCALING.

32X ==> No solo fué una cagada. Encima supuso que se cancelara VIRTUA FIGHTER para megadrive... [buuuaaaa] [buuuaaaa]

3D0 ==> Era una buena idea sí, pero como era un estandar y las compañias que la fabricaban, tenian que ganar dinero con su venta y no con la posterior venta de juegos salio a... ¡¡¡¡¡700$!!!!! osea muerta antes de salir...

JAGUAR ==> Potente como ella sola, es verdad, pero compleja a rabiar y un mando que... XD ... Salió con cartucho y luego le metieron el CD etc etc..

SATURN VS PSX ==> Cuando sega vió a PSX en movimiento vió que tenía que aumentar la potencia de SATURN sí o sí, al final le metio dos procesadores en última hora y se convirtió en imposible de sacarle partido. Osea mal diseñada desde el principio (y es una de mis consolas preferidas jeje).

NINTENDO 64 ==> Demasiados efectos gráficos le pesaron mucho en la definición de las texturas, la carga poligonal y el framerate. Salió con cartucho lo que le costó perder la saga FINAL FANTASY entre otras...

360 VS PS3 ==> Un caso casi calcado de SATURN VS PSX. Sony iba a sacar PS3 sólo con el CELL.. en cuanto vió la potencia de 360 tuvieron que incorporarle rápido una gráfica o veían que se la comían con patatas.

FM-TOWNS MARTY | PC-FX | HYPERNEOGEO 64 | AMIGA CD32 | HYPERGRAPH | NEOGEO CD | NOMAD... etc etc etc etc

===============================================================================

Echando la vista atrás en la historia de las consolas es fácil ver la cantidad de cagadas de la industria ¿No es posible que M$ la haya cagado con ONE?

Dicho esto, yo soy de los que piensan que ONE, de verdad sí tiene una arquitectura "futurista" por la cantidad de información que hay.
No os ralléis más. DX12 no hace milagros de por sí, pero lo que si hará es hacer funcionar a la XO como debe, ya que el hardware se diseñó para funcionar en la forma en que lo hace la arquitectura DX12, con el paralelismo en mente. Por eso en PC las gráficas actuales se pueden actualizar drivers pero no es lo mismo, en XO es que el hardware se hizo para "encajar" literalmente con la forma en que DX12 trabaja.

Por poner un ejemplo, es como usar el compilador de Intel, el resultado que te saca está pensado para la forma en que la CPU Intel le viene bien de ordenar las instrucciones y datos, y vaya si se nota cuando se usa.

Si hay algo en que debería notarse el uso de DX12 en XO es empezar a ver los juegos a 60 fps, con un reparto equitativo de tareas por todo el hardware debería ser fácil no tener limitadores de velocidad y poder ir metiendo más y más hasta encontrar dicho limitador. A partir de encontrar ese punto justo la resolución dependerá de las pasadas de render y la complejidad de los shaders, pero ésta siempre podrá funcionar a tope sin nada que la esté limitando.

Por mucho que se diga pues sí, ahora mismo XO está "capada", pero puede que sea involuntario incluso. La idea claramente se ve era la de sacar la consola junto a DX12 porque es que el propio hardware está diseñado en base a éste. Así que ahora se tira de SDK DX11 a la antigua usanza para la cual no se ha diseñado, pero porque con algo hay que trabajar y era más fácil portar un SDK ya hecho y más que probado de PC (DX11) que intentar acabar a la prisa uno que no estaba listo, además de ser imposible adelantar un DX tanto tiempo sin que lo hagas una chapuza total.
Es decir, DX12 debe notarse y mucho en XO, lo que se dice incluso puede que no sea una exageración si nos atenemos a rendimiento global. Así que cuando se tenga es cuando se podrá empezar a hablar.
Chifrinillo escribió:Buenas a todos!

Yo solo quiero decir que también existe la posibilidad de que XBOX ONE sea una "cagada".

De hecho es la historia que más se repite en la historia de las consolas, muy amenudo la cagan bien cagada jejeje.

SNES VS MEGADRIVE ==> Snes salió bastante después y podía haber machacado a MEGADRIVE pero el BUS de 8 bits del procesador hizo que MEGADRIVE pudiera plantarle cara durante casi toda su vida.

MEGACD ==> Sí en lugar de incluir otro procesador hubiera incluido una gráfica, podría haberle dado más colores/efectos a MEGADRIVE y los juegos se podrían haber diferenciado más a parte del SCALING.

32X ==> No solo fué una cagada. Encima supuso que se cancelara VIRTUA FIGHTER para megadrive... [buuuaaaa] [buuuaaaa]

3D0 ==> Era una buena idea sí, pero como era un estandar y las compañias que la fabricaban, tenian que ganar dinero con su venta y no con la posterior venta de juegos salio a... ¡¡¡¡¡700$!!!!! osea muerta antes de salir...

JAGUAR ==> Potente como ella sola, es verdad, pero compleja a rabiar y un mando que... XD ... Salió con cartucho y luego le metieron el CD etc etc..

SATURN VS PSX ==> Cuando sega vió a PSX en movimiento vió que tenía que aumentar la potencia de SATURN sí o sí, al final le metio dos procesadores en última hora y se convirtió en imposible de sacarle partido. Osea mal diseñada desde el principio (y es una de mis consolas preferidas jeje).

NINTENDO 64 ==> Demasiados efectos gráficos le pesaron mucho en la definición de las texturas, la carga poligonal y el framerate. Salió con cartucho lo que le costó perder la saga FINAL FANTASY entre otras...

360 VS PS3 ==> Un caso casi calcado de SATURN VS PSX. Sony iba a sacar PS3 sólo con el CELL.. en cuanto vió la potencia de 360 tuvieron que incorporarle rápido una gráfica o veían que se la comían con patatas.

FM-TOWNS MARTY | PC-FX | HYPERNEOGEO 64 | AMIGA CD32 | HYPERGRAPH | NEOGEO CD | NOMAD... etc etc etc etc

===============================================================================

Echando la vista atrás en la historia de las consolas es fácil ver la cantidad de cagadas de la industria ¿No es posible que M$ la haya cagado con ONE?

Dicho esto, yo soy de los que piensan que ONE, de verdad sí tiene una arquitectura "futurista" por la cantidad de información que hay.



Tu calificas como cagadas algunas de las consolas que han dado los mejores juegos de la historia. Evidentemente no estoy de acuerdo con la mitad de esa lista que pones, y mucho menos con la posibilidad de que Xbox One sea una camada con 5 millones de ventas. Ha batido los récords de Microsoft y por mucho.

Este discurso me suena al de los Madridistas clamando el fin de ciclo del Barça porque "sólo" había ganado la copa y la liga. Una cosa es ser inconformista y otra es ser radical.
Szasz escribió:Para los q les guste atar cabos:

"At this year’s Game Developer Conference, Microsoft announced the next version of DirectX, namely DirectX 12, will be hitting next year across mobiles, Xbox One and PC. DirectX 12 will supposedly reduce CPU overload by 50% and aims to remove bottlenecks, especially for dual GPU configurations. Aljosha believes that this could definitely have a positive impact on the SDK’s performance."

http://gamingbolt.com/granite-sdk-inter ... middleware

¿2x más de potencia?!

http://www.gamepur.com/news/14235-devel ... signi.html


No he leido los links (toi en el curro, no puedo), pero lo que quoteas no dice que 2x potencia.

Dice que la carga de CPU debido a d3d se reduce en un 50%, especialmente en configuraciones de GPU dual. De ahi no se puede deducir ni mucho menos que la potencia/rendimiento de la consola tendra un incremento del 100%
hsaoud escribió:Tu calificas como cagadas algunas de las consolas que han dado los mejores juegos de la historia. Evidentemente no estoy de acuerdo con la mitad de esa lista que pones, y mucho menos con la posibilidad de que Xbox One sea una camada con 5 millones de ventas. Ha batido los récords de Microsoft y por mucho.

Este discurso me suena al de los Madridistas clamando el fin de ciclo del Barça porque "sólo" había ganado la copa y la liga. Una cosa es ser inconformista y otra es ser radical.


Hablo de cagadas en el DISEÑO y ARQUITECTURAS de las máquinas, no entro en el tema de los juegos ni el comercial.
Chifrinillo escribió:
hsaoud escribió:Tu calificas como cagadas algunas de las consolas que han dado los mejores juegos de la historia. Evidentemente no estoy de acuerdo con la mitad de esa lista que pones, y mucho menos con la posibilidad de que Xbox One sea una camada con 5 millones de ventas. Ha batido los récords de Microsoft y por mucho.

Este discurso me suena al de los Madridistas clamando el fin de ciclo del Barça porque "sólo" había ganado la copa y la liga. Una cosa es ser inconformista y otra es ser radical.


Hablo de cagadas en el DISEÑO y ARQUITECTURAS de las máquinas, no entro en el tema de los juegos ni el comercial.


Eso sí [chulito]
BiG Porras escribió:
Chifrinillo escribió:Eso sí [chulito]


Jeje es que precisamente yo que no toqué la PS2 ni con un palo y estuve 100% con la DREAMCAST y que mientras todos estaban con MEGADRIVE y SNES yo tenía una Turbografx y me tenía que ir a Madrid a alquilar los juegos [buuuaaaa] [buuuaaaa] [buuuaaaa] [buuuaaaa] [buuuaaaa] [buuuaaaa]
Zokormazo escribió:
Szasz escribió:Para los q les guste atar cabos:

"At this year’s Game Developer Conference, Microsoft announced the next version of DirectX, namely DirectX 12, will be hitting next year across mobiles, Xbox One and PC. DirectX 12 will supposedly reduce CPU overload by 50% and aims to remove bottlenecks, especially for dual GPU configurations. Aljosha believes that this could definitely have a positive impact on the SDK’s performance."

http://gamingbolt.com/granite-sdk-inter ... middleware

¿2x más de potencia?!

http://www.gamepur.com/news/14235-devel ... signi.html


No he leido los links (toi en el curro, no puedo), pero lo que quoteas no dice que 2x potencia.

Dice que la carga de CPU debido a d3d se reduce en un 50%, especialmente en configuraciones de GPU dual. De ahi no se puede deducir ni mucho menos que la potencia/rendimiento de la consola tendra un incremento del 100%


Lo q dice ese texto, es q dx12 reduce la carga de la cpu en un 50% y apunta a eliminar los cuellos de botella ESPECIALMENTE en configuraciones DUAL GPU.

Digo lo de atar cabos por q se habla de q Xbox one es una dual GPU en un único encapsulado (al menos muchos de sus elementos están duplicados). Si pensamos q una parte esta bloqueada por software y los desarrolladores están diciendo q dx12 aumenta en 2x la potencia, pues da q pensar.

Desde luego esto no es una confirmación de los hechos. Pero, para eso esta el hilo, para intentar descubrir la verdad. Y m parece una información interesante para compartir.

Un saludo.
Szasz escribió:Lo q dice ese texto, es q dx12 reduce la carga de la cpu en un 50% y apunta a eliminar los cuellos de botella ESPECIALMENTE en configuraciones DUAL GPU.

Digo lo de atar cabos por q se habla de q Xbox one es una dual GPU en un único encapsulado (al menos muchos de sus elementos están duplicados). Si pensamos q una parte esta bloqueada por software y los desarrolladores están diciendo q dx12 aumenta en 2x la potencia, pues da q pensar.

Desde luego esto no es una confirmación de los hechos. Pero, para eso esta el hilo, para intentar descubrir la verdad. Y m parece una información interesante para compartir.

Un saludo.


El rio ya no suena.. es que esto es el AMAZONAS!!!!!! [+furioso]
Chifrinillo escribió:
Szasz escribió:Lo q dice ese texto, es q dx12 reduce la carga de la cpu en un 50% y apunta a eliminar los cuellos de botella ESPECIALMENTE en configuraciones DUAL GPU.

Digo lo de atar cabos por q se habla de q Xbox one es una dual GPU en un único encapsulado (al menos muchos de sus elementos están duplicados). Si pensamos q una parte esta bloqueada por software y los desarrolladores están diciendo q dx12 aumenta en 2x la potencia, pues da q pensar.

Desde luego esto no es una confirmación de los hechos. Pero, para eso esta el hilo, para intentar descubrir la verdad. Y m parece una información interesante para compartir.

Un saludo.


El rio ya no suena.. es que esto es el AMAZONAS!!!!!! [+furioso]


De donde sacáis que la xbox es dual GPU?
Y reducir la carga de la cpu en un 50% no es duplicar la potencia.
Mamaun escribió:
Chifrinillo escribió:
Szasz escribió:Lo q dice ese texto, es q dx12 reduce la carga de la cpu en un 50% y apunta a eliminar los cuellos de botella ESPECIALMENTE en configuraciones DUAL GPU.

Digo lo de atar cabos por q se habla de q Xbox one es una dual GPU en un único encapsulado (al menos muchos de sus elementos están duplicados). Si pensamos q una parte esta bloqueada por software y los desarrolladores están diciendo q dx12 aumenta en 2x la potencia, pues da q pensar.

Desde luego esto no es una confirmación de los hechos. Pero, para eso esta el hilo, para intentar descubrir la verdad. Y m parece una información interesante para compartir.

Un saludo.


El rio ya no suena.. es que esto es el AMAZONAS!!!!!! [+furioso]


De donde sacáis que la xbox es dual GPU?
Y reducir la carga de la cpu en un 50% no es duplicar la potencia.


Parece que no has leido lo que el a escrito.

Dice que hay gente que dice que la gpu es dual. No que lo sea. Lo que está claro es que tiene "circuiteria" duplicada. Eso es un hecho(no confundir con 2 gpu).
Y no. Reducir la carga de la cpu un 50% no es duplicar la potencia. Solo se hacia eco de unos comentarios de devolpers diciendo que dx12 duplicaba la potencia de la xbox one.
El no dice que sea real. Solo deja los comentarios aqui para que los debatamos.

"it's not literally (it's software, not hardware) but yes, dx12 games will likely by more than 2x as fast."

"it didn't. It was/is still basically a single core stack. With DX12 all 8 cores will be able to split the work." clarified Brad.
eloskuro escribió:Parece que no has leido lo que el a escrito.

Dice que hay gente que dice que la gpu es dual. No que lo sea. Lo que está claro es que tiene "circuiteria" duplicada. Eso es un hecho(no confundir con 2 gpu).
Y no. Reducir la carga de la cpu un 50% no es duplicar la potencia. Solo se hacia eco de unos comentarios de devolpers diciendo que dx12 duplicaba la potencia de la xbox one.
El no dice que sea real. Solo deja los comentarios aqui para que los debatamos.

"it's not literally (it's software, not hardware) but yes, dx12 games will likely by more than 2x as fast."

"it didn't. It was/is still basically a single core stack. With DX12 all 8 cores will be able to split the work." clarified Brad.



Si lo he leído. Me gustaría saber de donde salen estas informaciones de esa "gente que dice que la gpu es dual."

A mi me parece una noticia fantástica si se confirma. Más potencia para un mismo hard. Y encima se podrá aplicar a PC :D
No, esas declaraciones salen de Brad Wardell tras asistir a una conferencia sobre directx 12, creo que en la Build de Microsoft.

Es fundador CEO de Stardock que hace el Bench Star Warm con el que suele testar el rendimiento de Mantle.

Aquí tienes su twitter:

https://twitter.com/draginol

Y la GPU no es dual, según dicen tiene logica dual y dos pipelines, que si me preguntas ni se lo que es. De la misma forma dicen que toda la arquitectura que es vitualizable y puede añadir nucleos lógicos que actúen como nucleos físicos. pero esos extremos no están ni minimamente confirmados.

Lo de la dual gpu sale de los primeros SDK que sacaron para las desarrolladoras que funcionaban en dev kit con dos 7970 en crossfire.
Sea o no sea para xbox one (que lo es), el directx12 es un buen adelanto, al menos por lo que comentan en general.

Tengo ganas de ver ya juegos reales funcionando con el dx12
Buenas gente. Como he dicho más de una vez con respecto al tema de la GPU Dual o desdoblada de forma lógica... Hay dos graphics proccessor uno para el Sistema Operativo y otro para el juego en sí mismo. Esto ayuda a que la reactividad del sistema sea mucho mejor, por ejemplo cuando vas al menú y dejas el juego en segundo plano, o cuando el sistema superpone algo en pantalla mientras que estás jugando. Si no me creeis a mí tan solo tenéis que ir a la entrevista que los arquitectos de XboxOne concedieron a Digital Foundry. Sacado de allí:

http://www.eurogamer.net/articles/digit ... -interview

One thing to keep in mind when looking at comparative game resolutions is that currently the Xbox One has a conservative 10 per cent time-sliced reservation on the GPU for system processing. This is used both for the GPGPU processing for Kinect and for the rendering of concurrent system content such as snap mode. The current reservation provides strong isolation between the title and the system and simplifies game development (strong isolation means that the system workloads, which are variable, won't perturb the performance of the game rendering). In the future, we plan to open up more options to developers to access this GPU reservation time while maintaining full system functionality.

To facilitate this, in addition to asynchronous compute queues, the Xbox One hardware supports two concurrent render pipes. The two render pipes can allow the hardware to render title content at high priority while concurrently rendering system content at low priority. The GPU hardware scheduler is designed to maximise throughput and automatically fills "holes" in the high-priority processing. This can allow the system rendering to make use of the ROPs for fill, for example, while the title is simultaneously doing synchronous compute operations on the Compute Units.


No hay más historia.

Un saludo.
Chifrinillo escribió:
El rio ya no suena.. es que esto es el AMAZONAS!!!!!! [+furioso]


Vamos a cabar todos ahogados...
O como minimo, hartos de agua... [noop]
Polyteres escribió:Buenas gente. Como he dicho más de una vez con respecto al tema de la GPU Dual o desdoblada de forma lógica... Hay dos graphics proccessor uno para el Sistema Operativo y otro para el juego en sí mismo. Esto ayuda a que la reactividad del sistema sea mucho mejor, por ejemplo cuando vas al menú y dejas el juego en segundo plano, o cuando el sistema superpone algo en pantalla mientras que estás jugando. Si no me creeis a mí tan solo tenéis que ir a la entrevista que los arquitectos de XboxOne concedieron a Digital Foundry. Sacado de allí:

http://www.eurogamer.net/articles/digit ... -interview

One thing to keep in mind when looking at comparative game resolutions is that currently the Xbox One has a conservative 10 per cent time-sliced reservation on the GPU for system processing. This is used both for the GPGPU processing for Kinect and for the rendering of concurrent system content such as snap mode. The current reservation provides strong isolation between the title and the system and simplifies game development (strong isolation means that the system workloads, which are variable, won't perturb the performance of the game rendering). In the future, we plan to open up more options to developers to access this GPU reservation time while maintaining full system functionality.

To facilitate this, in addition to asynchronous compute queues, the Xbox One hardware supports two concurrent render pipes. The two render pipes can allow the hardware to render title content at high priority while concurrently rendering system content at low priority. The GPU hardware scheduler is designed to maximise throughput and automatically fills "holes" in the high-priority processing. This can allow the system rendering to make use of the ROPs for fill, for example, while the title is simultaneously doing synchronous compute operations on the Compute Units.


No hay más historia.

Un saludo.


Ahora esa conferencia es fiable, cuando hacen alusión al computo en lanube y demás cosas no lo es...

Además que no dice que sea para el sistema operativo, dice que dos pipelines para priorizar unas u otras operaciones del sistema.
Una pregunta Polyteres, esos dos render pipes, serían lo mismo que se utiliza en un juego para renderizar en dos planos? Uno para el juego y otro para el HUD, por ejemplo. Cada uno con su propio framerate y/o resolución. Supongo que en ese caso, no tendrías disponible el segundo plano para el sistema operativo.

Teorías para la segunda GPU ha habido unas cuantas, pero sigo sin creer que exista esa segunda GPU.

Personalmente tengo ganas de ver qué puede hacer DX12, pero mirando más que nada PC, que es donde creo que va a haber un cambio importante de la forma de trabajar de la API.

Lo que me ha dejado descolocado es lo de la circuitería duplicada. ¿Cuál es esa circuitería duplicada?
colets escribió:Una pregunta Polyteres, esos dos render pipes, serían lo mismo que se utiliza en un juego para renderizar en dos planos? Uno para el juego y otro para el HUD, por ejemplo. Cada uno con su propio framerate y/o resolución. Supongo que en ese caso, no tendrías disponible el segundo plano para el sistema operativo.

Teorías para la segunda GPU ha habido unas cuantas, pero sigo sin creer que exista esa segunda GPU.

Personalmente tengo ganas de ver qué puede hacer DX12, pero mirando más que nada PC, que es donde creo que va a haber un cambio importante de la forma de trabajar de la API.

Lo que me ha dejado descolocado es lo de la circuitería duplicada. ¿Cuál es esa circuitería duplicada?


Creo que esta:

http://www.elotrolado.net/viewtopic.php?p=1735665048
papatuelo escribió:Ahora esa conferencia es fiable, cuando hacen alusión al computo en lanube y demás cosas no lo es...

Además que no dice que sea para el sistema operativo, dice que dos pipelines para priorizar unas u otras operaciones del sistema.


Buenas gente. Para mí esa entrevista siempre ha sido lo más fiable que hay junto con la conferencia que dieron en el HotChip pq viene directamente de quien viene, no de relaciones públicas o comunity managers. Por otra parte en esa entrevista no hablan de la computación en la nube, hablan de la arquitectura de XboxOne.

Los dos párrafos que he puesto dicen explícitamente para que se usan ambos graphics proccesors, uno para el render del sistema y otro para el render del juego, no le sigáis buscando tres pies al gato.

@colect mmm no exactamente. Una cosa son los Display Planes y otra los Command Proccessors. A groso modo, lo q el sistema tiene que pintar se envía al command proccessors de baja prioridad y cuando esto se pinta se "escribe" en el Display Plane reservado para el SO. Posteriormente ambas capas "se fusionan" si fuera necesario. XboxOne tiene 3 Display Planes, uno se lo come el SO y los otros dos pueden ser usados por el juego. No se si responde a tu pregunta xD.

Un saludo.
Polyteres escribió:Buenas gente. Como he dicho más de una vez con respecto al tema de la GPU Dual o desdoblada de forma lógica... Hay dos graphics proccessor uno para el Sistema Operativo y otro para el juego en sí mismo. Esto ayuda a que la reactividad del sistema sea mucho mejor, por ejemplo cuando vas al menú y dejas el juego en segundo plano, o cuando el sistema superpone algo en pantalla mientras que estás jugando. Si no me creeis a mí tan solo tenéis que ir a la entrevista que los arquitectos de XboxOne concedieron a Digital Foundry. Sacado de allí:

http://www.eurogamer.net/articles/digit ... -interview

One thing to keep in mind when looking at comparative game resolutions is that currently the Xbox One has a conservative 10 per cent time-sliced reservation on the GPU for system processing. This is used both for the GPGPU processing for Kinect and for the rendering of concurrent system content such as snap mode. The current reservation provides strong isolation between the title and the system and simplifies game development (strong isolation means that the system workloads, which are variable, won't perturb the performance of the game rendering). In the future, we plan to open up more options to developers to access this GPU reservation time while maintaining full system functionality.

To facilitate this, in addition to asynchronous compute queues, the Xbox One hardware supports two concurrent render pipes. The two render pipes can allow the hardware to render title content at high priority while concurrently rendering system content at low priority. The GPU hardware scheduler is designed to maximise throughput and automatically fills "holes" in the high-priority processing. This can allow the system rendering to make use of the ROPs for fill, for example, while the title is simultaneously doing synchronous compute operations on the Compute Units.


No hay más historia.

Un saludo.


No veo donde dice que un pipeline se reserve para las APPs o SO.

De reservar solo hablan del 10% que se guardan para GPGPU de Kinect y para el snap del SO.

Pero reservar un pipeline entero para eso? NO, no lo dicen, eso lo añades tú. Y oye, está muy bien que aportes datos, opines y demás, pero no vendas tus opiniones como datos oficiales. Si tu piensas que solo es para eso dilo, pero especifica que es tu opinión, no la vendas como info oficial porque eso es mentir y manipular la información.

Y eso está muy mal [toctoc]
NICK BACKER dice q La GPU es capaz de hacer operaciones de rendering al mismo tiempo que procesa información de la nube.

https://www.youtube.com/watch?v=vg_DR0leAYw

Minuto 25:32 seg.

También dice q la CPU de One es capaz de hacer 6 operaciones por ciclo. Dato q he visto negar más de una vez. (Minuto 25:17 seg)
Horizonte, yo por "system content" entiendo contenido del OS digamos (incorrectamente) "más win8": apps como skype, explorer, etc. Y más que reservar un pipeline, yo diría más bien que la idea es hacerlos funcionar en paralelo.

Gracias Polyteres, sí responde. Es decir, en el snap mode dos display planes podrían estar usados por el juego + HUD y el tercero para tu skype, tu peli o lo que sea. Con los tres funcionando al mismo tiempo. Una solución curiosa.

Gracias por el enlace papatuelo, no había seguido mucho ese tema.

Será que hoy me he levantado en modo escéptico, pero no le encuentro lógica alguna. Me explico:
A no ser que Microsoft haya encontrado una forma de hacer que su circuitería ocupe la mitad, lo importante debería ser el área que ocupan. Con esas dos imágenes jpg es imposible saber ese área real.

No sé, por poner un ejemplo chorra, si yo me llevo una docena de naranjas en una bolsa y tú te las llevas en dos bolsas, cada forma de llevarlas tendrá sus ventajas e incovenientes, pero al final los dos podremos hacernos los mismos zumos.

No seguí mucho ese tema, e igual ya se había llegado a otras conclusiones, pero a mí me parece más una forma de distribuir las ALUs. ¿Hay algo que refuerce la teoría de tener un 33% más de ALUs que el que haya más rallitas? Perdón si es un tema que ya se había tratado con anterioridad.
Yo me quedo con la suma de lo que dicen @Polyteres y @Horizonte de sucesos.

Se tienen 2 para renderizar TODO lo que hay en pantalla, y diseñado de forma que NUNCA se molesten para que la una no afecte a la otra. Si tienes 2 y tienes un juego a pantalla completa pues todo a eso, si acoplas una App pues usas la parte necesaria para esa App, pero como el juego ahora ocupa menos pues necesita justo ese menos que se dedica a la App. Y poniendo 2 es mucho más sencillo que no se molesten.

Sistema diseñado para que funcione todo a tope siempre y que los 2 SSOO no se molesten entre sí. Hasta que no estén pulidos tanto el software de sistema como los SDK pues no se verá en su auténtica forma.
KinderRey escribió:Este hilo molaba. Ahora es otra mierda de Multi


Pues hagamos que vuelva a molar.

IBM en 2009, en plena crisis economica, despide a un equipo enterito de R&D para ahorrar gastos. Dicho equipo es absorbido casi en su totalidad por Microsoft, y con el cual montan el Computer Architecture Group en Microsoft Research. http://research.microsoft.com/en-us/groups/arch/

Dicho grupo se trae un monton de know-how de desarrollo de arquitecturas 'raras' que tenia IBM en investigacion en ese momento. De lo primero que hacen en Microsoft Research es publicar un paper sobre una arquitectura 'rara' llamada 'Explicit Data Graph Execution' (EDGE), y lo empaquetan en una solucion denominada 'E2 Dynamic Multicore'. http://research.microsoft.com/en-us/projects/e2/

Esta solucion sigue un poco la filosofia de las FPGA, en las cuales se puede 'microprogramar' lo que quieres que haga un chip, para que lo ejecute a velocidad nativa. o sea, en lugar que tener que ir a la RAM para leer el codigo que hay que ejecutar, el codigo esta 'en el mismo chip'.

mas tarde, los señores Andrew Putnam, Aaron Smith y Doug Burger, miembros todos del Computer Architecture Group, sacan un paper denominado 'Dynamic Vectorization in the E2 Dynamic Multicore Architecture', por el cual describen como puede ser 'microprogramado' el chip E2 para realizar diversas labores en aplicaciones masivamente paralelas. http://research.microsoft.com/pubs/1406 ... rt2010.pdf

Otro de esos mismos señores, Andrew Putnam, publica un paper denominado 'Performance and Power of Cache-Based Reconfigurable Computing', por el cual especifica como un hardware 'reprogramable' o 'reconfigurable' con una gran memoria cache 'on board' puede tener un rendimiento bestial si puede ser correctamente programado. En ese mismo paper habla de 'CHiMPs', que es un compilador que traduce C plano a 'puertas' FPGA, ideales para una arquitectura reconfigurable como, por ejemplo, el chip E2. http://www.cse.psu.edu/~xydong/files/pr ... s/p395.pdf

Y finalmente, en 2011, Doug Burger co-presenta un paper-resumen sobre 'Efficient Execution of Sequential Applications on Multicore Systems', donde hay un monton de datos sobre la arquitectura EDGE, TRIPs (implementacion de multiples cores EDGE en un chip), EDGE T3 Core (la tercera generacion de cores EDGE) y muchos mas acronimos nuevos interesantes. especial atencion merecen las imagenes de la pagina 49 y sucesivas. http://www.cs.utexas.edu/~cart/publicat ... behnam.pdf

Tenemos una plataforma (E2 Dynamic Multicore) reconfigurable y reprogramable, tenemos un compilador de C a FPGA, tenemos un monton de papers de como hacer que dicha plataforma sea rapida y optima...
ah, y tenemos un monton de rumores sobre 'chip-on-cloud' en el SoC de XboxONE y una segunda capa (como minimo) del SoC de la que no se sabe nada.

¿Shaders en la GPU? ¡eso esta muy visto! ¡programate tu propia GPU!
Polyteres escribió:Buenas gente. Como he dicho más de una vez con respecto al tema de la GPU Dual o desdoblada de forma lógica... Hay dos graphics proccessor uno para el Sistema Operativo y otro para el juego en sí mismo. Esto ayuda a que la reactividad del sistema sea mucho mejor, por ejemplo cuando vas al menú y dejas el juego en segundo plano, o cuando el sistema superpone algo en pantalla mientras que estás jugando. Si no me creeis a mí tan solo tenéis que ir a la entrevista que los arquitectos de XboxOne concedieron a Digital Foundry. Sacado de allí:

http://www.eurogamer.net/articles/digit ... -interview

One thing to keep in mind when looking at comparative game resolutions is that currently the Xbox One has a conservative 10 per cent time-sliced reservation on the GPU for system processing. This is used both for the GPGPU processing for Kinect and for the rendering of concurrent system content such as snap mode. The current reservation provides strong isolation between the title and the system and simplifies game development (strong isolation means that the system workloads, which are variable, won't perturb the performance of the game rendering). In the future, we plan to open up more options to developers to access this GPU reservation time while maintaining full system functionality.

To facilitate this, in addition to asynchronous compute queues, the Xbox One hardware supports two concurrent render pipes. The two render pipes can allow the hardware to render title content at high priority while concurrently rendering system content at low priority. The GPU hardware scheduler is designed to maximise throughput and automatically fills "holes" in the high-priority processing. This can allow the system rendering to make use of the ROPs for fill, for example, while the title is simultaneously doing synchronous compute operations on the Compute Units.


No hay más historia.

Un saludo.


Ahí no habla de que solo vale para eso. Dice como por ejemplo

A mi lo que me da a entender, con mis casi nulos conocimientos, (eso si xD) es que los dos pipes, ayudan al procesamiento en tareas de todo tipo.
Ya sea para kinect, para snap, o para lo que le mandes. No exclusye nada, solo da ejemplos.

Solo tienes que leer exactamente lo que dicen:
In the future, we plan to open up more options to developers to access this GPU reservation time while maintaining full system functionality.

To facilitate this, in addition to asynchronous compute queues, the Xbox One hardware supports two concurrent render pipes.
darksch escribió:Yo me quedo con la suma de lo que dicen @Polyteres y @Horizonte de sucesos.

Se tienen 2 para renderizar TODO lo que hay en pantalla, y diseñado de forma que NUNCA se molesten para que la una no afecte a la otra. Si tienes 2 y tienes un juego a pantalla completa pues todo a eso, si acoplas una App pues usas la parte necesaria para esa App, pero como el juego ahora ocupa menos pues necesita justo ese menos que se dedica a la App. Y poniendo 2 es mucho más sencillo que no se molesten.

Sistema diseñado para que funcione todo a tope siempre y que los 2 SSOO no se molesten entre sí. Hasta que no estén pulidos tanto el software de sistema como los SDK pues no se verá en su auténtica forma.


Correcto, te facilita la labor, pero no dicen de que se reserve solo para esos menesteres. Eso ya es la interpretación de Polyteres, pero en el texto no dice eso.
eloskuro escribió:
Polyteres escribió:Buenas gente. Como he dicho más de una vez con respecto al tema de la GPU Dual o desdoblada de forma lógica... Hay dos graphics proccessor uno para el Sistema Operativo y otro para el juego en sí mismo. Esto ayuda a que la reactividad del sistema sea mucho mejor, por ejemplo cuando vas al menú y dejas el juego en segundo plano, o cuando el sistema superpone algo en pantalla mientras que estás jugando. Si no me creeis a mí tan solo tenéis que ir a la entrevista que los arquitectos de XboxOne concedieron a Digital Foundry. Sacado de allí:

http://www.eurogamer.net/articles/digit ... -interview

One thing to keep in mind when looking at comparative game resolutions is that currently the Xbox One has a conservative 10 per cent time-sliced reservation on the GPU for system processing. This is used both for the GPGPU processing for Kinect and for the rendering of concurrent system content such as snap mode. The current reservation provides strong isolation between the title and the system and simplifies game development (strong isolation means that the system workloads, which are variable, won't perturb the performance of the game rendering). In the future, we plan to open up more options to developers to access this GPU reservation time while maintaining full system functionality.

To facilitate this, in addition to asynchronous compute queues, the Xbox One hardware supports two concurrent render pipes. The two render pipes can allow the hardware to render title content at high priority while concurrently rendering system content at low priority. The GPU hardware scheduler is designed to maximise throughput and automatically fills "holes" in the high-priority processing. This can allow the system rendering to make use of the ROPs for fill, for example, while the title is simultaneously doing synchronous compute operations on the Compute Units.


No hay más historia.

Un saludo.


Ahí no habla de que solo vale para eso. Dice como por ejemplo

A mi lo que me da a entender, con mis casi nulos conocimientos, (eso si xD) es que los dos pipes, ayudan al procesamiento en tareas de todo tipo.
Ya sea para kinect, para snap, o para lo que le mandes. No exclusye nada, solo da ejemplos.

Solo tienes que leer exactamente lo que dicen:
In the future, we plan to open up more options to developers to access this GPU reservation time while maintaining full system functionality.

To facilitate this, in addition to asynchronous compute queues, the Xbox One hardware supports two concurrent render pipes.

Eso no es lo de la GPU reservada para el sistema que van a liberar para que lo usen los desarrolladores?

En principio esto no sería duplicar la potencia, sino decidir quien accede, si sólo el s.o. Ó si los juegos también pueden acceder, pero mirando de no pisarse unos a otros.
No eso no es lo mismo. El % a liberar es lo que antes se resevaba tuvieras o no una App acoplada. Ahora se libera ese 8% porque si tienes un juego a pantalla completa era un desperdicio absurdo, era una optimización básica.

Lo que tiene no son 2 GPU, son 2 Graphics Proccessor, que ayudan a no dejar unidades sin trabajo. Al mismo tiempo permite repartir mejor la carga si tienes que hacer varias cosas a la vez.
nadie de nosotros ha dicho tal cosa david ricardo. Hemos dicho que ayudan. No que los dos pipes hagan turbo boost de duplicar potencia

-----------------

F5net:

Pues hagamos que vuelva a molar.

IBM en 2009, en plena crisis economica, despide a un equipo enterito de R&D para ahorrar gastos. Dicho equipo es absorbido casi en su totalidad por Microsoft, y con el cual montan el Computer Architecture Group en Microsoft Research. http://research.microsoft.com/en-us/groups/arch/

Dicho grupo se trae un monton de know-how de desarrollo de arquitecturas 'raras' que tenia IBM en investigacion en ese momento. De lo primero que hacen en Microsoft Research es publicar un paper sobre una arquitectura 'rara' llamada 'Explicit Data Graph Execution' (EDGE), y lo empaquetan en una solucion denominada 'E2 Dynamic Multicore'. http://research.microsoft.com/en-us/projects/e2/

Esta solucion sigue un poco la filosofia de las FPGA, en las cuales se puede 'microprogramar' lo que quieres que haga un chip, para que lo ejecute a velocidad nativa. o sea, en lugar que tener que ir a la RAM para leer el codigo que hay que ejecutar, el codigo esta 'en el mismo chip'.

mas tarde, los señores Andrew Putnam, Aaron Smith y Doug Burger, miembros todos del Computer Architecture Group, sacan un paper denominado 'Dynamic Vectorization in the E2 Dynamic Multicore Architecture', por el cual describen como puede ser 'microprogramado' el chip E2 para realizar diversas labores en aplicaciones masivamente paralelas. http://research.microsoft.com/pubs/1406 ... rt2010.pdf

Otro de esos mismos señores, Andrew Putnam, publica un paper denominado 'Performance and Power of Cache-Based Reconfigurable Computing', por el cual especifica como un hardware 'reprogramable' o 'reconfigurable' con una gran memoria cache 'on board' puede tener un rendimiento bestial si puede ser correctamente programado. En ese mismo paper habla de 'CHiMPs', que es un compilador que traduce C plano a 'puertas' FPGA, ideales para una arquitectura reconfigurable como, por ejemplo, el chip E2. http://www.cse.psu.edu/~xydong/files/pr ... s/p395.pdf

Y finalmente, en 2011, Doug Burger co-presenta un paper-resumen sobre 'Efficient Execution of Sequential Applications on Multicore Systems', donde hay un monton de datos sobre la arquitectura EDGE, TRIPs (implementacion de multiples cores EDGE en un chip), EDGE T3 Core (la tercera generacion de cores EDGE) y muchos mas acronimos nuevos interesantes. especial atencion merecen las imagenes de la pagina 49 y sucesivas. http://www.cs.utexas.edu/~cart/publicat ... behnam.pdf

Tenemos una plataforma (E2 Dynamic Multicore) reconfigurable y reprogramable, tenemos un compilador de C a FPGA, tenemos un monton de papers de como hacer que dicha plataforma sea rapida y optima...
ah, y tenemos un monton de rumores sobre 'chip-on-cloud' en el SoC de XboxONE y una segunda capa (como minimo) del SoC de la que no se sabe nada.

¿Shaders en la GPU? ¡eso esta muy visto! ¡programate tu propia GPU!


¿Sabes que Microsoft reserch estubo ayudando a black tusk entre otros a comprender la arquitectura de xbox one y desarrollar de manera mas eficiente?
http://www.vg247.com/2013/09/12/xbox-one-dev-black-tusk-pairing-with-microsoft-research-on-unannounced-project/

Phil Spencer @XboxP3
Follow

@Steverulez Collaboration between Black Tusk and MS Research is leading to very interesting gameplay mechanics. Gameplay is looking great.
Liberarán lo que puedan, porque como bien dice el texto ese 10% es tanto para GPGPU de Kinect, como para el SO.No solo es para kinect como mucha gente cree.

Y es de cajón que tengas que reservar GPU para el SO a no ser que quieras un SO sin interfaz gráfica a base de comandos tipo MSDOS. Esto le sucede a cualquier consola, ya sea la ONE, la 360, PS3, PS4 o las Wiis
Ya, ya, sólo era una aclaración para que me corrigiera quien corresponda si estaba mal, no era para corregir yo a nadie en concreto.
Buenas gente.

@Horizonte de sucesos y @eloskuro lo dice explícitamente, si queréis seguir dándole vueltas sois libres de hacerlo, cada uno q crea lo q quiera xD. Por otra parte, los SO se van puliendo con el tiempo y cada vez se liberan mas recursos para el juego...con un límite. Al final el SO siempre tendrá q dibujar algo en la pantalla y superponerlo con el juego.

@Szasz no, los datos son correctos, lo incorrecto es la interpretación. Explicar esto sería adentrarse a nivel demasiado profundo en como funciona una CPU, pero...resumiendo, no es lo mismo emitir instrucciones a las unidades de computo (issue) que captar/decodificar instrucciones de memoria, que RETIRAR instrucciones del pipeline.

En la arquitectura Jaguar, se pueden captar/decodificar 2 instrucciones por ciclo, puede emitir 6 instrucciones por ciclo y retirar como máximo 2 instrucciones por ciclo. Como máximo cada core podrá retirar/terminar 2 instrucciones por ciclo, si tienes 8 podrás retirar 16 instrucciones terminadas, es distinto del número de instrucciones q puedes emitir a las unidades de computo (6x8 = 48).

@colects [beer] .

Un saludo.
Tan sólo interrumpo un minuto para felicitar a los participantes y decir que ESTA CLASE DE HILOS, Y NO OTROS, SON LOS QUE HACEN GRANDES A EOL.

Da gusto seguir estos debates y las explicaciones y argumentos de cada uno...
Ya, ya, sólo era una aclaración para que me corrigiera quien corresponda si estaba mal, no era para corregir yo a nadie en concreto.
No Polyteres, no lo dice, eres tú el que le das vueltas. Aparte es absurdo tenerlo sin usar cuando le puedes sacar provecho.

Es un sin sentido...
The current reservation provides strong isolation between the title and the system and simplifies game development (strong isolation means that the system workloads, which are variable, won't perturb the performance of the game rendering). In the future, we plan to open up more options to developers to access this GPU reservation time while maintaining full system functionality.


O lo que es lo mismo: abrir más aún la disponibilidad para que los desarrolladores puedan usar recursos reservados a funciones secundarias para que sean usados en las principales. Esto como primera parte, pero ahora, como parte independiente:

To facilitate this, in addition to asynchronous compute queues, the Xbox One hardware supports two concurrent render pipes. The two render pipes can allow the hardware to render title content at high priority while concurrently rendering system content at low priority.


Xbox One lleva 2 pipelines que PUEDEN permitir renderizar el contenido de un juego con alta prioridad y el del sistema a baja. No se dan cifras porque la cantidad es variable.

PUEDEN, no que siempre se usen para eso. Dentro del uso que puede hacerse de ambos, se permiten ajustes

This can allow the system rendering to make use of the ROPs for fill, for example, while the title is simultaneously doing synchronous compute operations on the Compute Units.


Por ejemplo, para "llenar huecos" de varios procesos simultáneos ajustándolos a conveniencia.
f5inet escribió:
KinderRey escribió:Este hilo molaba. Ahora es otra mierda de Multi


Pues hagamos que vuelva a molar.

IBM en 2009, en plena crisis economica, despide a un equipo enterito de R&D para ahorrar gastos. Dicho equipo es absorbido casi en su totalidad por Microsoft, y con el cual montan el Computer Architecture Group en Microsoft Research. http://research.microsoft.com/en-us/groups/arch/

Dicho grupo se trae un monton de know-how de desarrollo de arquitecturas 'raras' que tenia IBM en investigacion en ese momento. De lo primero que hacen en Microsoft Research es publicar un paper sobre una arquitectura 'rara' llamada 'Explicit Data Graph Execution' (EDGE), y lo empaquetan en una solucion denominada 'E2 Dynamic Multicore'. http://research.microsoft.com/en-us/projects/e2/

Esta solucion sigue un poco la filosofia de las FPGA, en las cuales se puede 'microprogramar' lo que quieres que haga un chip, para que lo ejecute a velocidad nativa. o sea, en lugar que tener que ir a la RAM para leer el codigo que hay que ejecutar, el codigo esta 'en el mismo chip'.

mas tarde, los señores Andrew Putnam, Aaron Smith y Doug Burger, miembros todos del Computer Architecture Group, sacan un paper denominado 'Dynamic Vectorization in the E2 Dynamic Multicore Architecture', por el cual describen como puede ser 'microprogramado' el chip E2 para realizar diversas labores en aplicaciones masivamente paralelas. http://research.microsoft.com/pubs/1406 ... rt2010.pdf

Otro de esos mismos señores, Andrew Putnam, publica un paper denominado 'Performance and Power of Cache-Based Reconfigurable Computing', por el cual especifica como un hardware 'reprogramable' o 'reconfigurable' con una gran memoria cache 'on board' puede tener un rendimiento bestial si puede ser correctamente programado. En ese mismo paper habla de 'CHiMPs', que es un compilador que traduce C plano a 'puertas' FPGA, ideales para una arquitectura reconfigurable como, por ejemplo, el chip E2. http://www.cse.psu.edu/~xydong/files/pr ... s/p395.pdf

Y finalmente, en 2011, Doug Burger co-presenta un paper-resumen sobre 'Efficient Execution of Sequential Applications on Multicore Systems', donde hay un monton de datos sobre la arquitectura EDGE, TRIPs (implementacion de multiples cores EDGE en un chip), EDGE T3 Core (la tercera generacion de cores EDGE) y muchos mas acronimos nuevos interesantes. especial atencion merecen las imagenes de la pagina 49 y sucesivas. http://www.cs.utexas.edu/~cart/publicat ... behnam.pdf

Tenemos una plataforma (E2 Dynamic Multicore) reconfigurable y reprogramable, tenemos un compilador de C a FPGA, tenemos un monton de papers de como hacer que dicha plataforma sea rapida y optima...
ah, y tenemos un monton de rumores sobre 'chip-on-cloud' en el SoC de XboxONE y una segunda capa (como minimo) del SoC de la que no se sabe nada.

¿Shaders en la GPU? ¡eso esta muy visto! ¡programate tu propia GPU!


¿Estás queriendo decir que es posible que en la segunda capa que se ve debajo de la principal en el SoC, podría haber una FPGA para que se pueda programar (hardware) para hacer por software lo que más te convenga?

A bote pronto me parece ciencia ficción por el coste que tienen los chips programables por hardware, y más aún debería ser en el tamaño de construcción del SoC de la One. Eso sí, como tenga algo así, sería una auténtica bomba. No creo que llegara a actuar como una 2ª GPU, pero probablemente se podría programar para hacer un offload interesante.


Otra cosa ....

Por lo que nos cuentan, parece ser definitivo que la Xbox One funciona a base de capas virtualizadas ... ¿Os imagináis que en alguna revisión nos den la posibilidad de iniciar la consola con un SO muy muy pelado, sin interfaz apenas, y que sólo ejecutara juegos? Podría tener todos los recursos del sistema para el juego, y no tendría que estar repartiendo ...
Eso serviría de poco ya que lo que se usa en el sistema cuando tienes un juego a pantalla completa es prácticamente despreciable, lo mismo que te ocupará en SO en cualquier otra consola. No penséis que el SO de la XO está ahí chupando a saco. Sólo pilla lo que necesita, y si tienes una App acoplada pilla más pero da igual porque ahora el juego ocupa menos pantalla (menos puntos) y necesitará ese menos.

Y el sistema de juegos es "bare metal" es decir como un sistema pelado como dices, por lo que ya lo tiene.

Y de virtualización que no te venga a la mente Java ni VMs, es una capacidad que tiene el hardware y que tiene coste CERO, simplemente la han aprovechado y punto, lo que requiere trabajo de software y diseño hardware y por eso no todas lo hacen.

Es un sistema diseñado para eso, para que todo funcione a bajo nivel, que cada cosa sólo pille lo que necesite, y que el reparto no suponga ningún estorbo a la otra parte. Es resumen, tienes las 3 cosas a la vez y es lo que hace grande para mí este sistema. Una auténtica experiencia.
hsaoud escribió:¿Os imagináis que en alguna revisión nos den la posibilidad de iniciar la consola con un SO muy muy pelado, sin interfaz apenas, y que sólo ejecutara juegos? Podría tener todos los recursos del sistema para el juego, y no tendría que estar repartiendo ...


Es una posibilidad. No hay una cuantía fija reservada a recursos. Si se quisiera, podría hacerse un SO con una interfaz muy básica, como dices, que centrase sus recursos en los juegos consumiendo otra cantidad anecdótica para el sistema. Pero no creo que sea el caso, ya que más bien la tendencia va hacia seguir permitiendo la multifunción (aprovechando que el hard está diseñado para ello) reduciendo cada vez más el coste de recursos secundarios del sistema a base de optimización pura y dura, permitiendo cada vez una disponibilidad mayor para juegos. Por lo menos, esa es la intención.
hsaoud escribió:
f5inet escribió:
KinderRey escribió:Este hilo molaba. Ahora es otra mierda de Multi


Pues hagamos que vuelva a molar.

IBM en 2009, en plena crisis economica, despide a un equipo enterito de R&D para ahorrar gastos. Dicho equipo es absorbido casi en su totalidad por Microsoft, y con el cual montan el Computer Architecture Group en Microsoft Research. http://research.microsoft.com/en-us/groups/arch/

Dicho grupo se trae un monton de know-how de desarrollo de arquitecturas 'raras' que tenia IBM en investigacion en ese momento. De lo primero que hacen en Microsoft Research es publicar un paper sobre una arquitectura 'rara' llamada 'Explicit Data Graph Execution' (EDGE), y lo empaquetan en una solucion denominada 'E2 Dynamic Multicore'. http://research.microsoft.com/en-us/projects/e2/

Esta solucion sigue un poco la filosofia de las FPGA, en las cuales se puede 'microprogramar' lo que quieres que haga un chip, para que lo ejecute a velocidad nativa. o sea, en lugar que tener que ir a la RAM para leer el codigo que hay que ejecutar, el codigo esta 'en el mismo chip'.

mas tarde, los señores Andrew Putnam, Aaron Smith y Doug Burger, miembros todos del Computer Architecture Group, sacan un paper denominado 'Dynamic Vectorization in the E2 Dynamic Multicore Architecture', por el cual describen como puede ser 'microprogramado' el chip E2 para realizar diversas labores en aplicaciones masivamente paralelas. http://research.microsoft.com/pubs/1406 ... rt2010.pdf

Otro de esos mismos señores, Andrew Putnam, publica un paper denominado 'Performance and Power of Cache-Based Reconfigurable Computing', por el cual especifica como un hardware 'reprogramable' o 'reconfigurable' con una gran memoria cache 'on board' puede tener un rendimiento bestial si puede ser correctamente programado. En ese mismo paper habla de 'CHiMPs', que es un compilador que traduce C plano a 'puertas' FPGA, ideales para una arquitectura reconfigurable como, por ejemplo, el chip E2. http://www.cse.psu.edu/~xydong/files/pr ... s/p395.pdf

Y finalmente, en 2011, Doug Burger co-presenta un paper-resumen sobre 'Efficient Execution of Sequential Applications on Multicore Systems', donde hay un monton de datos sobre la arquitectura EDGE, TRIPs (implementacion de multiples cores EDGE en un chip), EDGE T3 Core (la tercera generacion de cores EDGE) y muchos mas acronimos nuevos interesantes. especial atencion merecen las imagenes de la pagina 49 y sucesivas. http://www.cs.utexas.edu/~cart/publicat ... behnam.pdf

Tenemos una plataforma (E2 Dynamic Multicore) reconfigurable y reprogramable, tenemos un compilador de C a FPGA, tenemos un monton de papers de como hacer que dicha plataforma sea rapida y optima...
ah, y tenemos un monton de rumores sobre 'chip-on-cloud' en el SoC de XboxONE y una segunda capa (como minimo) del SoC de la que no se sabe nada.

¿Shaders en la GPU? ¡eso esta muy visto! ¡programate tu propia GPU!


¿Estás queriendo decir que es posible que en la segunda capa que se ve debajo de la principal en el SoC, podría haber una FPGA para que se pueda programar (hardware) para hacer por software lo que más te convenga?

A bote pronto me parece ciencia ficción por el coste que tienen los chips programables por hardware, y más aún debería ser en el tamaño de construcción del SoC de la One. Eso sí, como tenga algo así, sería una auténtica bomba. No creo que llegara a actuar como una 2ª GPU, pero probablemente se podría programar para hacer un offload interesante.


Otra cosa ....

Por lo que nos cuentan, parece ser definitivo que la Xbox One funciona a base de capas virtualizadas ... ¿Os imagináis que en alguna revisión nos den la posibilidad de iniciar la consola con un SO muy muy pelado, sin interfaz apenas, y que sólo ejecutara juegos? Podría tener todos los recursos del sistema para el juego, y no tendría que estar repartiendo ...


Ni de coña, Microsoft no está vendiendo eso con ONE, no lo veo.

Respecto a lo que dice "f5inet coincido contigo, me parece ciencia ficción X-D

Pero que hay una segunda capa es tan cierto como que las alus son más pequeñas, porque ambas cosas se ven a simple vista. Incluso se lee el etiquetado de la segunda capa:

A12 41 para la primera
A 12 40 para la segunda.

Imagen

Si hay más cpas ya se desconoce, porque a simple vista solo se pueden ver dos. Pero a apuesta personal yo creo que son 3, por el desglose de 3 capas que da Microsoft

Imagen
Buenas gente.

@Horizonte de sucesos y @Forzimbras, para mi el tema está cristalino.

Un saludo.
Madre mía como vienen algunos a hacer downplay de las cosas que se dicen por aquí y que son oficiales o que se pueden ver físicamente. xDDD
Horizonte de sucesos escribió:Pero que hay una segunda capa es tan cierto como que las alus son más pequeñas, porque ambas cosas se ven a simple vista. Incluso se lee el etiquetado de la segunda capa:

A12 41 para la primera
A 12 40 para la segunda.

Imagen


¿Pero eso es el encapsulado, no? ¿¿¿ [comor?] Es decir, lo que se ve por fuera no tiene circuitería, no????
Strife 117 escribió:Madre mía como vienen algunos a hacer downplay de las cosas que se dicen por aquí y que son oficiales o que se pueden ver físicamente. xDDD


Bueno, esto ya lo decía Nuhar ayer: el astroturfing es una realidad incipiente en el hilo. Probablemente comisionada a base de publicidad encubierta, quién sabe. Demasiado interés veo en desmontar argumentos negándolos sistemáticamente en ese plan tan cansino, a base de teorías inventadas espontáneamente, manipulación o simple negación, sin más argumentos que un "no me lo creo", y con tanto ímpetu en desacreditar capacidades técnicas que por supuesto, seguro conocen. Un gran interés por imponer un credo de que "nada de lo que se dice es verdad" como realidad absoluta, por más que se aporten datos técnicos oficiales o extractos de declaraciones oficiales de expertos, muchos de los cuales son responsables directos de haber diseñado el hard o haber fabricado los componentes Un interés excesivamente exacerbado como para ser algo que supuestamente no interesa. Algo hay, y ya se han recibido avisos. de ello. Lo mejor por el momento, es actualizar la "lista mágica" para evitar desorientarse.
Siempre siempre siempre se pueden ganar ciclos, reescribir codigo, ordenar las cosas de forma diferente, optimizar, sacarse de la manga alguna genialidad que te permita ganar un par de frames. La capacidad del procesador es algo relativa ya que una simple multiplicacion de un par de vectores ya pone el procesador a su pleno uso. Lo importante es saber como obtener ese rendimiento el maximo tiempo posible, y mas en la programacion con varios hilos. Si eres capaz de mejorar la capacidad de tu motor para manejar y sincronizar los hilos podras optener mas y mas rendimiento.
17587 respuestas