HD problems in Xbox 360 and PS3 (Zenji Nishikawa article @ Game Watch)

[Mintmaster]

Titanio, bandwidth concerns are always related to the FB. I know they're talking about texturing, but on the original XBox you have to write your pixels somewhere. You have to read and update the Z buffer. These things go on while you're texturing, so to say XBox360 has only 3.5 times the bandwidth for texturing is very inaccurate. It's probably closer to 5-10 times.

I don't think I'm writing any of the concerns off, I'm just saying things aren't nearly as grim as the author's putting it. The way he's explaining the problems of tiling makes no real sense at all. It's as if he just made it all up, and threw in some quotes (unrelated to half the points he raised) to give the illusion of credibility.

 

[Dave Baumann]

I agree, but the point is that with LOD or not, tiling brings issues for some developers, and in some quite high profile and far-reaching cases (like UE3).

As ERP points out, the UE3 example if not a factor of tiling, but a factor of MSAA in general.

 

[Titanio]

Titanio, bandwidth concerns are always related to the FB. I know they're talking about texturing, but on the original XBox you have to write your pixels somewhere. You have to read and update the Z buffer. These things go on while you're texturing, so to say XBox360 has only 3.5 times the bandwidth for texturing is very inaccurate. It's probably closer to 5-10 times.

Yeah, I see yours and Shifty's point on this, absolutely. Although it might be interesting to see how texturing has scaled, in terms of texel rate. I've seen figures for Xbox, but I don't know if they're filtered or what.

The way he's explaining the problems of tiling makes no real sense at all.

Perhaps, but I like I say, be it for the reasons he discusses or not, it does represent an obstacle for some devs, and he was probably attempting to make an explanation as to why. I don't know how much of his own discussion of that was based on chat with developers, but many of their comments seem to pivot on the context that one is avoiding tiling.

As ERP points out, the UE3 example if not a factor of tiling, but a factor of MSAA in general.

I see that now, which is a bit surprising. I guess it's more a matter of their own implementation allowing them to avoid tiling rather than tiling forcing a different implementation

 

[Johnny Awesome]

The main value of this article seems to be the quality of the discussion that it provoked, rather than the dire conclusions it makes. Excellent thread guys. I learned a lot and everything was nice and civil IMO.

 

[Mintmaster]

The only reasonable excuses I've heard for lack of AA other than not enough time is the one Epic uses to justify it in the Unreal3 engine games. Basically their shadowing algorythm projects screen space pixels back into light space so they would have to do 2x or 4x the work for shadowing if AA was enabled, but that's true reguardless of the AA implementation.

Can you elaborate on this a bit, please?

Objects in light space sounds like shadow mapping, but I don't see how that causes any conflicts with AA. Actually, you can use the AA hardware to render your shadow maps four times as fast. Are you talking about stenciled shadow volumes? True, you need to do more work, but the eDRAM handles that anyway at the same speed as no AA. Are they doing some sort of post-processing of shadows?

(BTW, Titanio, read ERP's statement again. It's not tiling that's the problem for UE3, unless you have other info, which we'd all be interested in. EDIT: Okay, I see you've acknowledged this.)

 

[Jawed]

I suppose I might as well re-post stuff about predicated tiling, for the nth time:

http://www.beyond3d.com/forum/showpost.php?p=627728&postcount=202
http://www.beyond3d.com/forum/showpost.php?p=627748&postcount=206
http://www.beyond3d.com/forum/showpost.php?p=627758&postcount=208

With this caveat from kyleb:

http://www.beyond3d.com/forum/showpost.php?p=649340&postcount=215

which seems to have turned out to be true. I haven't kept on top of XB360 BC, but it appears to be pretty flaky. If the resolution thing is true then I guess that means tiling isn't causing BC problems.

Jawed

 

[joebloggs]

It's been said before: theoretical performance and real-world performance are two different things.

I'm sure there are plenty more skeletons in the cupboard waiting to be discovered (and hopefully in due course overcome).

 

[NavNucST3]

I remember where I got my 960 x 540 theory from, but I was off, the HP DLP literature I received in the mail. The 1080p hp dlp that I am looking to buy , the 65" uses wobulation, which is actually 960 x 1080...anyway heres a blurb...

Pixel Magic: How TI Puts the 1080p in DLP
Digital Light Processing (DLP) is today’s most-popular fixed-pixel, or “microdisplay,†rear-projection technology. It relies on a chip — called a DMD, or Digital Micromirror Device — that’s covered with microscopic mirrors, each representing one pixel of light on the screen. But rather than try to mass-produce a chip with all 2 million-plus mirrors needed to create a 1080p image, DLP developer Texas Instruments took a different route.
Using an HP technique known as “wobulation†(TI calls it SmoothPicture), TI achieves a 1,920 x 1,080 effective pixel resolution using half that number of mirrors. Wobulation relies on the same principle as interlacing, which shows half the picture at a time, but so rapidly the eye combines the two parts into one. Starting with the square pixel design of its 720p DLP chips, TI turned each mirror 45° relative to the sides of the display, creating rows of diamond-shaped pixels. There are only 960 x 1,080 micromirrors on the grid, but each of them, in effect, creates two separate pixels, one after the other.
During operation, light from the lamp bounces from the chip to a device called an optical actuator, a reflective panel that pivots. In its first position, the actuator reflects half of the image information (the odd-numbered pixels) onto the screen. After 8 milliseconds, the actuator switches position — or “wobulates†— half a pixel-width. Simultaneously, the chip flashes up the picture information for the other half of the image (the even-numbered pixels). This process is so quick that it’s impossible to differentiate between the sets of pixels, and the entire frame, with all 1,920 x 1,080 pixels, is “constructed†within the standard 1/60-second field time.

 

[darkblu]

Minty, i think you're overcritical toward the level of technical literacy of this article - as you see we've been trying to 'demystify' some of the points expresses there, and we've been giving some fair benefit of the doubt that the quotes there are true dev's. and nobody gives the ps3 any advantage in this regards (or at least i can see nobody doing that after the thread cleanup by Vysez). so let's get back to the fun of hypothesizing on those points

80% of PS2's BW was for the FB.

that was natural for the type of rasterizer the GS was - it's framebuffer was accomodating for everything, incl. 'shader registers', shading equations and post-effects relied on that monstrous bandwidth if they wanted to achieve any prettyness, it was essentially a read-modify-write galore. but that's not the case with a modern shader rasterizer pipeline - you're not meant to touch the frambuffer that often, except for inherently high-overdraw scenarios (say, particles). so direct parallels between a sm3 gpu and the GS may not be very indicative of the state of BW ballance these days.

Two thirds of the BW for the older 3DLabs Wildcat series (separate texture and FB memory) was for the FB. Framebuffer access occupies the lion's share of BW, so there's a reason ATI abandoned its previous architectures to make Xenos the way they did.

if ATi did something new wrt to ballancing the bandwidth it's the fact that they totally alleviated the fragment pipeline of the MSAA- and the read-modify-write -incurred bandwidth. nothing more. at the end of the day a render target of X*Y still takes as much FB bandwidth as it takes on every other sm3 rasterizer out there.

-"Lens effect, refraction, HDR effects such as bloom and glare" are all things which are unaffected by tiling. You have to resolve your scene and write it to main memory before you can do any of these effects. It sits as a whole image there.

yes, that's the general, by-the-book way. the devil is in the details, though. i'd venture to say some of those effects can be carried out as smart-approximation ROP-based techniques saving the need for the pre-final image to pass as another feed to the pipeline (i.e. through main memory), hence tiling here may come as a burdeon. we'll never know unless the quoted developer actually explained what techniques they had in mind. but we can guess with a high propability that it was a multi-pass technique.

-Xenos has 4 gigapixels per second fillrate, not texels. And if you're talking about bandwidth limitations, why bother mentioning this?

come on, that was an hones mistake. again, don't be too critical of the article's literacy.

-"It leaves only 0.5 times headroom" is just silly. Say 17% more if you want to say something meaningful. Moreover, you've got all your bandwidth for your CPU and texture/vertex access. Eliminating Z and colour bandwidth, which the original XBox still needed, is enormous.

it is. but i believe the original statement was WRT resolution requirements, not anything else.

I don't see how geometry can be that big of a deal, either. We keep hearing again and again that geometry isn't the bottleneck nowadays, so even sending the geometry down twice with a simple scissor test (i.e. no predication) should be an easy alternative. A decent culling system in your engine should keep the geometry increase well under a full factor of two, and also the cache locking is unaffected this way.

i believe the cache locking may be affected if the gpu is fed directly by the CPU through the L2 cache - not in the sense that you can't lock the cache, but in the sense that that does not help you at all - you still have to re-calculate all those verts for the tiles after the first one, unless all that CPU-generated data oringinally fitted in the L2 cache. but if it did not, the advantage of this 'shortcut path' gets voided.

And why the heck would a developer not implement any LOD? That's something that helps you whether you have tiling or not.

for any type of game where the average depth of the viewe volume and/or distribution of objects does not require LODs. think fighters, side-scrollers, etc. note that i'm not saying those would never utilize any LOD scheme - just that they may not need one, statistically.

Whatever. Just your usual stuff from a site trying to look more knowledgeable and connected than they really are.

don't they all do?

 

[Jawed]

i believe the cache locking may be affected if the gpu is fed directly by the CPU through the L2 cache - not in the sense that you can't lock the cache, but in the sense that that does not help you at all - you still have to re-calculate all those verts for the tiles after the first one, unless all that CPU-generated data oringinally fitted in the L2 cache. but if it did not, the advantage of this 'shortcut path' gets voided.

As I posted earlier:

To get XPS and tiling to work together, the developer has to perform their own tile extents testing and predication - it becomes a fully-manual tiling process, basically. Part of the XB360 D3D command set available to the developer is the predication instruction and the 2D extents capture, so it's not a nightmare. But it's certainly something for developers to get to grips with.

Jawed

 

[Carl B]

Memexport, we hardly knew ye... (j/k!)

Anyway it's been discussed and we've known for some time that individual devs would deviate from Microsoft's original useage 'vision' with regard to the eDRAM depending on their needs; it seems like as more information comes out, there are development models that seem to more readily lend themselves to certain 'types' of games. Ok now that's obvious, but does that happen almost on a 'per genre' basis? Is there going to be a subset of games that more regularly than not would benefit from the upscaling method of reaching 720p rather than the tiling method? Or really, is tiling the way to go in almost any situation - simply that the effort to tailor ones engine has to be put into it?

I know this question is a variation on a theme that has cropped up many a time before, but the seeming embracing of the upscale method in some of those quotes led me to wonder if in fact even three years from now, there would be clear cases where going 'non-tiled' might still be the way to go for some games.

 

[ERP]

Can you elaborate on this a bit, please?

Objects in light space sounds like shadow mapping, but I don't see how that causes any conflicts with AA. Actually, you can use the AA hardware to render your shadow maps four times as fast. Are you talking about stenciled shadow volumes? True, you need to do more work, but the eDRAM handles that anyway at the same speed as no AA. Are they doing some sort of post-processing of shadows?

(BTW, Titanio, read ERP's statement again. It's not tiling that's the problem for UE3, unless you have other info, which we'd all be interested in. EDIT: Okay, I see you've acknowledged this.)

This is my understanding, it is shadow mapping, but rather than rendering the recieving geometry multiple times they take the already rendered pixels in the frame buffer and project them back into the shadow texture space space to determine if they should be in shadow.

It makes the cost proportional to the number of recieving pixels, rather than the quantity of recieving geometry. However it would have to be done before the screen in downsampled, so it's done on the larger buffer, hence 2x or 4x the work in any AA implementation.

 

[ERP]

It would probably be less efficient but they could compute shadow contribution in their color rendering pass, multisampling or not it would not make any difference.

I would tend to agree, they don't have significant reciever complexity from what I've seen, and rerendering for shadow contributions might even be faster. But I have to assume they have done the tests and it isn't.

 

[.Melchiah.]

Afaik it (antialiasing) was never mandatory, but my info could be outdated. But from what I've read they included both 720P w/o AA, and 1066x600 (or something thereabouts) with 2xAA as "minimum allowed" resolutions.

The promises that were made:


http://www.anandtech.com/printarticle.aspx?i=2610

The logic and embedded DRAM on the daughter die is what allows the Xbox 360 GPU to essentially offer "free" anti-aliasing, which Microsoft enforces through requiring developers to support a minimum of 2X AA in all Xbox 360 titles. Although we were originally told back at E3 that all Xbox 360 titles would support 4X AA, it seems that the statement has since been revised to 2X or 4X AA. We're not certain why the change was made, as 2X and 4X are both effectively "free" on the GPU, but there may be something we're missing.

http://www.bit-tech.net/news/2005/05/25/ati_xbox_360_london/

ATI revealed this afternoon that every single Xbox 360 game will be required to run at a minimum of 720p resolution with 4x Anti-Aliasing.

Speaking at a press conference in London, ATI technology specialist Rene Froeleke told journalists that Microsoft had specified that games must run at the 1280x720 resolution at 4xAA with no slowdown. Every single game will be supported at this graphical specification, which we think is great news for gamers playing on big-screen TVs.

Because of the embedded DRAM architecture of Xbox 360, the AA was described as 'Absolutely free'.

 

[Jawed]

I would tend to agree, they don't have significant reciever complexity from what I've seen, and rerendering for shadow contributions might even be faster. But I have to assume they have done the tests and it isn't.

Ignorant question: would the extremely highly detailed normal mapping they're using for characters in UE3 games bias shadowing techniques towards what's described here. Perhaps the IQ is superior, rather than performance?

(I think this shadowing algorithm needs its own thread - I don't really understand it, sigh).

Jawed

 

[darkblu]

As I posted earlier:

To get XPS and tiling to work together, the developer has to perform their own tile extents testing and predication - it becomes a fully-manual tiling process, basically. Part of the XB360 D3D command set available to the developer is the predication instruction and the 2D extents capture, so it's not a nightmare. But it's certainly something for developers to get to grips with.

Jawed

well, yeah. but you have to agree that can be a nuisance.

 

[Alpha_Spartan]

I'm delighted that we're all coming down to earth in terms of the performance of these systems. At the end of the day, PS3 and Xbox 360 are mass consumer items that have to be sold at mass consumer prices. Busisness is business and 360 and PS3 will make huge compromises so that these wonderful companies can provide us with gaming pleasure.

 

[Serenity Painted Death]

Do you guys think there's any truth to the rumours that Japanese Developers are behind the curve with the new consoles because they are unfamiliar with the PC-based GPU's that both the new consoles use??

That isn't a rumor.

That is "project sabotage," wherein MS pays off Japanese companies to make games for them... however, said companies put their B-F teams on the projects, and hilarity (FCK, etc) ensues. Namco is leading the charge.

 

[mckmas8808]

Busisness is business and 360 and PS3 will make huge compromises so that these wonderful companies can provide us with gaming pleasure.

QFT. But the good thing is at least the devs have years to learn and work the systems, giving us wonderful games.

Man I love consoles.:smile:

 

[Dave Glue]

With this caveat from kyleb:

http://www.beyond3d.com/forum/showpost.php?p=649340&postcount=215

which seems to have turned out to be true. I haven't kept on top of XB360 BC, but it appears to be pretty flaky. If the resolution thing is true then I guess that means tiling isn't causing BC problems.

Jawed

I don't think tiling would have anything to do with it really - they're emulating a completely different GPU & CPU. The stuff is just damn difficult, especially considering the differences in the CPU architecture.

Regarding the X360's "upsampling" of Xbox games though, I've always wondered what exactly that means. In my experience, "upsampling" usually refers to a resolution simply being stretched to fill a higher resolution, rather than actually running "natively" in that res. The shots I've seen of Xbox games running in HD on the 360 don't really look like 1280*720 to me, they certainly look better but they look as how they're described - upsampled.

Can anyone point to some concrete info on what the 360 actually does with Xbox games in terms of resolution? Are they still running at 640*480 and just scaled to 720p with some free AA, or are they actually running in 720 res? I would expect if they were just upsampled we would also see a lot of aspect ratio problems which don't appear to be an issue.