How Do You Suppose PS3 Will Provide Backwards Compatible

[Mefisutoferesu]

OK, in a most likely vain attempt to save this thread from Vysez's big locking stick... how do you suppose PS3 will provide BC?

I'm thinking PS1 will be entirely software emulation. As some have said, considering how compatible 3rd party PS1 emus are, I imagine Sony could do a rather excellent job. Especially if they've been working on it since the PS2 launch in preparation of PS3.

As to PS2... I'm thinking the EE should be relatively easy to emulate on CELL, PPE is the main core and VU1 and VU0 are just pushed onto SPE 0 and 1 (or does the number start at 1??). Yes, it's complicated, I'm not saying it's easy, but it seems like a natural progression, no? That said I think the GS will probably be full blown added to the RSX, it's only some 35 million, transistors and what with the phantom transistors on the G70 and the possible close relation, it seems probable.

That said, I'm actually kinda hoping they just put the eDram on the RSX and emulate the rest. That way it should be relatively easy to add AA and AF to PS2 games, or so I hope, and I'm hoping a LOT.

Also, on an interesting note if the RSx turns out to be very generic as many would assume, do you think part of the reason is future compatability?? Make it easy for PS4 to support PS3 and PS2 and PS1... oh goodness!! :)

[pcostabel]

OK, in a most likely vain attempt to save this thread from Vysez's big locking stick... how do you suppose PS3 will provide BC?

I'm thinking PS1 will be entirely software emulation. As some have said, considering how compatible 3rd party PS1 emus are, I imagine Sony could do a rather excellent job. Especially if they've been working on it since the PS2 launch in preparation of PS3.

As to PS2... I'm thinking the EE should be relatively easy to emulate on CELL, PPE is the main core and VU1 and VU0 are just pushed onto SPE 0 and 1 (or does the number start at 1??). Yes, it's complicated, I'm not saying it's easy, but it seems like a natural progression, no? That said I think the GS will probably be full blown added to the RSX, it's only some 35 million, transistors and what with the phantom transistors on the G70 and the possible close relation, it seems probable.


Hmm, I rather think they will take an approach similar to PS2 emulation. Emulating a MIPS on the PPE could be feasible, but quite slow, especially considering all the timing issues with the VIF/GIF etc. OTOH, the gs is a very simple rasterizer: the RSX will have no problem emulating it and adding enhancements like AA and higher res, just like PS1 games are enhanched when emulated on PS2. It is easier for Sony to add a stripped down EE in hardware than deal with the nightmare of a software emulation.

[Mefisutoferesu]

That makes a good bit of sense, but is it viable to do CPUs in Hardware and GPUs in software? I imagine that would add to the pricing no? More over if Sony want's to maintain BC on down through the PS generations it's gonna be a problem no? Or will it just happen in PS4 when emulation will be a snap even if it's dog slow? Anyway, how much would having the additional CPUs add to the PS3s cost? I can't imagine it's prohibitive, but I doubt its free.

[Almasy]

I´m only talking out of my ass here, but I´d say we probably will only see hardware from two generations in a closed box. Say, PS5 will only have PS4 hardware to help emulation, the rest of the systems will be emulated through software (Afterall, it should be powerfull enough). I´d say it´s much more likely to see GS emulated through the RSX and just toss the MIPS core in there.

I don´t know how it´d run, and I think the vector units could be emulated quite well through the SPU´s, but I don´t know how much work it´d take to emulate the MIPS core on the PPC core.

[Farid]

OK, in a most likely vain attempt to save this thread from Vysez's big locking stick...
Nice try, but the thread is going to be hit no matter what. :wink:

But since I don't want to stop this new discussion, I just split the thread into a new, and I hope meaningful, discussion.

So, here we go, this thread is about speculating about what methods the PS3 will use to provide BC.

[Arty]

So, here we go, this thread is about speculating about what methods the PS3 will use to provide BC.
Could you please modify the title of this thread to reflect that. :)

[Reznor007]

I´m only talking out of my ass here, but I´d say we probably will only see hardware from two generations in a closed box. Say, PS5 will only have PS4 hardware to help emulation, the rest of the systems will be emulated through software (Afterall, it should be powerfull enough). I´d say it´s much more likely to see GS emulated through the RSX and just toss the MIPS core in there.

I don´t know how it´d run, and I think the vector units could be emulated quite well through the SPU´s, but I don´t know how much work it´d take to emulate the MIPS core on the PPC core.

Based on current PC PS2 emulators using dynamic recompilation CPU cores, I'd say it would be tight, considering that splitting the emulation of the MIPS and VU's over the PPE and SPE's wouldn't really be practical. Ask any of the MAME developers about using dual core Athlon's/P4's and they will say any gains you get would be taken back from time to sync everything. Also, it isn't really possible to split the emulation of the single MIPS core over multiple processors, and that's where a good portion of the time is spent. I also don't know if an individual SPE has enough power to emulate a VU though...it would certainly outperform one, but emulating is completely different from just running its software.

Here's a post about someone running Kingdom Hearts on the most compatible PS2 emulator available, getting 25 minutes of gameplay in 5 hours of time. http://www.ngemu.com/index.php?action=post&id=1909

Semi-related, MAME emulating San Francisco Rush is extremely slow. The system is only a 200MHz R5000 and a 33MHz TMS32031 for sound, but even without emulating the Voodoo graphics hardware the game only runs about 10-15% speed on the fastest CPU's around. This is using dynarec CPU cores for the MIPS also.

[Bohdy]

The MIPS core could be feasibly emulated on the PPU I think, as it is not terribly fast with a fairly low instructional thoroughput (afaik). The VU code could be dynamically recompiled and easily handled by the SPE's as they are SIMD units anyway, and thereby lend themselves to paralleling.

What is more salient to me (at least) is how MS is managing to emulate the Xbox in real time. Sure they have licensed the NV2A hardware for the GPU side of things, but emulating the 700mhz P3 must be a nightmare with multiple cores providing seemingly little benefit. My best guess as to how they are doing it given the info availible is through some form of static recompilation. I have done some research on the topic in the past, but it is a rather infrequently used method of emulation despite the huge speed gains. Often each program's execution path needs to be individually traced to make sure that conditional jump targets are all recompiled, which would explain the "emulation profiles".

[Farid]

Could you please modify the title of this thread to reflect that. :)
Done! :grin:

I changed it the first time, but I forgot to move pcostabel's post from the other, ill-fated, thread. So, I when I move it, the mege function changed the thread title again.

[lip2lip]

I am hoping that 512 kB cache on main core will be enough to hold instruction set conversion tables, this is probably only thing that could stop software emulation, but may not be an issue because of high dedicated ram bandwidth. because of high frequency of spes, they should be able to emulate timing of vu0, vu1. I am surprised no one mentioned, usually biggest burner in chip emulation is branch prediction logic; but as I understand it, branch prediction in new chips is long enough to not notice any differences.

[jvd]

I believe its all going to be emulation . I don't see them sticking in any bit of the ps2 in there . Its 6or 7 years old and I'm sure for whatever they could think of using it for (the ee for sound) could better be used by a dedicated newly designed chip .

[one]

(Since I was late to the original thread...) This is from PS Meeting in the last month. It's from day 1
http://ps3media.ign.com/ps3/image/article/636/636028/ps-meeting-2005-fun-with-slides-part-iii-20050722101609165.jpg

[BlueTsunami]

(Since I was late to the original thread...) This is from PS Meeting in the last month. It's from day 1

Well...theres the picture. From day 1.

Also about the emulation. I believe Sony will probably put some type of lecacy PS2 hardware in the PS3 (what exactly I don't know) to help with the emulation of PS2 games. As far as PSX..I believe the PS3 is more than capable to have the emulation software run purely on software (without the help of specific hardware for the PSX).

[Arty]

(Since I was late to the original thread...) This is from PS Meeting in the last month. It's from day 1
How does that contribute to this thread :?:

How do you think BC is possible on PS3, that is the question. ;)

[MasaC]

<a href="http://ps3media.ign.com/ps3/image/article/636/636028/ps-meeting-2005-fun-with-slides-part-iii-20050722101609165.jpg" target="_blank">Backward compatibility from day one</a> will be achieved through a combination of hardware and software <a href="http://hardware.gamespot.com/Story-ST-15015-2097-4-4-x" target="_blank">according to Ken Kutaragi</a>.

The details of how this will work have yet to be announced but if PS2 b/c is anything to go by, there will be some PS2 hardware inside the PS3. On the PS2 there is a PS1-cpu that doubles as an i/o-chip that handles the USB- and firewire-ports.

It's possible that there will be the EE+GS-chip that's used in the PSTwo to double as an i/o-chip on the PS3, perhaps shrunk to a smaller process. If this is the case I'd expect PS1-emulation will be done entirely in software on the cell.

Maybe the PC-leagcy logic on PS3-variant of the G70 will be replaced with PS2-legacy logic. I don't know if this is possible at all, though.

[Phil]

Hmm, I rather think they will take an approach similar to PS2 emulation. Emulating a MIPS on the PPE could be feasible, but quite slow, especially considering all the timing issues with the VIF/GIF etc. OTOH, the gs is a very simple rasterizer: the RSX will have no problem emulating it and adding enhancements like AA and higher res, just like PS1 games are enhanched when emulated on PS2. It is easier for Sony to add a stripped down EE in hardware than deal with the nightmare of a software emulation.

That sounds very feasable IMO. The only thing I'm wondering is how RSX is supposed to be emulating the eDRAM and its high bandwidth... wouldn't CELL technically have more (internal) bandwidth available that would help with the emulation of the eDRAM memory?


BTW; One, best of thanks for providing that picture. That should certainly put the other discussion to rest for good. :smile:

[Shifty Geezer]

The combined EE+GS definitely won't appear on a smaller process as it's already at 90nm and if Sony could use 65nm, they'd be using that for Cell! I doubt EE+GS will feature at all. The hardware aspect will be, I guess, some hardware emulation that maps some PS2 functions onto the PS3 hardware. The EE+VUs will probably be emulated on Cell, and GS emulated on PSX. Though as the Cell can seemingly handle in software graphics beyond PS2's capabilities maybe the bulk of emulation is in the Cell? The biggest concern has to be the 48 GB/s GS eDRAM and how they could tackle the fillrate, but as has been mentioned by others smarter than me, use of compression could alleviate brute-force BW requirements.

[london-boy]

The combined EE+GS definitely won't appear on a smaller process as it's already at 90nm and if Sony could use 65nm, they'd be using that for Cell!

Now, i'm only saying this, not expecting it to happen, but just for the sake of argument, don't you think a tiny little chip with about 40M trannies would be MUCH easier to fab on a new process like 65nm than Cell?
If anything, they might want to try their new 65nm process on something "easy" like the EE+GS, not on a big and complicated chip like Cell. So it would make sense if EE+GS were on 65nm and Cell stayed at 90nm for the time being.
Having said that, i find it very unlikely that they'll put EE+GS in there.

[Shifty Geezer]

Perhaps you are right, and they'll move PS2 production over to 65nm as well to make that more profitable, while keeping Cell at 90nm. Would it not be considerably more expensive though (several dollars per unit) to include PS2 in PS3 than emulate with some RSX extras for aid? Even with a process shrink. How much does the existing EE+GS chip cost, and how much would a process shrink save on that?

[Squeak]

That sounds very feasible IMO. The only thing I'm wondering is how RSX is supposed to be emulating the eDRAM and its high bandwidth...
If RSXs framebuffer compression is good enough to give the equivalent of 48Gb/s bandwidth, what does that tell us about the 32Gb/s EDRAM in Xenos? Is it silicon well spend, or would it have been better to but some (less area consuming) bandwidth saving logic on the main die?

[Phil]

^^ Yeah, I did think about compression, but what about latency :?:

[Shifty Geezer]

what does that tell us about the 32Gb/s EDRAM in Xenos?1.) That's BW TO the eDRAM. Internally, for the work it does, it's got 256 GB/s. PS2's 48 GB/s BW isn't enough for what Xenos has to do next-gen. 2.) That's so totally off topic :shock: . I'll pretend I didn't reply and I'm really talking about PS3's BC solution, which I believe uses magic, perhaps small gremlins and fairies.

[Squeak]

1.) That's BW TO the eDRAM. Internally, for the work it does, it's got 256 GB/s. PS2's 48 GB/s BW isn't enough for what Xenos has to do next-gen. 2.)
But that's "only" for AA and stencil. AFAICS 10Mb is just enough for Z and backbuffer, so If you want to do alpha blending or render to texture, you have to go through system memory or bus to VPU.

[Shifty Geezer]

If you want to continue this discussion you'd best take it to another thread.

[Fafalada]

OTOH, the gs is a very simple rasterizer: the RSX will have no problem emulating it and adding enhancements like AA and higher res
I disagree, simple though GS may be, the way it gets used in games is not simple to emulate at all. Unless RSX comes with certain GS extensions (in regards to address modes), this is very much in question whether it's possible to do fast enough.
As for AA/resolution enhancements - unless Sony follows up on MS idea of game profiles, forget about it, it's just not going to happen.


If RSXs framebuffer compression is good enough to give the equivalent of 48Gb/s bandwidth, what does that tell us about the 32Gb/s EDRAM in Xenos? Is it silicon well spend, or would it have been better to but some (less area consuming) bandwidth saving logic on the main die?
You don't need to think of it in such brute force manner - SDTV framebuffers are relatively small and the better optimized the game, the more closely it follows page buffer coherency.

IMO something around 128KB renderbuffer cache would trivially serve bandwith requirements of typical GS rendering patterns 90% of the time, even with much slower external memory then what RSX has available. And regular texture bandwith is a non-issue alltogether.

However, IMO there's two real problems with GS emulation.
One is that you need to emulate its addressing schemes in detail - majority of effects in PS2 games are coded around specific behaviour of memory accesses and addressing, you'll not get away with any kind of HLE for that.
The other problem is the few cases of games that ping-pong between texture&render buffer a lot (sometimes on every rendered primitive, using same memory addresses for texture and render buffer) - which will kill bandwith on any GPU without unified eDram (meaning Xenos like setup would be useless to assist this also). The only way I see around this issue is hoping that the emulation of the rest of rendering would be faster then real GS by a large enough amount to compensate for the slower rendering whenever this kind of rendering packets are encountered over course of a frame.

Anyway, one thing I'm certain about is that if they ended up sticking a full GS chip in there, it will NOT be part of RSX die.


What is more salient to me (at least) is how MS is managing to emulate the Xbox in real time. Sure they have licensed the NV2A hardware for the GPU side of things, but emulating the 700mhz P3 must be a nightmare with multiple cores providing seemingly little benefit.
Are they actually going to use NV2A hardware in there? I was under impression that it'll be some sort of highlevel emulation, so basically whenever a game does lowlevel stuff that isn't quite within DX spec, they'll code it into one of those game profiles (hence the initial low compatibility rate).

The P3 emulation is an interesting question though, if they were really sticking with static recompiles then you could well be looking at separate "emulation profile" for each game - which at least to me would sound like there'll never be anything close to full library compatibility.

[pcostabel]

I disagree, simple though GS may be, the way it gets used in games is not simple to emulate at all. Unless RSX comes with certain GS extensions (in regards to address modes), this is very much in question whether it's possible to do fast enough.


I know, but a simple hardware address decoder should take care of that. I don't think you'd need to put the whole GS+4MB VRAM in there.


As for AA/resolution enhancements - unless Sony follows up on MS idea of game profiles, forget about it, it's just not going to happen.


Why not? The enhancements on PS2 can be switched on or off by the user, there is no need to have game profiles. Scaling everything to 1080p shoul be pretty much transparent to the game, and so should be FSAA.


However, IMO there's two real problems with GS emulation.
One is that you need to emulate its addressing schemes in detail - majority of effects in PS2 games are coded around specific behaviour of memory accesses and addressing, you'll not get away with any kind of HLE for that.


I agree, this will probably need some hardware support.


The other problem is the few cases of games that ping-pong between texture&render buffer a lot (sometimes on every rendered primitive, using same memory addresses for texture and render buffer) - which will kill bandwith on any GPU without unified eDram (meaning Xenos like setup would be useless to assist this also). The only way I see around this issue is hoping that the emulation of the rest of rendering would be faster then real GS by a large enough amount to compensate for the slower rendering whenever this kind of rendering packets are encountered over course of a frame.


Not sure I follow. Why would rendering to texture kill bandwidth? I'm not familiar with nVidia architecture, but why would it matter if you render to a texture or to the frame buffer?


The P3 emulation is an interesting question though, if they were really sticking with static recompiles then you could well be looking at separate "emulation profile" for each game - which at least to me would sound like there'll never be anything close to full library compatibility.

That's why I think they have to include the EE in there. Emulating it will inevitably result in limited compatibility, which is clearly not what Sony has in mind.

[Fafalada]

I know, but a simple hardware address decoder should take care of that. I don't think you'd need to put the whole GS+4MB VRAM in there.
I agree, and I am still hoping they can do something like that, the benefit of RSX advanced texture filtering would already improve PS2 games a lot, even without any extra tricks. This would also still go along with the comments about "software+hardware" solution.

Why not? The enhancements on PS2 can be switched on or off by the user, there is no need to have game profiles. Scaling everything to 1080p shoul be pretty much transparent to the game, and so should be FSAA.
From hw perspective there's no concept of what is a frame buffer and what is a texture, let alone which buffers can be antialiased and which can not. And then you also have your games where rendering-buffers move around the memory in mid-frame, making the situation even more messy.
Unless you know the exact configuration of memory used in a specific game in advance, emulator has no way of knowing what should/can be scaled or antialiased. The only universal approach would be to scale up the entire "virtual" embeded memory, but that would also mean those GS addressing extensions would get more complicated, and multisampling AA is still flat out of the question.

Game profiles are the only way to give emulator the info about where screen buffers are and which parts are safe to mess around with.

Not sure I follow. Why would rendering to texture kill bandwidth?
PC GPUs use small onboard caches to keep traffic with main memory to minimum and help hide access latencies. Things like flushing texture cache on every rendered polygon is a pretty safe way to bring any current PC GPU to its knees.
Switching render targets is afaik also an expensive and not GPU friendly operation if done very often - and again on PS2 we sometimes do this on per primitive basis because it has no real penalty to speak of.

[pcostabel]

From hw perspective there's no concept of what is a frame buffer and what is a texture, let alone which buffers can be antialiased and which can not. And then you also have your games where rendering-buffers move around the memory in mid-frame, making the situation even more messy.
Unless you know the exact configuration of memory used in a specific game in advance, emulator has no way of knowing what should/can be scaled or antialiased. The only universal approach would be to scale up the entire "virtual" embeded memory, but that would also mean those GS addressing extensions would get more complicated, and multisampling AA is still flat out of the question.

Game profiles are the only way to give emulator the info about where screen buffers are and which parts are safe to mess around with.


Well, it is a pretty safe assumption that whatever is displayed is the frame buffer :)
It should be trivial to figure out where the buffers are from the CRT settings. This doesn't have to work with every game, but how many games are moving the framebuffers around anyways? Personally, I'd be happy if I can play GT4 at 1080p even without AA. if I can choose a setting to do that even if it screws up things like DOF and other full screen effects, it's a choice I'd like to have.


PC GPUs use small onboard caches to keep traffic with main memory to minimum and help hide access latencies. Things like flushing texture cache on every rendered polygon is a pretty safe way to bring any current PC GPU to its knees.
Switching render targets is afaik also an expensive and not GPU friendly operation if done very often - and again on PS2 we sometimes do this on per primitive basis because it has no real penalty to speak of.

I see, thanks for the explanation.

[Bohdy]

Are they actually going to use NV2A hardware in there? I was under impression that it'll be some sort of highlevel emulation, so basically whenever a game does lowlevel stuff that isn't quite within DX spec, they'll code it into one of those game profiles (hence the initial low compatibility rate).

There were reports that MS licensed nVidia tech for Xbox BC a while back, and I interpreted this a hardware solution, but I may be mistaken.

The P3 emulation is an interesting question though, if they were really sticking with static recompiles then you could well be looking at separate "emulation profile" for each game - which at least to me would sound like there'll never be anything close to full library compatibility.

It does seem that way to me as I don't know of any other option for emulating it. I haven't heard of any common emulators that work full speed with much less than a 10:1 speed ratio, and especially none that can gain speed linearly with multiple cpu's. Emulation has always been traditionally a very serial task afaik.

[BlueTsunami]

There were reports that MS licensed nVidia tech for Xbox BC a while back, and I interpreted this a hardware solution, but I may be mistaken.

Microsoft did license some NVidia tech but appearently it was low level stuff (not sure exactly what).

Heres the link to a thread that talked about this issue....

Nvidia Licenses Technology to Microsoft for Backwards Compatiblity (http://www.beyond3d.com/forum/showthread.php?t=20865&highlight=microsoft+license+nvidia)

[Farid]

There were reports that MS licensed nVidia tech for Xbox BC a while back, and I interpreted this a hardware solution, but I may be mistaken.
This deal give MS access to low level informations about the NV2A architectures and give them also the right to use it (In a software emulator).
It's now too late, for MS or Ati, to implement any NV2A hardware related silicon in the Xenos.

Also, it seems that MS decided to go the recompilation route for the .XBEs, therefore it's clearly a "case per case" basis kind of emulation. Making any hardwired emulation for the GPU, a non issue (At least a not that important one).

And about the main topic, I'm, I've to say, more interested in how the PS3 will handle the PSone emulation?
Because in this case there's clearly room for a lot of visual enhancement. (Resolution, FSAA, Filtering). Will they go Dynarec + HLE for the graphics or will they opt for R3K + HLE?

[Arnie Pie]

I'm, I've to say, more interested in how the PS3 will handle the PSone emulation
I can't imagine that it would handle it in a specialised way at all.. it makes sense just to emulate PS2. The PS2's emulation of PS1 titles just drops out of it, in the same way as the emulation of other PS2 applications.

Of course, there's nothing to stop a native rebuild of the PS1 emulator from taking place, but given the time constraints SCEI are under (for both completing the PS2 emulator, and testing PS1/PS2 titles) I seriously doubt that they'd risk being ready for launch by adding yet more complexity to the emulation setup.

Like others in this thread, I also believe that PS2 emulation will not add any additional gloss to a title (resolution increases, antialiasing, better texture filtering etc)... having worked on PS2 quite extensively, I can't see how SCEI would be able to distinguish GPGPU-like work and 'normal' rendering from each other. As far as the h/w is concerned, it's just pushing pixels without any associated context.

And game-specific profiles are out of the question.. SCEI have *no idea at all* what internal tricks each individual title are performing.. they perform only minor analysis of executables prior to submission (primarily to check that devs aren't calling OS functions that they shouldn't...). Knowing what bits of executables are using which areas of VRAM (dynamically allocated, in many cases), for specific display purposes is beyond their capability.

[Fafalada]

Well, it is a pretty safe assumption that whatever is displayed is the frame buffer
Unfortunately not - what CRTC reads is the front buffer, and in 99% of PS2 titles that's just a copy of backbuffer after all rendering has finished. (Some games may add some postprocessing to frontbuffer also, but either way, bulk of the rendering happens in the backbuffer).

I can't imagine that it would handle it in a specialised way at all.. it makes sense just to emulate PS2. The PS2's emulation of PS1 titles just drops out of it
Well I'd imagine that SPU and R3000 emulation modules will be shared between the two, but if we have a virtual GS there's no need to extend it for PS1 compatibility, when you could emulate PS1 GPU explicitly.
There's of course always a chance they'd just use a real GS in there.
So I do hope the PS1 GPU gets emulated, if for no other reason because I would prefer PS1 titles in progressive. Interlacing in titles that run in hires vertical gives me a splitting headache (there was no concept of flicker filters back then).

And game-specific profiles are out of the question.. SCEI have *no idea at all* what internal tricks each individual title are performing..
Running the title through PA it's not all that difficult to see where most of the buffers are and what they're doing. Make an online database of game profiles that gets updated over time - start with only 1st party titles if necessary (there's plenty of hits there, GT series alone in true HD would be a big deal for many people out there).
If a game has an entry in the DB, the option for HD modes gets highligted when you stick the DVD in, if not, you get standard PS2.

[robofunk]

Microsoft did license some NVidia tech but appearently it was low level stuff (not sure exactly what).

Heres the link to a thread that talked about this issue....

Nvidia Licenses Technology to Microsoft for Backwards Compatiblity (http://www.beyond3d.com/forum/showthread.php?t=20865&highlight=microsoft+license+nvidia)

It's pure software, they'll be using the same shader replacement tricks graphics companies have been using to 'cheat' in benchmarks. They must have to liscense the nvidia specific instructions to do it legally.

[Arnie Pie]

Running the title through PA it's not all that difficult to see where most of the buffers are and what they're doing.

You seriously think that SCEI would do this? Even given that fact that a very large number of titles use a dynamic VRAM allocation scheme (where the addresses are not fixed for the buffers)? I don't know if you're a developer, but if you are, then surely you know how long it takes to analyze a single frame *accurately* on a PA, right? A long time.. and that's for a title you're working on. Analyzing a single frame of someone elses title (ie without a map file, and the source code) and deriving some kind of game-specific meaning to the data is a much more daunting prospect. And that's not including the headaches associated with each frame being different! Or with code being in overlays! It's madness!

SCEI have committed to backwards compatibility on day one. I have no doubt that's what they'll provide (whether completely in software, or as a mix of hardware/software remains to be seen), but thinking they're going to automagically enhance PS2 (or PS1) titles to look 'HD-like' on PS2 is crazy. PS2 games will look like they're running on PS2. Nothing more. There is no financial gain in this kind of enhancement exercise. SCEI want people to buy PS3 games (with an increased per-unit license fee) for PS3. Not to play their old PS2 games.

Sure, BC looks good on a list of features, but it doesn't increase SCEI's bottom line.

[Squeak]

If it is deemed necessary to include a complete GS, it seems an awful waste not to be able to leverage the 4Mb eDRAM in some way.
35 million transistors is still quite a chunk to have lying around idle, when it could be used for texture buffering or other stuff. Although fitting the whole thing on to the RSX die, could be a problem and the integration for something useful an even bigger one.

About enhancing PS2 games: Even if the emulator doesn't know frame from texture and therefore can't do super sampling or multisampling, it knows polygons. How about edge AA?
Anisotropic and trilinear should "just" be a matter of making the EE emulator tag the geometry that needs to be filtered.

[Farid]

About enhancing PS2 games: Even if the emulator doesn't know frame from texture and therefore can't do super sampling or multisampling, it knows polygons.
You could do SSAA in 99% of the cases, I'd say. By nature, MSAA would be impossible, I'd say.

[Fafalada]

I don't know if you're a developer, but if you are, then surely you know how long it takes to analyze a single frame *accurately* on a PA, right?
We don't need to get 'that' accurate - for most part you just need to map certain address ranges over certain time intervals and then pretend they are different dimensions at runtime. You only need to know the locations of backbuffer and any offscreen targets that share it's ZBuffer - most of those won't move much, if it at all.
It's not trivial - but there's a lot of PS2 software out there that wouldn't make it 'that' difficult either.
And I wasn't suggesting they'd have to go about this in completely blackbox approach - it's why I said it could be an added feature for only 1st party titles at first. Like PS2 enhancements to PS1 titles, it would be optional.

There is no financial gain in this kind of enhancement exercise. SCEI want people to buy PS3 games (with an increased per-unit license fee) for PS3. Not to play their old PS2 games.
Well I should point out that I was discussing this from academic point of view - as I posted earlier in the thread I do Not expect any resolution/AA enhancements will happen with PS3. That said - RSX emulating GS could relatively easily add enhanced texture filtering (something that plagues PS2 games much more then lack of "AA" or resolution).

But if we are to debate economic perspective - there's some room for argument that enhanced PS2 content could be a good selling point early on, especially if it pertains to first party hits such as GT that won't have a PS3 version for at least a year after machine is out.
Kutaragi already spoke about 'enhancing' DVD content through fancy upscaling processing, this isn't really any different.

Although fitting the whole thing on to the RSX die, could be a problem and the integration for something useful an even bigger one.
GS die on 90nm is estimated around 40-45mm2, adding that to a chip that's possibly already over 200mm2 would probably have a noticeable effect on yields.

[MrSpiggott]

An additional emulation problem will be the need to upres PS1 and PS2 games. Sony can hardly expect people to unplug their HD panels and drag down an old portable TV every time they want to play an old game. If this is the case I wonder if any other IQ improvements will be made. Could bring a new lease of life to some old PS1 games.

[Arnie Pie]

It's not trivial - but there's a lot of PS2 software out there that wouldn't make it 'that' difficult either.
I guess we'll have to agree to disagree, but I do think it's more difficult that you believe. I've personally done weird stuff with the GS in terms of frame buffer management (and texture management as a whole, which includes off-screen render buffers, and dynamic texture uploads to the upper 8 bits of the active display area).. And I know many other developers who do the same kind of things. I would expect even the big 1st party titles such as GT4 to do similarly weird processes to get things like 1080i support to work in the limited VRAM space available.

That said - RSX emulating GS could relatively easily add enhanced texture filtering (something that plagues PS2 games much more then lack of "AA" or resolution)
Well, it's not so much the texture filtering that plagues PS2 games, it's the lack of any hardware-assisted mipmapping. It's up to application code to select a mip level for an object (or a strip, if you've got the cycles spare), whereas the PC approach (which I assume will be in RSX) is to automatically determine the mip levels based on derivatives computed during rasterisation. I guess it's possible to handle this in emulation (assuming they don't just slap a GS in the box!), but then what to do if the application is choosing its mip level for a reason.. maybe it's not supposed to be a function of the derivatives that selects it.

Ok, so maybe your proposed database of 1st party games is something that applies here too..? You know, kind of like "if a specific DMA chain from a specific memory address, on a specific frame number from bootup, is going through VU1 with a specific hardware state enabled, and the specific textures have their mipmaps located at known addresses then turn on hardware mipmapping". Never.. There are way too many variables to make this a feasible solution.. *waaaay* too many.

Kutaragi already spoke about 'enhancing' DVD content through fancy upscaling processing, this isn't really any different.
Come on.. this is completely different! Upscaling DVD players have been around for ages (although, strangely, not from Sony :|).. as such it would be stupid to not handle this. And for this it's technically a very simple thing to do.

[Shifty Geezer]

If it is deemed necessary to include a complete GS, it seems an awful waste not to be able to leverage the 4Mb eDRAM in some way.
35 million transistors is still quite a chunk to have lying around idle, when it could be used for texture buffering or other stuff.Part of the reason not to believe GS will be present. KK's categorically denied the presence of eDRAM. Unless they tried palming it off as texturecache or something on RSX, and hence 'it's not really eDRAM', they can't have included eDRAM in the system without KK talking porkies. And if they did include the GS+eDRAM but didn't incorporate the eDRAM into PS3's operation that'd be a waste. 48Gb second local storage to the GPU would be very nice I'm sure!

I'd expect compression of dta over the existing RAM would do well enough to accomodate PS2's BW demands.

[Fafalada]

I've personally done weird stuff with the GS in terms of frame buffer management (and texture management as a whole, which includes off-screen render buffers, and dynamic texture uploads to the upper 8 bits of the active display area).. And I know many other developers who do the same kind of things. I would expect even the big 1st party titles such as GT4 to do similarly weird processes to get things like 1080i support to work in the limited VRAM space available.
I think we've all done similar kind of stuff, my last game also overlaps a bunch of offscreen and texture buffers in the same address range via time-sharing as well as moving main backbuffer around the memory mid-frame at some times.
My point was that generally we wouldn't want to touch stuff outside backbuffer for changing resolution anyhow. So what if reflections and shadowmaps are still rendered at 128x128 or whatever, or motion and glow blurs are still computed at 1/8 the SDTV res - the increased resolution of the backbuffer will still make things look nicer.

Btw, GTs 1080i is a field render with horizontal scaling through CRT, at worst it needs a couple of extra lines over what you render normally (540 instead of 512/448). The only trick to it is of course running the game at 60hz.

Well, it's not so much the texture filtering that plagues PS2 games
Right, it's the GS lacking proper miplevel selection, but because of it, there's also a lot of PS2 games (especially early on) that have simply forgone the use of mipmaps.
Anisotropic would help this at least a little - and it would also help with titles that do mipmap, since the per-object mip-coefficients are only 'correct' on certain polygon angles(usually screen facing).

but then what to do if the application is choosing its mip level for a reason.. maybe it's not supposed to be a function of the derivatives that selects it.
Emulator does 'know' what the number of mipmaps and offset mip-koefficient are - I wasn't suggesting we'd just toggle the mipmap computation on and pray the default parameters will somehow work with PS2 games.
And yes, there may be some exceptions that will still fail - but that's no different then the occasional issues with enabling bilinear on PS1 games. It won't always work right - that's why it's optional.

as such it would be stupid to not handle this. And for this it's technically a very simple thing to do.
Ken was talking about storing DVDs on some network storage and then "aging" them - basically running them through fancy offline scaling processing, converting the MPEG2 into some auto-magic generated HDTV stream.
While it generally makes things a little better, having it fully automated is hardly any guarantee it will always do things right. :P

[pcostabel]

Unfortunately not - what CRTC reads is the front buffer, and in 99% of PS2 titles that's just a copy of backbuffer after all rendering has finished. (Some games may add some postprocessing to frontbuffer also, but either way, bulk of the rendering happens in the backbuffer).


Usually, the front and back buffer are swapped every frame, so you can tell where both are.

[Shifty Geezer]

Emulator does 'know' what the number of mipmaps and offset mip-koefficient are - I wasn't suggesting we'd just toggle the mipmap computation on and pray the default parameters will somehow work with PS2 games.
And yes, there may be some exceptions that will still fail - but that's no different then the occasional issues with enabling bilinear on PS1 games. It won't always work right - that's why it's optional.As long as certain effects are switchable in the Bios, like PS1's Smooth Textures and Double CD speed were optional improvements on PS2 that could be disabled if they stopped a game running, there's no worries.

[Arnie Pie]

My point was that generally we wouldn't want to touch stuff outside backbuffer for changing resolution anyhow.
Hmm.. our more recent PS2 titles have rendered to a single 32-bit back buffer, with a convert to 16-bit for the actual front buffer (it's difficult to tell the difference most of the time, and it gives back a fair amount of VRAM).. I guess this would be handled by your approach, as it would seem unlikely that those primary buffers move around during the game (ok, maybe for FMV playback and so on.. but not in gameplay), yes?

Other GS things that concern me with an emulated approach are the alpha fillrate, which - frankly - is poor on the NV4x series. And finally, the bizarre texture format hacks that you can do on PS3 (doing channel swaps.. the kind of stuff you do when tonemapping, or doing that hacky Dot3 implementation).

On the EE side, I'd be worried because most of CELL's power comes from immense FPU performance. Unfortunately, PS2's FPU and VU0/VU1 use non-standard (ie not IEEE compliant) floating point behaviour - whereas CELL/SPEs are IEEE compliant. I can't imagine them being able to make use of the FPUs on CELL to accelerate PS2 floating point emulation, as the results will be incorrect. Leaves them emulating PS2-style floats with integer ops, wasting most of the machines performance.

Challenging, to say the least! :)

[Panajev2001a]

SPE's SP floating point units are NOT fully IEEE compatible or they are about as much as the VU's SIMD array. I think you are getting confused with the SPE's DP FP support.

The problem comes from the fact they use Fused-Multiply-Add's and not FMAC's (not centered around the idea of the ACCumulator register) so some instructions will have to be emulated.

[MasaC]

Haven't Sony announced a plan to spend $1,1 billion on 65 Nm-process lines in their Nagasaki plant? That's the place were they manufacture the EE+GS chip plus the Cell processor, right?

Seems possible to me they start out their 65 Nm process with the EE+GS chip and later on the cell processor.

[Alpha_Spartan]

Well, according to what King Kenny said, it will be a combination of hardware and software. There is no such thing as hardware emulation without actual PS2 hardware (or another piece of hardware) in the box dedicated to b/c, otherwise it's all software. The way I see it, I don't see Cell/RSX doing any major EE/GS emulation in software. The overhead makes it impractical. So I see a 90nm EE/GS a la PSTwo in the box that handles all of the PS2 emulation while the PSX emulation is handled in software. The PSX games will therefore be enhanced while the PS2 games look the same.

Perhaps the EE/GS combo won't be idle while playing PS3 games and will be used as an I/O controller for broadband functions.

[Arnie Pie]

SPE's SP floating point units are NOT fully IEEE compatible or they are about as much as the VU's SIMD array. I think you are getting confused with the SPE's DP FP support.
No.. I'm not confused about DP support. That is of no concern, as PS2 has no DP support to emulate.. but you're right, in that PPU/SPU are not fully IEEE compliant. But they are more compliant than the PS2 VU/FPU implementation. Their behaviour relating to things like divide-by-zero, for example, where on PS2 VU/FPU you'll get zero, yet on PPU/SPU you'll get NaN.

[LunchBox]

they might go to a similar route they did with the ps2/ps1 compatibility...

the ps2 had the ps1 chip as its IO chip if i remember correctly...




maybe the ps3 will have the EE as an IO...

and have the rsx use its pixel pipes as an "emulated GS pipes"

the ps1 will be software emulated on the ps3 more likely