In the article, two key technical personnel behind the Xbox One project, Andrew Goosen andNick Baker, discuss with the site different aspects of the console internals, like the ESRAMand GPU.
According to them:
“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,” says Microsoft technical fellow Andrew Goosen.
“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 [GPU compute power]. There are 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.”
“Andrew said it pretty well: we really wanted to build a high performance, power-efficient box,” adds hardware architecture team manager Nick Baker. “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.”
Here are some more interesting quotes:
“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,” he says. “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.”
“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.”
Regarding the balanced approach to the GPU:
“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.”
Regarding GPGPU and Asynchronous Compute:
“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.”
Microsoft’s approach to asynchronous GPU compute is somewhat different to Sony’s – something we’ll track back on at a later date.
Official Source: http://www.neogaf.com/forum/showthread.php?t=683665