Best Linux distro for the PS3?

[Npl]

The security is done on the Cell itself inside SPEs using their secure mode (why else do you think it's not available in Linux?). If you can read additional memory with the RSX it's most likely on the Cell side and the hypervisor can probably block it as all read write's will go via Cell. Even if it can't prevent reads from the RSX they're not going to do you much good anyway as it'll be encrypted...

You mean the whole OS and its (runtime-)data fits into the 256KB LS? Pretty impressive work by Sony.
Everything else has to sit somewhere in RAM, inaccessible in Linux, but accessible in the PS3-OS - and very likely unencrypted for the biggest part.
I can only assume the potential weaknesses a direct accessible RSX could impose (my bet is that is that pending read/writes could happen in the wrong OS-Context), but what you say is obviously wrong.

 

[ADEX]

You mean the whole OS and its (runtime-)data fits into the 256KB LS? Pretty impressive work by Sony.
Everything else has to sit somewhere in RAM, inaccessible in Linux, but accessible in the PS3-OS - and very likely unencrypted for the biggest part.
I can only assume the potential weaknesses a direct accessible RSX could impose (my bet is that is that pending read/writes could happen in the wrong OS-Context), but what you say is obviously wrong.

GameOS will mostly be on disc and the OS proper isn't running when you're using Linux, it's completely invisible to Linux and won't be any different from the RSX. What needs to be protected is the Flash ROM, that is almost certainly encrypted and the most important parts are probably not even in the memory map at run time.

 

[Shifty Geezer]

I really don't. Why would they limit the flexibility like that?

One reason is because they want PS3 to be a place where homebrew developers work on Cell to create Cell solutions. Some of those solutions will be graphics rendering for use in single chip solutions. eg. A CE goods with UI's. You could have just a Cell in a TV which renders a flashy interface, and then out of the interface does image upscaling and whatnot. If no-one develops graphics solutions on Cell, CE devices will look towards a GPu and CPU combination. So by removing RSX from the developers, they have to think about getting best performance from Cell. A discussion on B3D had some of us wondering about the viability of a TBDR that minimized texture access to get around Cell's comparable limit with texture latency. Solutions like that won't be considered when you have a beefy GPU on hand!

 

[Npl]

GameOS will mostly be on disc and the OS proper isn't running when you're using Linux, it's completely invisible to Linux and won't be any different from the RSX. What needs to be protected is the Flash ROM, that is almost certainly encrypted and the most important parts are probably not even in the memory map at run time.

Yeah, its invisible in Linux, but its persistent and Cell sometimes has to swap to PS3-OS doing driver stuff and other things (running on the PPU). Then runtime-data and unencrypted code is accessible by the PPU - and other devices on the Bus. A shader doesnt care for OS-contexts (only DX10 starts to require it) and a DX9-class GPU cant easily store and resume its state, meaning that shaders could access Memory-Regions you shouldnt see on Linux. Thats the security-risk Im seeing.

 

[Npl]

So by removing RSX from the developers, they have to think about getting best performance from Cell. A discussion on B3D had some of us wondering about the viability of a TBDR that minimized texture access to get around Cell's comparable limit with texture latency. Solutions like that won't be considered when you have a beefy GPU on hand!

An the other hand why should you reimplement solutions if a perfect one is at hands in form of a Rasterizer?
I mean that if you require simple texturing you are wasting Cells potential for doing something new and fancy by re-implementing a algorithm that a small, 5 year old piece of silicon is doing faster and way more efficient.

 

[Shifty Geezer]

An the other hand why should you reimplement solutions if a perfect one is at hands in form of a Rasterizer?
I mean that if you require simple texturing you are wasting Cells potential for doing something new and fancy by re-implementing a algorithm that a small, 5 year old piece of silicon is doing faster and way more efficient.

Presumably because going forwards, device manufacturer will like the appeal of a single chip solution. As in my TV example - why have one processor for rendering the interface and another for tarting up the image if one processor can do the same job for less money (that latter point not being valid at the moment of course)? In a console or PC, you'll always want two chips. In smaller devices, a single chip could be a better choice eventually, as it's more flexible. If that's ever to happen, with Cell becoming widely adopted, it'll need people with experience of it, which is where PS3 comes in. It's not like Sony would open up PS3 development just to please folk!

 

[Rys]

Presumably because going forwards, device manufacturer will like the appeal of a single chip solution. As in my TV example - why have one processor for rendering the interface and another for tarting up the image if one processor can do the same job for less money (that latter point not being valid at the moment of course)? In a console or PC, you'll always want two chips. In smaller devices, a single chip could be a better choice eventually, as it's more flexible. If that's ever to happen, with Cell becoming widely adopted, it'll need people with experience of it, which is where PS3 comes in. It's not like Sony would open up PS3 development just to please folk!

I think you largely ignore efficiency, performance for a given area (and thus price) and power, and ease of implementation here (in a fairly pants use case too ). You rock, Shifty, but this is madness

Sony want to encourage Cell development for entirely different reasons, IMO.

 

[Shifty Geezer]

Sony want to encourage Cell development for entirely different reasons, IMO.

Whatever the reasons, locking out the GPU is beneficial to them, no? I was only giving the graphics idea as one possible reason. You'll also have people developing algorithms for Cell to drive graphics, which can be modified to drive other systems too, I'd have thought. The end result is basically everyone working on Cell generating best practice and ideas, which can be used in all other Cell situations. You want as many ideas, as many experimenters, as possible, without them getting annoyingly sidetracked developing shaders on a GPU!

 

[idsn6]

That's an optimistic view. From another perspective, programmer time and effort is being wasted replicating rendering functionality in software that would be better served by a dirt-cheap, basic, dedicated hardware solution. And I can't imagine that motivation for such endeavors is helped by the knowledge that RSX is just sitting there right across the bus, doing nothing.

 

[Panajev2001a]

That's an optimistic view. From another perspective, programmer time and effort is being wasted replicating rendering functionality in software that would be better served by a dirt-cheap, basic, dedicated hardware solution. And I can't imagine that motivation for such endeavors is helped by the knowledge that RSX is just sitting there right across the bus, doing nothing.

:round_of_applause

 

[Npl]

Whatever the reasons, locking out the GPU is beneficial to them, no? I was only giving the graphics idea as one possible reason. You'll also have people developing algorithms for Cell to drive graphics, which can be modified to drive other systems too, I'd have thought. The end result is basically everyone working on Cell generating best practice and ideas, which can be used in all other Cell situations. You want as many ideas, as many experimenters, as possible, without them getting annoyingly sidetracked developing shaders on a GPU!

Its a matter of interest too, Im certain if PS3-Linux had access to RSX (direct or through a paranoid Software-Layer) the demo szene would go wild over it. So alot ppl will simply stay on the PC or other Platforms with accelerated GFX.

So to sum it up:
* If your project does need a rasterizer you are crippled compared to any system with dedicated accessible HW and you are wasting alot of Potential by slaving Cell to rasterizing,
* if your project doesnt need a rasterizer you likely wouldnt be using RSX anyway (but still might appreciate if the 256MB DDRam were accessible somehow).

Its a loss either way as you lose options.

 

[Shifty Geezer]

That's possibly true. Though I'd have thought demo scenezers would jump at the chance to create realtime raytracers and 4 dimensional bozotronic renderers on Cell, rather than namby-pamby rasterized graphics on a graphics rasterizer processor. Maybe the demo scene has got soft in its old age?!

 

[Npl]

That's possibly true. Though I'd have thought demo scenezers would jump at the chance to create realtime raytracers and 4 dimensional bozotronic renderers on Cell, rather than namby-pamby rasterized graphics on a graphics rasterizer processor. Maybe the demo scene has got soft in its old age?!

Oh, Im sure we will some impressive non-rasterizer stuff (atleast on a technical level). But I cant befriend your assumption that the only reason we will/could see them is by disabling RSX.
You need to get ppl interested before they spend their time coding for Cell, you dont motivate anyone wanting do do "casual" 3D into writing a raytracer (, rasterizer or whatever) just to get his ideas done.

Made up example - Guy X wants to play around with procedural Geometry or HOS. Cell would fit the task for creating Geometry, but for displaying it he would want to just, well, render it. Spending time writing on a simple rasterizer is wasted from his perspective and using some existing he has a hard time using Cell to its fullest potential.

How can this be anyting but a downer for anyone requiring "casual 3D" ? Hoping that he instead scratch his plans and start developing a raytracer is a far strech.

 

[Shifty Geezer]

How can this be anyting but a downer for anyone requiring "casual 3D" ? Hoping that he instead scratch his plans and start developing a raytracer is a far strech.

Sure that's a downer. That's along the same principle of me wanting an application template that one can just use to run algortihms on, without having to worry about setting up and drawing UIs etc. None of us want to do extra work! But from Sony's POV, I think they want people to use Cell, and they'd rather we all wait for someone or other to release a Cell rasterizer engine before the rest of us dabble in our toys. Necessity is the mother of all invention, after all. There'll be some people who 'waste' some time that they want to spend creating polymorphic volumetric representations of whickywhackies, but instead spend creating a renderer just so they can see those whickywhackies, and what they consider a frustrating waste, Sony will consider a success. There may well be peeps who get so involved in the creation of rendering engines that they forget their whickwhackies altogether.

 

[ADEX]

Yeah, its invisible in Linux, but its persistent and Cell sometimes has to swap to PS3-OS doing driver stuff and other things (running on the PPU). Then runtime-data and unencrypted code is accessible by the PPU - and other devices on the Bus. A shader doesnt care for OS-contexts (only DX10 starts to require it) and a DX9-class GPU cant easily store and resume its state, meaning that shaders could access Memory-Regions you shouldnt see on Linux. Thats the security-risk Im seeing.

It all basically comes down to if anything important is in memory while Linux is running and if that can be accessed by the RSX.

If that's true then Sony will have seriously borked their security as it'll take just one dodgy developer to run a program to get to the relevant data. The data needs to be secured from everyone, be they linux or game developers.

The data I am referring to is the decryption system which allows the PS3 to read encrypted BluRay discs. This will be encrypted code, probably never held unencrypted in open memory.

Of course this routine itself has to be decrypted and the decrypter has to be held somewhere, I suspect that is held by the service processor* and it probably has hardware decryption so this routine is also never held in unencrypted memory. The only weak point I would see in that case would be transferring data from the service processor to the Cell, but getting that is not exactly going to be easy.

*The service processor is a second CPU which is used to boot the Cell.