[Mummy]

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"?

[Rys]

Getting Ubuntu on the PS3 isn't too difficult and Justin Lee @ CellPerformance has an article (might need some updating) 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]

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.

[Mummy]

Thank you both for your answers.

Mike, afaik there is no 3D acceleration under linux on PS3 right? or i've missed something?

[Rys]

Originally Posted by Mummy

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]

Originally Posted by Rys

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.

[Mummy]

Yeah, too bad, reallly toooo bad, i can understand why Sony is doing this though.

[OzzyBC42]

I'm using FC6, and everything seems pretty well so far. I have compiled some tips on my website, feel free to check it out.

[Panajev2001a]

Originally Posted by Mike Acton

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.

[Arwin]

But you didn't get that much access to the PS2 graphics chips around when PS2 Linux was first released either, right?

[Panajev2001a]

Originally Posted by Arwin

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]

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.

[Arwin]

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).

[Carl B]

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/li...ellinstallsdk/

[ADEX]

Originally Posted by Mummy

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]

Originally Posted by Mummy

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?

[Npl]

Originally Posted by Freak'n Big Panda

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.

[Arwin]

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]

Originally Posted by Npl

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

[ADEX]

Originally Posted by Npl

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...

[Npl]

Originally Posted by ADEX

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]

Originally Posted by Npl

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]

Originally Posted by Freak'n Big Panda

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]

Originally Posted by ADEX

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]

Originally Posted by Shifty Geezer

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.