What expect from Xenos smart edram except 4xAA

[darkblu]

Given that 32GB/s is enough for 8 bytes per pixel at 8 pix/clk, I can see where you're coming from. However, AA needs to determine the Z value for each sample. If I were to guess, I'd say it's probably a depth value plus two slopes for the quad, because slopes are needed anyway to interpolate the Z values. You also need an AA coverage mask and position information for the quad, which is likely 36 bits minimum.

i was speaking from blurried memories of an ATI conference, but now that you mention it - yes, that'd be more or less the case at hand - 4 colors + z + 2 z-grads + a coverage mask - hardly any savings at an individual fragment level, but your multisampling is indeed free from the POV of the fragment pipeline. and the stencil part was just thrown in as a bandwidth contributor, not that it goes in the same batch.

Also, not counting the z/rop read-write multiplicity is not really fair. For any pixel actually written, you must do at least a z read and write per pixel. Moreover, the only reason PS2 had that much bandwidth was so that the worst case was handled fast enough, so that's the case we should look at if we want to compare the figures. The PS2 eDRAM, AFAIK, was 19.2 GB/s read and 19.2 GB/s write for the framebuffer, exactly enough to read and write both z and colour values at 2.4 GPix/s. The remaining 9.6 GB/s was for texture bandwidth.

well, yes. i know you were originally comparing xenos to the ps2 but i wasn't - i was merely commenting on xenos' interconnect figures. but the ps2 numbers were welcome nevertheless : )

Anyway, it looks like Xenos needs 8 bytes of data transfer per pixel (which is what the interconnect has available at 4GPix/s), not 4. So the factor is 8, not 16. My mistake. Looking at these PS2 numbers is rather interesting, though. Framebuffer bandwidth for PS3 is less than half of PS2, yet 1080p has seven times the pixels of 640x448. I think PS2's GS had slightly misplaced priorities.

yep, and that's one of the things whose emulation i'm particularly curious about : )

 

[darkblu]

Yes, I remember them saying compressed Z and thought it was in the article. I think the Z is already at the multisample coverage level because of the fact that the Heirarchical Z buffer is on the parent die, and will be at the multisample level coverage.

that's what Mintmaster originally noted - if you pass down a depth + grads per quad you already have your depth info at a multi-sample level.

 

[Mintmaster]

I'm a little confused here. Are these numbers coming from Dave's G73 article, or somewhere else? Some of them are present in the article, but not all as far as I can tell for what you're presenting them as (I see where the 2.3Gpixels figure is coming from, but the only 2.8Gpixels figure I can find in the article relates to color+z fillrate as opposed to color-only).

Apologies for skipping over your question. I was talking strictly from a theoretical view of 100% efficiency. Simple alpha blending without z or texturing means you need to read 4 bytes and write 4 bytes. 22.4GB/s divided by 8 bytes per pixel gives you 2.8 GPix/s. You're right in that 2.3 GPix/s value for blending with texturing w/o Z is from the review.

yep, and that's one of the things whose emulation i'm particularly curious about : )

Excellent point. Who would have thought that PS2 would have an advantage over PS3 in some areas? I'm thinking this won't be too common, and faster speed in other parts of the scene would negate this deficiency in most cases. But if a PS2 developer took heavy advantage of the 38.4 GB/s framebuffer bandwidth, there's not much you can do on RSX. Is backwards compatibility written in stone, or just something Sony is aiming for?

 

[London Geezer]

Excellent point. Who would have thought that PS2 would have an advantage over PS3 in some areas? I'm thinking this won't be too common, and faster speed in other parts of the scene would negate this deficiency in most cases. But if a PS2 developer took heavy advantage of the 38.4 GB/s framebuffer bandwidth, there's not much you can do on RSX. Is backwards compatibility written in stone, or just something Sony is aiming for?

BC with almost 100% of PS2 titles is more a target and a promise to customers, rather than something that's set in stone. Peronally i don't think they'll be able to get there unless there's a GS in there somewhere.

 

[zidane1strife]

Excellent point. Who would have thought that PS2 would have an advantage over PS3 in some areas? I'm thinking this won't be too common, and faster speed in other parts of the scene would negate this deficiency in most cases. But if a PS2 developer took heavy advantage of the 38.4 GB/s framebuffer bandwidth, there's not much you can do on RSX. Is backwards compatibility written in stone, or just something Sony is aiming for?

It's almost set in stone, I'd expect them to boost vram quantity and b/w.

 

[Titanio]

It's almost set in stone, I'd expect them to boost vram quantity and b/w.

..or just put GS in the system, perhaps. For all the talk recently about software solutions, the last time Kutaragi referenced this, "hardware" was explicitly referenced.

 

[Shifty Geezer]

As has been mnetioned before on this forum, the logic of GS is about 15 million transitiors. If the eDRAM is emulated by texture compression across the RAM, GS and eDRAM are doable in the space. Though to be honest I don't know what are the tricks being exploited in hardware that need the low level emulation. I imagine it's convoluted things of the entire system design rather than any specific component. EE and GS are pretty straightforward as processors, no?

 

[tema]

Did you forgot nAo words? RSX will have a GS texture cache.

 

[Mintmaster]

As has been mnetioned before on this forum, the logic of GS is about 15 million transitiors. If the eDRAM is emulated by texture compression across the RAM, GS and eDRAM are doable in the space.

It's not the texture bandwidth that's the problem, especially because PS2 textures are quite small and are usually magnified. It's the framebuffer bandwidth that's the issue. Colour compression really only works with AA, unless you're drawing blocks of the same colour. Z-compression is effective, but not a miracle, and it doesn't help your worst case. Nevertheless, I don't think it'll be a problem, as worst case RSX and/or Cell will be maybe 50% slower than the GS w/ eDRAM in some parts of some scenes. All the other parts of the scene should render much faster, so it would take quite a pathological case for any PS2 game to run slower on PS3, I think. If such a game does run slower, it's not a big deal anyway.

Did you forgot nAo words? RSX will have a GS texture cache.

What? Did I miss out on some juicy news somewhere?

 

[Fox5]

Could 4x AA be used without tiling if only applied to specific areas of the screen? Would something like edge AA be possible?
I know supposendly Halflife 2 has a custom use of AA (rather than AAing the entire screen), and certainly enabling AA within Halflife 2 gives better performance than forcing it globally, so could the same be done for console games?

 

[tema]

What? Did I miss out on some juicy news somewhere?

Yes. Ask nAo.