Show Us Your Bits



Episode 2: Attack of the 16-bit GPUs

Last episode

Last episode we discussed the meaning of "bit", as in "The TurboGrafx-16 is really an 8-bit system". Specifically, I explained what 8-bit vs. 16-bit means with respect to CPUs, and the pros and cons of each. We saw that, in fact, for the TurboGrafX, being 8-bit isn't as big a disadvantage as the pundits would have it.

This week, we move on to graphics. I'll make liberal use of the term GPU, meaning Graphics Processing Unit. This is a term first popularized by NVIDIA, referring to a single-chip 3D graphics accelerator. I'll apply it retroactively to any dedicated graphics accelerator, chip or chipset, such as the spiffy sprite pushing gear in the TurboGrafX. 

Directly to the point

The point of this article is to examine the use of "n-bit" (eg 16-bit) as a measure of GPU prowess. In particular, I will explain the two important meanings of "n-bit" with respect to graphics hardware. Then, I will show where the TurboGrafX-16, its competitors, and modern console GPUs (mmm... toruses) rate on these scales.

The two scales are processor word size, like we used for CPUs, and colour depth. I (with my heavy graphics bias) prefer to base my measure of GPU generation first on colours, then on hardware architecture. Regardless, neither tells the complete story, so looking at both just makes sense. 

Processor bits

The first meaning of "n-bit" is related to the measure of "n-bit" I discussed last episode in the context of CPUs. Last time, I defined an 8-bit CPU as being one with "instruction opcodes" that are eight bits wide and which processes data eight bits at a time. A GPU, on the other hand, doesn't have the fetch-execute cycle of a CPU. Instead, a GPU is accessed by the CPU in the same way as a software library: via function calls. These function calls are initiated by the CPU loading data into registers on the GPU. In this way, a GPU only executes when explicitly called upon, rather than continously, like a CPU. As with opcodes for CPUs, the size of a register corresponds to a processor's word size. Thus a 16-bit GPU will have 16-bit registers and process data 16 bits at a time. 

Pipelines

Or not. GPUs often have multiple pipelines that execute in parallel. So do modern (well post-Hu6280) CPUs, but in CPUs the parallelism is currently hidden from the programmer. GPU programmers must explicitly activate the multiple pipelines if they need them. So, then, this definition of bit width is only a first-cut measurement. However, it is a reasonable measure of graphics processor "generation", so I will run with it. 

Colours

Colours are what we perceive as the output of a GPU. Each generation of video game console so far has produced more colours (simultaneously on the screen) than the previous generation. Therefore, I consider colour depth to be the other significant measure of power.

So how many bits of colour in a given GPU? The simplest measure is the log2 (base 2) of the max number of onscreen colours. (You can compute this as log(colours) / log(2)). For example, the NES could produce 16 simultaneous colours for a bit-width of 4. 

What about palette size?

A key feature of the so called 8- and 16-bit generations of consoles was colour palettes. A palette is a table of colours, each with an index. The size, in bits, of each index is the number of bits of colour, as discussed above. The size of the palette is 2 to the index size, so an 8-bit palette holds 28, which is 256 colours. The actual colours referred to by the palette are arbitrary, and can be changed easily. This provides for a number of nice tricks, about which I know little. One example is that a given sprite can be recoloured from, say, a green scheme to a purple scheme just by changing the palette, without changing the sprite data or program code. Moreover, the palette need not be constant from frame to frame or necessarily even within a frame, allowing the machine to display more colours than it's raw bit-width would suggest. However, the TurboGrafX apparently didn't use palettes in this way. Okay I've never coded for such a system, so it seems awfully confusing to me.

TurboGrafX-16 GPU

The TG16 isn't so simple: the stats say 482 onscreen, but really it has two independent pipelines with 256 colours each. One is for sprites, the other for the background. Some colours are duplicates, hence the 482 (rather than 512). Anyway, the TG16 has two log2(256) = 8 bit colour pipelines. It so happens that these are processed in parallel (because its a 16-bit GPU), and that's why it's so fast. Effectively, the TurboGrafX has a 16-bit GPU producing 8-bit colour. 

The competition

Let's look at some other systems: the Genesis could produce 61 colours, presumably 64 minus transparency and whatnot, so log2(64) = 6 bits. This corresponds to 6 bit colour, out of a 512-colour (9-bit) palette. Halfway between NES and the venerable TG16. 

The SNES, with its 256 onscreen colours, is, like the TurboGrafX, producing 8-bit colour, but with a much larger, 15-bit, palette. This means that games can use entirely different colour schemes from one level to the next, or even one frame to the next. The TurboGrafX, by contrast, is apparently limited to a fixed set of 512 (or is that 256?) colours.

Presumably, since their GPUs are both 16-bit chips, the Genesis and SNES are dual-pipelined, like the TurboGrafX. 

The Neo Geo could display 4096 colours. Oh baby. That's 12 bits of colour, out of a 16-bit palette. 

What is 16-bit colour?

16-bit colour about is 216 = 65,536: thousands of colours. So many colours that palettes become unnecessary; colours can be accessed directly. Much nicer on the programmer, in my opinion, although cool palette tricks are lost.

Typically, 16-bit colour for games means 5 bits for each of Red, Green, and Blue, with 1 bit reserved for transparency (a pixel would thus be either opaque or transparent). This means 215 = 32,768 distinct colours. 

24-bit colour

24-bit colour typically means eight bits for each of Red, Green, and Blue (RGB colour). 24 bits means a total of 16,777,216: millions of colours. That is considered to be more colours than the human eye can see, so its not surprising that the entire next generation used 24-bit colour.

These next-gen consoles, however, varied widely in the graphics hardware they used. The Jaguar, for example, had a 32-bit Graphics Processor and supposedly 64-bit Object and Blitter coprocessors, and 3D effects including a Z buffer and Gouraud shading. So is it really a 32-bit system, 64-bit, or does its Genesis-equivalent 68000 CPU make it 16-bit? Beats me. 

The 3DO, another smashing success, used a straight 32-bit RISC graphics processor, coupled with a 32-bit ARM CPU. That makes it, in my mind, a "true" 32-bit system (despite the "mere" 24-bit colour). 

The Japanese PC-FX, supposedly (and by its specs) the bomb, also featured 24-bit graphics, coupled with a decent 32-bit CPU. That its effects include fade implies greater than 24 bit internal colour computation.

Sega's Saturn had two graphics processors, one for geometry and sprites, and one for backgrounds. Looks spiffy. Todo: bit width. Playstation: one graphics chip, apparently. In the same league as the Saturn, which probably means the Saturn lacked texture filtering, too. 

Nintendo 64, sort of half a generation late again, features a 32-bit GPU producing 21-bit colour. This is because it used SGI hardware, see, and SGI engineers get woodies from being "clever". Incidentally, the Nintendo 64's so-called "64-bit" MIPS R4300i only processes thirty-two bits at a time, and has a 32-bit instruction set. Its only claim to 64-bitness is its 64-bit address space, which is completely irrelevant since the N64 only has a max of 8 MB RAM, entirely accessible with 23 bits. So really, it's the "N crock". 

Where are we at now?

Modern GPUs all produce 32-bit RGBA colour. That means 8 bits for each of Red, Green, Blue, and Alpha (transparency). So, really, that's twenty-four bits of colour, as with the previous generation. "Modern GPUs" so defined include Dreamcast, PlayStation 2, GameCube, and that evil one from that evil company that produces the evil operating system I'm writing this on and wrote the evil library for which this text editor is a demo.

Due to pipelining and whatnot, it is not clear how many bits a modern GPU crunches per clock. It isn't even constant. I was all about to guess, but I'd probably get one wrong and offend someone to death. Assuming anyone reads these columns. Nowadays, more bits just means more "free" textures; geometry processing is always 32-bit. 

Ultimately

The ultimate game system would run at a frame rate just beyond the maximum frame rate perceiveable by the human eye, and produce all the colours the human eye can distinguish. Supposedly, the human eye can distinguish about fourteen million colours, so twenty-four bits is enough. Hence the fact that last three or so generations of PC GPUs have produced 24-bit colour. 

Enough is never enough

However, the sixteen million colours produced by 24-bit RGB do not include all fourteen million colours the human eye can perceive. This is due to the inherent difference between RGB colour and the way our eyes' "wetware" responds to colour. RGB means three stimuli, where the meaning of each channel is, respectively, the amount of red, amount of green, and amount of blue, in an additive colour system. Each stimulus (or component) can take on values in the range 0-255 (for 24-bit colour). 

Biology is the bomb

Our retinas, however, are actually a four-stimuli system, with 3 kinds of cells (cones) responding to colour (technically hue), and one kind of cell (rods) responding to brightness (technically, luminance). Furthermore, cells can respond both positively and negatively. 

For you bio freaks, this is because rods and cones are neurons, which fire electrical impulses at a fixed, low rate when unstimulated. In the eye, stimulation increases their firing rate, and decreases are caused by inhibition from neighbouring cells. For example, if some red-sensing cones are seeing a lot of red, they'll fire rapidly, while simultaneously suppressing nearby cones that are tuned to sensing green. Very complicated, indeed. 

The truth is out there

With this in mind, some smart French dudes came up with the CIE colour system, which is, like RGB, a tri-stimulus system, with the components named (arbitrarily) X, Y, and Z. Y encodes both luminance (brightness) and an aspect of hue. X and Z just encode hue components. Each of X, Y, and Z has a different range of possible values, to account for the eye's nonuniform sensitivity. Furthermore, negative values are allowed, to account for inhibition. This theoretically allows 24 bits to actually represent the entire range (technically gamut) of colours the human eye can perceive. 

"In theory" = "Not really"

So the problem is solved for software. However, it apparently isn't so easy to produce hardware that can display CIE colour. CRTs, hopefully soon to be obsolete, use Red, Green, and Blue phosphours, all of which are equally responsive. LCDs similarly use R, G, and B LEDs (Light-Emitting Diodes). To display CIE colour, screens would need chemically different phosphours or LEDs, which might be hard to produce. Moreover, they'd have to respond nonuniformly. This itself is a huge change, which would likely make screens more expensive to produce and harder for graphics hardware to communicate with. Screen producers would hate to throw out all of their existing technology just because of a couple of million mismatched colours. Mostly blues, anyway, if I recall correctly, and who really wants more of the blues? 

Think about the future

Therefore, GPUs can throw as many bits as they want at the screen (the most, currently, is 48 bits, in SGI's Octane2 and Fuel), but they won't increase the number of colours we can actually see. Hence, I expect that 32-bit colour will remain the norm for quite a few years. Unless, of course, Marketing catches on to colour-bits as a measure of GPU power. If this happens, expect to see 48- and 64-bit colour that, for some strange reason, looks shockingly like 24-bit colour. 


Authored by Robodork
(c) 2002 Turbo2k
Columns

Last week:
Episode 1: The Phantom 16-bit CPU