View Full Version : Best Linux distro for the PS3?
Hello all,
i don't have currently a PS3, but i might get one soon, i was wondering, from your (i refer to ps3 coders here) experience, what's the best linux distro for programming on PS3 ? is it the best even from a non programming user's perspective ?
Personally Im an Ubuntu fan (maybe better use Xubuntu on ps3), but i know that it's not the main officially supported distro there, does Ubuntu have the cell support yellowdog has ? can it be installed if it doesn't come "out of the box"?
Getting Ubuntu on the PS3 isn't too difficult (https://help.ubuntu.com/community/PlayStation_3) and Justin Lee @ CellPerformance has an article (might need some updating) (http://www.cellperformance.com/justin_lee/2006/08/cellbroadbandengine_sdk_11_on_ubuntu.html) about getting the SDK installed on Ubuntu. Whether or not the 2.1 SDK installs in the same fashion I'm not quite sure, guess it's time I tried!
Mike Acton
10-Jul-2007, 09:24
So far my experience has been that the distro doesn't matter that much. So long as you can get the PS3 kernel support running, everything after that is pretty much the same.
Especially since you'll probably just want to install all the libs and tools you'll need manually anyway (either from source or RPMS) - that saves a whole lot of headaches.
The only thing that springs to mind is that if you want Mesa support - that's a lot simpler to set up under Fedora (yum install - no issues), but it can be set up on any of the distros anyway.
So I'd say, go with whatever you're already most confortable with.
Mike.
Thank you both for your answers.
Mike, afaik there is no 3D acceleration under linux on PS3 right? or i've missed something?
Thank you both for your answers.
Mike, afaik there is no 3D acceleration under linux on PS3 right? or i've missed something?
There's no acceleration provided by RSX on user-installed Linux, if that's what you mean, because there's no driver available.
Mike Acton
10-Jul-2007, 09:42
There's no acceleration provided by RSX on user-installed Linux, if that's what you mean, because there's no driver available.
Yes, in an ironic twist, the best things to use the Playstation 3/Linux environment to develop is just about anything other than a big 3D game.
You can however write straight to the framebuffer (stored in main RAM) and draw whatever you like. And software drivers are available if drawing speed isn't your issue.
Mike.
Yeah, too bad, reallly toooo bad, i can understand why Sony is doing this though.
OzzyBC42
10-Jul-2007, 12:02
I'm using FC6, and everything seems pretty well so far. I have compiled some tips on my website (http://www.renderstate.de), feel free to check it out.
Panajev2001a
10-Jul-2007, 12:20
Yes, in an ironic twist, the best things to use the Playstation 3/Linux environment to develop is just about anything other than a big 3D game.
You can however write straight to the framebuffer (stored in main RAM) and draw whatever you like. And software drivers are available if drawing speed isn't your issue.
Mike.
Sadly, going from PS2 Linux and the awesomeness that SPS2dev (thanks Sauce and sparky.. sigh...) was to PS3 Linux you have about the same level of CPU low level access (actually you have more stuff to handle), but you lose all the GPU side stuff you had.
For 3D stuff you either have the option of using MesaGL or writing a software rasterizer with triangle set-up, 3D clipping, 3D primitives scan conversion, texture fetching and filtering, VS and PS programs support, etc...
Of course, if Sauce were here he would tell me not to worry about that stuff and to learn more about CELL which is most important, but I do want some GPU access anyways :P.
But you didn't get that much access to the PS2 graphics chips around when PS2 Linux was first released either, right?
Panajev2001a
10-Jul-2007, 12:39
But you didn't get that much access to the PS2 graphics chips around when PS2 Linux was first released either, right?
SPS2dev was not officially developed by Sony, neither Sauce nor Sparky worked at Sony.
The access to CPU, DMA, GIF, GS, etc... was there... the docs gave you address ranges, tags description for DMA packets/commands/registers, VIF packets, GIF tags and data to be placed inside packets to eb sent to the GS, etc... That library and associated kernel module helped developers to use all those functions as well as providing you an easy way to get contiguous blocks of unswappable physical memory (basially if you asked for 32 KB of unswappable memory to the allocator you would get 32 KB of contiguous virtual memory which was divided in 8 different 4 KB pages inside which you were guaranteed to have contiguous physical addresses... DMA did not understand virtual addresses... a simple use of DMA Next tags jumping from page to page would do the trick).
inefficient
10-Jul-2007, 14:36
Well I have been using YDL5 until now.
But, if you want to do development on it with the latest version of the SDK 2.1, you need to have glibc2.5 which is not yet available for YDL.
You'll either need FC6 to use SDK 2.1 or you need to manually update glibc yourself - which is has the potential to end your PS3 hacking experience in tears.
I thought I read somewhere that FC6 is used by a lot of folks at IBM, I think I recall they announced in some article that they were moving up to FC6 from FC5 for Cell development stuff recently. I'd probably pick this version myself (though my experiences with it on PC have been a tad rough so far).
Yeah, like Inefficient mentioned in order to (practically) use SDK 2.1, FC6 is required. This was their announcement of such back in April:
http://www.ibm.com/developerworks/library/pa-cellinstallsdk/
Hello all,
i don't have currently a PS3, but i might get one soon, i was wondering, from your (i refer to ps3 coders here) experience, what's the best linux distro for programming on PS3 ? is it the best even from a non programming user's perspective ?
Personally Im an Ubuntu fan (maybe better use Xubuntu on ps3), but i know that it's not the main officially supported distro there, does Ubuntu have the cell support yellowdog has ? can it be installed if it doesn't come "out of the box"?
Cell support is in the kernel so it's appearing in various distros now. The last version of Ubuntu has a PS3 build including Xubuntu:
https://help.ubuntu.com/community/PlayStation_3
Freak'n Big Panda
11-Jul-2007, 17:30
Yeah, too bad, reallly toooo bad, i can understand why Sony is doing this though.
I really don't. Why would they limit the flexibility like that?
I really don't. Why would they limit the flexibility like that?Security. On the Cell-side you have the hypervisor that sits on top, theres no such thing for RSX. Means with direct HW-Access shaders on the RSX could read/write to memory they arent allowed to.
Hopefully they can at least release a driver that is limited enough. It is probably partly taking a long time because they really, really want it secure, if they do it at all.
Freak'n Big Panda
12-Jul-2007, 00:00
Security. On the Cell-side you have the hypervisor that sits on top, theres no such thing for RSX. Means with direct HW-Access shaders on the RSX could read/write to memory they arent allowed to.
Oh OK thanks for the info
Security. On the Cell-side you have the hypervisor that sits on top, theres no such thing for RSX. Means with direct HW-Access shaders on the RSX could read/write to memory they arent allowed to.
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...
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. :roll:
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.
You mean the whole OS and its (runtime-)data fits into the 256KB LS? Pretty impressive work by Sony. :roll:
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
12-Jul-2007, 16:01
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!
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.
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
12-Jul-2007, 18:10
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!
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 :razz:). You rock, Shifty, but this is madness :runaway:
Sony want to encourage Cell development for entirely different reasons, IMO.
Shifty Geezer
14-Jul-2007, 11:44
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!
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
14-Jul-2007, 14:35
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
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
14-Jul-2007, 20:47
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?!
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
14-Jul-2007, 21:20
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.
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.
vBulletin® v3.8.6, Copyright ©2000-2013, Jelsoft Enterprises Ltd.