Long read: The beauty and drama of video games and their clouds

"It's a little bit hard to work out without knowing the altitude of that dragon..."

If you click on a link and make a purchase we may receive a small commission. Read our editorial policy.

Spec analysis: Durango vs. Orbis

Digital Foundry on what the recent leaks mean and how the next-gen Xbox and PlayStation compare.

The next console war has yet to begin but the battle lines have already been drawn and the processing firepower available to Microsoft and Sony is now a known quantity. It's Durango vs. Orbis, and it's a console head-to-head quite unlike anything we've seen before. The raw technological building blocks powering each next-gen console are designed by the same people, and the raw architecture is almost identical in nature as a consequence. The differences between the two consoles are less pronounced than in any preceding console generation: fundamentally, Sony and Microsoft faced the exact same challenges and went to the same people to find the solution, resulting in very similar end-products. However, there are differences between Durango and Orbis, and they reflect how the platform holders envisage the evolution of the home console.

We won't dwell too much on the known similarities between the two consoles, but we've already mentioned that both the next generation Xbox and its PlayStation competitor feature the same CPU - an eight-core AMD offering running at 1.6GHz and based on its forthcoming low-power, high-performance architecture, Jaguar. From a graphics perspective, AMD is also offering the same tech to both manufacturers: the GCN core, as found in the highly popular Radeon HD 7xxx graphics cards.

Here's where we see our first point of divergence: GPU rendering is all about spreading the computational load across many cores and we find that the new Xbox has 12 of these "Compute Units" (CUs), while Orbis has 18 - a 50 per cent advantage. These numbers have been hotly contested in the last couple of weeks but our Orbis sources confirm the Sony side of the equation, while SuperDAE's leak - in combination with proof of his claims supplied to us behind the scenes - confirms the Durango CU count. The information there is around nine months old, hailing from Durango's beta period - in theory, the hardware could be improved, but practically it's almost impossible for this to actually happen. You can't just slap on some extra hardware without setting back your production schedule significantly by many months.

So does the GPU difference translate into as large an advantage as it sounds? VGleaks' Orbis spec, again derived from platform holder documentation, suggests that four of these CUs are reserved for Compute functions, conceivably bringing the PlayStation's raw advantage down from 50 per cent to just over 16. However, while Compute is often used for elements like physics calculations, there's nothing to stop coders hiving off specific graphics features to this hardware - Just Cause 2, for example, used NVIDIA's own Compute solution, CUDA, for enhanced water effects, while a core element of Battlefield 3 - the deferred shading solution that power its beautiful lighting - is handled via DirectX 11 Compute shader code.

VGLeaks' block diagram of Durango's technological make-up, almost certainly leaked from official Microsoft documentation. It's a complex design indicative of a machine that's about more than gaming - a state of affairs backed up by the presence of an HDMI input.

Durango uses an approach similar to PC, where the developers choose how to allocate GPU resources between rendering and Compute. A potential bottleneck can be seen here, however: rendering and Compute will compete for resources on the 12 Radeon GCN cores on the Microsoft console, while Orbis has dedicated Compute hardware and still commands a rendering advantage in terms of CU count.

Other information has also come to light offering up a further Orbis advantage: the Sony hardware has a surprisingly large 32 ROPs (Render Output units) up against 16 on Durango. ROPs translate pixel and texel values into the final image sent to the display: on a very rough level, the more ROPs you have, the higher the resolution you can address (hardware anti-aliasing capability is also tied into the ROPs). 16 ROPs is sufficient to maintain 1080p, 32 comes across as overkill, but it could be useful for addressing stereoscopic 1080p for instance, or even 4K. However, our sources suggest that Orbis is designed principally for displays with a maximum 1080p resolution.

The 'secret sauce' debate

There's an argument that suggests that comparing Durango and Orbis on these terms is not realistic; that the platform holders have far more control over the design of the silicon than the raw specs suggest; that they can be adapted with manufacturer-specific 'secret sauce' customisations.

The raw teraflop measurements being mooted - 1.23TF for Durango and 1.84TF for Orbis - have been dismissed as meaningless, and to a certain extent that is true. However, check out AMD's specs page for all of its various GCN hardware and you'll find similar metrics based a very easy formula derived from clock speed and CU count. It's not the be-all-and-end-all of processing power of course, but these are accurate measurements used by AMD itself in giving a broad assessment of the raw computational power of the parts it creates. You'll find that the next-gen console parts slot in quite nicely with their PC equivalents - in short, the teraflop metrics aren't much use in isolation but they are effective for comparison purposes in terms of base hardware capabilities.

This is not to suggest that Durango and Orbis don't have custom hardware, however. They do, but even here we see a great deal of commonality between the two systems as engineers posed with the same problems come up with similar solutions: both have dedicated hardware video encoders and decoders (expect both consoles to be capable of recording and sharing gameplay footage with no impact to game performance), and both have custom audio processors and support for hardware de-archiving of LZ-compressed assets (think of this as support for lossless compression like ZIP files).

But here we do see some intriguing enhancements that are Durango-specific. Its 'Data Move Engines' carry out hardware compression as well as decompression (and support for JPEG too - perhaps to handle Kinect camera streams), while there is also support for texture swizzling. However, the main takeaway here is that core elements of the Move Engine functionality are apparently designed to extract the best performance from a RAM set-up that is much more complex (and slower) than its Orbis equivalent. Elsewhere, most of the custom hardware works to ease the CPU burden, not to improve GPU performance, so those hoping for 'secret sauce' to overcome Orbis's theoretical graphics advantages are probably going to be disappointed.

An overview of the Durango graphics core via VGLeaks.com's unique access to Microsoft documentation. We see 12 GCN Compute Units with close access to 32MB of fast embedded RAM, in turn connected to the Data Move Engines.

Indeed, many of the functions assigned to the Move Engines - tiling/untiling of textures, lossless decompression, texture decompression - were often hived off to the SPUs on the PlayStation 3. VGLeaks' quoted bandwidth specs - around 25GB/s, a plausible figure - is also ballpark with SPU performance carrying out the same task. So in essence, you could view elements of this "secret sauce" hardware as something like two or three fixed function SPUs available alongside the eight-core AMD processor. Orbis has its own custom hardware that does many of the same functions, and for the rest, it has the luxury of a fully programmable Compute module that Durango lacks (unless you cut into rendering resources).

The fact that Durango's Data Move Engines are there at all points to another major difference between the two next-gen platforms: memory, and how data is shuttled around the system.

RAM: capacity vs. bandwidth

Durango is a memory monster, shipping with 8GB of RAM up against 'just' 4GB in its Sony competitor. It's an ambitious strategy, made necessary owing to Microsoft's hopes for the new Xbox to be more than just a games machine - the hardware is believed to reserve a significant amount of RAM for media functions, and rumours persist that the console can run dedicated apps and media side-by-side with gameplay.

There's just one problem. Cramming 8GB of the fastest memory into a console box simply isn't logistically possible. A key Xbox 360 advantage over PS3 was a unified pool of 512MB of fast GDDR3 memory. GDDR5 is the latest equivalent, used principally in PC graphics cards, but the problem here is that the modules only come in certain capacities - the largest and most difficult to produce being 512MB. Daisy-chaining 16 of those onto a console motherboard just wouldn't work. Sony has opted for a tighter system - fewer memory modules, but all of them very, very fast. It retains GDDR5 as the single memory pool with all the raw bandwidth advantages that entails, but it is limited to 4GB (there are rumours of 6GB/8GB upgrades but this is highly unlikely to happen).

Microsoft's technique for accommodating 8GB is to fall back on cheaper DDR3 modules - the same type found in current PCs and indeed Wii U. This presents a problem - namely, bandwidth. Think of data as water flowing through a pipe - the wider the pipe, the more water can flow through it at any given point. DDR3 can only process around one third the amount of data as the wider GDDR5, because the "pipe" is that much thinner. Microsoft's solution? To equip Durango with 32MB of fast memory (ESRAM) attached directly to the graphics core, but capable of being accessed from the CPU too. This little cache of memory can run in parallel with the DDR3, and combined bandwidth then rises back up to around 170GB/s - a number close to the throughput of the GDDR5 in Orbis.

Durango's Data Move Engines are designed to shuttle data around a complex system of 8GB of DDR3 and 32MB of ESRAM, while providing CPU back-up for compression and decompression. Those hoping 'secret sauce' upgrades to boost graphics performance probably won't find much joy here.

So what does this mean for game devs in real terms? Well, whichever way Microsoft tries to finesse it, the 32MB of ESRAM is a bit of a sticking plaster solution that is nowhere near as fast or efficient as the single unified pool of RAM available to Orbis. However, while the disadvantages are obvious, this is not to say that the situation is anything like a complete disaster for Durango development. Speaking to game makers, the impression we come away with is that not every feature in a game actually requires ultra-fast memory. Systems will be developed on the DDR3, and if memory throughput becomes an issue, those features will be ported over to the ESRAM where there's enough bandwidth to provide the raw performance if needed.

Also mitigating the difference to a certain extent is the fact that Durango operates under an enhanced version of DirectX 11 - dubbed internally DirectX 11.x. It's highly likely that crucial rendering functions will automatically be optimised by Microsoft for use with the ESRAM.

Direct X 11 vs. LibGCM

All of which brings us on quite nicely to the development environments accompanying the new hardware. It's business as usual for Microsoft, expanding on the existing Visual Studio tools used to create current-gen Xbox 360 titles. The switch from PowerPC to 64-bit x86 processors sees the introduction of a number of new extensions designed to leverage the new hardware, while the customised version of DX9 utilised by 360 gives way to a similarly enhanced DX11.

From what we've heard, it should be a seamless transition for developers (especially those who've worked with DX11 on prior PC projects) and while some appear to be worried that being locked to the Microsoft API will be an issue, the fact is that there are specific DX11 functions available to devs tied into the custom Durango hardware. There's also a level of flexibility in how DirectX is used that is equivalent to the almost legendary concept of "coding to the metal". For example, on Xbox 360, Microsoft allow developers to load shader constant data into the GPU in its native form. Devs point the hardware to the data and it loads it - the challenge is to ensure it's in the right place, in the right format before the GPU gets to it. Strictly speaking, it's still working within the DirectX API, but effectively, developers are writing to the hardware directly.

With regards the next-generation PlayStation, developers are highly unlikely to have the same kind of issues with the toolchain that they had with PS3. Having acquired SN Systems back in 2005, principally to improve the development environment for their consoles, we're told that the quality of the tools has increased exponentially to the point where one highly experienced game-maker we spoke to rates the PlayStation Vita tools as the most impressive he's used.

With Orbis, Sony is using a new variant of the LibGCM library, which has also been utilised in PS3 and Vita. This allows developers to more directly address the hardware, so elements of the AMD graphics hardware in particular can be accessed in a manner where there is no direct correlation in DirectX. You only need to look at games like God of War and Uncharted to see what Sony's approach to exploiting its hardware can produce: these remain state-of-the-art video games to this day, despite utilising graphics hardware directly derived from now-obsolete vintage 2005 Nvidia graphics hardware. Of course, with PS3 in particular, the GPU is only one part of the overall hardware offering, but the fact remains that developers are extracting performance from RSX that could only have been dreamed of when the console was designed.

A very basic overview of how the principal elements of Orbis link together. The core components - CPU and GPU - are an architectural match for Durango, but the memory set-up is simpler and faster and the graphics core is indeed 50 per cent larger.

The next-gen battle-scape takes shape

Back in 2005, Microsoft and Sony revealed their 'next-gen' console designs - Xbox 360 and PlayStation 3. These were ambitious pieces of hardware: they pushed the power consumption envelope to a new high (with some disastrous consequences for reliability), they both co-opted performance PC parts into a console design. Microsoft pushed the boat out in terms of GPU power - the Xenos GPU was a forward-looking design architecturally more advanced than anything else available at the time. Sony gambled with Cell and Blu-ray - a complex CPU design that developers had trouble getting to grips with, and a storage system that few fully exploited - these elements, beyond all the others account for the gulf in performance between the best of the first- and third-party titles.

Some might say that their replacements are products of the era of austerity, where the 'power at any cost' approach of the Xbox 360 and PS3 is replaced by a more sensible approach of re-purposing existing architecture and getting the best from it in a closed-box environment. Therefore, faced with the same essential challenges, it's no real surprise that both Microsoft and Sony have acquired very similar parts from the same vendor, based on existing technology (or in the case of the AMD CPU, a revised, improved version of a currently available processor), and that the more forward-looking approach of the current-gen designs isn't really present in their successors. The main point of differentiation is much narrower in the new hardware - Sony has invested more heavily in visual performance, while Microsoft's gamble is on RAM.

On paper, Orbis looks like the tighter, more powerful, more games-focused design. With Durango, the astonishing lengths to which Microsoft has gone to accommodate 8GB of RAM adds further weight to the hypothesis that its plans for the Xbox hardware extend beyond gaming, that it wants the hardware to form a next-gen media centre. The question is to what extent its non-gaming plans impact on the processing resources available to developers...