I could not find the XDR latency topic in the search function, so

And of course people will start doing some benchmarking as soon as they get their hands on Linux. You might see people close to or from Sony themselves even mentioning details about the hardware to indicate when something in Linux prevents reliable tests. But since I understand you'll have pretty extensive access to the Cell, we should see some good tests anyway.
I believe Linux will not have full access to all the PS3 has to offer.

I think I read it won't have full access to CELL and it's 7 SPEs (or SPUs whatever you prefer) and there will be no RSX specific software dev tools included.

Whether that means Linux will have limited access to RSX or you'll have to be a certified nvidia gpu genius to get decent levels of performance out of it I do not know.
 
I believe Linux will not have full access to all the PS3 has to offer.

I think I read it won't have full access to CELL and it's 7 SPEs (or SPUs whatever you prefer) and there will be no RSX specific software dev tools included.

It may not have full access, but since it includes the Cell SDK 1.1, I'm expecting it to have at least quite extensive access - this is the distro that sells Mercury systems, after all, and it would be a lot of extra work to severely limit Cell access. At best, Sony will block off everything to do with the firmware/Game OS. It's going to be interesting, for sure.

Whether that means Linux will have limited access to RSX or you'll have to be a certified nvidia gpu genius to get decent levels of performance out of it I do not know.

I'm expecting decent OpenGL/ES support, but beyond that, it's wait and see. Ideally Sony will leave open as much as possible, as this will create an excellent breeding ground for new companies and developers. On the other hand, it shouldn't be so open that everything becomes a tremendous hack-fest, obviously, but as long as they can control BluRay game starting and the licence code system, they can get pretty far. And hopefully with Hypervisor mode, this time they succeed - because honestly, all these ISO abusers are so far only getting in the way of the Homebrew community and I'd be happy to be rid of them. ;)
 
As long as someone manages to port WinUAE onto the PS3s breed of Linux I will be a happy man.

As for the specific restrictions re the system rom and all that, there was a graphic from TGS that explained how it was going to work.

Everything there will be no access to the firmware from linux and CELL is pretty well protected with the on-board protection stuff.

I think the chances of someone making a hack that will run PS3 games through Linux are remote.
 
Gubbi said:
Didn't NV double the texture caches in RSX to deal with the added latency ? Or did I dream that.
You didn't dream that someone posted it here - but neither the numbers nor the actual explanation of what is changed in the caches was right.

London Boy said:
So what's the fuss all about? UE3 is already a PC-centric engine, so what's the problem?
Who said that UE3 had texture problems on PS3 though? Isn't the commentary on that referring specifically to performance not being quite there - hence could even be completely unrelated to rendering in the first place?
 
Last edited by a moderator:
Which kinda begs the question - Is R6:V really a UE3 title? Maybe the engine isn't the problem at all, and it's simply a complication from developing with 360 as the lead platform.
It probably isn't. It's probably using the same engine as the latest SC and that is supposed to be an evolved version of the already tried and true UE 2.5.

I remember when Frame City Killer was supposed to be the first UE3 title to be released but it was cancelled. I couldn't get a straight answer 'from people in the know' other than the language barrier problem but I think the fact that Epic still wasn't done with their engine was a problem. When they showed off Lost Odyssey this year Feelplus still had not received the latest version of UE3 with the multithreaded renderer. I wouldn't be surprised if the same thing happened to SK as well. The fact that Epic was still working on the engine for the 360 probably kept many UE3 games for the system from being released this year. Now that Gears will soon be released for the Xbox 360 we will finally start to see other UE3 games being released for the system. The PS3 is likely to run into some problems because Epic isn't putting full effort into getting UT2007 done for that machine until it is released for the PC. At least the multithreaded renderer will be partly ready for the PS3 but I think some devs are going to hold off on releasing some UE3 games until the PS3 has Epic's full attention.
 
Last edited by a moderator:
I don't understand one thing, i've been looking the Flex IO specs, and it's only a 16bits bus, so, how could it carry a texture? it's impossible, isn it?
 
Actually I think it's 8 bit ;) Or rather, 12 lanes each of 8 bits which can be set as input or output. You can easily send a texture or any other data, by sending it a byte at a time. For a 128x128x32 bit texture, you'd do 4 reads per pixel. Or if you have four lanes for input, send 4 bytes per cycle.

The width of the bus doesn't limit the width of the data that can be sent. Smaller buses just mean sending the data piecemeal.
 
Actually I think it's 8 bit ;) Or rather, 12 lanes each of 8 bits which can be set as input or output. You can easily send a texture or any other data, by sending it a byte at a time. For a 128x128x32 bit texture, you'd do 4 reads per pixel. Or if you have four lanes for input, send 4 bytes per cycle.

The width of the bus doesn't limit the width of the data that can be sent. Smaller buses just mean sending the data piecemeal.

You mean, you can divide a texture of 64 bits, for example, in 4 packages of 16 bits...Ă‚Âż? But the textures are indivisible, aren't they?
 
You mean, you can divide a texture of 64 bits, for example, in 4 packages of 16 bits...Ă‚Âż? But the textures are indivisible, aren't they?
Since there are no smilies attached, I guess you are serious.
A bus is just some electric signal lines, whatever data structure you send over it does not need to be of that size, the interface logic of the bus will arrange the data for the bus.

64 bit texture? Sounds like a damn small texture to me. ;)
 
I don't understand one thing, i've been looking the Flex IO specs, and it's only a 16bits bus, so, how could it carry a texture? it's impossible, isn it?
This question does not make any sense. Do you need a 8 Miliion bits wide bus to transfer a 1 Mbyte file? A texture is transferred like any other type of data, you can't possibly transfer a (big enough) texture in one clock cycle, it will be just transferred in multiple clock cycles.
 
There's only two theories that seem to fit the idea that Ubisoft have less RAM for textures on PS3 than XB360. Either the OS is consuming vast amounts of RAM meaning less is available, or they're only using the GDDR for textures. Neither sounds entirely plausible, but the XDR-based textures seems the more probable of the two! Because RSX has to fetch textures over the FlexIO, making it indirect access, perhaps that adds a problem for the existing texturing engine either in setting up the fetch or managing the extra latencies or somesuch?

I would add a 3rd theory there...

As long as i'm wrong the entire framebuffer resides in Edram, while in the system memory is just a 720p/1080p image... In 720p that would be an extra ~28 MB on memory, while on 360, thanks to edram, its just a ~4 MB image...

Maybe is just a combination off all that: The OS consumes more ram, the splited memory pool may be used, but not helping as much as it could, and the frame buffer that probably uses more ram on Ps3...
 
There is a figure in the OBM docs for latency somewhere, IIRC it's "at least" 460 cycles or something like that. That includes latency of going across EIB etc.
 
There is a figure in the OBM docs for latency somewhere, IIRC it's "at least" 460 cycles or something like that. That includes latency of going across EIB etc.
Are you talking about latency to RSX, in RSX cycles? Or latency to the SPE?
 
I would add a 3rd theory there...

As long as i'm wrong the entire framebuffer resides in Edram, while in the system memory is just a 720p/1080p image... In 720p that would be an extra ~28 MB on memory, while on 360, thanks to edram, its just a ~4 MB image...

Maybe is just a combination off all that: The OS consumes more ram, the splited memory pool may be used, but not helping as much as it could, and the frame buffer that probably uses more ram on Ps3...
I'll add a fourth theory...

Given the X360 and PS3 are completely different graphics chips, its possible they are using some X360 custom texture compression mode that they don't have on PS3. Especially if short on dev time they simply might not have able to find an exact replacement on PS3 yet, so the only answer was to reduce the texture set.
 
I'll add a fourth theory...

Given the X360 and PS3 are completely different graphics chips, its possible they are using some X360 custom texture compression mode that they don't have on PS3. Especially if short on dev time they simply might not have able to find an exact replacement on PS3 yet, so the only answer was to reduce the texture set.

Nah, it doesn't sound like a good one...


(J/k, I think your guess is probably what happened :p)
 
Is there another Flex I/O bus connecting RSX and CELL? or there is a PCI Express, like in pc's?

PD: I know my english isn't perferct.
 
Is there another Flex I/O bus connecting RSX and CELL? or there is a PCI Express, like in pc's?

PD: I know my english isn't perferct.

The flex I/O bus is very configurable hence the name, so there is no need for any secondary I/O bus.
The system interface used in Cell, also a Rambus design, is known as FlexIO. The FlexIO interface is organized into 12 "lanes," each lane being a unidirectional 8-bit wide point-to-point path. Five 8-bit wide point-to-point paths are inbound lanes to Cell, while the remaining seven are outbound. This provides a theoretical peak bandwidth of 62.4 GB/s (36.4 GB/s outbound, 26 GB/s inbound) at 2.6 GHz. The FlexIO interface can be clocked independently, typ. at 3.2 GHz. 4 inbound + 4 outbound lanes are supporting memory coherency.
Some of these 12 lanes are assigned to the communication with the RSX and some to other peripherals, like the north bridge.
 
Back
Top