Thoughts and records on hacking PS3 rsx

Thanks to several hackers, firmware 2.0 and below can use the "partially" GPU (NVIDIA rsx) feature. Recently, I have spent a lot of time on this and have a rough understanding of the GPU underlying layer and tool chain.

 

On the PS3, there is an operating system at the bottom layer that provides hardware functional interfaces, which is called Level 1. Any operating system on it needs to interact with the hardware interface through level 1 API, which is called Level 2. With this concept, the default Operating System (gameos) running on the PS3 and other third-party operating systems (otheros) are level 2 OS. For complex purposes, Sony has developed a third-party operating system, called openplatform. Specifically, it is a dedicated employee who maintains the Linux kernel for the PS3. Because the kernel must be open, although only a few of them call Level 1 OS systems without comments, it still gives hackers the opportunity, here is a wiki that collects and describes Level 1 APIs: http://wiki.ps2dev.org/ps3:hypervisor

 

All hacking starts with these Apis. By exploring, experimenting, and reverse engineering analysis dump, and using the Nouveau open-source driver project, hackers finally found some solutions to control the GPU.

 

NVIDIA series GPUs all have a FIFO round Queue (command buffer) for storing GPU commands. The size of the block in the system memory is about 64 KB (or 2 MB cannot be remembered ?). There isProgramThe pointer (Register) of the pointer PC, pointing to the FIFO. The other pointer (Register) marks the end of the current GPU queue. Once the two pointers do not match, the former will separately DMA the commands in the queue to the GPU until they overlap with the latter. So what we need to do is to enter the correct command in the FIFO, so that the GPU will execute our commands one by one.

 

Because the cost of implementing a set of driver and graphic APIS is too high, it is almost difficult for individuals to complete. So there is no driver, no graphical API, no resource management, and everything is only FIFO and instructions. This is similar to the libgcm library in the official SDK. It can bypass the lower layer of psgl and perform some operations on the command buffer, such as passing in the pre-compiled command queue.

 

What is most uncomfortable is not the lack of graphic APIs. Since hardware commands are not made public, we need to use nouveau's project resources and some dump to analyze nv40 series commands. Some can be used normally, others are not (for example, in VP add and FP movr, the color of float4 cannot be correctly output ). Even if you have mastered these hardware commands, writing shader will be very painful if you don't have a compiler or an advanced language compiler. So the current tool chain is like this: Write CG on the PC and use the CG compiler to output vp20 and fp30 assemblyCode. On PS3 Linux, there is already a good javaser that can translate assembly code into hardware commands. Therefore, writing a shader will switch back and forth on the two platforms, so it is very busy.

 

I think the work in the future can include some simple resource management and queue management work, including memory allocation, resource cache, and swap-out, such a simple "driver" can greatly enhance the current creativity and visualization capabilities for cell development in the future.

 

Finally, let's put a screenshot. using SDL, we can use sixaxis almost perfectly.