KinderRey escribió:Este hilo molaba. Ahora es otra mierda de Multi
KinderRey escribió:Este hilo molaba. Ahora es otra mierda de Multi
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...
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... ... 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.
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
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.
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.
BiG Porras escribió:Chifrinillo escribió:Eso sí
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%
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.
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!!!!!!
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!!!!!!
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.
"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.
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.
Chifrinillo escribió:
El rio ya no suena.. es que esto es el AMAZONAS!!!!!!
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 ... -interviewOne 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.
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?
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.
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 ... -interviewOne 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.
KinderRey escribió:Este hilo molaba. Ahora es otra mierda de Multi
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 ... -interviewOne 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.
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.
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 ... -interviewOne 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.
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!
Phil Spencer @XboxP3
Follow
@Steverulez Collaboration between Black Tusk and MS Research is leading to very interesting gameplay mechanics. Gameplay is looking great.
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.
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.
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!
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 ...
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 ...
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.
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