PS3 network + back-compat news

[Shrike_Priest]

Are people forgetting that the PS2 has done PS1 emulation for quite a while without any specific "game-profiles" stored on a hard-drive or stuff like that?

Or is that just hype? I know Kutaragi has made some comments about the "newer PS2s" no longer used the hardware method they had in the beginning. Some PS2 dev has to know how they're doing it these days And that can't possibly be under NDA can it?

So if they can make the PSOne work on PS2, wouldn't it be logical that with a year or two of working on an emulator (They were looking for emulator-staff well before the PS3 was announced), they could have a similar thing going with PS2 emulation. Sure, there are some hurdles (mainly the almighty "VRAM-buffer" bandwidth), but I'm quite sure Sony knew the PS3 had to be backwards compatible when they made it. Basically, what I'm saying is that they've done it before, and they started designing the machine with the intent of it being able to play PS2 games. I'd be surprised if they didn't think of issues that forum posters can figure out in five minutes.

I mean, with the increased RAM, they could put everything in the VRAM, or have everything in the Cell RAM and go software only, or mirrored in both, so they wouldn't have to stream it at those speeds Now, I know that probably isn't smart for other reasons, but I just figure that's the kind of crazy stuff they could pull just to get it to work

 

[makaveli87]

http://www.watch.impress.co.jp/game/docs/20060426/3dhd.htm

scroll down to the first chart. Impress Watch seems to think rsx has the same transistor count as the g71.

 

[Qroach]

Are people forgetting that the PS2 has done PS1 emulation for quite a while without any specific "game-profiles" stored on a hard-drive or stuff like that?

PS2 is NOT emulating PSone. Everything was done in hardware essentially on one chip.

 

[Fafalada]

PS2 is NOT emulating PSone. Everything was done in hardware essentially on one chip.

Not quite right.
For one, it's at least 3 chips (DRam + SPU2 + IOP), and second, there are parts emulated on EE (mostly pertaining to converting PS1 display lists to GS format, and rendering them).
They took the safe route though - no shenanigans with trying to guess each title VRam layout and upscaling it(though it would certainly be possible, at cost of some compatibility - GS has enough VRam to do this).

Of course in the latest revisions of PS2, IOP itself is emulated by another chip, which leaves only the SPU as far as legacy hardware goes.

Yeah, I read that it was due to the EDRAM only being 10MB, and to take advantage of tiling, the software had to be written from the start to do so. Obviously, no XBox titles would be doing that...

Well adding AA already requires emulator to have knowledge specific to each title so...

The bandwidth saving/campression techniques will help, sure, but if you have a game with mad alpha blending or some of the more interesting PS2 framebuffer effects one has to wonder if that is enough.

IMO, FB effects aren't going to be a big problem - but standard rendering will. There's a ton of virtually free operations (render target switch, context/state switches, cache flush etc.) on GS that have massive performance penalties on PC GPUs.
On PS2 - couple hundred render target switches per frame aren't uncommon - on PC something like that can reduce rendering performance by an order of magnitude.

Anyone with more indepth emulation architecture knowledge feel free to correct me - but I just don't see how emulator could work around those, without title-specific data (aka game profiles).

 

[[maven]]

Are people forgetting that the PS2 has done PS1 emulation for quite a while without any specific "game-profiles" stored on a hard-drive or stuff like that?

Bzzt. Wrong. Remember what the PS2 "Independence" exploit operated upon? The emulation profiles of PS1 games... http://en.wikipedia.org/wiki/PS2_Independence_Exploit

 

[London Geezer]

Are people forgetting that the PS2 has done PS1 emulation for quite a while without any specific "game-profiles" stored on a hard-drive or stuff like that?

Of course, PS2 has the PS1 chipset as a I/O chip, so of course BC is good! That's the whole point of this thread! No one knows if there will be PS2 hardware in PS3, or if it will all be done in software, and we're speculating on this...

Didn't you read the thread?

EDIT: Oh, I'm a bit late with this post aren't I...

 

[Shifty Geezer]

IMO, FB effects aren't going to be a big problem - but standard rendering will. There's a ton of virtually free operations (render target switch, context/state switches, cache flush etc.) on GS that have massive performance penalties on PC GPUs.
On PS2 - couple hundred render target switches per frame aren't uncommon - on PC something like that can reduce rendering performance by an order of magnitude.

Wouldn't this be good reason to stick the GS logic onto RSX? If Kutaragi is hoeenst about adding a hardware level BC solution, this sounds to me the likely approach, with Cell handling EE, VU0 and 1, and that side of things.

 

[London Geezer]

Wouldn't this be good reason to stick the GS logic onto RSX? If Kutaragi is hoeenst about adding a hardware level BC solution, this sounds to me the likely approach, with Cell handling EE, VU0 and 1, and that side of things.

I thought all those "free operations" you get on the GS are free because the EDRAM is there, not just because the GS can.

If anything, i was thinking that the RSX might need the EDRAM more than the logic of GS, as the logic can be emulated on the RSX pipes, but the benefits of EDRAM can't. Could be totally wrong of course.

 

[Mintmaster]

One suggestion is just using compression. PS2 didn't have texture compression, so with 4:1 RSX has 80 GB/s available relative to PS2 textures.

I mentioned this in the eDRAM thread, but I figured it's pertinant here. Texture bandwidth isn't really the problem. From what I found, the 48 GB/s of PS2 is divided up as 19.2 GB/s FB read, 19.2 GB/s FB write, and 9.6 GB/s texture. You can compress the Z without loss and texture with reduced quality, but there's nothing you can do about colour. The other problem is that whenever you texture from something you've rendered (for post processing, dynamic environment maps, reflections, etc), you can't compress it. Granted, most of the time PS2 won't saturate the bandwidth it has available, but is "most" good enough for BC? Maybe.

IMO, FB effects aren't going to be a big problem - but standard rendering will. There's a ton of virtually free operations (render target switch, context/state switches, cache flush etc.) on GS that have massive performance penalties on PC GPUs.
On PS2 - couple hundred render target switches per frame aren't uncommon - on PC something like that can reduce rendering performance by an order of magnitude.

When I mentioned this to nAo he said that consoles are very different in their overhead. I don't know if this is a hardware or software/API issue on the PC, nor how fast they are on RSX, but a couple hundred per frame isn't a deal breaker. Even if you took 10,000 cycles to do a render target switch, it should only eat away 10-20% in the worst case.

The way I see it is that if the odd PS2 title is a bit slow on PS3 due to the way it's coded, no big deal.

 

[PeterT]

You can compress the Z without loss and texture with reduced quality, but there's nothing you can do about colour. The other problem is that whenever you texture from something you've rendered (for post processing, dynamic environment maps, reflections, etc), you can't compress it.

Exactly, that's why Fafalada's "IMO, FB effects aren't going to be a big problem" surprises me greatly. But if he says so, I'm inclined to believe it

 

[Shrike_Priest]

Bzzt. Wrong. Remember what the PS2 "Independence" exploit operated upon? The emulation profiles of PS1 games... http://en.wikipedia.org/wiki/PS2_Independence_Exploit

Fair enough, my bad. Never heard of said exploit. But my point still remains, if they can make profiles and have a good 90% compatibility with the PS2 (sans HDD), why couldn't they do the same for PS3?

Sure, they might need some piece of legacy hardware at first, but does it have to be that much? And the PSOne playback should be just a matter of porting the PS2's emulator to PS3.

And for those correcting me with the I/O chip (I'm looking at you london-boy ), I was referring to this comment by Kutaragi:

"PSone runs on the PlayStation 2 through emulation rather than actual hardware. PlayStation 3 will offer the same compatibility for PS2 software and the format will continue forever," he explained."

http://www.gamesindustry.biz/content_page.php?section_name=pub&aid=2171

Which to me sounds like they aren't using the same method.

Now, I never claimed to be 100% certain here (if you'll read my post you'll see that quite clearly in the second paragraph), since Kutaragi's comments are known to be quite loose, but I was pointing out that if he is telling the truth here, then they've already solved BC through emulation once, and could probably do it again if they put some effort into it.

But I guess Kutaragi was blowing smoke as usual? Or was it mistranslated? Or is it "almost" true? Fafalada's post made it seem like most of it was handled on the PS2 hardware these days.

 

[Fox5]

Not quite right.
For one, it's at least 3 chips (DRam + SPU2 + IOP), and second, there are parts emulated on EE (mostly pertaining to converting PS1 display lists to GS format, and rendering them).
They took the safe route though - no shenanigans with trying to guess each title VRam layout and upscaling it(though it would certainly be possible, at cost of some compatibility - GS has enough VRam to do this).

Of course in the latest revisions of PS2, IOP itself is emulated by another chip, which leaves only the SPU as far as legacy hardware goes.

Well adding AA already requires emulator to have knowledge specific to each title so...


IMO, FB effects aren't going to be a big problem - but standard rendering will. There's a ton of virtually free operations (render target switch, context/state switches, cache flush etc.) on GS that have massive performance penalties on PC GPUs.
On PS2 - couple hundred render target switches per frame aren't uncommon - on PC something like that can reduce rendering performance by an order of magnitude.

Anyone with more indepth emulation architecture knowledge feel free to correct me - but I just don't see how emulator could work around those, without title-specific data (aka game profiles).

Wait, the IOP is emulated? Wasn't it supposed to be available for PS2 games to use as well?
Oh, and I think generic pixel shader math could probably replace a lot of the framebuffer effects. I would like to point to the Humus(?) fix for ATI cards and Doom 3, but I guess that was kind of app specific, and I think replaced texture lookups anyway. Even still, current PSX and N64 emulators pull off non-specific pixel shader replacements of framebuffer effects. That or Sony could just lower the quality of the framebuffer effects, halve the resolutions or updates.