Progress on the PS3 Linux RSX front..

Titanio

Legend
Panajev pointed this out on GAF, but I thought it worth mentioning here too, to shine some light and attention on some excellent work being done at ps2dev.org (chiefly by IronPeter and Glaurung) on opening access to RSX in PS3 Linux.

The whole thread is here if you want to read a blow-by-blow account of reported progress to date - it's been on the boil for a couple of months now:

http://forums.ps2dev.org/viewtopic.php?t=8364&postdays=0&postorder=asc&start=0

There's a perhaps more readable wiki here: http://wiki.ps2dev.org/ps3:rsx

I won't pretend to understand all the ins and outs of what they're doing, but basically it seems they have managed to find a way to send commands to the GPU via a hypervisor FIFO buffer..they have vertex/index buffers, vertex and pixel shading, texturing and some other stuff working already. There's a video of a demo here:

http://www.youtube.com/watch?v=vuRLsB2q7QY

The project has been opened up, and they're looking for suitably able people to contribute.
 
Yes, I've been following this for a while now ... they're doing really well! Much better than I'd have expected!
 
I'm sure they can, I don't think they will though.

Yellow Dog were implying they would be allowed access to RSX in the future a while ago so I guess sony aren't really that bothered.
 
Will or can Sony react on this and in that case, how?

From what I understand of the thread, they have taken the provided fb driver from Sony for Linux and analysed that and started messing about with hypervisor calls.
Ie its not an exploit.

While there, I wanted to point out that it's not actually a security hole :) The cell chip has an iommu that protects the hypervisor, whatever DMA you can do will only land in linux partition space afaik. I think when linux registers it's memory with the GPU (some HV call at one point, no source at hand right now) it basically gets the logical memory (peudo-physical partition memory) mapped into the iommu for access by the video chip.

I've not verified, and it's possible that they disabled the iommu for performances reason (that would definitely be a security hole) but it sounds logical that way.

In this case, leaving access to the chip is not a hole to be plugged, in fact, it's something that sony might use themselves if they ever release an accelerated linux driver, and calling it a hole might just be damaging for us by giving the wrong message to whoever from sony is lurking on this forum ...

The fact that you are supposed to use the HV to access RAMIN sounds more like an architecture decision of how sony own driver work here... now we need to find the right HV API calls to manipulate the object.

But I'd guess a FW update could ofcourse "stop" it, still why do they want to do that?
 
I'd turn this around, and suggest that what they have found is how they are intending any RSX support to be in Linux by design. They're just currently not yet doing it themselves, for whatever reason (priority most likely)
 
This is sounding mighty interesting. Not being very well versed in Linux here i gotta ask how Linux executes code over the SPEs, if they do so at all? Perhaps there is a site i can learn from *goes searching the google*
 
This is sounding mighty interesting. Not being very well versed in Linux here i gotta ask how Linux executes code over the SPEs, if they do so at all? Perhaps there is a site i can learn from *goes searching the google*

To make a long story short:

PPU creates one or more SPU threads, loading for each the code that needs to run on them and then starting them up. After this moment the SPU's are on their own and need as little PPU help as you the programmer wants them to have (they can DMA code and data [although inside the LS they are the same thing really... all data] in and out the LS getting data from and to XDR memory).
 
Does it automatically thread apps onto the SPEs without mych coding work being done? As i understand it you have to code for threading for the cpu to take advantage of it, so do all apps have to be coded for the SPEs or is it automated?
 
Does it automatically thread apps onto the SPEs without mych coding work being done? As i understand it you have to code for threading for the cpu to take advantage of it, so do all apps have to be coded for the SPEs or is it automated?

You have to write your code to take advantage of the SPU's.
 
Good to know, i would think Sony would be rather helpful in providing information and documentation to ease development. I've been looking forward to Sony makeing their own or supporting their own operating system. Would be awesome to have all of their software on Linux with extensions for Cell. Developing laptops with Cell and workstations with Cell. The PS3 is just the first step on the road to a revolution!





...i hope :p
 
Progress still seems to come along quite well over at ps2dev.org. Always nice if you have visuals to show for it though and although simple, here's another little video of the OtherOS demo now using some simple RSX stuff:

http://www.youtube.com/watch?v=ZJQkXmG6UTI
 
Back
Top