RSX: Vertex input limited? *FKATCT

easier was not the only reason sighted by Joker for his comments.


I doubt NT was not experiencing some of the issues, my guess is without coming FROM the 360 with their code, they aren't able to distinguish the differences in going from one to the other which Joker has addressed in this thread.

NT just worked around it as they always would because they are smart and talented. Joker also agreed that they would do the same but that the hardware (memory available for one) physically makes it better for their game which was already using more memory than they could find on PS3.

 

Guys, this is the final call! From here on, there'll be bloodshed...

I am trying as hard as I can to keep this thread on topic and to keep the quality as high as it can possibly be. This is topic about programming on RSX and Xenos (Note: this is not a software comparison thread!). So please stay on-topic.
To make things a little more obvious:

• If your post contains / needs to relie on visual evidence, don't post...
• If your post is about the "allegiance" of the devs, don't post ... Beyond3d readers should be smart enough to form their own judgement
• If your post needs to statistical evidence (X games look better than Y games. X>Y), don't post... I think the focus should be on developing rather than the numbers of games released
• etc.

Since I've spent now some time pruning this thread, I will not be very tolerant concerning derailment etc. In fact, further abuse will have consequences.

That said I'd like to say a big thanks for contributions of the devs. Everyone else keep the questions coming!

 

Who has benched RSX? Even though it is based on G71 architecture, no one has ever benchmarked the RSX to my knowledge. There are no results that say, ok RSX gets 2200 points on 3dmark 06 Shader 3.0 benchmark, or whatever. Something that gives us a frame of reference. Obviously what is a good benchmark is debatable, so it doesn't have to be 3dMark. The Cell benchies that we have are useful only in looking at how fast cell can iterate mandelbrot, or how fast it can render a terrain in a contrived case. Very interesting, but it doesn't tell us a whole lot about how it handles AI + Physics + Culling etc concurrently under specific workloads.

It is true that Cell has been benched more than Xenon (I wonder if anyone can dig up legitimate Xenon benchies ), but how useful are those numbers to us for comparitive purposes? The only stuff that I've seen that hasn't come from IBM isn't very optimized.

The more important part question is how well Cell + RSX + split buses complement each other. It is more than the sum of its parts.

The same question exists for Xenos + Xenon.

And in-depth tech specs are readily available for Xenos and Xenon just like they are for Cell. If anything RSX is the more unknown part due to the lack of disclosure from Sony.

edit: I don't know how legitimate these are but these are "estimated" benchies for Xenon, but here goes : http://www.anime.net/~goemon/benchmarks.html

Can anyone tell me if Xenon's performance is more predictable because of its likeness to PPC architecture?

 

Every GPU has hardware bugs RSX as well, it is difficult to get something good when you rush a project involving a high complex asic.

 

about the pixel shading capabilities of the two console, Joker454 can you confirm this (comparison with Pixel Shader 3.0, taken from the article about xenos by Dave Baumann)?

# Instruction slots
PS3 512
360 4.000
NB: MEMEXPORT" could be used to increase the length of a shader program beyond the nominal 4000 instructions.

Max # of instructions executed
PS3 65.535
360 500.000

Temp Registers
PS3 32
360 64

# constant registers
PS3 224
360 512

Dynamic Flow Control Depth
PS3 24
360 8.388.608 nesting

# of texture samplers
PS3 16
360 32

Interpolated Registers
PS3 10
360 16

could be this different capabilities the reasons that makes xenos faster in your code?

edit:
and what about other 360 features as:

excuse me for so many questions, and thank in advance if you can answer some of those (if NDA permit this)

 

We use a job based system, a job being a single task >100,000 spu cycles. A small job manager (running on the SPUs themself) simply takes job descriptor from a main memory list and allocates that job to a free SPU. Each job runs to completion, so you have a simply co-operative multitasking system. One key point is that a job can create new jobs, which allows a single SPU job to kick off a lots of other jobs, providing autonomy from the PPU.
We use the facility in the army code, an SPU job is kicked off, this does a spatial hierachy job division. Each new sub job then does a localised AI/Physics update for the soldiers inside that small part of the battlefield.
Per frame (in the army sections) we might have ~500 jobs, covering animations (DeanA the man with the details, but essentialy we batch something like 32 animation updates per job), army AI/Physics, rendering, procedural (i.e. hair & flags), frustra culling and clipping, etc.

 

Unlikely, with the Xenos you can do very important and cheap operations for free (like changing constants), not with the RSX, so you can imagine that when we try to run the same asset + same shaders on both platform the latter blows up.

 

Of course we encountered problems, we moved from PC and an early 360 version (alpha kit) to PS3. However we have the advantage of just doing whatever voodoo the PS3 requires.

However we seemed to have worked around them, without any major SPU GPU work (I personally see too much SPU time on graphics as a waste, I want the SPU to make the game better).

 

this is a very useful information, can you elaborate more about those operations and the other things related?

 

Maybe I'm wrong but vertex shader unit (in term of gflops/real performance) were not very very good. Some companies wanted to use GPU to help CPU in common tasks and don't achieve one tenth of the number given by Nvidia or ATI. So with all the power in Cell, it would very useful in games when coorectly used because :

8 vertex shader at 500 Mhz (or 550) versus 6 SPE at 3.2 GHz, that must make a difference, isn't it?

 

This is a great thread. What a breath of fresh air from System Wars at Gamespot

I have a question... I don't know if this is the appropriate question to ask or not.

Everywhere I read it says that the PS3 is crippled by the split-memory, and that developers are restricted to essentially 256MB from the GPU for textures, and that developers have a hard time with that, but what about the 256MB of system memory? Can developers go about and use that 256MB of system memory for textures, or is that not possible? Can someone clear this up, because I have not been able to find any conclusive answer(s) as to why this is such a huge problem (as said by certain people). Or is it even a problem?

 

Yes the XDR is accessible for textures…all 256MB of it…I don’t think so. There’s other things going on in PS3 (OS, code, ETC…) that requires XDR memory also.

 

from what I know RSX can't reach directly the system memory but it have to pass trought cell adding ome serious latencies

the simple scheme is

DDR3<-->RSX<--------->CELL<-->XDR

DDR3 can hardy used as main memory from the system (if it can ve used at all)

from a dev perspective the texture flow from the memory have to be constant as possible, I thought that FB and textures are mainly stored in Vram, and other textures used less often can be stored in sysram
I think this can put some serious limitations to the overall amount of critical-mission textures of the scene, but I'm not a ps3 dev plu some further limitations (I think of how hard can it be to rsx and cell to work on the same large data without duplicate this), so wait for some exact information by nAo, deanoC, joker454 and others for more educated and precise informations.

 

All systems pose a challenge, no matter how good the programmer and dev-tools are. Xbox 360 may have the advantage over PS3 as being more programmer friendly, but that doesn’t elevate it from certain bottlenecks the system has. Balance is the key…

 

I've read somewhere that the OS keeps a separate frame buffer for OS function while a game is running (32 MB in Vram), don't know if it's correct but it make sense to me
never heard a single word about code which uses Vram, can you elaborate?

Since I thought that all the custom hardware makes of the 360 a very well balanced machine, can you elaborate further, please?

 

Some have speculated that since Sony said that a game developer can create a custom OS as they wish and please -- correct me if I am wrong NT devs -- that it is potentially possible that Sony will release libraries to be stored in that "reserved for OS" SPE and allocated RAM.

Again, this is just what I hear, and take it with a grain of salt. I am not a dev.

 

Any way you PS3/360 devs. can tell us exactly how much memory is free to use on either machine? I mean how much is locked and set aside for the OS?

Concerning texturing from XDR, is the latency really anything to worry about, since there is no way you are ever going to be able to splash all 256MB on the screen in any one frame in a normal game? Won't there be plenty of time to fetch textures between frames?

 

I think that you are asking for infromation protected by NDA and they already have said more than they should in that deparment.

Are you talking about moving the textures to the VRAM? if not you have a problem with the GPU cache size, you can't fech textures for the next frame because the cache is limited.

 

Perhaps I am getting something wrong but doesn't an avg. workload of 1k operations/fragment exceed the theoretical capabilities of RSX & Xenos by a factor of at least 4 at 720p/120Hz (assuming zero overdraw)?

 

There is a technique that makes constant changes quite cheap on RSX, but discussion is not for here...

And neatly hooking up with another question, texturing (note NV also consider other things as a texture fetch) from XDR is fine. The hardware is designed to cope with it fairly well, there are some caveats but they probably only become a problem with very simple shaders.
The main problem you find, is that given up some of your precious main ram for graphics can be a hard pill to swallow.