PGR 3 - Pictures and Framebuffer Discussion

You could contend that but it would be silly considering I have already taken that into account. It seems to me that your man argument is that I'm eyballing it, which seem pointless as I have never stated anything but.

And yeah c0_re, that is photo mode, but unless they are doing something downright amazing with photo mode it isn't going to have AA anywhere like that.
 
From reading the XB360 Predicated Tiling whitepaper, I've learnt the following:
  • The alpha kit "emulated" predicated tiling - though it did so with slightly different tile-size restrictions (i.e. how tile boundaries are aligned within the render target/back buffer). It also did so without actually performing any predication! so that 2 tiles performed at half the speed of 1 tile, etc.
  • Predicated tiling in Xenos works by having the GPU render all commands on the first tiling pass (even if they don't fit into the first tile) - this first pass works out the extents (2D coordinates) of the draw commands. This only applies to vertices. Pixels are not "overdrawn".
  • The Z-pass is actually separate from the "tiling prepass" - but the data for the two can be consolidated. A discussion of this isn't in the whitepaper (it's fairly old).
  • A special "patch-up" process runs on a CPU core, which edits each draw command's "predicate instruction" in the command buffer with the set of extents generated by the first tiling pass - this is not something done by the GPU. The edit simply entails noting which tiles the draw command affects, which is a process of comparing the draw command extents (generated by the first pass) against the tile coordinates.
  • Triangles that overlap multiple tiles will be "clipped" to each tile - much as triangles are clipped to a normal viewport. This clipping will incur a small overhead (not quantified yet), and adds in to the overhead of predicated tiling.
  • Xbox Procedural Synthesis isn't able to work directly with automatic predicated tiling. Automatic predicated tiling is where the developer can just say "render with tiles" and predicated tiling happens. 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.
  • Memexport also requires manual tiling, otherwise memexport will perform duplicate writes to memory, once per tile.
In general, I think a lot of the issues with predicated tiling will be ameliorated by the "multi-pass" nature of 3D rendering. e.g. during shadow calculation or tessellation, the entire 48 pipelines are able to process vertex data since there is no pixel shading - so that the vertex overhead associated with tiling (around 2x) is easily within the capabilities of Xenos.

Simple examples where manually-predicated tiling can occur are rendering the gun in an FPS or the HUD, since these items are static or nearly static in the 2D space of the screen.

So, all in all, predicated tiling in XB360 seems to be operating at a fairly crude level. The more advanced features of XB360 (XPS and memexport) require that the developer performs tiling themselves.

Having said that, it also seems that M$ intended that (automatic) predicated tiling became the baseline. With a "simple" 3D engine M$ shows that only a few high level D3D calls are required to activate predicated tiling - for the developer it's practically transparent. Care needs to be taken in fitting screen-render tiles plus any other render targets (that are created concurrently) into EDRAM. As soon as the 3D engine gets into advanced techniques like stencil shadow volues or post-processing, though, automatic predicated tiling is no longer a fire and forget concept.

I actually think (automatic) predicated tiling will come into play for emulation of XBox 1 titles (the whitepaper includes an analysis of tiling overhead based on over 150 XBox 1 titles) giving them 4xMSAA and 720p "for free". In these titles, sheer brute force presumably means that the overheads associated with automatic predicated tiling are not material. Whereas I think the complexities of newer 3D engines for "next gen" games will prevent developers from simply "flicking the switch" to enable predicated tiling. The limits on XPS, particularly, seem to fly in the face of "easy predicated tiling".

Since I'm not a developer, my characterisation of the cut-over between simple engines that are compatible with automatic predicated tiling and manually implemented tiling is not well-informed! It could be that practically all 3D games require at least some manual tiling, and perhaps all XB360 games require manual tiling. I'm guessing that XBox 1 games are a trivial workload for XB360, so that any mismatches caused by automatic predicated tiling (e.g. rendering an entire frame's special effects, such as shadows or depth of field, thrice instead of once!) are not deal-breakers.

All of which, I hope, sheds light on why early XB360 games have seemingly used "lower resolutions" to avoid tiling, rather than to get sucked into the complexities of manual tiling - even if they only apply to special effects.

Jawed
 
Great info, though I'm left wondering a bit about the implementation of AA in launch games. If the Alpha kits had tiling emulation, why weren't tiling engines created from the get go? Why isn't PGR3 as an example rendering 720p + AA? Does this suggest tiling is quite tricky, or that perhaps the techniques used for some effects aren't ideal for the tiled approach and a different system is needed? That's kinda taking PGR3 as an exampleto consider. I don't know what percentage of XB360 launch titles are 720p+AA so don't know how widespread the issue reaches. Is it just Bizarre that couldn't fit everything into a tiled engine, and why not?
 
Jawed said:
From reading the XB360 Predicated Tiling whitepaper, I've learnt the following:
  • The alpha kit "emulated" predicated tiling - though it did so with slightly different tile-size restrictions (i.e. how tile boundaries are aligned within the render target/back buffer). It also did so without actually performing any predication! so that 2 tiles performed at half the speed of 1 tile, etc.
    ...
    ...
    Since I'm not a developer, my characterisation of the cut-over between simple engines that are compatible with automatic predicated tiling and manually implemented tiling is not well-informed! It could be that practically all 3D games require at least some manual tiling, and perhaps all XB360 games require manual tiling. I'm guessing that XBox 1 games are a trivial workload for XB360, so that any mismatches caused by automatic predicated tiling (e.g. rendering an entire frame's special effects, such as shadows or depth of field, thrice instead of once!) are not deal-breakers.

    All of which, I hope, sheds light on why early XB360 games have seemingly used "lower resolutions" to avoid tiling, rather than to get sucked into the complexities of manual tiling - even if they only apply to special effects.

    Jawed


  • Seeing as a game like PGR3 didnt seem to use procedural synthesis (no round steering wheels, healdights,etc), what would be the sticking point from bizarre not using predicated tiling? The Cockpit/hud views of the game?

    Once a developer writes an engine that has incorporates manual tiling, how 'reusable' is that?

    What do you presume the performance hit for manual tiling, and predicated tiling as you now understand it, to be?

    Thanks for this great writeup, it was a good read.
 
Last edited by a moderator:
Shifty Geezer said:
Great info, though I'm left wondering a bit about the implementation of AA in launch games. If the Alpha kits had tiling emulation, why weren't tiling engines created from the get go? Why isn't PGR3 as an example rendering 720p + AA? Does this suggest tiling is quite tricky, or that perhaps the techniques used for some effects aren't ideal for the tiled approach and a different system is needed? That's kinda taking PGR3 as an exampleto consider. I don't know what percentage of XB360 launch titles are 720p+AA so don't know how widespread the issue reaches. Is it just Bizarre that couldn't fit everything into a tiled engine, and why not?
The whole gist of my posting is that automatic predicated tiling seems easy, but quickly grows in complexity and performance suffers unnecessarily. XPS and memexport will both run at 1/3 speed if you have 3 tiles and just dumbly turn on automatic predicated tiling.

In other words, it's not trivial to implement in a modern game. I don't know what the cut-over point is in terms of 3D engine features/render-passes.

But at the same time, I suspect the overwhelming brute force of XB360 allows it to emulate XBox 1 games with an automated predicated tiling for 720p 4xAA, despite the 2x or 3x overheads that "dumb" tiling might incur in games with sohpisticated techniques - e.g. shadowing or depth of field.

But, obviously, that's just me guessing.

Jawed
 
one said:
Is it stated by the developers?

Well i made the assumption since if it were, it would have been obvious to use it to make perfectly round headlights, steering wheels, etc, none of which are in PGR3.

I'll go back and reword the question slightly so as to remove the absolute statement that is unproveable by me (and i usually hate absoltues myself.)
 
expletive said:
Seeing as a game like PGR3 didnt use procedural synthesis, what would be the sticking point from bizarre not using predicated tiling? The Cockpit/hud views of the game?
Shadowing? HDR tonemapping (post-processing effect)? Who knows...

Once a developer writes an engine that has incorporates manual tiling, how 'reusable' is that?
Probably very. Once you render to 2 tiles instead of using no tiling, then the tile count becomes mildly irrelevant. 3 tiles? 4 tiles?

What causes a problem is if you're trying to render to the back buffer and you're also trying to render to other targets (e.g. for depth of field blur, or HDR bloom). Each of those render targets uses EDRAM, which basically means you have to increase your tile count. And you have to consider whether you want to use horizontal tiling, vertical tiling or "quads" or ...

What do you presume the performance hit for manual tiling, and predicated tiling as you now understand it, to be?
I expect it genuinely is in the region of 5% for typical games. But as rendering techniques advance over the years, who knows?

It does seem, though, that tiling is key to getting the most out of XB360. If you don't use it, then the rest of the 3D engine is ultimately limited (resolution of the screen and resolution/number of render targets). This all stems from the absolute space limitation presented by EDRAM.

Jawed
 
Alstrong said:
is there anything preventing the use of 4xAA outside of the eDRAM? (like PC cards)
The ROPs (which perform AA) are tied to the EDRAM. That's for MSAA.

The only other way to perform AA is to supersample - e.g. render at 1280x720 and then scale to 1/4 res (oh dear: 640x360). If you render at even higher resolutions (say 2560x1480) in order to end-up with a decent resolution after supersampling/down-scaling, then you need predicated tiling...

Supersampling is super slow - it'll use four times as much pixel-shading power for the desired screen-res.

Jawed
 
Jawed said:
But at the same time, I suspect the overwhelming brute force of XB360 allows it to emulate XBox 1 games with an automated predicated tiling for 720p 4xAA, despite the 2x or 3x overheads that "dumb" tiling might incur in games with sohpisticated techniques - e.g. shadowing or depth of field.

But, obviously, that's just me guessing.

Jawed

Maybe thats why none of the Splinters Cells made it one the BC list yet...
 
blakjedi said:
Maybe thats why none of the Splinters Cells made it one the BC list yet...

Rainbox Six 3 has the same engine as Splinter Cell and, arguably, the same quality of lighting and shadowing. Something is not adding up like it should.
 
Great info jawed.

It seems that if every object has a bounding box, you can simply do a 3d to 2d projection of each objects bounding box to get your tile information. That says about 8 verts need to be done per object. Static objects need to be done only once and dynamic objects would need this done every frame, or perhaps dynamic objects only should be done when each particular object moves or the camera moves. This would likely need to be part of the animation system.

Their may be a good deal of savings from doing this on the cpu as opposed to the gpu. Draw calls on the gpu are usually split by materials; this has little to do with position. Objects in the animation system are likely arranged in a hierarchal fashion, where when one object moves several attached objects also move. This hierarchical info can have dual uses in both animation and tiling. If integrated deeply into the animation system the overhead will be very small.

Some novel collision systems already rely on this type of 2d information. If two objects occupy a common spot in 2d space then they may or may not collide in 3d space. But if 2 objects don’t occupy a common spot in 2d space then they definitely do not collide in 3d space. This provides sort of an early out to avoid doing full 3d collision detection for all objects. You can also play with the resolution to make this early out even faster and less accurate, as long as its inaccuracy can only cause false positives and not false negatives. This system falls apart quickly as you compare more objects, but with a small amount of objects it is very fast.
 
Jawed said:
But at the same time, I suspect the overwhelming brute force of XB360 allows it to emulate XBox 1 games with an automated predicated tiling for 720p 4xAA, despite the 2x or 3x overheads that "dumb" tiling might incur in games with sohpisticated techniques - e.g. shadowing or depth of field.
But aren't all the orginal Xbox games are just getting upscaled to 720p, with no tiling needed for the 640x480 with AA rendering?
 
I wonder why MechAssault or Unreal Championship are not on the list... they were the launch titles for Live...
 
Back
Top