PS3 Conference Report - Date and More! (1up.com) [LWN.net]

PS3 Conference Report - Date and More! (1up.com)

Posted Mar 21, 2006 5:51 UTC (Tue) by jerrysiebe (guest, #33230) [Link]

The following is just my speculation and understanding based on what Sony
(really SCE*) has said about PS3 and what they have done in the past (i.e.
Linux for PS2).

DRM will be handled by a Hypervisor software layer that sits between the
hardware and All other software; not just linux, but games as well. Not
even professional game developers will have uncontrolled access to the
hardware.

Sony talks about Linux running as a 'guest' OS, and we have heard about
Cell being able to run multiple OS at the same time. PS3 has been
described as an always on system, being able to do tasks like
re-processing a library of standard definition videos to higher quality of
downloading new content while not in use. My guess would be these and
other services would not necessarily be part of linux, but another OS,
which I'll call MediaOS for now (though could be any other third party
guest OS).

Both MediaOS and Linux would run side by side. When you play a game or
watch a video (either put in a disk or some downloaded content within
MediaOS), it would take priority, though Linux wouldn't really have to be
shut down or stopped, it could run in the background or, more likely, be
suspended, depending on what's being done. Linux will most likely have no
access, visibility, or influence whatsoever to what is happening outside
of Linux. A game or video running from Linux would be treated the same,
suspended when a disk is inserted or the MediaOS is called up for another
reason.

The Linux Sony will provide pre-installed may be prettied up and/or a bit
dumbed down, but most likely it will still be fully functional, possibly
even including a development environment (If not included, Sony will
provide the tools for download, both for PS3 and other platforms). Sony
has speculated on what possibilities the community might bring, even
suggesting that such community development is really the only place
radical ideas could be brought to life. (a swipe at conservative
tried-and-true rehash game development, perhaps?)

I don't see Sony DRM locking PS3 to only run signed kernels, ala TiVo.
Community developers will be able to build and run their own Linux
versions and even develop different OS if they choose. However, they will
all run as guests, in the same controlled environment (subject to
Hypervisor and MediaOS preemption). The crux of the PS2 Linux Kit was a
PS2 boot disk that would act as a boot loader that could load from the
memory card. Though Linux was provided, there was no restriction on what
could be booted. The user had access to put whatever they wanted on the
memory card. More up to date versions of Linux became available quickly.

The DRM, or hardware lockdown via the Hypervisor, in the PS3 is better
than it was in the PS2. I think that was deliberate, in part so they
wouldn't have to restrict what runs as a guest OS (and in part, to limit
what even "official" software can do. HD-Loader, anyone?). TiVo's
revenue comes from subscription to their service, so locking the hardware
they make to that money making service makes business sense. Linux on PS3
will not interfear with the services Sony's builds into the PS3, they will
always be there.

The Hypervisor layer software (and MediaOS), however, will be protected by
every means possible, including digital signatures and probably even legal
action. Don't play there. Stay in the sand box and nobody gets hurt. :P

I'm also curious about the drivers for the RSX. The PS3 will only support
OpenGL ES features, so a lot of cruft in full blown OpenGL normally in
nVidia drivers will be cut out (like shader compilers, etc). I would
think this would make for a much easier port than perhaps the IA64 one, as
well as giving it a smaller memory footprint. How it will handle possibly
9 different threads (7 SPE, dual threaded PPE) simultaneously wanting to
send data... perhaps it will be much more complicated. :)

Keyboard & mouse? USB, or even bluetooth. Will PS3 ship with them...
probably not, to keep costs down. I do hope (and suspect) that KB&M will
be supported by more games than was the case with the PS2 (a dismal few).

PS3's RAM is pretty lean for typical desktop/workstation use. However,
stick to one workload app at a time and it should be fine. If high
performance 3D graphics isn't needed, it may be possible to use part of
the video ram as well. Given the recent noise about offloading physics
onto the GPU, perhaps some of the RSX's power could be harnessed as well.
Though even if possible, it would be application specific, and only
benefit code that would already work well in the highly parallel Cell
architecture.

Ergh! So long... oh well.

PS3 Conference Report - Date and More! (1up.com)

Posted Mar 21, 2006 10:12 UTC (Tue) by nix (subscriber, #2304) [Link]

The Cell can run multiple OSes at the same time in exactly the same way that any other PowerPC CPU can. You can't sensibly run an OS on the (multiple ancillary) SPUs: they're too small and too strange and have very odd I/O paths (all I/O mediated by the main CPU). The code running on the SPUs of necessity has to cooperate closely with the code running on the main CPU, too.

GCC can target the SPU with a cross-compiler, though, so you'll be able to tell them what to do. But there's no chance of running Linux *on* the SPUs --- or Windows, either, or any other OS I can think of.

SPU data paths, asymmetric multiprocessing in Linux

Posted Mar 21, 2006 13:45 UTC (Tue) by shapr (subscriber, #9077) [Link]

To be pedantic, the sidekick SPUs each have their own DMA controller, so they can do their own I/O directly to memory. They also have dedicated paths to the two SPUs on either side for pipelining purposes.
There's no necessity for SPUs to cooperate with the strawboss CPU, it's just that 'coprocessors' is the view with the shortest mental distance from current viewpoints.

I think this is a good opportunity to extend the asymmetric multiprocessing ability of Linux to work with different CPUs instead of just different speed CPUs.
Then you would be able to run Linux on the SPUs, they'd just be another CPU.

Personally, I'm looking forward to doing nested data parallelism on the Cell.

SPU data paths, asymmetric multiprocessing in Linux

Posted Mar 21, 2006 16:26 UTC (Tue) by nix (subscriber, #2304) [Link]

True, I quite forgot about the nifty SPU-to-SPU-to-RAM array processing stuff.

In practice the SPUs are likely to be told 'here's what to do and where to find it' by the main CPU, and then go away and DMA that data directly in, possibly chattering with each other along the way. But it's not a fully general-purpose CPU: it foesn't have the other I/O pathways that the main CPU has got.

You could time-share them in theory, I suppose, which would require a sort of OS, but with most I/O off-limits most of he other jobs of an OS are superfluous. (And in practice the main CPU will be cooperating so closely that it'd all be one OS anyway. In *theory* the SPUs could do their own thing, but even that would probably be a message-passing thing where the CPU sticks stuff-to-be-done at some known location in RAM and the SPUs periodically check it, and by that stage why not just have the CPU tell the SPUs what to do directly?)

SPU data paths, asymmetric multiprocessing in Linux

Posted Mar 21, 2006 17:25 UTC (Tue) by shapr (subscriber, #9077) [Link]

And in practice the main CPU will be cooperating so closely that it'd all be one OS anyway. In *theory* the SPUs could do their own thing, but even that would probably be a message-passing thing where the CPU sticks stuff-to-be-done at some known location in RAM and the SPUs periodically check it, and by that stage why not just have the CPU tell the SPUs what to do directly?

For something like nested data parallelism where array operations can be unrolled and parallelized.
Then you'd do just what you described: leave a bunch of tasks to be done in memory where the SPUs would pick them up and execute them without needing explicit scheduling.
As for why not have the strawboss CPU tell the sidekick SPUs what to do, it's about implicit versus explicit. Why involve the strawboss CPU if you don't need to?
You could get advantages like best-effort rendering where the chunks are done in order, but the entire input queue would be cleared when the frame needs to be sent to the display.
(Virtual reality systems use this, they randomly choose which on-screen pixel to update next, giving a motion blur effect when the user turns their head faster than the system can render.)

PS3 Conference Report - Date and More! (1up.com)

Posted Mar 21, 2006 16:45 UTC (Tue) by jerrysiebe (guest, #33230) [Link]

Yes, and no.

True, the Cell's PPE does run multiple OS much like any other CPU. However, the similarity ends there.

The SPUs can only address 32 bits, so can only address 4 GB of memory (main, local of other SPUs, video ram, etc.), so their memory access is mapped. That mapped access, however, is not done by the PPE, but by their own local DMA. The SPUs are not necessairly dependant on or in need of close cooperation of the PPE. While an SPU is running, it can be completly independant of the PPE.

The SPUs can also be locked down, so the PPE or other SPUs cannot access them while they are running. This means that while the PPE may only run one OS at a time, different SPUs can be running tasks assigned from different OS at the same time. (Don't forget, though, that Hypervisor has the one ring to rule them all. :D The Hypervisor can stop a SPU, dump it's state to memory, and assign aother task to it.)

So in another sense, you are wrong. The Cell can be running code from multiple OS at the same time.

While the SPUs have only 512k of local store, their access to mapped memory allows a SPU to accomplish for more than you might think. While you won't be running a desktop OS on them, they could manage their own memory, paging memory between local store and main memory. They could also run multiple threads (in a limited way, not preemptive), switching contexts by themselves. They can indeed run their own OS. Performance, however, is a significant barrier to the usefulness of such a setup.

Also, don't forget that multiple SPUs can work in conjunction with each other. A SPU only OS or other independant running code isn't limited to a single SPU.

PS3 Conference Report - Date and More! (1up.com)

Posted Nov 17, 2006 17:18 UTC (Fri) by zaibaker (guest, #41732) [Link]

Hello,

i have a question about the PS3 and Linux.

Can we use the power of the PS 3 without restriction? Or some software will lock the skills of the PS 3?

And if restrictions they are, what are them? Hypervisor?

So, if i want to use it like a nice mediacenter, i will be able to make it without problems?

Sorry about those questions of newbie :P

See you later!