Here's a peculiar aspect of Xenon. While the chip, by itself, incorporates interesting technology to make it a powerful contender against the competition, Xenon was never conceived as a one-man band. To make this console, as a whole, extremely competitive and long-lasting, Xenon was closely bonded to another chip, the GPU.
Assassin's Creed (2007).
Half-life 2 (The Orange Box, 2007).
Portal 2 (2011).
Borderlands 2 (2012).
Grand Theft Auto V (2013).
The graphics chip is designed and manufactured by none other than ATI, Nvidia's direct rival. To put it into perspective, a new company called 'ArtX' was set up by former SGI employees who developed the Nintendo 64's graphics chip, the Reality Co-Processor. Afterwards, Nintendo hired them again to produce the GameCube's Flipper chip... at the same time ATI was in the process of acquiring them . By then, ATI was competing in the PC arena with their 'ATI Rage' graphics cards and will soon inherit Flipper's engineers. Fast forward to 2005, Nvidia (now supplying Sony) was now facing ATI again in the console market.
Good old competition, one can only wonder what new innovative product will come out of it.
Overview
Since the early naughties, Nvidia and ATI have been trying to outmatch one another in terms of performance, often by adding incremental improvements to their flagship brands.
The Xenos + EDRAM package next to GDDR3 chips.
Nvidia enjoyed considerable leverage after the introduction of programmable pixel pipeline which later became part of the OpenGL and Direct3D specification. Thus, ATI had no other choice but to follow suit. However, in 2003, ATI recovered its user base after Nvidia's anticipated 'GeForce 5' line disappointed Direct3D 9 users, who were expecting better performance and functionality from Nvidia's flagship card . As a result, attention shifted towards ATI's Radeon 9000 series.
These events allowed ATI to keep the crown for a while longer, but unbeknownst to Nvidia, ATI had been working on a new disrupting ingredient that could hold Nvidia for another decade. This project eventually materialised in the form of Unified Shaders and debuted in none other than the Xbox 360, with the new graphics chip called Xenos.
A new foundation on the way
You'd be surprised that Microsoft's push for homogeneous computing also dragged the GPU into this mix.
You see, there was a time when GPUs were mere rasterisers with 'take it or leave it' functionality, meaning they provided a fixed set of functions and programmers could either activate them or not. Later on, thanks to SGI's innovations, workloads were offloaded from the CPU thanks to the new programmable vertex pipelines. Finally, the 'mere rasteriser' definition was rendered obsolete (pun intended) as Nvidia promoted a new stage called programmable pixel shader which gave programmers the liberty to control what happens after rasterisation.
Overview of the units that compose a GPU with programmable shaders. In this example, our GPU provides more units for vertex operations than pixel operations, meaning geometry transformations will be quick at the expense of colour effects, for instance.
This pattern shows us that, as GPUs grow in performance and functionality, they eventually open up to allow developers to implement the exact functionality they seek. However, this also increases the overall complexity of the silicon.
Over the years, both vertex and pixel pipelines kept enlarging to accommodate current needs, with new scalability problems emerging. Space, costs and heat emissions have a limit. So, which tasks should be prioritised? Vertex operations or pixel effects? A weak vertex pipeline will stall the pixel pipeline. Alternatively, a disappointing pixel unit won't attract users with its dully-composed frames.
Overview of the units that compose a GPU with a new unified pipeline. Now that both stages are now provided with the same amount of resources, developers won't have to trim down operations executed by a weak shader units.
Thus, architects at ATI took two steps back and asked themselves 'Is there any way to simplify this model instead of adding more transistors on top of it?' which later became 'Why are pixel and vertex pipelines segregated?'. And so, the two stages were ultimately merged into a single -unified- block of circuitry. This is what we call the Unified shader model and a GPU implementing it still provides both programmable vertex and pixel pipelines, but the circuitry used for computations is shared.
The new model has two primary benefits: a more balanced scaling (as it will now improve both pixel and vertex pipelines to the same degree), and programmers can now develop shader programs that are not constrained by the limitations of an individual pipeline type. Though the latter will require major changes in the API to standardise its behaviour and availability, which won't arrive until 2006 with DirectX 10 or in 2010 with OpenGL 3.3.
Suffice to say that the unifier shader model is now another standard in the graphics industry.
Architecture of Xenos
To construct Xenos, ATI borrowed material already present in their consumer products. Though it's hard to say which existing card they based Xenos on. Wikipedia pairs it with the 'R520' core (found in the Radeon x1800) , though I find it hard to believe as the R520 contains fundamental differences (related to the new unified architecture) that make me doubt about such relation. In the absence of any reliable source, I turned to the Xenia emulator Discord where I luckily received a lot of input from the community, especially TriΔng3l, who works in emulating Xenos.
In essence, Xenos is based on R400 (also known as 'Crayola'), a new architecture from the ground up that never materialised in the form of a consumer card (except Xenos, being the only incarnation to this day). Instead, ATI shipped R500-based cards to PC users, which are a continuation of the R300 architecture. Curiously enough, some R520 cards incorporated part of Crayola's technology, but were marketed as 'ATI Avivo' and only used for accelerating video decoding.
In the end, ATI brought the unified shader model to the masses through their new R600 architecture (an evolution of R400), also known as 'TeraScale', released in 2007 with the Radeon HD 2000. And the rest is history.
Interestingly enough, the R400 branch carried on in the smartphone world with the ATI Imageon Z430 , later called Qualcomm Adreno 200, which also went through many iterations. This is another example of innovative technology that finds its way into the mobile market!
Organising the content
Another unusual element from Xenos is its triple memory architecture (so much for emphasising the UMA...). Xenos relies on two different chips to render graphics, one is the aforementioned 512 MB of GDDR3 DRAM (which is shared with the CPU) and the other is a smaller but way faster memory chip residing within the same package (which only Xenos has access to). The latter piece provides 10 MB of Embedded Dynamic RAM (EDRAM) . Curiously enough, EDRAM is not a new ingredient, having been found in the Graphics Synthesiser, the Graphics Engine and, most importantly, Flipper (also ATI's invention).
Those 512 MB store most - if not all - the materials Xenos needs to render a frame, including textures, shaders and many types of buffers as the game sees fit. On the other side, the 10 MB of EDRAM are left for small elements that require rapid access, such as the Z-buffer, the stencil buffer, the back buffer (intermediate frame buffer) and any other custom buffer if needed. This mitigates congestion from the shared GDDR3 RAM and speeds up operations that make use of those buffers.
Example of how data is organised across the memory available.
As if this wasn't enough, there's a third source that can feed the GPU, and that is a direct line to the CPU! Unlike anything seen before, the CPU can stream commands and geometry without going through the traditional steps of storing command buffers in external memory, thereby saving once again traffic from main RAM. This is what Microsoft advertised as Xbox Procedural Synthesis (XPS) and made possible by two changes :
- Firstly, the CPU's front-side bus was adapted so the GPU can directly fetch data from the CPU's L2 cache (where the CPU may procedurally generate the geometry) in blocks of 128 Bytes (the size of a cache line).
- Secondly, a separate cached location was added into Xenon so the GPU can notify its current state to the CPU as fast as possible. Microsoft calls it the Tail pointer write-back and keeps both components in sync while the CPU updates the L2 cache and the GPU pulls from it. According to Microsoft, this routine provides a theoretical bandwidth of 18 GB/sec .
Overall, this synergy is what has enabled the Xbox 360 to achieve such a high level of performance without requiring overpriced hardware.
Constructing the frame
Having said all that, how does Xenon actually render a frame? Well, similarly to other GPUs in the market, there are many steps involved. Take a look at this diagram of Xenos' pipeline.
Overview of the graphics pipeline in Xenos.
As you can see, the pipeline stages are not different at all compared to other graphics chips that don't employ the unified shader model. This is because the actual change happens at the circuitry level and not at the API level (for now). This way, developers are not forced to learn new techniques that will disrupt their traditional methods, but they'll soon find that the new underlying design will benefit them in terms of performance and extra functionality (on top of the 'traditional' one).
Conversely, this GPU is strongly aligned to a proprietary API developed by Microsoft called Direct3D 9. This API has enjoyed increasing adoption in the PC market due to its wide compatibility rate with off-the-shelf graphics cards, making the job of game developers a bit more enjoyable. And even though Xenos will also expose some behaviour not seen in the off-the-shelf market, Direct3D is the only high-level API that Microsoft provided to talk to Xenos. So, what we find in the Xbox 360 is a semi-customised version of Direct3D 9 that makes room for the extra functions of Xenos. Curiously enough, Direct3D influenced the design of Xenos in the same way Xenos influenced future revisions of Direct3D (starting with version 10).
Now it's time to make a full dive and see how this pipeline works, just like we did in the other articles.
Commands
Overview of the command stage.
Welcome to the tour of the 12th polygon factory of this series. As always, the starting point is the command stage. Commands tell the GPU what, where and how to draw something on the screen. This time, however, commands may be stored in Main Memory (within a buffer) or directly streamed by the CPU. Both are subsequently fetched by the Command Processor , which parses it and forwards it to the respective unit that performs the required operations (as commands may encode different types of instructions, such as 'draw a triangle' or 'set X register').
It's worth mentioning that by this generation, the traditional practice of using Display Lists for composing commands has been long superseded by a new structure called Command Buffer (as OpenGL and Direct3D call it). While both terms sound similar, the new entity makes room for new operations that weren't originally envisioned when Display Lists were conceived (primarily related to vertex, pixels and GPU control). As the APIs evolve, Command Buffers are adapted to reflect modern needs, while Display Lists have been deprecated since 2008 (OpenGL removed them with OpenGL 3.2) .
Furthermore, Direct3D 9's command buffers (found in the official SDK of the Xbox 360) provide the option to embed an interesting data format called Index Buffers. This enables developers to reuse existing vertex points to avoid duplicating geometry data in memory .
Finally, this GPU can also conditionally execute commands depending on arbitrary conditions set by the developers. In Direct3D's world, this is called Predication and saves the GPU from processing geometry that may be occluded, for instance.
Vertex Shader
Overview of the vertex stage. You'll soon find that this stage and the pixel stage are not that different.
Since the times of Flipper (or even the RCP, as it shared its core team members), ATI maintained the initiative of providing a geometry block to accelerate vertex operations. With Xenos, it is now fully programmable using Direct3D's High-Level Shader Language (HLSL), which is similar to C but used for implementing vertex shaders without needing assembly, although the latter is still possible.
Both Xenos and RSX implement the Vertex Shader Model 3.0 (vs_3_0) specification, which outlines a common set of capabilities and limitations. This includes providing 512 or more slots for instructions, branching opcodes and support for texture fetching, among others. The difference, however, is that PlayStation 3 programmers must use Nvidia's CG compiler (once a collaborative work with Microsoft's HLSL) while Xenos developers rely on Microsoft's toolkit instead, and thus use Direct3D's HLSL compiler.
Furthermore, let's not forget that the hardware carrying out those operations relies on a new formula. The new unified design means vertices are processed through a shared but bigger pipeline, which works as follows:
- Based on the received commands, the Vertex grouper reads the memory addresses where vertices are located in main RAM and the Tessellator transforms non-triangular geometry (i.e. quadrangles and parametric curves) into triangles, so the rest of the GPU can process it. The latter can also split triangles into smaller primitives, so bigger detail can be achieved without consuming extra bandwidth. The grouper can read 16 Bytes of data per clock and caches the last 14 vertices processed.
- The Sequencer loads the vertex shader and pulls vertex data using 8 KB of cache.
- Now that all vertex data is ready to be processed, 3 Shader Pipes (groups of 16 ALUs, each) execute the shader program. Each shader pipe receives batches of 64 Bytes. Vector-to-vector arithmetic takes four cycles while vector-to-scalar operations take only one.
- The Shader Export buffers the results and sends them back to the start of the line where Primitive Assembler picks them up for rasterisation. Alternatively, the shader export can forward the results to the Backend Central, where they are exported to main RAM.
- The latter capability means a shader can write raw data into main RAM, remember this when we reach the 'Anti-piracy' section...
Rasterisation
Overview of the rasteriser stage.
Once the primitives have been transformed or subdivided as requested, the rasteriser begins the transformation to pixels.
Firstly, the Primitive Assembler receives vertex data from the Tessellator and/or Shader Export and begins building triangles out of vertices. This operation takes one cycle, except when vertices require clipping and culling applied (to discard unseen triangles outside the bounding area).
Secondly, the Scan converter receives triangles and packs them into 8x8 pixel blocks called tiles (yes, the same word appropriated by 2D consoles...). The converter generates one tile per cycle and sends them to a dedicated unit that performs early Z and Stencil test. So far so good? Well, here's the interesting part: the latter unit implements a new and efficient rejection technique called Hierarchical Z (Hi-Z).
Instead of testing each pixel of the triangle, Hi-Z evaluates groups of pixels (2x2 pixels in this case) by calculating the maximum and minimum Z-value among the four pixels. Then, if the maximum z-value of the quadrant is less than the respective value stored in memory, the whole portion is assumed to be occluded and the quadrant is discarded .
The Hi-Z block uses dedicated memory for these operations, this memory can store up to 16 different Z-values for Z-testing 64 pixels per cycle. The downside is that available memory only allows Xenos to perform Hi-Z if the framebuffer's resolution is no greater than 1280 x 720 pixels along with MultiSampling Anti-aliasing with up to two samples (2x MSAA) activated.
Finally, the scan converter gets back groups of 2x2 blocks (so 16x16 pixels in total) and sends them in batches of 64 pixels to the next stage, where the pixel shader adds the eye-catching effects.
Pixel Shader
Overview of the pixel shader stage.
To execute the pixel shader, Xenos re-uses the same components of the vertex pipeline with slight detours. Similarly, HLSL's Pixel Shader Model 3.0 (ps_3_0) specification states what developers can accomplish at this stage, which is not significantly different from Sony's counterpart. Nevertheless, since the underlying foundation has been simplified (well, unified), resources have been homogenised, improving the balance of performance across all stages.
That being said, the pixel stage works as follows:
- The Sequencer loads the pixel shader program and forwards pixels to the interpolator.
- The Shader Pipe interpolator interpolates colours between four vertices (creates intermediate values to fill in the gap between two extremes) that will be used by the pixel shader. It can generate 16 colours per cycle.
- 32 KB of Texture cache fetches and decompresses textures from main RAM, then, the Texture pipes send up to 16 texels per cycle to the shader pipes. The texture pipes can instantly apply bilinear filtering, but they also offer trilinear and anisotropic filtering at the cost of extra cycles.
- The 3 previous Shader pipes are now used to execute the pixel shader, each pipe operates vertex made of 16 2x2 pixel blocks coming from the interpolator. The ALUs can process 32-bit floating-point numbers (IEEE 754 compliant) without penalties.
- The Shader Export and Backend Central forward the results to memory. The latter outputs two blocks of 2x2 pixels (8 pixels in total) per cycle. Other kinds of data that can be exported include new Z-values for the Z-buffer and arbitrary data to main RAM.
- The result from the shader export doesn't necessarily have to be the final frame buffer, games with lots of scenery often render multiple buffers (called 'render targets') that are used to derive the final frame. This is called Multiple-pass rendering and Xenos supports outputting up to four Multiple Render Targets (MRT) at the same time .
Pixel Operations
Overview of pixel operations available.
This is as far as it goes for rendering, but one thing we haven't explored yet is how those 10 MB of EDRAM benefit all of this. Well, this chip is very special, because it contains internal logic to perform automatic Multisample Antialiasing (MSAA) along with Depth and Stencil testing. Its internal bandwidth (between its internal logic and internal memory) provides an absurd 256 GB/second, which makes it very attractive for storing intermediate buffers (as opposed to storing them in main RAM).
The only drawback is that 10 MB is not enough for storing large buffers, especially those needed for rendering high-definition frames (1280x720 pixels wide with 2x MSAA enabled), let alone 1920x1080 frames. But fear not, as ATI supports tiled rendering (the same featured in the Dreamcast!). This enables to render portions of the screen, store the results in EDRAM (for performance reasons) and, finally, reconstruct the tiles in main RAM to form the final frame. Tiled rendering became so critical that Microsoft took a step forward and devised Predicated Tiling , a function in Direct3D that automatically sets up and optimises the rendering pipeline specifically for tiled rendering. This prevents developers from manually programming each pipeline stage to handle tiles.
Thanks to the new bandwidth achieved, game designers may push for a level of quality that otherwise would've been unfeasible with a traditional rendering system. This includes applying extended antialiasing methods (4x MSAA) or even High-dynamic-range (HDR) rendering. You see, HDR requires 64-bit pixels, where each channel is encoded as a 16-bit float. This has always been very expensive in terms of bandwidth, but in exchange, it provides the right precision to obtain realistic lighting and colour effects, something the Xbox 360 can now enjoy.
The impact on the industry
The state of the industry after 15 years has demonstrated that the unified shader model was meant to become another building block within GPUs. Interestingly enough, when Direct3D 10 and OpenGL 3.3 debuted in 2006 and 2010, respectively, not only did they standardise this model, but they also defined new features and applications that were now possible to implement. For instance, a new pipeline stage called Geometry shader was added in Direct3D 10 to expand the uses of the tessellator.
On a related note, Xenos also introduced new encoding methods for storing HDR pixels using no more than 32-bit values (thus, saving bandwidth and storage). One of their proposals was to encode the three primary colors using 10-bit floats and leave the remaining two for the alpha channel (transparency) . A year later (2006), Direct3D 10 and a new OpenGL extension took this idea further and implemented the (now standardised) 'packed float' structure, consisting in encoding Red and Green using 11 bits and Blue using 10 bits .
Froggy (2006), Nvidia's latest demo that showcased the capabilities of the unified shaders (incorporated with the GeForce 8 line). For demonstration purposes, the demo also allows to, ehem, slap and stretch the poor ugly frog.
Similarly, over the next years since the console's release, the concepts of Xenos' shader exports would be embraced by many new APIs, namely Apple & Khronos' OpenCL, Nvidia's CUDA, Direct3D 10's DirectCompute and OpenGL 4.3's Compute shaders. All of which provide a platform to access the power of GPUs without necessarily having to render anything, just perform computation using the fast shader pipes. Overall, this was another great leap for General-purpose GPU programming.
Now, if you wonder if any of these advancements were later incorporated into the Xbox 360. I'm afraid by the time this console debuted, the unified shaders were still a relatively new concept. So, unfortunately, none of the consequent developments (i.e. Direct3D 10) were ever back-ported to the Xbox 360. But hey, that's a legacy left for the next generation of consoles to enjoy!
On the other side, the PC market experienced a different revolution that strangely didn't originate from ATI. It turns out Nvidia won the race on becoming the first company to ship a graphics card using the unified model, I'm referring to the GeForce 8 series (and its Tesla architecture) that landed in 2006 . Ironically, it was the same year the PlayStation 3 arrived (also powered by Nvidia's technology, though with an older architecture...).
Video Output
Unlike the PlayStation 3, which arrived a year later, the release of the Xbox 360 in 2005 got caught up in the middle of a transition from analogue video (i.e. RGB and composite) to digital (i.e. HDMI), so the first shipments of the console didn't bundle the famous HDMI connector that quickly displaced the analogue video salad.
Two different revisions of the Xbox 360 stacked together, the top one is a Zephyr and the bottom revision is a Xenon. Notice that the Zephyr model adds the HDMI connector, while Xenon only has the analogue A/V socket.
Instead, the first revision (called Xenon, like the CPU) is only equipped with a multi analogue socket called 'A/V'. This carries all the signals previously featured with the original Xbox, with the addition of VGA-compliant pins (its predecessor had the wires in place but, for some reason, were never powered ).
Later on, in 2006, the follow-up motherboard revision called Zephyr ultimately added an HDMI socket to catch up with Sony's quality of signal. Internally, the original video encoder (known as the ANA chip) had been replaced with the 'HDMI ANA' (or HANA) block .
As outdated as this may seem today, Microsoft still required developers to consider their games being played on CRT screens, which are prone to overscan. Thus, games couldn't place any important indicators within the Danger Zone.
Short-lived features
Following the requirements of the Video Electronics Standards Association (VESA), Microsoft released a software update in November 2008 to support 16:10 aspect ratios, although only available through the VGA signals. Games were still only required to support 16:9 and 4:3 ratios, so using 16:10 would show a black backdrop (a.k.a. letterbox). Curiously enough, the operating system contains routines to allow games to detect whenever 16:10 is activated, though they were never made public.
Additionally, Microsoft shipped a software update in May 2011 to add support for 3D TVs, much like the PlayStation 3 did.
New attitudes towards resolutions
Even though the video encoder can broadcast signals in a multitude of formats, including PAL, NTSC, 720p and 1080p, Microsoft pushed publishers to focus on 720p for two reasons:
- The general consensus from 2005 predicted that most consumer TVs will soon be equipped with high-resolution and widescreen screens.
- Since it would take time to master Xenos' capabilities, launch titles were assumed to not use all of the GPU resources. Thus, games painlessly added HD support to compensate.
With the same rationale, why is 1080p not the focus instead? Well, 1080p puts a significantly higher workload on Xenos, which limits effects like anti-aliasing. Instead, Microsoft suggested developers to render at 720p and direct the internal video scaler to upscale the frame to 1080p, if required. To assist with this, Microsoft released another software update in October 2006 to enable 1080p output (initially, only 1080i had been available).