PlayStation
Image: Damien McFerran / Time Extension

When Sony published Polyphony's Gran Turismo in 1997, it wasn't just the amazing handling, realistic physics and wealth of real-world cars that so impressed critics and players alike โ€“ the game looked like it was an entire generation ahead of its PlayStation rivals at the time, boasting (mostly) convincing reflections and a level a visual detail that had never been witnessed before on Sony's 32-bit console.

The Performance Analyser was fundamentally a PS1 devkit with an integrated bus analyzer and a bunch of memory

While this amazing step forward can be at least partially attributed to the advanced age of the console by this point and the fact that developers were becoming more and more adept at extracting the maximum amount of performance from the hardware, a vital tool in making Gran Turismo the game we known and love was the 'Performance Analyser', a bespoke development tool which offered a unique insight into what was going on 'under the hood' (no pun intended) of the console at any given time.

When quizzed by EDGE magazine in October 1997 about how Sony intended to keep pace with the more technically advanced Nintendo 64, Sony Computer Entertainment CEO and 'father of PlayStation' Ken Kutaragi replied: "I am always asking the same question to my engineers! So they have made a new weapon โ€“ we call it the Performance Analyser โ€“ to test software with, to see how much it is exploiting the PlayStation." He goes on to give some examples. "Formula One from Psygnosis is a great-looking game, but according to our Performance Analyser, it is only using 50% of the PlayStation's potential. And this was, until very recently, the most advanced game. Tekken 2 uses only 30% to 40%. But now Tobal 2 uses 90% of its potential."

Gran Turismo
Image: Damien McFerran / Time Extension

Shortly afterwards, Sony Computer Entertainment Europe's Manager of Development Support & Technology Paul Holman spoke to EDGE again, explaining the Performance Analyser in more precise terms โ€“ extolling its "non-obtrusive" nature and explaining that using it could mean the difference between a title running at 30 fps or 60. "It allows you to move up to hi-res as well," Holman adds. "There are a couple of very successful games in Europe which have gone to hi-res directly as a result of using the Performance Analyser and being able to rejig their code." F1 '97, Porsche Challenge and Rapid Racer were cited as a trio of games which had benefitted from the tool, but Gran Turismo โ€“ which launched in Japan just in time for Christmas 1997 โ€“ was arguably the most effective advertisement for the Performance Analsyer's worth.

This meant that by capturing the externally visible signals on the CPU and GPU buses, you could understand almost everything about what the system was doing

That was then, however, and it's important to remember that back in 1997, Sony was very much in the business of hyping up the latent power still residing within its 32-bit console โ€“ especially as Nintendo had it beat in terms of raw processing grunt. What was the Performance Analyser actually like to work with, and was it really the silver bullet when it came to getting the most out of Sony's 32-bit powerhouse? To find out, we spoke with Mike Froggatt, who is currently employed as Xbox Advanced Technology Group manager for Europe, the Middle East and Africa. Prior to joining Microsoft, he worked as Principal Software Engineer at Sony Computer Entertainment Europeโ€™s Cambridge Studio โ€“ and therefore has a unique and intimate knowledge of this groundbreaking piece of kit.

"The Performance Analyser was fundamentally a PS1 devkit with an integrated bus analyzer and a bunch of memory โ€“ 64MB, if I recall, which was a lot in those days โ€“ to hold the data that was collected," he explains. "Unlike the devkits that we use now โ€“ and unlike most, if not all, the console devkits that had preceded it โ€“ most of the iterations of the PS1 devkit were ISA or PCI boards that you could plug into your development PC. On the PS1, there was very little 'hidden state', with the exceptions of the instruction cache and 1KB of fast scratch RAM that was integrated with the CPU. This meant that by capturing the externally visible signals on the CPU and GPU buses, you could understand almost everything about what the system was doing. This was hugely valuable for both debugging and performance optimization."

Ridge Racer Type 4
Gran Turismo and Ridge Racer Type 4 both benefitted massively from the Performance Analyser — Image: Damien McFerran / Time Extension

So, as Sony claimed in the late '90s, the Performance Analyser was a key weapon when investigating where code could be more efficient. "It was invaluable for seeing how much you were utilizing the available hardware resources, particularly the GPU," says Froggatt. "The Performance Analyser had enough memory to allow capturing several framesโ€™ worth of data, and the associated software graphically and intuitively showed you system activity over that period. You could see if the GPU was idle for long periods and analyse draw calls to see if performance could be improved โ€“ often a case of reducing texture resolution or colour depth. CPU activity was also broadly visible and, in particular, you could see whether performance might be data bandwidth-limited, in which case it was time to try fitting the data set into the fast scratch RAM."

It offered zero-overhead profiling of performance, meaning there was no skewing of your data due to instrumenting your code. Thatโ€™s pretty rare, even by todayโ€™s standards

Not only this, but the Performance Analyser also supplied a valuable band-aid to an issue that had been present in the PlayStation hardware since launch, as Froggatt explains. "It was a life-saver for catching one of the most pernicious PS1 title bugs โ€“ 'writing off the end of the ordering table'. The PS1 had no depth buffer, and depth sorting was achieved by โ€“ roughly speaking โ€“ adding GPU draw commands into an array that was traversed from farthest to nearest. Since the array had a fixed size, there was a risk that distant objects would have a Z value, placing them beyond the array bounds. Writing off the end of the ordering table typically resulted in a GPU crash โ€“ if the data then got stomped by something else โ€“ or corruption of CPU data, maybe even instructions, yielding a CPU crash. With the Performance Analyser, if a crash happened, you could go 'back in time' through the data and find if the memory beyond the ordering table got hit. It was also possible to set CPU data access hardware breakpoints to catch the erroneous write as it happened."

There was yet another added benefit with the Performance Analyser, thanks to the fact that it was a separate piece of hardware. "It offered zero-overhead profiling of performance, meaning there was no skewing of your data due to instrumenting your code," says Froggatt. "Thatโ€™s pretty rare, even by todayโ€™s standards."

So, that's how the Performance Analyser worked, but what real-world difference did it make to PlayStation titles developed with it? "It was a huge asset in allowing teams to wring every last cycle of performance out the PS1," Froggatt states. Namco's Ridge Racer Type 4, released in Gran Turismo's wake, was noted as having made use of it in an EDGE magazine preview close to its launch, and it's likely that pretty much any notable post-1998 release will have done the same (the kit would later be made available to all licenced PlayStation developers, not just internal studios, as the DTL-H2700 Performance Analyser / Development System).

Mike Froggatt
Mike Froggatt — Image: Mike Froggatt

"I wouldnโ€™t be surprised to hear that every outstanding late-generation PS1 title benefitted from the scrutiny you could apply with the Performance Analyser," Froggatt comments. "I was still working on shipping our last PS1 title back when the rest of the studio was working on PS2, and the Performance Analyser was my 'go-to' tool for optimization." That title was Studio Cambridge's 2001 action game C-12: Final Resistance โ€“ a very late PlayStation release on which Froggatt served as a programmer and is blessed with some of the most visually impressive graphics you'll see on the system.

Indeed, such was the impact of the kit that Froggatt feels that many of the subsequent optimisation tools he has used didn't come close. "Iโ€™m not sure we ever had any tools in the PS2 / Dreamcast generation that provided transparency on system behaviour that the PA gave us for PS1. It probably wasnโ€™t until the Xbox 360 / PS3 generation and tools like PIX that we started to achieve the same level of insight into what a game was doing at the hardware level."

Sadly, the incredible legacy of the Performance Analyser has gone largely unheralded; while the games it helped to create have become solid-gold classics, there's little information online to celebrate its existence โ€“ perhaps because, for modern-day developers, similar pieces of hardware simply aren't feasible. "Unfortunately, with the highly integrated systems that appeared after the PS1 โ€“ CPUs and GPUs with complex internal state, and entirely integrated CPU/GPU SOCs โ€“ the approach of understanding system behaviour through observing external signals just ceased to be effective," says Froggatt. "Now weโ€™re entirely dependent on dedicated hardware counters that our hardware partners integrate. And with the amount of data generated by systems running at multiple GHz, a 64MB buffer probably wouldnโ€™t cut it any longer!"