Since I did a similar post for the Xbox 360 XDK a while back and since this is intended to be mostly a developer-oriented blog, I thought it would be in keeping with that spirit to let people have a general idea of what to expect from a debug PS3 – which recently arrived.
Photo album: All of the screenshots linked to below (and more) can be viewed separately in this photo album here.
Profiling/debugging
There are some limitations as to what you can do with regards to profiling – even on a Debugging Station. Code instrumentation through gcov is entirely possible, but this was not very appealing to me anymore given that we have been able to do this more or less even on Retail with Themaister’s net-stdio implementation. Gprof seems to have been made unavailable as Sony started moving more and more away from the open source GNU toolchain they originally based their development environment on. What’s left is a proprietary profiler that will not work on Debugging Stations but requires a Reference Tool instead – it has 256MB extra main RAM, bumping up the main system RAM in total to 512MB (plus 256MB RAM for the RSX) – which, together with the unit’s Communication Processor, gives it the extra horsepower it needs to do real-time profiling on-the-fly amongst some other things like realtime video capturing and graphical analysis through GPAD – which I’ll touch on in a moment.
LibGCM HUD
A very nice feature which seems to be only available on debug PS3s is the ability to run code with an RSX profiling tool called ‘GCM HUD’. As the name would imply, this is a Heads-Up Display overlaid on top of the application you’re running that neatly provides you with a point-and-click interface giving you access to features such as as:
- Fragment/Vertex program debugger (with the ability to set breakpoints and step through the code line by line from the console itself – with no PC having to be involved or connected to the PS3.
- RSX Performance Counters (telling you how effectively you’re utilizing the RSX).
- RSX Command Buffer log (showing you the workload of the RSX in real-time)
The whole interface is mouse-driven – so to interact with it, you have to hook up an USB mouse to be able to control it. This is not where the usefulness of this tool ends, however – GPAD (Graphics Performance Analyzer and Debugger) allows you to interface your PC with this HUD and dump all the performance data to your PC. However, again, some options – such as live video capturing – can only be done with the Reference Tool.
GPAD on a Windows PC interfacing with a debug PS3 running GCM HUD
Samples
A brief rundown of the samples that struck my eye –
Deferred shading
Deferred shading lends itself well to the architecture of the PS3 where you have a comparatively humble GPU (RSX) and up to 6 SPEs each running at 3.2GHz – the idea is to essentially subdivide the result of a shading algorithm into multiple parts that can be spread across different render targets/CPUs only to combine them at the end into one composite whole. Using this approach, the RSX can simply offload a lot of the vertex and fragment computations that are done in shaders to the SPEs which in turn crunch through the calculations (the original shader algorithm having been subdivided into parts for each SPE to chew through) only for the RSX to combine all these separate parts and render the picture.
Commercial game developers like DICE have started using this approach for games like Battlefield 3 to achieve graphical results and performance which normally would have been unattainable if all that was available to them was the RSX alone. A link to a slideshow presentation is available here.
Deferred shading sample pics
Yes, the FPS count starts to drop heavily once you start adding extra spot lights.
PSGL samples
At one point, Sony was asking developers whether they would be interested in having PSGL conform to the OpenGL ES 2.0 specs (link here). This has unfortunately never happened however, as developers seem to have mostly preferred to go with libGCM as their main graphics API of choice on PS3. This has meant that the development environment has started becoming more libGCM-centric over the years with PSGL eventually becoming a second-class citizen – in fact, new features like 3D stereo mode is not even possible unless you are using libGCM directly.
However, this has not deterred them from still making available a couple of nice samples that illustrate what PSGL is capable of in conjunction with Cg shaders (which is mostly what we use with the homebrew emulators up until now). Some nice examples show Cg being applied to render hair, skin mapping, normal mapping, parallax mapping, and sophisticated water effects (the latter ones definitely being a cut above our own water.cg shader – made by Themaister).
Below you can see some screenshots illustrating nice tech demos using Cg and SPUs in tandem –
Cg being used for hair specular highlights
Cg being used for water ripple effects
Conclusion
What the debug PS3 will allow us to do is to finally start getting rid of bugs – memory leaks that were simply impossible to flush out with a retail box because of the inherent limitations of printf debugging. There are quite a few memory leaks that can now be tracked down in FBANext PS3 through crash dumps and live TTY logging.
Most ambitious of all, it will finally allow us to start writing code for SPUs – which I didn’t even want to attempt doing before because of the pain that was the retail environment. It remains to be seen whether we can really offload much if anything in the emulators to the SPUs – however, I have seen many creative uses for PPU-to-SPU offloading in some samples already, including function/virtual function call offloading to specific SPEs amongst a host of other things I didn’t even consider before.
Expect to see some real solid progress on MAMENext PS3 very soon, and for the emulators to improve immeasurably overall. Still, there are some inherent limitations even to the Debugging Station – the proprietary profiler will only allow me to do static analysis right now with a Debugging Station – if we wanted real-time profiling, we would have to be in possession of a Reference Toolkit, which is simply above anybody’s budget to be honest. This means that it might be impossible for any homebrew dev to ever do a serious attempt at porting a demanding emulator such as PCSX2 or Dolphin even with a debugging station because libgcov will only carry them so far – definitely forget it altogether on the retail units and the limited development environment they have available to them (whether it be the PS3 SDK or PSL1GHT).
The debugger that comes with it however is a seriously powerful tool and can carry us a long ways since it shows us live disassemblies of the code – meaning we can at least set a breakpoint somewhere, look at the ASM that the ‘shitty’ PS3 compiler turned our C/C++ code into, and then rewrite the code ad nauseam until the code generation starts to make more sense of our code and translate it to faster ASM code.
