When will they send out PS3 dev kits?

[MfA]

And graphics tasks better have some basic abstraction for task distributing available at the start (it's not exactly rocket science to do that for vertex and pixel processing), if they think people want to start handscheduling out of the box they're idiots, and then some.

I think they will still have a triangle rasterizer.

Thing is, doing parallel programming for vertex shading really isnt rocket science ... if providing programmers with the tools to instance threads of execution and synchronization and communication primitives doesnt allow them to do parallel vertex shading by their little old self the future doesnt look good for utilization of Cell. I was suggesting Sony providing the things I mentioned because really apart from that they cant help them all that much ... helping them with the stuff which isnt rocket science in the first place doesnt get them very far.

Using a single threaded game engine with a high level graphics API is nice ... but it will only result in a game with physics/AI/interactivity on the same level as we have today, only with more polygons (if we resign ourselves to approximate collision detection).

 

[marconelly!]

Lazy, thanks for the link.

For those of you who asked about the VF4:Evo improvements, IGN has a hands on impressions and have said that the image quality is greatly improved (looks like Tekken 4 in that regard, they say) and lighting and overal background details is much closer to the arcade version of the game. No pro-scan, at least in the japanese version, though.

 

[Phil]

For those of you who asked about the VF4:Evo improvements, IGN has a hands on impressions and have said that the image quality is greatly improved (looks like Tekken 4 in that regard, they say) and lighting and overal background details is much closer to the arcade version of the game. No pro-scan, at least in the japanese version, though.

Wow, thanks for that. Guess I'll better start saving...

 

[Fafalada]

Fafalada, I think your being a little harsh on the R5900 (without VU's), I'd say roughly comparible to the DC's SH4.

Yeah, probably (I guess I'm just too bitter at the small caches on the thing ), but it was to emphasize a point. If you're already using R5900, doing a few macroops with VU0 to handle transforms is hardly a stretch. Especially if you've worked with SH4 before, it's practically the same thing, aside for the few instruction set differencies.
I just don't find the whole "not using VUs at all" thing very likely. Although yeah, we could argue not using micro mode isn't really using VUs as processors at all, since relatively speaking macro mode is still wasting 50% of resources...

weird, because i thought that u pretty much have to use at least VU1 if u want to show something on screen.... of course using it properly is another matter altogether...

As mentioned, there are 3 paths to GS, all of which are used to transfer graphics data to it (and aside for target address, there's no real distinction between different types of data GS accepts, making all paths equivalent in terms of what they can transfer).

If you only used the FPU for transforms you would end up taking 12 cycles for vertex transformation - a lot slower than the VU code, but not too shabby... ( You could transform over 20M verts/second just on the CPU core in theory... )

Without perspective, and no loads/stores.
And compiler doesn't really optimize for muladds, so you'd have to write it in asm - In which case using VU0 macro would make it easier to write