12

As is well-documented, the Fifth Generation of game consoles brought 3D accelerated graphics hardware to the home market. The main combatants in this particular console war of the mid-1990s were the Sega Saturn, Nintendo 64, and Sony PlayStation.

It is also pretty well documented how Sega and Nintendo came by their 3D hardware expertise: Sega through their arcade hardware business and Nintendo through their famous partnering with SGI. What I have not seen is much of any documentation on the origins of Sony's 3D hardware in the PS1.

Given that this was all pretty new technology, at least in the realm of affordable bits for consumer devices, it would be surprising if Sony engineered their own unique solution at the 11th hour, and ended up winning this console war to boot!

Is there any known history about when, where, and by whom Sony's original 3D graphics hardware was developed?

  • 3
    Sony apparently licensed technology from SGI for the CPU, but the GPU was primitive enough that it wouldn't surprise me if it was designed in house, much like the Sega Saturn really. The GPU in the Nintendo 64 was significantly more advanced by comparison. – Ross Ridge Dec 31 '17 at 23:51
  • This is interesting: psx.rules.org/gte.txt Unfortunately it doesn't answer the question, unless it is similar to another chip. – wizzwizz4 Jan 1 '18 at 11:45
  • 2
    I agree with @RossRidge — having worked with Nintendo on a CD ROM add-on, Sony invested quite a few years into this, and their GPU is very simple. Given that it discards perspective, the work of filling each polygon scan line is really little beyond the work the SNES does for each line of the display in Mode 7. – Tommy Jan 1 '18 at 16:29
13

I'd be likely to endorse the verdict that Ken Kutaragi designed it alone.

Kutaragi designed the SPC700, the sound processor used in the SNES. Like any other moderately advanced sound processor, it is part DSP — amongst other things, it contains the logic to pitch shift an audio sample, which pretty much means taking a 1d signal of m samples across and using it to produce n output samples. It also has an in-house designed on-board CPU core, albeit that is only of similar complexity to a 6502 (i.e. a generation behind the system's main processor).

So he was involved in DSP design within videogame budgets at least prior to 1990.

The step from being able to stretch or compress one-dimensional data from a source size to a destination size, to being able to stretch or compress two-dimensional data from a source size to a destination size isn't actually all that great. And that's the thing the Playstation spends the overwhelming majority of its time doing: the original machine forgets about perspective when it gets to actually painting polygon pixels, reducing the problem to merely stepping at a constant rate through a 2d source to paint a 1d output (i.e. the current scan line).

A smart engineer like Kutaragi could very easily have made that small step in the four years between working on the Super Nintendo and working on the PlayStation, while simultaneously figuring out edge scanning (which as the Playstation does it is also just a linear 2d calculation with a 1d output) and adding fairly generic multiplication-with-accumulate and divide to handle the maths prior to rasterisation. Especially as they licensed the CPU core this time around.

It's a completely separate line of development with no direct influence over Sony, but for evidence of how easily a good DSP can scale up from audio to video usage, see demos such as Quake for the Atari Falcon. That's a 68030 computer from 1992 with an off-the-shelf Motorola 56000 DSP intended to cement Atari's position in recording studios. More than twenty years after the fact, it's churning out a version of Quake that a decent 486 would be proud of (and with perspective-correct textures – take that, Kutaragi!) because the difference between audio processing and graphics processing at that level of sophistication isn't vast.

EDIT: Additional attempts to evidence the close nexus between Playstation-quality 3d and audio generation:

This is the per-channel update process for non-noise on a SID:

while(in perpetuity) {
    output(sample_function_of(phase))
    phase += pitch
}

Where phase is 24 bit, pitch is 16 bit, and sample_function_of does one of (i) output the top 12 bits (for a sawtooth wave); (ii) output the one-from-top 11 bits XORd with the top bit (for a triangle wave); (iii) output one of two levels by running the top 12 bits through a comparator (for a pulse wave); (iv) do as per the triangle wave but grab the MSB from a different channel (for ring modulation).

When the SID develops into the Ensoniq, that special phase -> wave logic is removed in favour of simple lookup tables, so you're at:

while(in perpetuity) {
    output(sample(phase))
    phase += pitch
}

And you can see exactly the same thing arising separately in various other sources, from the early-to-mid-'80s: the Amiga does this, as does the Konami SCC that went into various MSX cartridges, it's just a natural way to perform audio synthesis, and is something the SNES chip does also.

In Mode 7, discarding the addressing that gets it into a tile map, the SNES does this to source pixels for video output:

while(not finished raster line) {
    output_to_analogue_domain(sample(x, y))
    x += x_step
    y += y_step
}

If it isn't applying Goraud shading, then the Playstation does almost exactly the same thing, but limits it to the length of that triangle's body on a particular line:

while(not finished scan line) {
    output_to_frame_buffer(sample(x, y))
    x += x_step
    y += y_step
}

It's just not very different, and doesn't require a huge leap in expertise.

EDIT2:

Additional on repurposing of an older 1d DSP for 2d texturing, as it cuts to my contention that the difference isn't substantial:

Suppose you have a 64x64 texture. So you decide to adopt 5.11 fixed point addressing, because that's already a whole lot of subpixel precision. Then suppose you recoded the Playstation loop as:

uint32_t position = (y << 16) + x
uint32_t adder = (y_step << 16) + x_step

while(not finished scan line) {
    output_to_frame_buffer(sample(position))
    position += adder
}

With sample being a function that uses only bits 11–15 and 27–31 to look into a 1d blob of memory.

Well, if you could discard carry between bits 15 and 16 then you've got exactly Playstation-quality texturing, you've just decided to express it oddly.

But even if you're stuck using ordinary 32-bit arithmetic then: you've just wrangled 2d interpolation out of a classic 1d 32-bit interpolator. All you've lost through treating it as a 1d problem is an error of 1/2048th of a pixel any time there's carry out of the x component. Which could be every pixel if you're stepping negatively, and otherwise will occur if your texture is tiled. So call that a bit more often than 50% of the time. But is very, very unlikely to be noticeable across the number of pixels you're likely to paint.

Switch to 8.8 fixed point and you can instead do:

uint32_t position = (y << 16) + x
uint32_t adder = (y_step << 16) + x_step

while(not finished scan line) {
    output_to_frame_buffer(sample(position))
    position += adder
    position &= 0x3fff3fff;
}

Now you've got error flowing into y only when you're trying to traverse more than four source pixels for each screen pixel, which you can either hope is unlikely or else ensure is unlikely through MIP mapping.

I'd dare imagine that logic along those lines is behind every low-end machine texturer in existence.

But more to the point: if you had silicon implementing 32-bit 1d interpolation already, then repurposing that for a modest texture size of the era isn't a lot more complicated than removing one of the carry lines from your adder and wiring the output of that to your texture lookup in an appropriate fashion. No need for actual computed shifts or ANDs.

  • Is that really a 56000 being used to generate the video signal?! – Wilson Jan 2 '18 at 15:18
  • 3
    To draw the polygons, yes. It is freely available for real hardware, and that's just a 16Mhz 68030 plus a 32Mhz 56001. The author's travails as development progressed are documented via atari-forum.com/viewtopic.php?t=26775 — it's 48 pages so I won't try to summarise much but he starts thinking that filled polygons might be the result, discusses CPU texturing strategies for a while but by the final post of page 7 has started DSP code for texturing. He ends up with a completely custom DSP/CPU engine producing >7fps versus <0.15fps for id's original code. Astounding for 1992 hardware! – Tommy Jan 2 '18 at 15:47
  • Meta comment: although it's fundamental to my case that the advance from 1d interpolation to 2d interpolation is sufficiently minor that there's no reason to suppose Sony couldn't implement the lot itself from scratch, I am aware that the progressive extensions to my answer are getting ever more nebulously attached to the question. So I promise that's it, in the absence of clarification queries. – Tommy Jan 2 '18 at 20:57
  • 1
    One more quick comment on Falcon Quake 2, for the doubly curious; that port's surprising competence is in part due to: going all fixed point, with camera-local coordinates updated each time the player moves a BSP leaf, and thereby putting all transform, projection and clipping onto the DSP, using Quake's inherent span buffers to produce a zero-overdraw list of necessary pixels to paint via DSP/CPU collusion, using piecemeal quadratic approximation to eliminate perspective division in texturing (1024 quadratics; pick the coefficients by coarse z, work out the answer with full z). – Tommy Jan 9 '18 at 14:59
  • 1
    I don't have a source for this, but I had read an article that said Kutaragi had been experimenting with real-time 3D graphics for years, to the extent that his supervisors at Sony didn't know what to do with his research but allowed him to proceed as long as it didn't interfere with other work. The implication was that he had been thinking about how to improve and solve problems related to 3D graphics for a long time and was able to apply that to the PlayStation. I'd agree he should take full credit for the design, it seems to be a pet project that eventually turned into a real product. – raisin-wrangler Sep 4 '18 at 15:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.