daloni escribió:La mala optimizacion de PC esta gen es tan "real" como seguir comparando rendimientos de esta gen de consolas con la venidera y obviar su arquitectura.
Una corriente si se entiende bien y se responde mejor, y es la comparacion del que le conviene con el "la ps3 tambien era mas potente, esta gen pasara lo mismo" . Vamos el problema de ps3 esta gen y su superioridad frente a xbox360 que no se noto tanto por su arquitectura y esta generación no se puede alegar lo mismo ya que son lo mismo las consolas nuevas, pero lo extraño es que ese razonamiento lógico y verdadero sigue sin dar ese pasito igual de evidente, lógico y verdadero. Y es el siguiente:
-Esta generacion no solo comparten homología ps4 y xone para hacer ver que 1,8 con 1,3 no sufrirá de los problemas de esta generación para notarse diferencias como venia pasando, las nuevas consolas son PCs y la homologia se extiende a ps4, xone y PC,sin ninguna duda el PC tampoco sufrirá los quebraderos de esta generación, sin ninguna duda, se avecina la generación mas cómoda para jugar en PC.
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
Natsu escribió:daloni escribió:La mala optimizacion de PC esta gen es tan "real" como seguir comparando rendimientos de esta gen de consolas con la venidera y obviar su arquitectura.
Una corriente si se entiende bien y se responde mejor, y es la comparacion del que le conviene con el "la ps3 tambien era mas potente, esta gen pasara lo mismo" . Vamos el problema de ps3 esta gen y su superioridad frente a xbox360 que no se noto tanto por su arquitectura y esta generación no se puede alegar lo mismo ya que son lo mismo las consolas nuevas, pero lo extraño es que ese razonamiento lógico y verdadero sigue sin dar ese pasito igual de evidente, lógico y verdadero. Y es el siguiente:
-Esta generacion no solo comparten homología ps4 y xone para hacer ver que 1,8 con 1,3 no sufrirá de los problemas de esta generación para notarse diferencias como venia pasando, las nuevas consolas son PCs y la homologia se extiende a ps4, xone y PC,sin ninguna duda el PC tampoco sufrirá los quebraderos de esta generación, sin ninguna duda, se avecina la generación mas cómoda para jugar en PC.
Sin ninguna duda, estoy de acuerdo.
GR SteveSteve escribió:Natsu escribió:daloni escribió:La mala optimizacion de PC esta gen es tan "real" como seguir comparando rendimientos de esta gen de consolas con la venidera y obviar su arquitectura.
Una corriente si se entiende bien y se responde mejor, y es la comparacion del que le conviene con el "la ps3 tambien era mas potente, esta gen pasara lo mismo" . Vamos el problema de ps3 esta gen y su superioridad frente a xbox360 que no se noto tanto por su arquitectura y esta generación no se puede alegar lo mismo ya que son lo mismo las consolas nuevas, pero lo extraño es que ese razonamiento lógico y verdadero sigue sin dar ese pasito igual de evidente, lógico y verdadero. Y es el siguiente:
-Esta generacion no solo comparten homología ps4 y xone para hacer ver que 1,8 con 1,3 no sufrirá de los problemas de esta generación para notarse diferencias como venia pasando, las nuevas consolas son PCs y la homologia se extiende a ps4, xone y PC,sin ninguna duda el PC tampoco sufrirá los quebraderos de esta generación, sin ninguna duda, se avecina la generación mas cómoda para jugar en PC.
Sin ninguna duda, estoy de acuerdo.
Yo estoy de acuerdo pero sólo parcialmente. No creo que la mala optimización que vemos en PC en comparación con las consolas se deba sólo a tratarse de arquitecturas diferentes, sino también, muy en gran parte, a que las consolas son hardware cerrado y específico y los PC's no lo son. Cuando se programa un juego para una consola, se utilizan específicamente los recursos de su CPU, GPU, chips de sonido, memoria, etc... se puede llegar a explotar bastante. Cuando se programa un juego para PC, en cambio, hay que tener en cuenta los miles de modelos diferentes de tarjetas gráficas, procesadores, placas base, etc. que pueden tener en sus configuraciones los potenciales usuarios del juego. Si se programase un juego específicamente para X tarjeta gráfica rendiría mucho mejor, por eso me resulta muy curioso el planteamiento de las Steam Machines.
Por otro lado, aunque para ésta gen se haya apostado por arquitectura x86-64 tanto en PS4 como en ONE, me parece que no se puede decir que sea exactamente lo mismo que un PC. Hay algunas diferencias que impiden que se pueda decir que sean arquitecturas idénticas idénticas.
juan19 escribió:en francia y alemania parece ser que ps4 esta agotada hasta enero de 2014.
http://www.neogaf.com/forum/showthread.php?t=691761
![[bye]](/images/smilies/nuevos2/adio.gif "adios")
. 
Herebus escribió:PARTE 1Basicamente que es una buena oportunidad para saber los entresijos de un Hardware.Entrevista completa a los arquitectos de ONE.
So here we go - a complete transcript of Digital Foundry's discussions on the Xbox One architecture with two integral members of the team that helped create the hardware. We're looking at around an hour's worth of very dense tech talk here, much of which you will not have seen before.
But first, a little background. How did this opportunity come about? At Gamescom in August, it became clear that Microsoft was looking to adjust its stance on how it talked about its hardware from a technological perspective. Almost certainly this came about owing to an overall spec sheet that does not look too encouraging compared to the equivalent metrics being offered by Sony for the PlayStation 4, and it was clear that gamer interpretations of some of the specs didn't quite square with Microsoft's thinking over its design.
Over and above the upcoming console war though, it's clear that Xbox One has been designed with a very different philosophy in mind, with some ambitious tech powering elements such as concurrent apps and multiple virtual machines. There's a very different approach to GPU compute too - not to mention the whole balance argument. Coming out of the experience, it was clear that this was a story that the architects were passionate about and very much wanted to tell.
That said, Microsoft does have a history in sharing in-depth data on the make-up of its console architectures, and its presentation at Hot Chips 25 this year at Stanford University indicated that the design team were willing to talk in detail about the silicon to a degree beyond what Sony are willing to share - which is perhaps understandable on the PlayStation front when you have a spec sheet that essentially does most of the talking for you.
So the question many of you are no doubt asking is, are we looking at a free-flowing technical discussion or a PR exercise? Well, let's not kid ourselves - every interview that reaches publication is some form of public relations for the interviewee and that applies equally whether we're talking to Microsoft, Sony or anybody else. Perhaps the lingering disappointment for us with our Mark Cerny interview was the fact that it quickly became evident he was not going to let us into much that he hadn't already covered elsewhere. It's also fair to say that the impressive specs, well-rounded line-up and a phenomenally well-managed PR strategy have left Sony in a very favourable position, with nothing to prove - for now, at least.
For Microsoft, things are clearly very different. It's a case of explaining a design philosophy that core gamers aren't connecting with so easily, while at the same time getting across the message that the technological prowess of a games console isn't limited just to the compute power of the GPU or the memory set-up - though ironically, in combination with the quality of the development environment, these are the very strengths that allowed Xbox 360 to dominate the early years of the current-gen console battle.
Que si la gente se pregunta si esto es un panfleto de relaciones publicas, dice que todas las entrevistas de este tipo son en parte un panfleto de relaciones publicas.
Y que le extraña la reacción viendo que no ocurrió lo mimos cuando entrevistó a Mark Cerny
Y me parte el culo de risa, porque en las entrevistas que Mark Cerny ha ido dando este no estaba a la defensiva tratando de explicar el porqué un hardware 100$ mas caro, es menos potente.Nada presentación de ambas personas, que han estado directamente involucradas en el desarrollo de la consola, estando en el equipo tambien que hizo posible XBOX 360.Eurogamer escribió:Onto the discussion then - perhaps Digital Foundry's most expansive hardware interview yet, kicking off with the requisite conference call introductions...
Andrew Goossen: My name is Andrew Goossen - I'm a technical fellow at Microsoft. I was one of the architects for the Xbox One. I'm primarily involved with the software side but I've worked a lot with Nick and his team to finalise the silicon. For designing a good, well-balanced console you really need to be considering all the aspects of software and hardware. It's really about combining the two to achieve a good balance in terms of performance. We're actually very pleased to have the opportunity to talk with you about the design. There's a lot of misinformation out there and a lot of people who don't get it. We're actually extremely proud of our design. We think we have very good balance, very good performance, we have a product which can handle things other than just raw ALU. There's also quite a number of other design aspects and requirements that we put in around things like latency, steady frame-rates and that the titles aren't interrupted by the system and other things like that. You'll see this very much as a pervasive ongoing theme in our system design.
Nick Baker: I'm Nick Baker, I manage the hardware architecture team. We've worked on pretty much all instances of the Xbox. My team is really responsible for looking at all the available technologies. We're constantly looking to see where graphics are going - we work a lot with Andrew and the DirectX team in terms of understanding that. We have a good relationship with a lot of other companies in the hardware industry and really the organisation looks to us to formulate the hardware, what technology are going to be appropriate for any given point in time. When we start looking at what's the next console going to look like, we're always on top of the roadmap, understanding where that is and how appropriate to combine with game developers and software technology and get that all together. I manage the team. You may have seen John Sell who presented at Hot Chips, he's one of my organisation. Going back even further I presented at Hot Chips with Jeff Andrews in 2005 on the architecture of the Xbox 360. We've been doing this for a little while - as has Andrew. Andrew said it pretty well: we really wanted to build a high-performance, power-efficient box. We really wanted to make it relevant to the modern living room. Talking about AV, we're the only ones to put in an AV in and out to make it media hardware that's the centre of your entertainment.Le preguntan que lecciones han aprendido despues de analizar lo hecho en XBOX 360 y como lo han aplicado para XBOX One.Eurogamer escribió:Digital Foundry: What were your takeaways from your Xbox 360 post-mortem and how did that shape what you wanted to achieve with the Xbox One architecture?
Nick Baker: It's hard to pick out a few aspects we can talk about here in a small amount of time. I think one of the key points... We took a few gambles last time around and one of them was to go with a multi-processor approach rather than go with a small number of high IPC [instructions per clock] power-hungry CPU cores. We took the approach of going more parallel with cores more optimised for power/performance area. That worked out pretty well... There are a few things we realised like off-loading audio, we had to tackle that, hence the investment in the audio block. We wanted to have a single chip from the start and get everything as close to memory as possible. Both the CPU and GPU - give everything low latency and high bandwidth - that was the key mantra.
Some obvious things we had to deal with - a new configuration of memory, we couldn't really pass pointers from CPU to GPU so we really wanted to address that, heading towards GPGPU, compute shaders. Compression, we invested a lot in that so hence some of the Move Engines, which deal with a lot of the compression there... A lot of focus on GPU capabilities in terms of how that worked. And then really how do you allow the system services to grow over time without impacting title compatibility. The first title of the generation - how do you ensure that that works on the last console ever built while we value-enhance the system-side capabilities.
Responden basicamente ---> Balance
Destacan y manda huevos el tema del Ancho de Banda y Latencia como los Mantras ... , y digo que manda huevos porque mas adelante en la entrevista no se corta al decir que la GPU efectivamente se la rempanpinflan las latencias. En CPU sí que son hasta cierto punto importantes, y digo hasta cierto punto, porque CUALQUIERA que haya ido a comprar RAM para su PC, habrá visto que si tienes la opcione de comprar digamos DDR3 1600Mhz con Latencias de 7, y tiene la opcion y dinero para comprar RAM DDR3 a 2400Mhz con Latencias de 13/14, irá o debería ir de cabeza a por las segundas. ¿Porque?
La Latencia es el tiempo que tarda un dato entre ser llamado y ser servido.
A mayor Lantecia mas tiempo tarda el dato en ser encontrado, leido y mandado a la CPU.
Pero la memoria al ganar en Frecuencia de trabajo (que es lo que significa los Mhz), trabaja mas rápdio aunque tarde en encontrar mas el dato al trabajar mas rápido puede enviarlo antes, y enviar datos en mayor cantidad.
Por tanto hay un momento en que cuando subes lo suficiente de Frecuencia, compensa y mucho (salvo en trabajos muy concretos), el sacarficar latencia por frecuencia de trabajo/ancho de banda.
Y repito desde luego a la GPU la latencia se la trae al pairo, están pensadas de hecho para no ser susceptibles a la misma, al trabajar en paralelo.Les preguntan por la virtualizacion, y comentan que efectivamente es uno de los puntos clave del sistema si querían no verse limitados a la hora de retocar el Sistema Operativo en un futuro, y a la hora de no afectar a los juegos. El hacer todo esto, junto con Kinect es lo que les lleva a tener que meter CoProcesadores "de más" , y a tener que reservar por ejemplo tiempo de trabajo de GPU.Eurogamer escribió: Digital Foundry: You're running multiple systems in a single box, in a single processor. Was that one of the most significant challenges in designing the silicon?
Nick Baker: There was lot of bitty stuff to do. We had to make sure that the whole system was capable of virtualisation, making sure everything had page tables, the IO had everything associated with them. Virtualised interrupts.... It's a case of making sure the IP we integrated into the chip played well within the system. Andrew?
Andrew Goossen: I'll jump in on that one. Like Nick said there's a bunch of engineering that had to be done around the hardware but the software has also been a key aspect in the virtualisation. We had a number of requirements on the software side which go back to the hardware. To answer your question Richard, from the very beginning the virtualisation concept drove an awful lot of our design. We knew from the very beginning that we did want to have this notion of this rich environment that could be running concurrently with the title. It was very important for us based on what we learned with the Xbox 360 that we go and construct this system that would disturb the title - the game - in the least bit possible and so to give as varnished an experience on the game side as possible but also to innovate on either side of that virtual machine boundary.
We can do things like update the operating system on the system side of things while retaining very good compatibility with the portion running on the titles, so we're not breaking back-compat with titles because titles have their own entire operating system that ships with the game. Conversely it also allows us to innovate to a great extent on the title side as well. With the architecture, from SDK to SDK release as an example we can completely rewrite our operating system memory manager for both the CPU and the GPU, which is not something you can do without virtualisation. It drove a number of key areas... Nick talked about the page tables. Some of the new things we have done - the GPU does have two layers of page tables for virtualisation. I think this is actually the first big consumer application of a GPU that's running virtualised. We wanted virtualisation to have that isolation, that performance. But we could not go and impact performance on the title.
We constructed virtualisation in such a way that it doesn't have any overhead cost for graphics other than for interrupts. We've contrived to do everything we can to avoid interrupts... We only do two per frame. We had to make significant changes in the hardware and the software to accomplish this. We have hardware overlays where we give two layers to the title and one layer to the system and the title can render completely asynchronously and have them presented completely asynchronously to what's going on system-side.
System-side it's all integrated with the Windows desktop manager but the title can be updating even if there's a glitch - like the scheduler on the Windows system side going slower... we did an awful lot of work on the virtualisation aspect to drive that and you'll also find that running multiple system drove a lot of our other systems. We knew we wanted to be 8GB and that drove a lot of the design around our memory system as well.
Y admiten sin problema que el requerimiento de los 8GB fue sobre todo para poder tener un sistema así.Ahondando en lo anterior.Eurogamer escribió:Digital Foundry: Were you always targeting 8GB right from the beginning?
Andrew Goossen: Yeah I think that was a pretty early decision we made when we were looking at the kind of experiences that we wanted to run concurrently with the title. And how much memory we would need there. That would have been a really early decision for us.
Sí efectivamente Kinect y el lograr esa experiencia fue lo que les llevó a tener que apostar por 8GB de RAM desde el muy muy al principio.Le preguntan el porqué escoger Jaguar y no otra arquitectura de CPU.Eurogamer escribió: Digital Foundry: CPU-side, I'm curious. Why did you choose eight Jaguar cores rather than, say, four Piledriver cores? Is it all about performance per watt?
Nick Baker: The extra power and area associated with getting that additional IPC boost going from Jaguar to Piledriver... It's not the right decision to make for a console. Being able to hit the sweet spot of power/performance per area and make it a more parallel problem. That's what it's all about. How we're partitioning cores between the title and the operating system works out as well in that respect.
Y dice que sacrificar mayor consumo por una mayor potencia no era una buena idea. Y sí pero no.
Es una cuestión de consumos, tiempo y precio, basado en escoger una APU. AMD no podía ni puede a día de hoy ofrecer con garantías una APU, con CPUs potentes y GPUs potentes. Y tenía que ser AMD por narices, porque Intel hace unas CPUs estupendas, pero no GPUs potentes, pero es cara de narices. Nvidia hace GPUs potententes pero no tiene licencia para desarrollar CPUs, x86, y es cara de narices.
Integrar en una APU GPU de Nvidia y CPU de intel pues como que ni de coña, saldría por un ojo de la cara y hacer que CPU y GPU se entendieran bien (tanto como lo ha conseguido AMD con el tema de Fusión, hUMA, etc), hubiera requerido años de desarrollo y muchos muchos millones de inversión, así que ni de coña.
Asi que solo quedaba AMD.
La idea original tanto de Sony como de MicroSoft, era montar CPUs SteamRoller, pero quedó claro que un diseño, bueno, bonito y barato de CPU con nucleos SteamRoller y GPU potente no iba a estar a tiempo.
Asi que a las dos no les quedó mas remedio que pasar a Jaguar, que es mejor que la arquitectura anterior para ese tipo de procesadores que era BobCat, pero siguen siendo Nucleos para sistemas integrados y Set-Top-Box, no son nucleos de rendimiento sino nucleos repito para consumir poco y cubrir. Es sin duda el apartado mas flojo de las nuevas consolas. OJO no quiere decir que no vayan a cumplir. Cumplir cumplen pero muy muy raspado.Le preguntan si han hecho modificaciones a los nucleos Jaguar, y comentan que basicamente las pertinentes para que 2 Clusters de 4 Nucleos Jaguar, se comporten no como un Cluster sino como un micro completo. Lo comentan por coherencia con GPU, pero mas bien es por coherencia interna de CPU, que a su vez es la que tiene que orquestar a la GPU.Eurogamer escribió: Digital Foundry: Is it essentially the Jaguar IP as is? Or did you customise it?
Nick Baker: There had not been a two-cluster Jaguar configuration before Xbox One so there were things that had to be done in order to make that work. We wanted higher coherency between the GPU and the CPU so that was something that needed to be done, that touched a lot of the fabric around the CPU and then looking at how the Jaguar core implemented virtualisation, doing some tweaks there - but nothing fundamental to the ISA or adding instructions or adding instructions like that.
NO han tocado ni Instrucciones del procesador, ni aspectos internos de los nucleos.
Es decir lo mismo que 100% seguro que ha hecho Sony.Le pregunta por los CoProcesadores, y dice que hay 15. De los cuales 4 son los DMEs (Data Move Engines encargados de Comprimir y Descomprimir Datos al Vuelo desde el Pool de DDR3), otro es Codficiador de Video (este tambien lo tiene PS4), otro un DeCodificador de Video (este tambien lo tiene PS4, de hecho gracias a estos dos es por lo que ambas consolas puede grabar la partida mientras juegas), otro que es ReEscalador (no está claro si PS4 tambien lo tiene pero no sería raro), y luego 8 en el Bloque de Audio, donde está Shape, y ACP (Audio Controller Processor, AVC (Audio Vector Processor), etc, etc.Eurogamer escribió: Digital Foundry: You talk about having 15 processors. Can you break that down?
Nick Baker: On the SoC, there are many parallel engines - some of those are more like CPU cores or DSP cores. How we count to 15: [we have] eight inside the audio block, four move engines, one video encode, one video decode and one video compositor/resizer.
The audio block was completely unique. That was designed by us in-house. It's based on four tensilica DSP cores and several programmable processing engines. We break it up as one core running control, two cores running a lot of vector code for speech and one for general purpose DSP. We couple with that sample rate conversion, filtering, mixing, equalisation, dynamic range compensation then also the XMA audio block. The goal was to run 512 simultaneous voices for game audio as well as being able to do speech pre-processing for Kinect.
Lo que no es Shape dentro del bloque de Audio, es probable o yo diría que seguro que PS4 tambien lo tiene exactamente igual. Como el mismo comentan Shape y el resto del Bloque de Audio está ahí por y para comerse el trabajo de control por Voz de Kinect, sin que se lo tenga que comer la CPU. Junto con manejar hasta 512 streams de audio. De esos 512 Streams de Audio creo que se refieren en realidad al conjunto de lo que puede dar, si sumamos Kinect que siempre tiene que tener espacio reservado, a saber cuando queda realmente.
Y aquí yo añado que eso de que el Bloque de Audio y los CoProcesadores están ahí para realizar el curro que tiene que hacer la CPU, pues en parte sí pero en parte NO. Si porque si que le quitan trabajo, mucho y pesado, pero NO porque no se lo puedes evitar del todo.
El Bloque de Audio, puede Pre-Tratar los datos, para darselos mascados a la CPU, pero es la CPU, la que tiene que coger esos datos, llamar a una base de datos curzarlos, y asociarlos con una orden y ejecutar la opcion que da esa orden. El trabajo mas pesado que es el procesar esos datos de primeras sí que se lo ahorra a la CPU, pero la CPU, sigue siendo la directora de orquesta y el hecho de tener que atender a las llamadas de Kinect, les va a tener que hacer reservar tiempo de proceso para ello. Tanto del control por gestos (que ya se reserva ademas tiempo de GPU un 10% para eso y para el Snapping [es lo de tener la pantalla de juego y a la izquierda el Skype abierto o la clasificación del partido de la NFL] para ello), como del control por Voz, que aunque el pretratamiento de datos lo haga en un caso el Bloque de Audio y en otro la GPU, REPITO es la CPU la que tiene que coger esos datos cruzarlos y ejecutar las acciones.
Eso tambien va a consumir tiempo de CPU, pero en el articulo claro no dicen ni pio ... :roll: :evil: :scratch:
De hecho ha sido en el articulo anterior en el que han tenido que admitir que el control por Gestos y Snapping se comería un 10% de tiempo de proceso de GPU, para despues "aliviarlo", (dado que es un varapalo en TODA REGLA, cuando los recursos ya son de por sí exiguos), diciendo que lo reducirán en un futuro. Y no dudo que lo reduzcan en un futuro, pero no creo ni de coña que lo puedan quitar del todo, y desde luego si ellos bajan el FootPrint de su sistema, Sony no va a estar de brazos cruzados tampoco, y ya de por sí no tienen que tirar con esos aspectos ya que PS4, no tiene que reservar un pimiento para el control por voz y gestos ya que no es de serie, y no tiene Snapping. Solo sistema de Notificaciones que se tratan por CPU, en segundo plano y que aprovecharán un Overlay.Le preguntan que hay gente que comenta que el hardware específico no va a ser usado por los juegos Multiplataforma (refiriendose a Kinect, a Shape, etc). Y responde que se están currando las herramientas para que los desarrolladores no tengan que gastar tiempo y recursos en ello y puedan aprovecharlo.Eurogamer escribió: Digital Foundry: There's concern that custom hardware may not be utilised in multi-platform games but I'm assuming that hardware-accelerated functions would be integrated into middlewares and would see wide utilisation.
Nick Baker: Yeah, Andrew can talk about the middleware point but some of these things are just reserved for the system to do things like Kinect processing. These are system services we provide. Part of that processing is dedicated to the Kinect.
Andrew Goossen: So a lot of what we've designed for the system and the system reservation is to offload a lot of the work from the title and onto the system. You have to keep in mind that this is doing a bunch of work that is actually on behalf of the title. We're taking on the voice recognition mode in our system reservations whereas other platforms will have that as code that developers will have to link in and pay out of from their budget. Same thing with Kinect and most of our NUI [Natural User Interface] features are provided free for the games - also the Game DVR.
Ahora vamos con lo interesante:Esta historia ya la soltaron antes.Eurogamer escribió: Digital Foundry: Perhaps the most misunderstood area of the processor is the ESRAM and what it means for game developers. Its inclusion sort of suggests that you ruled out GDDR5 pretty early on in favour of ESRAM in combination with DDR3. Is that a fair assumption?
Nick Baker: Yeah, I think that's right. In terms of getting the best possible combination of performance, memory size, power, the GDDR5 takes you into a little bit of an uncomfortable place. Having ESRAM costs very little power and has the opportunity to give you very high bandwidth. You can reduce the bandwidth on external memory - that saves a lot of power consumption as well and the commodity memory is cheaper as well so you can afford more. That's really a driving force behind that. You're right, if you want a high memory capacity, relatively low power and a lot of bandwidth there are not too many ways of solving that.
Dice la gilipollez mas grande que he leido en mucho tiempo que esta subrayada en negro, que en terminos de tener la mejo combinacion de rendimiento, tamaño, conusmo, GDDR5 te lleva un poco a un lugar inconfortable ...X-D
Ya me rei agusto en su momento pero ahora me vuelvo a reir ...
Despues dice lo que no le queda mas remedio que decir que desde un punto de vista de costes y consumos, la eSRAM te da el Ancho de Banda suficiente. Y que al no ser una memoria externa ahorras ancho de banda (sí pero no, ya estamos como siempre), y ahorras en consumo (eso sí, pero es que solo faltaba), a parte de que la memoria es mas barata (BINGO, TENEMOS UN BINGO!!!).
Y lo remata que si quieres una memoria de alta capacidad, con un consumo relativamente bajo, y con bastante ancho de banda, que no hay muchas mas opciones que tirar por la solución que han tirado ellos.
Y no ...
Mas adelante no tiene problema en admitir que el problema fue simple y llanamente que ellos apostaron por los 8GB de DDR3 muy pronto porque no veían posible el meter 8GB de GDDR5, por PRECIO.
Eso condicionó el resto, y les llevó a tener que apostar por eSRAM y al apostar por eSRAM dentro de la APU, (porque para algo montas una APU y es para tener el menor numero de componentes en placa), pues les llevó a su vez junto con el tema del ancho de banda de la DDR3, a tener que apostar por una GPU mas pequeña.
El tema es que en ese sentido SONY les ganó por la mano. Le echaron huevos y apostaron por GDDR5, y tuvieron la suerte de que los pronosticos se cumplieron y que el llegaron los chips de 4Gbits, y el precio bajo lo suficiente, como para que fuera posible meter en lugar de 4GB los 8GB. Lo de los 8GB les debió de pillar completamente por sorpresa, se esperaban 4GB y que ellos a nivel de experiencia de usuario con Kinect a la cabeza, iba a sorprender, y que aun quizá teniendo peor GPU, al tener mas cantidad de RAM iban a plantar cara, pero ...El entrevistador le dice a las claras, que Sony jugó con los tiempos de dispobilidad y precio de la GDDR5.Eurogamer escribió:Digital Foundry: And there wasn't really any actual guarantee of availability of four-gigabit GDDR5 modules in time for launch. That's the gamble that Sony made which seems to have paid off. Even up until very recently, the PS4 SDK docs still refer to 4GB of RAM. I guess Intel's Haswell with eDRAM is the closest equivalent to what you're doing. Why go for ESRAM rather than eDRAM? You had a lot of success with this on Xbox 360.
Nick Baker: It's just a matter of who has the technology available to do eDRAM on a single die.
Y luego le comenta que quizá las APUs de Intel Haswell que montar eDRAM para poder suplir la falta de ancho de banda de la DDR3 y poder alimentar a sus GPUs es la aproximación mas parecida a la que ellos han hecho. Y luego le pregunta porque escogieron eSRAM y no eDRAM.
Y Nicka Baker responde que basicamente porque o bien AMD o bien TSMC (Taiwan SemiConductor Company) , quien presumiblemente fabricará las APUs, no tiene disponible la tecnología para fabricar eDRAM o bien la cantidad que ellos querían de eDRAM.
Asi que ahora queda todo mas claro ... . Para quien no lo sepa la eDRAM le da en cuanto a Anchos de Banda sopas con ondas a la eSRAM. Por eso llamaba la atencion que si metían un ScartchPAD (un añadido de memoria a un Micro para que haga de PseudoCaché, aunque no es una caché porque todo tiene que direccionarse por la aplicación), para poder suplir la falta de ancho de la GPU, sería eDRAM y no eSRAM.
Ahora queda claro el porqué. :twisted:Le pregunta si no querían un Duaghter Die (es decir un Chip que esta dentro de encapsulado de la APU, pero no esta integrado dentro de la propia APU), como hicieron con XBOX 360.Eurogamer escribió:Digital Foundry: So you didn't want to go for a daughter die as you did with Xbox 360?
Nick Baker: No, we wanted a single processor, like I said. If there'd been a different time frame or technology options we could maybe have had a different technology there but for the product in the timeframe, ESRAM was the best choice.
Y responde que no, que ya que se metían en APU, lo querían todo integrado.
Y en eso tienen razon, a corto plazo es mas caro el proceder así, pero a largo plazo supone ser mucho mas barato al poder bajar todo del tirón.Preguntan por la eSRAM que son en realidad 4 cluster de 8MB cada uno y como funcionan.Eurogamer escribió:Digital Foundry: If we look at the ESRAM, the Hot Chips presentation revealed for the first time that you've got four blocks of 8MB areas. How does that work?
Nick Baker: First of all, there's been some question about whether we can use ESRAM and main RAM at the same time for GPU and to point out that really you can think of the ESRAM and the DDR3 as making up eight total memory controllers, so there are four external memory controllers (which are 64-bit) which go to the DDR3 and then there are four internal memory controllers that are 256-bit that go to the ESRAM. These are all connected via a crossbar and so in fact it will be true that you can go directly, simultaneously to DRAM and ESRAM.
Ellos responde que hay 4 controladores para la eSRAM de 256bits cada uno, lo que da un bus total de 1024bits conectados al Crossbar. A parte hay otros 4 controladores conectados tambien al Crossbar de la APU de 64bits cada uno para la DDR3 que da un bus de 256Bits totales.
Nada nuevo.Le preguntan sobre el tema de sumar los anchos de Banda de eSRAM y DDR3.Eurogamer escribió:Digital Foundry: Simultaneously? Because there's been a lot of controversy that you're adding your bandwidth together and that you can't do this in a real-life scenario.
Nick Baker: Over that interface, each lane - to ESRAM is 256-bit making up a total of 1024 bits and that's in each direction. 1024 bits for write will give you a max of 109GB/s and then there's separate read paths again running at peak would give you 109GB/s. What is the equivalent bandwidth of the ESRAM if you were doing the same kind of accounting that you do for external memory... With DDR3 you pretty much take the number of bits on the interface, multiply by the speed and that's how you get 68GB/s. That equivalent on ESRAM would be 218GB/s. However, just like main memory, it's rare to be able to achieve that over long periods of time so typically an external memory interface you run at 70-80 per cent efficiency.
The same discussion with ESRAM as well - the 204GB/s number that was presented at Hot Chips is taking known limitations of the logic around the ESRAM into account. You can't sustain writes for absolutely every single cycle. The writes is known to insert a bubble [a dead cycle] occasionally... One out of every eight cycles is a bubble, so that's how you get the combined 204GB/s as the raw peak that we can really achieve over the ESRAM. And then if you say what can you achieve out of an application - we've measured about 140-150GB/s for ESRAM. That's real code running. That's not some diagnostic or some simulation case or something like that. That is real code that is running at that bandwidth. You can add that to the external memory and say that that probably achieves in similar conditions 50-55GB/s and add those two together you're getting in the order of 200GB/s across the main memory and internally.
One thing I should point out is that there are four 8MB lanes. But it's not a contiguous 8MB chunk of memory within each of those lanes. Each lane, that 8MB is broken down into eight modules. This should address whether you can really have read and write bandwidth in memory simultaneously. Yes you can there are actually a lot more individual blocks that comprise the whole ESRAM so you can talk to those in parallel and of course if you're hitting the same area over and over and over again, you don't get to spread out your bandwidth and so that's why one of the reasons why in real testing you get 140-150GB/s rather than the peak 204GB/s is that it's not just four chunks of 8MB memory. It's a lot more complicated than that and depending on how the pattern you get to use those simultaneously. That's what lets you do read and writes simultaneously. You do get to add the read and write bandwidth as well adding the read and write bandwidth on to the main memory. That's just one of the misconceptions we wanted to clean up.
Andrew Goossen: If you're only doing a read you're capped at 109GB/s, if you're only doing a write you're capped at 109GB/s. To get over that you need to have a mix of the reads and the writes but when you are going to look at the things that are typically in the ESRAM, such as your render targets and your depth buffers, intrinsically they have a lot of read-modified writes going on in the blends and the depth buffer updates. Those are the natural things to stick in the ESRAM and the natural things to take advantage of the concurrent read/writes.
Y da bastantes datos.
El pico teorico máximo de Lectura de la eSRAM son 109GBps. EL pico de lectura máximo de la eSRAM son 109GBps. Lo que da un pico teorico máximo de 218GBps.
Ahora Real y en conjunto (lectura+escritura), están teniendo anchos de 140/150GBps.
Por otra parte el acceso a DDR3 son 68GBps (escritura+lectura) teoricos, que reales se quedan en 50/55GBps.
Como tienen controladores distintos, y son clusters de memoria distintos, la GPU puede acceder a la vez a ambos, y sí pero no es tan sencillo. La eSRAM son 32MB, siendo tan poco, y dado que en esos 32MB tiene que estar tambien los Buffers, lo normal es que tengan que estar iendo y viniendo datos desde DDR3 a eSRAM de forma continua, de hecho por eso están ahí los DMEs. Por tanto el grado de uso en paralelo real para alimentar a la GPU, es como poco muy limitado. Es decir que gran parte del ancho de acceso de la GPU a DDR3 no es para llamar o dejar, datos diferentes a los que tiene en la eSRAM sino que son para traer o llevar datos a o desde la eSRAM. No sé si me seguís.
El caso es que ellos dice que sumando los 140+150GBps de la eSRAM a los 50/55GBps de DDR3 dan segun ellos 200GBps de ancho totales, y parte de por lo dicho ahí arriba, hay otro factor que obvia es cuando yo me apeo.
Los 50/55GBps de la DDR3 son A COMPARTIR CON CPU. La CPU se tiene que comer unos 20GBps. Por lo que quedan 30/35GBps reales de DDR3 para la CPU.
Hablaríamos por tanto de que para GPU, tendríamos entre 140/150GBps de la eSRAM mas 30/35GBps de DDR3. Pero OJO porque ya he dicho que de esos 30/35GBps para escribir y leer de DDR3, son en su mayoría por y para meter y sacar datos de la eSRAM ... :roll: . Porque a la fin de la postre la mayor parte de los datos que demande los micros se almacenarán en los 8GB de DDR3 y esos 8GB de DDR3 para la GPU solo quedan 30/35GBps ----> :shock: . Ahora queda claro el porque de los DMEs, y ya pueden ser la recontra leche comprimiendo y descomprimiendo datos, porque una GPU 7750 que es menos potente que la que monta XBOX One, demanda para ella sola OJO, unos 73GBps.
En fin que ... , es un muy buen pifostio.Eso confirman que el ancho real de eSRAM a repartir entre lectura y escritura es de 140/150GBps. Ni de coña NADA de 209GBps.Eurogamer escribió:Digital Foundry: So 140-150GB/s is a realistic target and you can integrate DDR3 bandwidth simultaneously?
Nick Baker: Yes. That's been measured.Le preguntan mas por el tema de la eSRAM.Eurogamer escribió:Digital Foundry: On the leaked whitepapers, peak bandwidth was a lot smaller and then suddenly we ran a story [based on an internal Xbox One development blog] saying that your peak bandwidth doubled with production silicon. Was that expected? Were you being conservative? Or did you get hands-on time with your final processor and figured out that - wow - it can do this?
Nick Baker: When we started, we wrote a spec. Before we really went into any implementation details, we had to give developers something to plan around before we had the silicon, before we even had it running in simulation before tape-out, and said that the minimum bandwidth we want from the ESRAM is 102GB/s. That became 109GB/s [with the GPU speed increase]. In the end, once you get into implementing this, the logic turned out that you could go much higher.
Andrew Goossen: I just wanted to jump in from a software perspective. This controversy is rather surprising to me, especially when you view ESRAM as the evolution of eDRAM from the Xbox 360. No-one questions on the Xbox 360 whether we can get the eDRAM bandwidth concurrent with the bandwidth coming out of system memory. In fact, the system design required it. We had to pull over all of our vertex buffers and all of our textures out of system memory concurrent with going on with render targets, colour, depth, stencil buffers that were in eDRAM.
Of course with Xbox One we're going with a design where ESRAM has the same natural extension that we had with eDRAM on Xbox 360, to have both going concurrently. It's a nice evolution of the Xbox 360 in that we could clean up a lot of the limitations that we had with the eDRAM. The Xbox 360 was the easiest console platform to develop for, it wasn't that hard for our developers to adapt to eDRAM, but there were a number of places where we said, "Gosh, it would sure be nice if an entire render target didn't have to live in eDRAM," and so we fixed that on Xbox One where we have the ability to overflow from ESRAM into DDR3 so the ESRAM is fully integrated into our page tables and so you can kind of mix and match the ESRAM and the DDR memory as you go.
Sometimes you want to get the GPU texture out of memory and on Xbox 360 that required what's called a "resolve pass" where you had to do a copy into DDR to get the texture out - that was another limitation we removed in ESRAM, as you can now texture out of ESRAM if you want to. From my perspective it's very much an evolution and improvement - a big improvement - over the design we had with the Xbox 360. I'm kind of surprised by all this, quite frankly.
Y ellos responden pronfundizando un poco y comentando que les sorprende la controversia del planteamiento cuando es una evolución natural de la eDRAM de XBOX 360 y nadie tuvo quejas en su día sobre la dificultad de desarrollar para XBOX 360. Que la eSRAM y la DDR3 se integran y complementan entre sí, y que dan lo suficiente para el sistema.Le preguntan si los 32MB de eSRAM no son una limitacion sobre todo para planteamientos de juegos con ciertas resoluciones y Render Targets. Y que si pueden separa la información que sale de la GPU y mandarla bien a eSRAM o bien a DDR.Eurogamer escribió:Digital Foundry: Obviously though, you are limited to just 32MB of ESRAM. Potentially you could be looking at say, four 1080p render targets, 32 bits per pixel, 32 bits of depth - that's 48MB straight away. So are you saying that you can effectively separate render targets so that some live in DDR3 and the crucial high-bandwidth ones reside in ESRAM?
Andrew Goossen: Oh, absolutely. And you can even make it so that portions of your render target that have very little overdraw... For example, if you're doing a racing game and your sky has very little overdraw, you could stick those subsets of your resources into DDR to improve ESRAM utilisation. On the GPU we added some compressed render target formats like our 6e4 [six bit mantissa and four bits exponent per component] and 7e3 HDR float formats [where the 6e4 formats] that were very, very popular on Xbox 360, which instead of doing a 16-bit float per component 64pp render target, you can do the equivalent with us using 32 bits - so we did a lot of focus on really maximizing efficiency and utilisation of that ESRAM.
El responde que sí, que desde luego que hay por ejemplo escenarios y pone un ejemplo de un juego de coches en que el cielo no hace falta que se renderice cada frame, en que pueden mandar esos datos a DDR3, para dejar mas espacio en eSRAM. Tambien usando formatos de archivo mas optimizados que ocupan mucho menos espacio (otra vez los DMEs), y soluciones de compromiso.
Lo que no dicen es que eso hay que programarlo, y eso requiere tiempo y trabajo a las desarrolladoras. Y si no quieren que les lleve tiempo y usan un sistema de memoria virtual en que es el sistema quien directamente recoloca los datos en los dos Pools (eSRAM y DDR), en funcion de su demanda, importancia, etc, pues esa gestión y virtualización tambien consume recursos y bastantes. Como siempre tetas y sopas no caben en la boca. SI le quieren allanar el camino a los desarrolladores eso les va a suponer rebajar aún mas los recursos que ya tienen.
Está claro que lo han hecho reservando tiempo de proceso de GPU, para que siempre quede espacio para que el sistema pueda realizar el calculo de control de gestos y el Snapping, y es de suponer que si quieren currarse unas buenas herramientas tengan que hallar medios para la gestion de los datos en ambos pools sea sencilla y no comprometa muchos recursos, si lo consiguen pues habrá hecho la cuadratura del circulo.
El tema es que SONY no tiene que hacer nada de eso. No tiene que reservar sistema para la virtualizacion de la memoria, no tiene que reservar sistema para control por gestos, voz y hacer Snapping.NOVEDAD al canto, la primera realmente importante de esta versión completa de la entrevista:Eurogamer escribió:Digital Foundry: And you have CPU read access to the ESRAM, right? This wasn't available on Xbox 360 eDRAM.
Nick Baker: We do but it's very slow.
Le pregunta si la CPU tiene acceso a la eSRAM.
Responden que sí, que la CPU sí que tiene acceso a la eSRAM pero es lento.
Pero en esto tambien lo que dicen es cierto pero se olvida de citar ciertas cosas, estamos en las mismas es un SÍ pero NO.
Sí que tiene acceso. Y si que es lento. Pero no dicen que es lento y tiene acceso porque es un acceso puenteando por el Controlador de memoria de la GPU. A la fin de la postre importa un huevo porque no vale para un carajo. Los datoa de eSRAM no tiene coherencia con la CPU en ningun caso, asi que lo de pensar en hUMA, pues ni por asomo, ya que hUMA es basicamente que CPU y GPU compartan un acceso directo y coherente a los datos que tienen uno y otro micro en las cachés. La eSRAM de XBOX One, es un ScratchPAD es decir es una pseudoCaché, pero que es direccionada (es decir en que los datos son guardados en cada celda directamente por el programa NO por un controlador integrado que lo haga automaticamente, como hacen las cachés), por tanto el como se guardan, cuando se modifican, de donde vienen, de los datos que se almacenan en eSRAM no lo puede saber la CPU, por tanto la CPU no puede localizar o diferenciar los datos que le pueden resultar útiles y cuales no.
Asi que XBOX One ≠ hUMA.
Eso ya lo sabíamos y sigue siendo igual.OTRA NOVEDAD:Eurogamer escribió:Digital Foundry: There's been some discussion online about low-latency memory access on ESRAM. My understanding of graphics technology is that you forego latency and you go wide, you parallelise over however many compute units are available. Does low latency here materially affect GPU performance?
Nick Baker: You're right. GPUs are less latency sensitive. We've not really made any statements about latency.
Le pregunta basicamente si el tema de la baja latencia de la eSRAM tiene alguna incidencia en la GPU.
Nick Baker responde que como el entrevistador comenta efectivamente NO. Las GPUs no son sensibles a las latencias.
Es decir que el MUY MANIDO argumento de que la GPU de XBOX One se iba a beneficiar de tener la eSRAM o DDR3 ya que estas memoria tenían y tienen unas latencias muy bajas, comparadas con GDDR5 ... pues como que no ...
A la GPU repito se la traen al pairo las latencias, sean altas o sean bajas.Le preguntan por DirectX y como el hecho de ser ellos los creadores de esa API puede suponer una ventaja.Eurogamer escribió:Digital Foundry: DirectX as an API is very mature now. Developers have got a lot of experience with it. To what extent do you think this is an advantage for Xbox One? Bearing in mind how mature the API is, could you optimise the silicon around it?
Andrew Goossen: To a large extent we inherited a lot of DX11 design. When we went with AMD, that was a baseline requirement. When we started off the project, AMD already had a very nice DX11 design. The API on top, yeah I think we'll see a big benefit. We've been doing a lot of work to remove a lot of the overhead in terms of the implementation and for a console we can go and make it so that when you call a D3D API it writes directly to the command buffer to update the GPU registers right there in that API function without making any other function calls. There's not layers and layers of software. We did a lot of work in that respect.
We also took the opportunity to go and highly customise the command processor on the GPU. Again concentrating on CPU performance... The command processor block's interface is a very key component in making the CPU overhead of graphics quite efficient. We know the AMD architecture pretty well - we had AMD graphics on the Xbox 360 and there were a number of features we used there. We had features like pre-compiled command buffers where developers would go and pre-build a lot of their states at the object level where they would [simply] say, "run this". We implemented it on Xbox 360 and had a whole lot of ideas on how to make that more efficient [and with] a cleaner API, so we took that opportunity with Xbox One and with our customised command processor we've created extensions on top of D3D which fit very nicely into the D3D model and this is something that we'd like to integrate back into mainline 3D on the PC too - this small, very low-level, very efficient object-orientated submission of your draw [and state] commands.
Gossen responde que la GPU de AMD es un muy buen diseño para DirectX 11. Comentan como han retocado el Commando Processor de la GPU (es que es lo mínimo que hay que retocar), y una versión propia de DirectX para escribir mas y mejor (de forma mas directa a la GPU), tal y como hicieron en XBOX 360, (repito que esto no es único suyo, esto es lo normal y mínimo que haces si vas a hacer un hardware cerrado), y que las customizaciones que han hecho de su versión de DirectX espera que lleguen en algun momento a PC (la entrevista ya tiene su tiempo, pero no sería raro que ya supieran de la API MANTLE de AMD, y que esto sea una referencia a que esperan mejorar la API de DirectX para PC, con vistas a que otras APIs como OpenGL y MANTLE (ahora) les pasen por encima.
En ciertos aspectos DirectX es funcional pero esta limitada y va en ciertos aspectos demasiado lenta en cuanto a sus revisiones, en cambio OpenGL es menos funcional, (carga con mucha morralla), pero en cambio al ser libre los cambios llegan mucho mas rápido.
CONTINUA ....
![[poraki]](/images/smilies/nuevos/dedos.gif "por aquí!")
Herebus escribió:CONTINUACIÓN ...
PARTE 2Comentan cosas importantes.Eurogamer escribió:Digital Foundry: When you look at the specs of the GPU, it looks very much like Microsoft chose the AMD Bonaire design and Sony chose Pitcairn - and obviously one has got many more compute units than the other. Let's talk a little bit about the GPU - what AMD family is it based on: Southern Islands, Sea Islands, Volcanic Islands?
Andrew Goossen: Just like our friends we're based on the Sea Islands family. We've made quite a number of changes in different parts of the areas. The biggest thing in terms of the number of compute units, that's been something that's been very easy to focus on. It's like, hey, let's count up the number of CUs, count up the gigaflops and declare the winner based on that. My take on it is that when you buy a graphics card, do you go by the specs or do you actually run some benchmarks? Firstly though, we don't have any games out. You can't see the games. When you see the games you'll be saying, "What is the performance difference between them?" The games are the benchmarks. We've had the opportunity with the Xbox One to go and check a lot of our balance. The balance is really key to making good performance on a games console. You don't want one of your bottlenecks being the main bottleneck that slows you down.
Balance is so key to real effective performance. It's been really nice on Xbox One with Nick and his team and the system design folks have built a system where we've had the opportunity to check our balances on the system and make tweaks accordingly. Did we do a good job when we did all of our analysis a couple of years ago and simulations and guessing where games would be in terms of utilisation? Did we make the right balance decisions back then? And so raising the GPU clock is the result of going in and tweaking our balance. Every one of the Xbox One dev kits actually has 14 CUs on the silicon. Two of those CUs are reserved for redundancy in manufacturing. But we could go and do the experiment - if we were actually at 14 CUs what kind of performance benefit would we get versus 12? And if we raised the GPU clock what sort of performance advantage would we get? And we actually saw on the launch titles - we looked at a lot of titles in a lot of depth - we found that going to 14 CUs wasn't as effective as the 6.6 per cent clock upgrade that we did. Now everybody knows from the internet that going to 14 CUs should have given us almost 17 per cent more performance but in terms of actual measured games - what actually, ultimately counts - is that it was a better engineering decision to raise the clock. There are various bottlenecks you have in the pipeline that [can] cause you not to get the performance you want [if your design is out of balance].
Nick Baker: Increasing the frequency impacts the whole of the GPU whereas adding CUs beefs up shaders and ALU.
Andrew Goossen: Right. By fixing the clock, not only do we increase our ALU performance, we also increase our vertex rate, we increase our pixel rate and ironically increase our ESRAM bandwidth. But we also increase the performance in areas surrounding bottlenecks like the drawcalls flowing through the pipeline, the performance of reading GPRs out of the GPR pool, etc. GPUs are giantly complex. There's gazillions of areas in the pipeline that can be your bottleneck in addition to just ALU and fetch performance.
If you go to VGleaks, they had some internal docs from our competition. Sony was actually agreeing with us. They said that their system was balanced for 14 CUs. They used that term: balance. Balance is so important in terms of your actual efficient design. Their additional four CUs are very beneficial for their additional GPGPU work. We've actually taken a very different tack on that. The experiments we did showed that we had headroom on CUs as well. In terms of balance, we did index more in terms of CUs than needed so we have CU overhead. There is room for our titles to grow over time in terms of CU utilisation, but getting back to us versus them, they're betting that the additional CUs are going to be very beneficial for GPGPU workloads. Whereas we've said that we find it very important to have bandwidth for the GPGPU workload and so this is one of the reasons why we've made the big bet on very high coherent read bandwidth that we have on our system.
I actually don't know how it's going to play out of our competition having more CUs than us for these workloads versus us having the better performing coherent memory. I will say that we do have quite a lot of experience in terms of GPGPU - the Xbox 360 Kinect, we're doing all the Exemplar processing on the GPU so GPGPU is very much a key part of our design for Xbox One. Building on that and knowing what titles want to do in the future. Something like Exemplar... Exemplar ironically doesn't need much ALU. It's much more about the latency you have in terms of memory fetch [latency hiding of the GPU], so this is kind of a natural evolution for us. It's like, OK, it's the memory system which is more important for some particular GPGPU workloads.
Algunos que decían por ahí que la GPU de AMD podía estar basada en Volcanic Islands se van a llevar una decepcion. Porque está basada no un Souther Islands, sino en ese paso intermedio que AMD no llegó a materializar del todo que es Sea Islands y cuyo único ejemplo es BONAIRE (la 7790). AMD no sacó la arquitectura Sea Islands que era una revision y mejora de Southern Islands porque se dieron cuenta que tenían todavía Stock de sobra de Souther Islands, y que dada la bajada de ventas de PC, era absurdo sacar una generación que era un avance sobre la anterior pero no un punto de ruptura lo suficientemente importante como para que la gente buscara lo nuevo con respecto a lo que ya tenían. Asi que Sea Islands se quedó en el limbo sin salir mas que la gama baja que es la 7790 (que es la GPU en la que se han basado para la GPU de XBOX One), y han saltado a Volcanic Islands, por eso las proximas tarjetas de AMD en lugar de ser la serie 8000, serían la serian la serie 9000 (pero AMD viendo que ya se iban a las 10.000, ha decidido cambiar su nomenclatura y ahora sus proximas tarjetas se denominarán como R9 290x por ejemplo ese R9 si mal no recuerdo hace referencia a que serían la generación 9000.
Despues salta con el tema del BALANCE FAMOSO, (sí, para variar), y que lo que importa no son las especificaciones sino son los BenchMarks, y que los BenchMarks en una consola los dan los juegos.
Y mira ...
Sí efectivamente lo que importa son los Benchsmarks, pero si tienes unas especificaciones, y tienes unas GPUs que son claramente un derivado y muy muy proximo a las GPUs actuales que ya hay en el mercado puedes perfectamente hacerte una idea aproximada de cuanto van a rendir en terminos reales haciendo BenchMark a la GPU mas proxima a la que tiene la consola, y subiendo o capando ciertos aspectos.
Eso ya se ha hecho con ambas consolas. De hecho la propia Eurogamer lo ha hecho aunque de manera horriblemente MAL, ellos sabrán el porque ... , pero ya ha habido usuarios que lo han hecho y de forma bastante pero bastante mas ajustada y lo que da es esto:El caso es que como se me está haciendo muy largo y muchas de las cosas se repiten entre el articulo que colgaron anteriormente y este pues pongo lo mismo que ya puse y fuera:To preface this post I want to say that although I admire what Digital Foundry tried to do but their methodologies were not only flawed but straight up wrong.
The first thing they did wrong was select the wrong graphics cards to correctly compare the 2 situations.
For the Xbox One they used a HD 7850 over a HD 7790 while for the PS4 they used a 7870 XT over a 7850. This is wrong because using the 7850 for the Xbox One thrusts it into a whole different category of graphics cards that bring many advantages not present in the Xbox One GPU (32 ROPs vs 16 ROPs).
The methodology they used would have been perfect if they grabbed a HD 7790 and clocked it to ~731 Mhz for the Xbox One's GPU and used a a HD 7850 and clocked it to 898 Mhz.
Xbox One = 1.310 Teraflops ------- (HD 7790)Bonaire @ 731 Mhz = .731*2*896 = ~1.310 Teraflops
PS4 = 1.84 Teraflops ------- (HD 7850)Pitcairn @ 898 Mhz = .898*2*1024 = ~1.84 Teraflops
I reckon using these cards at these clocks would really show the GPU difference between the two consoles but alas Digital Foundry went about this some other dumbass way.
To get to the point since I don't have the hardware I mentioned above on hand to conduct the tests myself but I can extrapolate data from graphics cards that are similar to what goes into these consoles. For the Xbox One that would be an HD 7770 because it has a similar amount of GPU power as the GPU used in the Xbox One (1.310 Tflops vs 1.28 Tflops) while for the PS4 I would use the HD 7850 (1.84 Tflops vs 1.76 Tflops) and then compare the results for a realistic look at the performance gap. Oh, by the way the gap between 1.28(HD 7770) and 1.76(HD 7850) is smaller than the gap between 1.31(Xbox One) and 1.84(PS4) so that's already giving a slight break to the Xbox One in this comparison.
For my analysis I am using benchmark numbers from Anandtech.com:
http://anandtech.com/bench/product/777?vs=778
Using the data above I came up with the following chart:
I submit to you that the performance difference between the Xbox One and the PS4 will be much more apparent than what Digital Foundry has hypothesized and that the overall difference in power will not only be tangible but possible even staggering.Eurogamer escribió:Digital Foundry: With regards the benefits of the 6.6 per cent GPU clock speed boost over the 17 per cent of extra compute power offered by the two redundant compute units, is there a chance that they might have been ROP-bound in that scenario? 16 ROPs is another point of differentiation up against the 32 in the competition.
Andrew Goossen: Yes, some parts of the frames may have been ROP-bound. However, in our more detailed analysis we've found that the portions of typical game content frames that are bound on ROP and not bound on bandwidth are generally quite small. The primary reason that the 6.6 per cent clock speed boost was a win over additional CUs was because it lifted all internal parts of the pipeline such as vertex rate, triangle rate, draw issue rate, etc.
The goal of a 'balanced' system is by definition not to be consistently bottlenecked on any one area. In general with a balanced system there should rarely be a single bottleneck over the course of any given frame - parts of the frame can be fill-rate bound, other can be ALU bound, others can be fetch bound, others can be memory bound, others can be wave occupancy bound, others can be draw-setup bound, others can be state change bound, etc. To complicate matters further, the GPU bottlenecks can change within the course of a single draw call!
The relationship between fill-rate and memory bandwidth is a good example of where balance is necessary. A high fill-rate won't help if the memory system can't sustain the bandwidth required to run at that fill rate. For example, consider a typical game scenario where the render target is 32bpp [bits per pixel] and blending is disabled, and the depth/stencil surface is 32bpp with Z enabled. That amount to 12 bytes of bandwidth needed per pixel drawn (eight bytes write, four bytes read). At our peak fill-rate of 13.65GPixels/s that adds up to 164GB/s of real bandwidth that is needed which pretty much saturates our ESRAM bandwidth. In this case, even if we had doubled the number of ROPs, the effective fill-rate would not have changed because we would be bottlenecked on bandwidth. In other words, we balanced our ROPs to our bandwidth for our target scenarios. Keep in mind that bandwidth is also needed for vertex and texture data as well, which in our case typically comes from DDR3.
If we had designed for 2D UI scenarios instead of 3D game scenarios, we might have changed this design balance. In 2D UI there is typically no Z-buffer and so the bandwidth requirements to achieve peak fill-rate are often less.
Digital Foundry: With the recent disclosure that Ryse is running at "900p" and Killer Instinct at 720p, and that launch titles were profiled to balance the system, what are the limiting factors that prevent these tiles running at full 1080p?
Andrew Goossen: We've chosen to let title developers make the trade-off of resolution vs. per-pixel quality in whatever way is most appropriate to their game content. A lower resolution generally means that there can be more quality per pixel. With a high-quality scaler and antialiasing and render resolutions such as 720p or '900p', some games look better with more GPU processing going to each pixel than to the number of pixels; others look better at 1080p with less GPU processing per pixel. We built Xbox One with a higher quality scaler than on Xbox 360, and added an additional display plane, to provide more freedom to developers in this area. This matter of choice was a lesson we learned from Xbox 360 where at launch we had a Technical Certification Requirement mandate that all titles had to be 720p or better with at least 2x anti-aliasing - and we later ended up eliminating that TCR as we found it was ultimately better to allow developers to make the resolution decision themselves. Game developers are naturally incented to make the highest-quality visuals possible and so will choose the most appropriate trade-off between quality of each pixel vs. number of pixels for their games.
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.Herebus escribió:Para quien no lo sepa ha salido un articulo de Digital Foundry en el que un redactor entrevista a dos de los ingenieros encargados del diseño del Hardware de XBOX One.
Echadle un ojo.
Yo dejo mi opinion por aqui, justo mas abajo:
Aclaran por un lado cosas pero por otro siguen dejando cosas en el aire.
El titulo debería de ser BALANCE. Y cierto pueden balancear todo lo que quieran pero hay unos cuantos aspectos, que me han llamado poderosamente la atención. Y no para bien:
Empezamos:
Con respecto a la eSRAM
Comentan que les ha sorprendido la respuesta de la gente ante su aproximación de memoria para XBOX One, cuando es una evolución de lo visto en XBOX 360 y XBOX 360 era un hardware fácil para trabajar.
Comentan que los 204GBps son en pico. (Obvio)
Confirman que el rendimiento medio real sería de 140/150GBps.
Confirman que no es una caché ni por asomo es un ScratchPAD, por tanto nada de espacio de memoria direccionable directamente por hardware, sino que tiene que ser administrado por cada App.
Confirman que sí se puede leer y escribir a la vez, dado que son 4 Módulos de 8MB cada uno con un controlador cada uno de 256Bits lo que da un bus total de 1024.
Eso quiere decir que por ejemplo 2 clusters pueden estar leyendo y dos escribiendo. Si lo manejas bien puedes tener en un momento dado a todos leyendo y conseguir el pico comentado, salvando los errores de acceso.
Lo que NO Comentan:
- No comentan que en la generación actual si lo comparamos con PS3, XBOX360 es aplastantemente mas facil de programar. Pero dado que en la anterior estabamos con PowerPC, pues ya había que dar un salto (por decirlo de alguna manera), para los juegos Multiplataformas que se desarrollaban pensando en PC. Y por tanto pues puestos a saltar el salto a un pool unificado y un ScratchPAD de eDRAM de XBOX 360 era y es más fácil.
El problema es que en la genearción al caer hemos saltado de arquitectura RISC PowerPC a arquitectura CISC x86. ¿Porque? Porque no había una alternativa RISC que fuera interesante por precio y potencia, y porque los desarrollos cada vez son mas caros. Por tanto la idea es abaratar costes. ¿Como? Simplificando la vida al desarrollador haciendo que solo tenga que programar para x86 para que salga en PC y consolas, le estas ahorrando esfuerzo, personal y tiempo, o lo que es lo mismo dinero.
Y ya que saltas a x86 si quieres hacer las cosas aún más fácil al desarrollador, lo ideal es olvidarse de los ScratchPADs, que no dejan de ser añadidos anexos a un Microprocesador para poder trabajar sueltos a pesar de las limitaciones de ancho de banda a la memoria principal. Pero si ya tienes un buen ancho a una memoria principal y esa memoria es unificada y en cantidad, es hacerle las cosas mucho mas sencillas aún. Meter un ScratchPAD lo que hace es complicarles la vida, porque en PC NUNCA se programan juegos pensando en esos ScratchPADs porque NO los hay.
Por eso Intel y AMD a pesar de que ya hace tiempo que han tocado techo con sus APUs (GPU+CPU), en el sentido de que no pueden meter GPUs mas potentes sin que la falta de ancho de banda ahogue por completo esas GPUs, no se han lanzado a meter ScratchPADs de eDRAM o eSRAM en sus APUs para PC. ¿Porque?. Porque habría que desarrollar ex professo para ello, (algo que los desarrolladores de Juegos para PC no van a hacer, es decir no van a currarse una versión para un puñado de CPUs de PC). O bien meter una capa de abstracción, que se comería gran parte de los recursos. Asi que por eso lo han descartado y estan pensando en tirar como ha hecho AMD para PS4, en meter una APU con solo GDDR5, y que vaya todo soldado en placa, Micro y Memorias, (interesante quizá para Ordenadores portatiles (aunque saca de la ecuación la opcion de ampliar), o bien lo que están haciendo que es esperar como lobos a que salga la memoria DDR4.
- Si tienes 4 clusters y no 1, tienes un problema si tienes digamos un dato grande (las texturas lo son por ejemplo) tienes que repartirlo entre uno, dos o hasta tres de esos clusters. Segun como repartas eso puede jugar en tu contra o en tu favor. El problema es que en cualquier de los casos, el hacer que juegue en tu favor y no en tu contra, te va a llevar a tener que planear y con mucho ojo como lo haces.
- Siguen siendo 32MB. Y son esos 32MB los únicos que tienen y ofrecen un ancho suficiente a la GPU para trabajar sin problema. El trabajo para traer, almacenar y llevar datos entre GPU y Pool de DDR3, va a ser fino.
La XBOX360 tenía un ancho de 22,4GBps a los 512MB de GDDR3 (notese que ya la XBOX 360 motaba GDDR3 y NO DDR2, que sería lo equivalente a lo que monta ahora XBOX ONe que es DDR3).
La GPU de XBOX 360 llamada Xenos, era un derivado del chip RV600 de AMD, que iendonos por arriba sería un "a caballo" entre una Radeon HD 2400 y 2600, y Xenos tiene 230millones de trasistores, corre a 500Mhz, y . Ese "a caballo" de GPU debería requerir de ancho para ella sola unos 12/15GBps aprox. La CPU por tanto se tendría que conformar con el resto.
A lo que voy es que el acceso al Pool central de RAM GDDR3 en XBOX 360 era lo suficientemente rápido como para asegurar el ancho de banda que necesitaba la GPU y quedaba algo para la CPU. Tenía un ScratchPAD de 10MB eDRAM con un acceso inicial de 30GBps y otro interno a 256GBps para tratar ciertos datos de forma más rapido y no tener que abusar del ancho al pool Central de 512MB que compartía con CPU, pero repito que tenía opcion a alimentarse por completo (como de hecho en gran medida hacía) de los datos que llegaban e iban al Pool de GDDR3.
En XBOX One el tema es otro. La GPU de XBOX One es un derivado de la serie 77xx de AMD. De hecho en el articulo comentan a las claras que es Southern Islands, NADA de Volcanic Islands (de hecho era absurdo pensar en que una APU para algo que se lanza en 2 meses iba a basarse en Volcanic Islands, cuando Volcanic Islands es una arquitectura para 2014, porque AMD se ha saltado la serie 8000 que iba a ser Sea Islands de 2013 por la bajada de ventas de PCs y porque es absurdo lanzar algo nuevo cuando tienes todavía Stock de lo anterior, ademas el chip tanto de PS4 y XBOX One tenían que estar 100% diseñado y cerrado como tarde en el tercer cuarto de 2012).
El caso y volviendo al tema y perdón por la disgresión, la GPU de XBOX One es una derivación de la serie 77xx de AMD. La GPU más básica de esa serie la 7750 (que es de hecho menos potente que la GPU de XBOX One, que tiene aspectos de la 7790 [2 cálculos por ciclo], de hecho comentan mas adelante que en realidad su GPU monta 14Compute Units (CUs), como la 7790 solo que 2 de ellos estan capados para redundancia y tener mas chips buenos por oblea, la 7790 con 14CUs aún cuando corre a 1GHz reclama como mínimo para ella sola 96GBps, y la 7770 con 10 CUs y corriendo a 1GHz reclarma 72/73GBps, y lo mismo reclama la 7750 que tiene apenas 8CUs y corre segun la version entre 800 y 9xxMhz
El acceso de XBOX One a los 8GB de DDR3 es de 68GBps a repartir entre CPU y GPU. :roll: :roll:
Asi que la eSRAM y los DMEs están no como complemento sino que van a tener que estar a destajo para poder alimentar desde el Pool Central a la GPU.
- Segun estos señores, la decisión de escoger DDR3 y eSRAM es por dos cuestiones. Una evolucionar un modelo que les fue bien en XBOX 360, y otro los consumos.
Y lo han apostillado soltando esto:
<<< "Yeah, I think that's right. In terms of getting the best possible combination of performance, memory size, power, the GDDR5 takes you into a little bit of an uncomfortable place," >>>
Hasta aquí el articulo ha tenido sus puntos, pero cuando basicamente han soltado esto es cuando literalmente me he quedado así :o :o :?
Vamos a ver, sí cierto que GDDR5 consume mas energía, y emite mas calor, pero que en ningun momento digas a las claras que el motivo fundamental que puede llevar a estas alturas de los tiempos a alguien a meter para alimentar a una GPU DDR3 y no GDDR5, es el PRECIO .... , pues hombre ... X-D
El consumo y el calor de GDDR5 e mayor que el de DDR3 sí sin duda, eso te lleva a tener que meter una fuente algo mayor, y un sistema mejor de disipación ventilación lo que redunda todo ello a la fin de la postre en ---> COSTES MAS ALTOS. Y la GDDR5 ya es mas cara de por sí. Así que la GDDR5 es una memoria infinitamente mejor para una GPU de gama media actual, pero a costa de ser mas cara en sí y en su implementación. Al final a lo que voy es que todo redunda en COSTES y PRECIO.
Y punto pelota.
Ahora mismo salvo en gamas muy muy bajas (es decir las mas baratas de las baratas) ni una sola compañía en gama media o media baja tiene en Stock NI UNA pero NI UNA sola GPU que tire con DDR3. Todas montan GDDR5. ¿Porque?. Porque es la única memoria que aporta un ancho de banda suficiente.
La aproximacion de buscar el menor coste tiene su sentido, si vas con la idea de lanzar el producto a un precio de venta al público menor que el de tu competencia mas directa.
Pero es que aquí ha pasado lo contrario ... :roll: :shock: ... , sale 100€ mas cara. ¿Quien puñetas se ha llevado el gato al agua para que a pesar de montar un hardware de base mas barato y rebañando en aspecto tan fundamentales como la memoria, salgo costando 100€ mas que la competencia? ---> KINECT.
DDR3
- En el articulo comentan que la polemica de sumar anchos no la entienden ya que en realidad la GPU si que puede leer del ScartchPAD y del Pool de DDR3.
Sí es cierto, de hecho solo faltaba, pero las cosas no funcionan así, no puedes sumar tan alegremente ambos anchos cuando el ancho a DDR3 hay que repartirlo con CPU. Ademas la GPU tiene su propio controlador de memoria, a ese controlador de memoria es al que conecta todo DMEs, GPU, y eSRAM, y de ese controlador hay un canal que lleva al controlador de memoria de la APU, (al que conecta tambien la CPU), y es lo que a su vez conecta a DDR3.
Si la GPU llama a DDR3 el dato tiene que llegar pasa por el controlador de APU, llegar al controlador de GPU y pasar DMEs donde presumiblemente se descomprime se pasa de nuevo al controlador de GPU, y desde allí tira a eSRAM o tira a GPU directamente.
A lo que voy es que con apenas 32MB de eSRAM los datos van a tener que estar entrando y saliendo de ahí de forma continua, no tienes apenas espacio (si tienes por ejemplo 2 o 3 FrameBuffers), para dejar datos residentes, por lo que a la fin de la postre, tienes que estar de forma continua llamando y enviando datos al Pool de DDR3 que está muy muy costreñido ya, y de ahí repito que haya DMEs y eSRAM.
¿Es decir aportan datos la eSRAM y el pool de DDR3 a GPU?
Sí
Pero dado el tamaño, apenas (si es que puedes) dejar datos residentes en eSRAM mas allá de FrameBuffers & Co, y los datos que debe servir la eSRAM a GPU en realidad son los mismos que han sido llamados antes al Pool de DDR3.
Por tanto sumarlos es absurdo, salvo quizá algun momento muy puntual que dudo que se dé ... :| :roll:
GPU
- Comentan que la GPU de XBOX One, tiene por defecto 14CUs, pero de esos 14CUs, solo 12 están activos. Y para los que os lo pregunteis, NO, nunca van a poder activarse.
Esos 2CUs de más están ahí para asegurar que el ratio de Chips "buenos", por Oblea es bueno. Es decir que de los chips que salen de fabrica hay algunos que salen perfectos y con los 14CUs, bien y otros que salen solo con 13, y otros con 12CUs. Algunos salen solo 11CUs bien. Los que salen con menos de 12CUs se tiran a la basura. Los que salen con 12CUs o más se ponen en placa, y luego a las estanterías de las tiendas. Los que salen con 13 o 14CUs simplemente se les capa uno o dos CUs respectivamente. Asi todo el mundo tiene el msimo hardware.
De hecho es mas que probable que en realidad PS4 tenga no 18 sino 20 CUs, estando dos de ellas tambien desactivadas por redundancias.
- Comentan que hicieron pruebas de hecho y cogieron un chip con los 14CUs bien y los activaron para ver como rendían. Y el rendimiento de meter 2CUs más en lineas generales aporta un 17% más de potencia.
Y luego probaron a hacer un OverClock a solo 12CUs y les dio un 6,6% de ganancia.
Sin embargo segun ellos en circunstancias reales hay una serie de cuellos de botella en el pipeline que hacen realmente mas rentable desde un punto de vista de rendimiento subir frecuencias y no desbloquear CUs.
Y aquí es donde es un sí, tienen razón, pero por otro lado NO, porque no cuentan toda la historia tampoco.
Los cuellos de botella al que se refieren son las ROPs. La GPU de XBOX One cuenta con 16 ROPs. Los ROPs son Raster Operators (Operadores de Raster), que basicamente son un componente de la GPU que se encarga de juntar toda la información que viene del Vertex, Vertex Shader, Pixel, Pixel Shader, Color, Stencil, etc, y juntarlas de acuerdo a la resolución que buscas y escupirlo a la pantalla.
Es como la última parte del proceso. Teners mas ROPs significa a la hora del rendimiento ahorrar mucho ancho de banda, ya que te ahorras llamadas a memoria.
El caso es que subir el número de CUs NO SUBE EL NUMERO DE ROPs.
De hecho en las gráficas de arriba se puede ver como la 7750, 7770 y 7790 tiene 8, 10 y 14 CUs respectivamente pero todas tienen 16 ROPs.
Conclusión ---> SÍ QUE HAY UN CUELLO DE BOTELLA Y GORDO EN LA GPU DE XBOX ONE Y ES ---> FALTA DE ANCHO DE BANDA.
Si hubieran decidido sacrificar dinero desechar las APUs que tiene solo 12 o 13CUs bien y coger solo las que salen perfectas de 14CUs, (cosa que tampoco pueden hacer porque sería una sangría de dinero salvaje), no solo seguirían teniendo sino que estarían empeorando aún mas el problema que tiene que es la falta de Ancho de Banda porque tienen solo 16 ROPs.
Si suben en cambio frecuencia y no solo la frecuencia de la GPU, que aquí viene lo importante, sino tambien de la eSRAM y por tanto tienen de base en lugar de 102GBps tienen 109GBps, tienen mas ancho con el que tirar y minimizan un poco el problemas de ir justos con las ROPs (y repito si tienes ancho suficiente tener mas ROPs no hace falta, por eso la 7750, 7770 y 7790, tiran las 3 con 16 ROPs, pero si vas justo y tened claro no, sino critalino que XBOX One va justa pero que muy justa de ancho de banda, el tener mas ROPs te puede reducir esa demanda de ancho), y dan a su vez mas salida y juego a los FrameBuffers.
Esa subida de frecuencias les permite ir mas balanceados, y es cierto. El tema es que PS4 no va mal balanceada para nada cuanta de hecho con 32 ROPs y un ancho a un Pool centra de 176GBps a repartir entre CPU y GPU. Pero las 7850 y la 7870 no demanda mas de 153GBps.
Dejando 23GBps para la CPU.
El tema de las TUs (Texture Units) que hablamos de 48 en XBOX One y 72 en PS4, pues tambien puede suponer y mucho ciertos problemas sobre todo a largo plazo dado que se sigue ampliando y ampliando resolución de las texturas, pero esa es otra historia ...
Lo que no comentan al hablar de dichos aspectos es que:
- Siguen sin comentar un pijo, como han apañado el tema de los anchos de banda desde el Pool de DDR3. Si ya de por sí el ancho al Pool de DDR3 iendo a 68GBps iba justo con la CPU a 1,6Ghz y la GPU a 800Mhz, ahora que lo han subido a 1,7Ghz la CPU y 853Mhz la GPU, lo van a llevar todavía mas crudo ... :pale:
En su momento ya comenté esto mismo, y comenté que al subir toda la APU suben CPU, suben GPU, suben eSRAM, y suben tambien de frecuencia de trabajo los DMEs, por tanto quizá lo haya solucionado apostando por aprovechandose de la mayor frecuencia de trabajo de los DMEs, hayan aumentado el nivel de compresión de los datos que van y vienen al Pool de DDR3, pero no han dicho ni Pamplona al respecto.
GPU &GPGPU
Esto ya con todos los respetos por momentos me parece que no saben ni por donde salir.
- Primero comentan que Sony está de acuerdo con ellos porque Sony tambien ha pensado en el balance y hace referencia al tema de los 14CUs para Render y los otros 4CUs para GPGPU.
Algo desmentido ya por Cerny hace meses.
Los 18CUs de PS4 son CUs y punto. Se pueden dedicar a lo que sea a Render o a GPGPU a discrección del programados, y de hecho han reforzado esa capacidad subien de 2 (que tendría una GPU como la de PS4 en PC) a 8 hilos diferentes y simultaneos de tareas tipo GPGPU que puede comerse la GPU.
- Comentan tambien que ellos en sus 12CUs tambien tienen margen (eso es lo que significa HearRoom), entre lo que da actualmente y puede dar sin problemas, por lo que tambien pueden aprovechar temas de GPGPU. Es cierto no es un mentira ni mucho menos, pero sin animo de ofender ... , hombre ...
- Segun ellos la soluciones GPGPU para XBOX One las abordarán o detallarán mas adelante. Pero al parecer ellos aprovecharan la baja latencia de la memoria DDR3. Por lo que deduzco que se refieren mas que GPGPU, se refieren a aprovechar las bajas latencias de la memoria DDR3 para que la CPU trabaje mejor ... :no:
A ver vamos por partes. El cálculo GPGPU consiste en aprovechar la GPU para tratar tareas de proposito general, aprovechando su capacidad de procesado en paralelo.
Las bajas latencias son importantes cuando se realizan procesos consecutivos y ordenados que hay que tomar los datos y hacer una labor con ellos en orden y uno por uno.
Cuando se trabaja en paralelo a gran escala como en las GPUs, el impacto de las latencias es mínimo. Porque se cogen todos los datos del tiron y se van reaprovechando usando los resultados y trazando un mapa de trabajo en cascada.
Por eso tirar un RENDER por GPU en cualquier programa actual que le de uso tarda digamos 30 minutos tirando de una CPU de Gama Alta y con una GPU de gama media o baja los tienes en 15 minutos.
A mayor capacidad e hilos posibles de ejecución de GPGPU mejor. Asi de simple.
Ellos comentan que hay ciertas labores de GPGPU que tiran mejor aprovechando bajas latencias. Y estamos en lo de siempre sí pero no.
Si porque efectivamente tienes menos latencias y los datos entre que son llamados y servidos hay menos retardo y contar con un retardo pequeño te da mas margen de ejecutar "a tiempo", sin pérdida de ciclos. Pero eso es cierto siempre que que estés llamando a los datos digamos que casi de uno en uno ...
Si llamas un paquete de datos grandes y lo sueltas sobre una GPU el aumento de retardo entre que llamas y se sirven se pulveriza y se invierte hasta el extremo al procesar toda esa avalancha de datos de forma paralela en la GPU. ESA ES LA VENTAJA DE GPGPU de hecho.
CPU
- Segun ellos han visto que los juegos uno de los factores que mas costriñe es la CPU. Y sí es cierto. Es un factor limitante de base. La CPU que montan PS4 y XBOX One es lo que es.
- Ahora estamos con lo de antes, subir un 9% de CPU, ayuda sí sin duda. y es bienvenido, pero no supone un cambio radical ni mucho menos. Hablamos de 1 fotograma por segundo más, ¿quizá?.
Y seguimos aún por esas en las mismas y ver si el hecho de subir la frecuencia de trabajo de ambos micros, tanto CPU como GPU, pero no subir la frecuencia de la RAM DDR3 que sigue en 68GBps, lo han resuelto realmente o no. Si no lo han resuelto la primera perjudicada será la CPU, ya que la GPU como es normal suele tener prioridad en una consola de videojuegos ya que es el apartado que mas recursos demanda con diferencia. Luego esa subida quedaría mermada en gran parte. La CPU podría trabajar mas rapido con los datos que ya tenga pero si el ancho a repartir es el mismo y ya iba justo, y ahora ambos micros demandan más, pues hay que decidir en el reparto quien se lleva mas trozo del pastel, porque ademas la GPU hace un uso y repito continuo e intensivo de acceso a RAM.
DESCARGA DE LA CPU
- Comentan que ellos gracias a la labor de los CoProcesadores del chip de Sonido Shape, y etc, que pueden descarga mucho a la CPU de cierta carga.
- Y tambien son ellos mismos quienes comentan que gran parte de esa carga es de Kinect, y que si esos CoProcesadores están ahí es por y para hacer que el uso de Kinect tenga el impacto menor posible en el resto del hardware.
- PS4 simplemente no cuenta con un control por gestos y voz, de serie, no tiene que lidiar con ello, no tiene esa carga simplemente. Es igualmente cierto que si algun juego hace uso de control por voz y gestos, esos aspectos tendrán que deducirse de quitar parte de proceso a CPU y GPU para que se encarguen de ello, mientras que en XBOX One no.
REESCALADO
- Comentan tambien en la misma linea que tienen en la miriada de esos CoProcesadores, sistema para llevar a cabo Overlays. Hacer un Overlays no es mas que superponer capas o si lo preferís ventanas. Separar la imagen en ventanas y que esa separación en ventanas o apartados tenga un coste lo mas reducido posible.
- Comentan que pueden aplicarlo por ejemplo para ajustar de forma dinamica la resolución de un juego. Para que en momentos de mucha carga baje la resolución del escenario pero que poniendo el HUD o al personaje principal en una de esas ventajas a parte pueden dejar que esos aspectos mantengan esa resolucion inicial (pongamos 1080p), mientras que el resto de la imagen baja a 900p por ejemplo. Segun ellos hace que el impacto de bajar de resolución en momentos puntuales para asegurar un buen FrameRate, sea apenas percibido por el usuario.
- Lo que no comentan es que se supone que esos CoProcesadores encargados de Escalar y hacer Overlays, tiene que estar tambien pendientes del sistema, pero de hecho si están ahí es porque el Sistema Operativo de MicroSoft, se basa en que tener por ejemplo para la videoconferencia durante el juego (PiP, Picture in Picture), es decir el juego y sobre el juego una ventana en la que se ve a la persona al otro lado de la llamada. Y para tener por ejemplo en el margen del Televisior los mensajes de texto y Chat con otras personas.
Si tienen que dejar esas opciones del sistema abiertas, (y lo tiene que dejar sí o sí a menos que cambien radicalmente todo el planteamiento del Sisteam Operativo y no creo que estén por la labor a estas alturas), y queda algo para que lo usen los desarrolladores, es lo que está por ver. A mi entender, sí queda pero desde luego no mucho.
Conclusión: la consola estará balanceada pero no hay novedad.
Esto sigue siendo inamovible:
PS4's GPU: 800Mhz; 18CUs; 1152SPs; 72TMUs; 32ROPs;
Xbone's GPU: 853Mhz; 12CUs; 768SPs; 48TMUs; 16ROPs;
Xbox One...............................................................PS4:
CPU 1,75 Ghz (+9%) ..........................................CPU 1,6 Ghz
GPU 12 Compute Units (CUs).............................GPU 18 Compute Units (CUs) (+50%)
1.31 TFLOPS / 1,18TFLOPS (for GAMES) ...........1.84 TFLOPS (+40%)
40.9 GTex/s ........................................................57.6 GTex/s (+40%)
13.6 GPix/s..........................................................25.6 GPix/s (+90%)
68GB/s 8GB DDR3..............................................176GB/s 8GB GDDR5(+160%)
109GB/s eSRAM .................................................. ,, (+61% vs eSRAM)
4/16 ACE/GPGPU Lines...............................................8/64 ACE/GPGPU Lines (+300%)
768 Shaders.......................................................1152 Shaders (+50%)
48 Texture units..................................................72 Texture units (+50%)
16 ROPS.............................................................32 ROPS (+100%)PS4: 1152 Shaders
Xbone: 768 Shaders
PS4: 72 Texture units
Xbone: 48 Texture units
PS4: 32 ROPS
Xbone: 16 ROPSSi se verá o no en los juegos multis y exclusivos, coincido que es la mejor prueba, está por ver ...Xb1+PS3+X360 < PS4
Xb1: 1.31 TF
PS3: 250 Gflops (without Cell) aprox
X360: 230 Gflops aprox
PS4: 1.84 TF
PS4 - XB1 = 530GFlops
Xb1+PS3+X360 < PS4Sigo con esto que comentan de GPGPU que no aparecía anteriormente:Herebus escribió:
GRAFICAS (Comparativas) provienen de GAF
GRAFICA 1En el caso de XBOX One, se ha tomado en cuenta que la GPU siendo como es Bonaire tiene la opcion de tratar 2 Primitivas por Ciclo de Reloj, (eso es lo que indica la columna Roja PRIM RATE). Y se ha tomado como referencia los 140/150GBps de Ancho de Banda de Media que puede dar la eSRAM.Artist (NeoGAF) escribió:
A nivel de computación se ha tomado con valido los datos de 2 ACEs y 8 colas de ejecución. (16 registros de ejecución)
En el caso de PS4, en computacion NO sé si han tomado en cuenta los 8 ACE y 8 colas de ejecucion (64 registros de ejecución).
En ambas consolas y por motivos obvios se salta la columna de Performance dado que no hay Benchmarks.
En cuanto a las conclusiones se puede apreciar como los valores mas interdependientes con el Rendimiento (Performance), son y por orden de mas importantes a menos:
1º Computación
2ºTexturizado,
3ºPixel FillRate / Memory Bandwith
4º Prim Rate.
Grafica 2En esta otra gráfica es igual que al anterior, solo que cambiando el valor del Ancho de Banda de XBOX One, al ancho al pool principal de RAM es decir 68GBps.Nib95/Artist (NeoGAF) escribió:
Grafica 3Relacion entre el Rendimiento y numero de ALUs o Stream Processors y por tanto al numero de CUs (Compute Units).Nib95/Artist (NeoGAF) escribió:
EDITO: Para poner los datos de rerferencia:
XBOX One tiene 768 Stream Processors y PS4 tiene 1152 Stream Processors.Les preguntan por el procesado tipo GPGPU.Eurogamer escribió:
Digital Foundry: So what is your general approach to GPGPU? Sony has made a big deal about its wider compute pipelines in order to get more utilisation of the ALU. What is your philosophy for GPGPU on Xbox One?
Andrew Goossen: Our philosophy is that ALU is really, really important going forward but like I said we did take a different tack on things. Again, on Xbox One our Kinect workloads are running on the GPU with asynchronous compute for all of our GPGPU workloads and we have all the requirements for efficient GPGPU in terms of fast coherent memory, we have our operating system - that takes us back to our system design. Our memory manager on game title side is completely rewritten. We did that to ensure that our virtual addressing for the CPU and GPU are actually the same when you're on that side. Keeping the virtual addresses the same for both CPU and GPU allows the GPU and CPU to share pointers. For example, a shared virtual address space along with coherent memory along with eliminating demand paging means the GPU can directly traverse CPU data structures such as linked lists.
On the system side we're running in a complete generic Windows memory manager but on the game side we don't have to worry about back-compat or any of these nasty issues. It's very easy for us to rewrite the memory manager and so we've got coherent memory, the same virtual addressing between the two, we have synchronisation mechanisms to coordinate between the CPU and GPU that we can run on there. I mean, we invented DirectCompute - and then we've also got things like AMP that we're making big investments on for Xbox One to actually make use of the GPU hardware and the GPGPU workloads.
The other thing I will point out is that also on the internet I see people adding up the number of ALUs and the CPU and adding that onto the GPU and saying, "Ah, you know, Microsoft's CPU boost doesn't make much of a difference." But there still are quite a number of workloads that do not run efficiently on GPGPU. You need to have data parallel workloads to run efficiently on the GPU. The CPU nowadays can run non-data parallel workloads but you're throwing away massive amounts of performance. And for us, getting back to the balance and being able to go back and tweak our performance with the overhead in the margin that we had in the thermals and the silicon design, it kind of enabled us to go back and look at things. We looked at our launch titles and saw that - hey we didn't make the balance between CPU and GPU in terms of our launch titles - we probably under-tweaked it when we designed it two or three years ago. And so it was very beneficial to go back and do that clock raise on the CPU because that's a big benefit to your workloads that can't be running data parallel.
Digital Foundry: The GPU compute comparison seems to be about Xbox One's high coherent read bandwidth vs. raw ALU on PS4. But don't the additional ACEs added to PS4 aim to address that issue?
Andrew Goossen: The number of asynchronous compute queues provided by the ACEs doesn't affect the amount of bandwidth or number of effective FLOPs or any other performance metrics of the GPU. Rather, it dictates the number of simultaneous hardware "contexts" that the GPU's hardware scheduler can operate on any one time. You can think of these as analogous to CPU software threads - they are logical threads of execution that share the GPU hardware. Having more of them doesn't necessarily improve the actual throughput of the system - indeed, just like a program running on the CPU, too many concurrent threads can make aggregate effective performance worse due to thrashing. We believe that the 16 queues afforded by our two ACEs are quite sufficient.
Another very important thing for us in terms of design on the system was to ensure that our game had smooth frame-rates. Interestingly, the biggest source of your frame-rate drops actually comes from the CPU, not the GPU. Adding the margin on the CPU... we actually had titles that were losing frames largely because they were CPU-bound in terms of their core threads. In providing what looks like a very little boost, it's actually a very significant win for us in making sure that we get the steady frame-rates on our console. And so that was a key design goal of ours - and we've got a lot of CPU offload going on.
We've got the SHAPE, the more efficient command processor [relative to the standard design], we've got the clock boost - it's in large part actually is to ensure that we've got the headroom for the frame-rates. We've done things on the GPU side as well with our hardware overlays to ensure more consistent frame-rates. We have two independent layers we can give to the titles where one can be 3D content, one can be the HUD. We have a higher quality scaler than we had on Xbox 360. What this does is that we actually allow you to change the scaler parameters on a frame-by-frame basis. I talked about CPU glitches causing frame glitches... GPU workloads tend to be more coherent frame to frame. There doesn't tend to be big spikes like you get on the CPU and so you can adapt to that.
What we're seeing in titles is adopting the notion of dynamic resolution scaling to avoid glitching frame-rate. As they start getting into an area where they're starting to hit on the margin there where they could potentially go over their frame budget, they could start dynamically scaling back on resolution and they can keep their HUD in terms of true resolution and the 3D content is squeezing. Again, from my aspect as a gamer I'd rather have a consistent frame-rate and some squeezing on the number of pixels than have those frame-rate glitches.
Y AQUI HAY NOVEDAD:
Porque confirman que tienen 16 registros para hacer GPGPU. PS4 tiene 64. Es decir PS4 es hasta un 300% mas potente en ese apartado que XBOX One.
Lo cachondo es que según ellos le dan mucha importancia al tema GPGPU, porque de hecho usan GPGPU para tratar los datos de Kinect, pero por otro lado salen por la tangente cuando se les pone en la cara los 8ACEs y los 64 registros.
Comentando para variar el tema del BALANCE, (por cierto citan 15 veces la palabra BALANCE durante el articulo), y que en ciertos escenarios puede ser mas perjudicial el tener mas ACEs,
Pero vamos a ver ... , será perjudicial si no tienes ancho de banda con que alimentarlos ... , pero si tienes ancho con el que meter y sacar los datos, de perjudicial tiene lo que yo te diga ... :lol:
Segun ellos le dan mucha importancia a GPGPU, pero al parecer hablan mas de la CPU y de lo que supone el subir su frecuencia de la misma, que de usar la GPU para calculo general (GPGPU). ¿Porque?.
Pues porque una vez dicho que tienes 2/4 ACEs y 16 registros para ejecutar GPGPU, no puedes decir nada mas sobre GPGPU, esta claro.
Es como decir que te importa mucho la potencia pero tienes un motor cuatro cilindros de 1.2L y que da 70CV pero que te importa mucho la potencia de un coche.
Por mucho que digan es un aspecto que a la hora de diseñar o elegir la GPU les ha debido de traer al pairo y manda narices, porque ellos precisamente que iban a hacer una apuesta tan fuerte por Kinect, debería de haberles importado bastante pero bastante más y al menos haber metido lo que ha metido PS4. Asi que el que no le hayan dado mucha relevancia ... pues manda huevos ... , pero que muchos huevos.
Allá ellos ... , para mi es un cagada.
Y en 2/3 años cuando empiecen en PS4 a calzar de forma intercalada codigo GPGPU en los juegos, le van a sacar los colores a XBOX One que no te quiero ni contar.
Porque una cosa es subir tener un 50/56% de ventaja en ciertos aspectos de la GPU, que se los puede comer facilmente el subir un 44% mas el numero de pixeles a tratar que es el pasar de 1600x900 a 1920x1080, y otra el que PS4 tenga un 300% mas de capacidad de calculo GPGPU que XBOX One.
Ahí si que el salto y la diferencia es espeluznante, y en cuanto se pongan a ello ... UFF, pero UFFF, y UFFF y UFFF ....Les preguntan por los DMEs.Eurogamer escribió:Digital Foundry: So often you're CPU bound. That explains why so many of the Data Move Engine functions seem to be about offloading CPU?
Andrew Goossen: Yeah, again I think we under-balanced and we had that great opportunity to change that balance late in the game. The DMA Move Engines also help the GPU significantly as well. For some scenarios there, imagine you've rendered to a depth buffer there in ESRAM. And now you're switching to another depth buffer. You may want to go and pull what is now a texture into DDR so that you can texture out of it later and you're not doing tons of reads from that texture so it actually makes more sense for it to be in DDR. You can use the Move Engines to move these things asynchronously in concert with the GPU so the GPU isn't spending any time on the move. You've got the DMA engine doing it. Now the GPU can go on and immediately work on the next render target rather than simply move bits around.
Nick Baker: From a power/efficiency standpoint as well, fixed functions are more power-friendly on fixed function units. We put data compression on there as well, so we have LZ compression/decompression and also motion JPEG decode which helps with Kinect. So there's a lot more than to the Data Move Engines than moving from one block of memory to another.
Y ellos responden aun dandole muchas vueltas que están basicamente para mover los datos, porque con 32MB de eSRAM si quieres tener Buffers, usar texturas pues vas de culo.
Y así para cada aspecto, sean JPEGs de Kinect, sean LZ COmpression, o lo que sea.
Sea lo que sea, tienen que estar permanentemente jugando como mover y llevar datos de la eSRAM hacia o desde la DDR3.Sobre los 8Gb de memoria NAND, comentan lo obvio que es para el sistema operativo, (y para el arranque y parada rapida), etc.Eurogamer escribió:Digital Foundry: Another thing that came up from the Hot Chips presentation that was new information was the eMMC NAND which I hadn't seen any mention of. I'm told it's not available for titles. So what does it do?
Andrew Goossen: Sure. We use it as a cache system-side to improve system response and again not disturb system performance on the titles running underneath. So what it does is that it makes our boot times faster when you're not coming out of the sleep mode - if you're doing the cold boot. It caches the operating system on there. It also caches system data on there while you're actually running the titles and when you have the snap applications running concurrently. It's so that we're not going and hitting the hard disk at the same time that the title is. All the game data is on the HDD. We wanted to be moving that head around and not worrying about the system coming in and monkeying with the head at an inopportune time.
Doy por hecho que PS4, montará exactamente lo mismo, por eso puede sustituirse el Disco Duro interno de PS4 por otro sin que haya problema ya que el sistema operativo no está en el disco duro. De hecho PS3 ya montaba en placa una cantidad de memoria sóida para ese fin.Les pregunta porqué llegarona la conclusión del OverClock, y que si ha tenido cualquier incidencia en la tasa de chips viables por obleamEurogamer escribió:Digital Foundry: Can you talk us through how you arrived at the CPU and GPU increases that you did and did it have any effect on production yield?
Nick Baker: We knew we had headroom. We didn't know what we wanted to do with it until we had real titles to test on. How much do you increase the GPU by? How much do you increase the CPU by?
Andrew Goossen: We had the headroom. It's a glorious thing to have on a console launch. Normally you're talking about having to downclock. We had a once in a lifetime opportunity to go and pick the spots where we wanted to improve the performance and it was great to have the launch titles to use as the way to drive an informed decision performance improvements we could get out of the headroom.
Comentan que hasta que no tuvieran juegos en cierto estado de desarrollo tampoco podían determinar cuanto y como de fuerte debería de ser ese OverClock, y me otra cosa que como que no me trago.
El Overclock que han hecho es el Overclock que podían hacer.
De hecho el tema de reducir el numero de mercado en los que van a lanzar finalmente con respecto a lo que contemplaron en un principio SI que es posible que sea porque al hacer las overclock el numero de micros que son viables es menor.
De hecho no responden directamente a la pregunta.
Lo único que hacen es no parar de dar importancia al OverClock y sus grandezas y beneficios, pero pasar olimipicamente de hablar de lo que puede suponer en cuanto a demanda de Ancho de Banda para conseguir los 1080p al tener solo 16ROPs, o lo que puede suponer tener menos Texture Units, etc, etc.
Es triste pero entiendo que tienen que vender sus decisiones y el hardware ...De esta parte lo único interesante es que comentan que no pueden decir por ahora cuanto consume la consola por hora. Solo que tienen diversos estados de consumo.Eurogamer escribió:Digital Foundry: So can you tell us how much power Xbox One takes from the wall, during gameplay for example?
Microsoft PR: That's not a figure we're disclosing at this time.
Nick Baker: But we've said on other forums as well that we have implemented multiple power levels - we scale all the way from full power down to 2.5 per cent depending on the scenario.
Digital Foundry: Yeah I heard about that, I'm just interested in the final figure. I guess I'll need to measure the final console at the wall when I get one! Just a final question. It's more of a personal question really. You've been working on Xbox hardware for many years, you've been working on Xbox One for many years. We saw last week the production run kicking off. How does that feel to see the culmination of your work?
Nick Baker: Yeah, getting something out is always, always a great feeling [but] my team works on multiple programs in parallel - we're constantly busy working on the architecture team.
Andrew Goossen: For me, the biggest reward is to go and play the games and see that they look great and that yeah, this is why we did all that hard work. As a graphics guy it's so rewarding to see those pixels up on the screen.
Espero que os valga.
ESTO:Sigue siendo cierto por mucho Balance y paños frios que le quieran poner.
PS4's GPU: 800Mhz; 18CUs; 1152SPs; 72TMUs; 32ROPs;
Xbone's GPU: 853Mhz; 12CUs; 768SPs; 48TMUs; 16ROPs;
Xbox One...............................................................PS4:
CPU 1,75 Ghz (+9%) ..........................................CPU 1,6 Ghz
GPU 12 Compute Units (CUs).............................GPU 18 Compute Units (CUs) (+50%/+56%)
1.31 TFLOPS / 1,18TFLOPS (for GAMES) ...........1.84 TFLOPS (+40%)
40.9 GTex/s ........................................................57.6 GTex/s (+40%)
13.6 GPix/s..........................................................25.6 GPix/s (+90%)
68GB/s 8GB DDR3..............................................176GB/s 8GB GDDR5(+160%)
109GB/s eSRAM .................................................. ,, (+61% vs eSRAM)
4/16 ACE/GPGPU Lines...............................................8/64 ACE/GPGPU Lines (+300%)
768 Shaders.......................................................1152 Shaders (+50%)
48 Texture units..................................................72 Texture units (+50%)
16 ROPS.............................................................32 ROPS (+100%)
Lo único es que todos esos datos de XBOX One, ahora están confirmados.
Salu2
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
Natsu escribió:Joder jugan, en el colegio no te enseñaron a resumir? xD
Resume un poco anda, que todavía me duele la cabeza del tochaco de DF de esta mañana como para leerme la versión extendida con comentarios del director
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
The goal was to run 512 simultaneous voices for game audio as well as being able to do speech pre-processing for Kinect.
The audio block was completely unique. That was designed by us in-house. It's based on four tensilica DSP cores and several programmable processing engines. We break it up as one core running control, two cores running a lot of vector code for speech and one for general purpose DSP. We couple with that sample rate conversion, filtering, mixing, equalisation, dynamic range compensation then also the XMA audio block.
Yes everything we showed at E3 and Gamescom was on kits. From my point of view the development is coming along well and with the optimizations we have put in, I am pretty confident the final game will look better than what we showed at E3. I even had to open the cupboard to prove it to some guys from Guerilla who didn’t believe me. At the demo stations our kits were on top of the cupboard directly connected to the screens, so no way we could have done anything else other than run on kits.”
Natsu escribió:Una imágen vale más que mil parabras
xufeitor escribió:Yo después de tantos magnaflops, chips, apus, shapes y demás jerga ininteligible voy a viciarme al Wind Waker, que no se cuantos de esos tiene pero es muy "bonico"
xufeitor escribió:Natsu escribió:Una imágen vale más que mil parabras
Yo después de tantos magnaflops, chips, apus, shapes y demás jerga ininteligible voy a viciarme al Wind Waker, que no se cuantos de esos tiene pero es muy "bonico"
xufeitor escribió:Natsu escribió:Una imágen vale más que mil parabras
Yo después de tantos magnaflops, chips, apus, shapes y demás jerga ininteligible voy a viciarme al Wind Waker, que no se cuantos de esos tiene pero es muy "bonico"
Natsu escribió:xufeitor escribió:Natsu escribió:Una imágen vale más que mil parabras
Yo después de tantos magnaflops, chips, apus, shapes y demás jerga ininteligible voy a viciarme al Wind Waker, que no se cuantos de esos tiene pero es muy "bonico"
Yo ayer me pasé el Beyond 2 souls, eso sí que es bonico
Ahora no sé a que jugar, creo que retomaré el fahrenheit o el Heavy Rain xD
FanDeNintendo escribió:xufeitor escribió:Yo después de tantos magnaflops, chips, apus, shapes y demás jerga ininteligible voy a viciarme al Wind Waker, que no se cuantos de esos tiene pero es muy "bonico"
Sí, pero al final esto es lo que contará de verdad, los juegos y cómo nos lo pasemos. Las mierdas técnicas como las que se dicen en esta entrevista/librodetomclancy/biblia/panfleto/ sólo sirven para rompernos los ojos, disputas absurdas y medidas de pollas
Natsu escribió:Yo ayer me pasé el Beyond 2 souls, eso sí que es bonico
Ahora no sé a que jugar, creo que retomaré el fahrenheit o el Heavy Rain xD
![[mad]](/images/smilies/nuevos/miedo.gif "loco")
). ![[360º]](/images/smilies/nuevos/vueltas.gif "como la niña del exorcista")
Rai_Seiyuu escribió:
Si os molan los juegos de Quantic Dream. probad el Omikron: The Nomad Soul. Esta tanto para Dreamcast como para PC.
xufeitor escribió:Y en el montón de juegos por acabar aún me quedan unos cuantos. Halo 4, Xenoblade, Dead Space 2 y 3, Farcry 3, Remember Me.... y alguno más.
No me da tiempo a acabarlo antes de que salgan las consolas
NeCLaRT escribió:Se puede decir que EG/DF son de MS? Lo digo porque aqui la liaron parda cuando a alguno se le ocurrio observar que EDGE se habia posicionado a favor de Sony de manera clara en esta concreta batalla, y ahora parece lo mas normal del mundo por muchisimo menos.
Xbox One:
Digital Foundry: the complete Xbox One architects interview - The whole story.
Microsoft to unlock more GPU power for Xbox One developers - Kinect and app reservations will be accessible to game-makers.
Digital Foundry vs. the Xbox One architects - "There's a lot of misinformation out there and a lot of people who don't get it. We're actually extremely proud of our design."
Xbox One exclusive Ryse runs at 900p - Full HD off the table for Crytek's showcase. Digital Foundry assesses the news
Xbox One CPU speed increased by 9.375 per cent - 1.6GHz processor bumped up to 1.75GHz in production hardware.
Beyond live TV - what the Xbox One user interface means for gamers - Digital Foundry on the next-gen dash, voice control... and Kinect.
Digital Foundry vs. Respawn: the Titanfall interview - Xbox One, the cloud, the Source Engine - and the 1080p60 question
Xbox One graphics speed increased by 6.62 per cent - GPU receives post-E3 53MHz speed boost.
PS4:
Digital Foundry vs. Resogun - Head-to-head with Housemarque, plus exclusive PlayStation 4 60fps gameplay video.
Mark Cerny: lead architect of... PlayStation Vita? - PS4 design chief also responsible for Sony's handheld.
Llama a Steven spielberg porque tu imaginación es digna de pelicula taquillera.
EDGE= Miento mas, que escribo.
REYSHARK escribió:Llama a Steven spielberg porque tu imaginación es digna de pelicula taquillera.
EDGE= Miento mas, que escribo.
juan19 escribió:NeCLaRT escribió:Se puede decir que EG/DF son de MS? Lo digo porque aqui la liaron parda cuando a alguno se le ocurrio observar que EDGE se habia posicionado a favor de Sony de manera clara en esta concreta batalla, y ahora parece lo mas normal del mundo por muchisimo menos.
lo digo en coña eso del medio oficial de micro , pero sinceramente es raro que de ps4 apenas hablen , en cambio de micro hay noticias dia si y dia tambien.
estas son las noticias que ha publicado DF desde agosto , que casualmente , el chorreo de noticias de micro comienzan el mes que se comenzaba ha hablabar de las bajas reservas de ONE en comparacion con ps4.Xbox One:
Digital Foundry: the complete Xbox One architects interview - The whole story.
Microsoft to unlock more GPU power for Xbox One developers - Kinect and app reservations will be accessible to game-makers.
Digital Foundry vs. the Xbox One architects - "There's a lot of misinformation out there and a lot of people who don't get it. We're actually extremely proud of our design."
Xbox One exclusive Ryse runs at 900p - Full HD off the table for Crytek's showcase. Digital Foundry assesses the news
Xbox One CPU speed increased by 9.375 per cent - 1.6GHz processor bumped up to 1.75GHz in production hardware.
Beyond live TV - what the Xbox One user interface means for gamers - Digital Foundry on the next-gen dash, voice control... and Kinect.
Digital Foundry vs. Respawn: the Titanfall interview - Xbox One, the cloud, the Source Engine - and the 1080p60 question
Xbox One graphics speed increased by 6.62 per cent - GPU receives post-E3 53MHz speed boost.
PS4:
Digital Foundry vs. Resogun - Head-to-head with Housemarque, plus exclusive PlayStation 4 60fps gameplay video.
Mark Cerny: lead architect of... PlayStation Vita? - PS4 design chief also responsible for Sony's handheld.
en esta vida se mal pensado y casi siempre acertarasLlama a Steven spielberg porque tu imaginación es digna de pelicula taquillera.
EDGE= Miento mas, que escribo.
pues EDGE se podria decir que es el new york times del mundo de las consolas
si ese comentario lo haces por que se han posicionado a favor de ps4 , deberias saber que no es la primera vez que se posicionan a favor de una consola , y mas que posicionarse , lo que hacen es dar su opinion.
deberias revisar las portadas de EDGE , te llevarias mas de una sorpresa
.........................................
Nuevo Gameplay de Killzone.
http://www.youtube.com/watch?feature=pl ... 0dCX5AvBc8
........................................
Battlefield 4 , PS3 vs PC gama media.
http://www.youtube.com/watch?feature=pl ... 7nLBM#t=44
Pero es que ha habido más noticias de ONE que de PS4, no hay mucho que rascar ahí. Sony no suelta prenda de casi nada, y porque les pillaron que los 7Gb para juegos era falso, sino aún estábamos con esa idea.
Si hasta SonyGaf habla más de ONE que de PS4.
tiene que ser chungo vivir con esa mania persecutoria juan19 escribió:Pero es que ha habido más noticias de ONE que de PS4, no hay mucho que rascar ahí. Sony no suelta prenda de casi nada, y porque les pillaron que los 7Gb para juegos era falso, sino aún estábamos con esa idea.
Si hasta SonyGaf habla más de ONE que de PS4.
GAF tambien es sonyer?
para vosotros todo el mundo es sonyer
te recuerdo que salio la noticia que ps4 era hUMA y DF no dijo ni pio , y en mi opinion es algo importante.
Nuhar escribió:juan19 escribió:Pero es que ha habido más noticias de ONE que de PS4, no hay mucho que rascar ahí. Sony no suelta prenda de casi nada, y porque les pillaron que los 7Gb para juegos era falso, sino aún estábamos con esa idea.
Si hasta SonyGaf habla más de ONE que de PS4.
GAF tambien es sonyer?
para vosotros todo el mundo es sonyer
te recuerdo que salio la noticia que ps4 era hUMA y DF no dijo ni pio , y en mi opinion es algo importante.
Y al reves tambien pasa, cualquiera que diga o escriba algo bueno de xbox one esta comprado, incluso los multis...
Asi que dejemos el tema, me quedo con la opinion de gynion que sufre un poco el efecto natsu de doble personalidad jajajaja, yo me quedo con los juegos no con los papeles.
