New dev tools ? PlayStation 3 Edge

[archangelmorph]

I remember an interview with Robin Saxby (ARM) a few years ago and he kept saying "hardware is always done before the software".

I know what you mean though. MS have an seemingly equally complex box and had the tools ready.

Mind you, MS are a software company and (you could argue) Sony aren't - (I'm not sure where I stand on that!) and with the same logic you could start comparing supposed hw failure rates.

Well Sony own SN systems so in effect they kind of are too..

 

[slider]

Well Sony own SN systems so in effect they kind of are too..

Yeah I agree, undoubtedly lots of software. I tried to make sure I put in enough caveats in my post.

I guess I kind of meant the layman's perception of the two companies.

 

[Shifty Geezer]

Sony's history is not software, though they are expanding their software side. And rightly so, because that's probably more important than anything else these days. iPod got where it did as much due to the software side as anything. It's the software that users interface with, and no amount of hardware whizz-bang can make that a good or bad experience.

 

[rounin]

Sony's history is not software, though they are expanding their software side. And rightly so, because that's probably more important than anything else these days. iPod got where it did as much due to the software side as anything. It's the software that users interface with, and no amount of hardware whizz-bang can make that a good or bad experience.

While I agree that software is important, playing down the hardware side isn't very wise either. I'm sure PS3 owners appreciate their relatively headache and worry free hardware experience in terms of console failures

 

[archangelmorph]

While I agree that software is important, playing down the hardware side isn't very wise either. I'm sure PS3 owners appreciate their relatively headache and worry free hardware experience in terms of console failures

They'd bloody have to when they paid £425 pounds for it..!!

 

[Butta]

Can we get back on topic? For those that are making use of Edge what are the results?.. in the case of Joker454, jonabbey had the following question

How far behind do you find RSX to be at a similar 3 mil polygon workload? Is the issue primarily the vertex setup?

 

[Shifty Geezer]

Can we get back on topic?...in the case of Joker454, jonabbey had the following question

That's an RSX question and not an Edge question

 

[Butta]

Did you read Joker's post?

My post in that older thread was referring to the geometry of just one particular subsystem not the entire scene, hence the smaller number. A typical frame in our game will have 3+ million verticies in total. You need to optimize your shaders to get 60+fps with that much geometry, but you don't need to use the cpu to do it on 360. Alot of the stuff in Edge (backface culling, skinning, zero area triangle culling, zero pixel triangle culling, etc) are not necessary on 360, just feed everything to the gpu and it will happily rip thru them. I tried doing cpu skinning on the 360 for the hell of it, and the gains were negligible.

Our next years PS3 title will use Edge ideas, but not Edge itself. Being multiplatform, it's easier to just take the pieces we need from Edge and implement them in our framework ourselves. Using GCMHud and GCMReplay we've been able to get some estimates and it looks promising so far!

 

[joker454]

The way he describes it, it sounds really impressive. I wonder how long it will take before we will see games from third party developers benefiting from these tools: 6 months, 1 year?

GCMReplay is very impressive. In some ways it's even better than Pix, which is great since this will now put pressure on Microsoft to improve their tools. Gotta love competition It's a little buggy (crashes sometimes) but still very usefull in it's current state today.

I don't think you'll need to wait very long to see PS3 games benefit from it. Internally, we're all benefiting from it today. On retail shelves, it won't take very long, certainly less than a year.

What I wonder now is why they couldn't offer GCMReplay before the PS3 launch especially since RSX is not an abnormal GPU.

I've got two theories. First, maybe they didn't foresee Microsoft having a tool as powerful as Pix ready from day one. Development of GCMReplay started 'relatively' late (my old office mate was hired by Naughty Dog specifically to make it) so it did seem to me as though they kinda realized one day that they need a tool like that and they need it asap. Or, maybe it was due to a bit of complacency. In other words, they figured they would be the major player again in this generation (like they were with the PS2) so they didn't have as urgent a need to make that kind of tool. Either way, I definitely feel the existence of Pix along with good sales of the 360 very much helped indirectly create GCMReplay. But thats just my take.

 

[Shifty Geezer]

Did you read Joker's post?

Sure, but...
How far behind do you find RSX to be at a similar 3 mil polygon workload? Is the issue primarily the vertex setup?
...isn't a question about Edge, but a question about RSX's polygon limitations. These were talked about in past RSX threads.

Regarding Edge, have any devs here had a good look at PSSG (or whatever it's called!)? Is this the same thing as the Edge graphics libs?

 

[Butta]

How far behind do you find RSX to be at a similar 3 mil polygon workload? Is the issue primarily the vertex setup?[/I]
...isn't a question about Edge, but a question about RSX's polygon limitations. These were talked about in past RSX threads.

Yeah, you're right... I guess the way I was reading it is can RSX match the 3 mil poly workload regardless of what method is used (i.e. culling and others using Edge). In other words can the "PS3" as a system match that workload?

 

[Shifty Geezer]

Yeah, you're right... I guess the way I was reading it is can RSX match the 3 mil poly workload regardless of what method is used (i.e. culling and others using Edge). In other words can the "PS3" as a system match that workload?

This came up in a thread somewhere earlier (may even have been this one!). The vertex rates seemed comparable, with Cell helping RSX where Xenos goes it alone. Wasn't there a 3 million triangle figure for the Getaway Edge demo, 50 cars+700 peeps?

 

[Butta]

Yeah but... can a demo really be compared to a game? What would the SPU usage be like in a demo whose only purpose is to show alot of geometry compared to a full-on game with physics, music, collisions, AI, etc... all sucking away potential SPU resources

 

[Jesus2006]

This came up in a thread somewhere earlier (may even have been this one!). The vertex rates seemed comparable, with Cell helping RSX where Xenos goes it alone.

Looking at FM2, i wonder what exactly Xenos "does alone" since a whole Xenon core is dedicated to rendering on that engine (and it doesn't look too good to be honest)?

 

[Shifty Geezer]

You can't judge a platform by a single game. MotorStorm is entirely on RSX (thanks to the B3D Evo interview for this nugget!). And who knows what Untold Legends is doing, other than if you go by that one title, PS3 can't do dynamic lighting!

 

[Heinrich4]

My post in that older thread was referring to the geometry of just one particular subsystem not the entire scene, hence the smaller number. A typical frame in our game will have 3+ million verticies in total. You need to optimize your shaders to get 60+fps with that much geometry, but you don't need to use the cpu to do it on 360. Alot of the stuff in Edge (backface culling, skinning, zero area triangle culling, zero pixel triangle culling, etc) are not necessary on 360, just feed everything to the gpu and it will happily rip thru them. I tried doing cpu skinning on the 360 for the hell of it, and the gains were negligible.

Our next years PS3 title will use Edge ideas, but not Edge itself. Being multiplatform, it's easier to just take the pieces we need from Edge and implement them in our framework ourselves. Using GCMHud and GCMReplay we've been able to get some estimates and it looks promising so far!

thanks a lot for the information and impressions Joker454.

 

[joebloggs]

On the whole RSX vertex issue Cpiasminc from PSINext (known as Shootmymonkey here) made a pretty detailed and well explained post that I thought was worth re-iterating here:

Originally Posted by mokmok
1. The Xenos Vertex Performance is up to 6x greater than the RSX's.

So I've talked about this one a few times before, but it is a flat-out absurdity in the sense that it ignores all other limitations of the respective hardware. So the assumption is that the smallest possible vertex shader is 4 dot products (basically, transform the vertex). And since you've got 8 vertex shader pipes in RSX, and 8/4 = 2 * 500 MHz = 1 billion verts.
On Xenos, you've got 48 ALUs which if you assume are all dedicated to vertex processing (this is actually impossible, but for the sake of theory we'll ignore that), you get 48/4 = 12 * 500 MHz = 6 billion verts.

Sounds that way, but unfortunately, it's completely untrue. The thing is vertices do not get moved in at unlimited speed. You can only move vertex attributes at a fixed number of attributes per clock cycle, and that means in 99% of all *major* render passes, that a single vertex takes more than one clock cycle to get in. So no matter what, it doesn't matter how much you can theoretically process because the data doesn't move through the system fast enough. The real theoretical advantage is still there for Xenos, but it is by no means 6:1. In reality, they both suck pretty bad. RSX simply sucks a little worse.

In the end, Xenos can only set up one triangle per cycle, while RSX can set up 1 every two cycles. It should be noted, though, that because of things like a post-transform cache, if you're smart, you can actually exceed the theoretical limits. And since RSX's post-transform cache is about 8x larger than Xenos', it has more potential for gain. To be fair, though, RSX needs it far more badly than Xenos does. The vertex attribute read rate on RSX is incredibly god-awful, but it's not an insurmountable wall. Xenos simply hits fewer internal limits.

BTW, about the 6 billion verts figure... that kinda ignores a little detail. This may come as a shock to a lot of people, but vertices consist of this thing called DATA. If you take a pretty average-sized vertex, 6 billion vertices per second requires more than double the bandwidth than the entire Xbox360 has... and that's including the totally internal busses which don't actually connect any two separate devices (you know how people like to pretend the the 256 GB/sec on the eDRAM die can be treated like a point-to-point link). You want to move that much data over a main memory bus (which is the real bus of concern for this purpose), that's not going to happen within the next 3 or 4 console generations. Memory architectures simply don't grow that quickly. Currently you can't move 6 billion of even the smallest possible vert (per second) over the main memory bus, and I don't see that happening on Xbox720 or PS4 either.

2. The use of the Edge Tools and SPEs brings the Vertex Performance of the PS3 on par with the 360 but prevents the SPEs from being used for Physics, AI etc.

They're kind of assuming a lot of things because the demos, which were meant for a technical audience, used all the available SPEs in order to demonstrate the concept and showcase techniques that can keep all the SPEs busy. If you actually did it like that in a real game, yeah, you'd certainly tie up all the SPEs for that period of time within the frame. Something that I think nobody outside the industry actually realizes is that the CPU side of rendering does NOT take up a huge portion of the time between frames. Physics, AI, etc. take up much more time than rendering. It's a little hard to see that with the PC as a reference point, of course, because Windows and the API layer robs you of so much.

That aside, the point of Edge is not to fill up all the SPEs. You certainly don't NEED to use more than 1 or 2 SPEs in order to get a huge gain out of it. More importantly, while Edge was specific to graphics, a lot of the same principles can be applied to physics (Havok's tech talks demonstrated that quite handily and nobody talks of Havok precluding the use of Edge) and AI and so on.

Just looking at the raw specs of the Xenos GPU it does seem to have a Vertex processing advantage.

For all you might say about the dynamic allocation of vertex pipes, you end up limited by a lot more external things than anything internal to the GPU. Also, no matter what, on major passes, you're going to end up spending more effort on pixels anyway, and RSX has a moderate advantage over Xenos in that area. All the same, getting a billion triangles per second to the GPU in the first place is basically impossible. It doesn't matter how much power the GPU has to work with them because it can't get to that point. In general, the challenge in getting 100-150 million tris per second moved through the pipe is hard enough whether you're on PS3 or 360, and it's not the GPU itself that's the problem.

I look back at how things looked when the 360 was still a little while shy of release, and back then, the notion of even drawing a scene of up to 750,000 polygons per frame at 30 fps was looking pretty much impossible to almost every developer out there. Nowadays we talk of nearly double that pretty freely. It's certainly not because the GPU suddenly got more powerful or we learned how to dedicate more ALUs to vertex processing. It's because we're doing better on the *CPU* side that we're able to keep that push buffer pushing more often.

My understanding is that pixel shaders are mainly used for bump mapping etc. whereas Vertex shader are used to render complex lighting effects etc.

Vertex shaders are simply for things you would do that operate at the level of a single vertex (transformation, positioning, and more often than not, setting up data for the pixel shaders to use). Pixel shaders are for things you would do at the level of a single pixel (all texturing, all lighting, etc). On hardware prior to programmable shaders, of course, you'd probably do just about everything at the vertex level because that's what you have available to manipulate both at the hardware and software level.

LINK

 

[ShootMyMonkey]

Hm. That thread actually went on for a while, and gets into further stuff down the line of the thread (the site itself seems to be chugging at the moment, but the thread itself is at -- http://forums.e-mpire.com/showthread.php?t=73148). It was a little difficult to leave out certain... "play-it-safe-by-not-mentioning"... details.

BTW, there were moments I was being condescending mainly because the OP mentioned NeoGAF, which never really struck me as a great tome of meaningful exchange of thoughts in spite of the few people who represent extreme exceptions to the rule. Though it seems it was edited to include B3D as a source.

 

[betan]

Hm. That thread actually went on for a while, and gets into further stuff down the line of the thread (the site itself seems to be chugging at the moment, but the thread itself is at -- http://forums.e-mpire.com/showthread.php?t=73148). It was a little difficult to leave out certain... "play-it-safe-by-not-mentioning"... details.

Thanks for the info.
I am curious though, at some point you mention explicit triangle culling being provably impossible (I assume you mean in realtime).
Is there a reference for this?

I would think even naive stuff like a special low resolution software z-buffer rendering could be used for culling.

 

[ShootMyMonkey]

Thanks for the info.
I am curious though, at some point you mention explicit triangle culling being provably impossible (I assume you mean in realtime).
Is there a reference for this?

I would think even naive stuff like a special low resolution software z-buffer rendering could be used for culling.

Convenient timing. Someone was mentioning a similar question about raytracing recently posted to that thread, and I was about to respond to that.

What I was referring to was that occlusion/visibility culling is one of those things that the only really generic solution is the exhaustive brute force search. For the case of visibility, that's basically raycasting/raytracing through the scene to every conceivable point. In practice, you downsample the infinite space to a finite number of pixels. The Z-Prepass culling is essentially equivalent to raycasting and storing the distance of the first hit.

I was strictly referring to a closed solution that could totally be done with the raw numerical representation of the geometry before ever shipping anything down to the GPU.