ARM Mali-400 MP

[rpg.314]

If you have done the spatial binning for all the triangles, is it really much harder to make a deferred renderer over a early-Z renderer.

 

[darkblu]

If you have done the spatial binning for all the triangles, is it really much harder to make a deferred renderer over a early-Z renderer.

Surely JohnH would give you a much better answer, but hypothetically, it should not be that much more difficult - you need an extra pixel ownership test/enumeration step during the shading stage. That also introduces certain interesting moments with partial derivatives & co, in situations where you don't have enough neighbour pixels of the same draw call, to trivially compute deltas with. But that's not unlike similar situations that arise from the use of fragment discard ops, or mere z-early-out, in any other rasterizer architecture.

 

[JohnH]

Had this one out with aaronspink/darkblu/et al once.

It's deferred and not immediate in the sense that it's scene-grabbing instead of rendering primitives as they're issued.

It's not deferred and is immediate in the sense that it performs full rendering (minus early-Z elimination) within a tile as opposed to having a fast internal Z-path and then index based rendering.

Technically I'd agree, however within the industry TBDR i.e tile based deferred rendering has always referred to PowerVRs particularly brand of tile based rendering. Trying to call Mali a hybrid IMR/TBR is just marketing smoke and mirrors to try and claim that they have something clever, when in fact it's just a bog standard tile based renderer that is missing one of the useful optimisations that TBDR provides.

An important distinction between it and z430 is that it appears to have more explicit tiling and a fixed small (16x16) tile size, and therefore probably has a hardware binning pass prior to geometry as opposed to binning with geometry with skips for already binned polygons. This probably saves a lot of bandwidth in comparison, but like IMG I imagine they employ some kind of compression on their post-transform data. PowerVR should be as "traditional" as you get, having been the only tile based renderers for years, but yeah, there are clearly holes in their statements.

I'm pretty certain that ARM's binning process is very similar to PowerVR's, with the exception that they do bounding box based tiling instead of perfect tiling.

To the best of my knowledge the Z430's "tiling" processes the incoming geometry twice, once to tile it and once to rasterise it. This works fine within a closed system (the XBox360) that has a very large tiles but rapidly falls to pieces with smaller tile sizes and in an open API where applications can and do modify their VBO's mid scene.

What I've always wanted to see was a tile-based early-Z renderer with hardware binning that also performed some level of depth sorting. If it's going to bin per-tile anyway this can't be that much more expensive (or maybe it can, I don't really know the binning algorithms and haven't thought this through that thoroughly). That'd make early-Z much more effective, and if you also add in binning of opaque vs alpha primitives you'd get order-independent translucency too... seems like it'd bring the per-pixel savings much closer to TBDR (especially w/faster than fill early-Z) while not having highly costly alpha test and having order-independent translucency.

The problem is that you need to avoid nlogn time (or worse) within the binning process, although possible this is actually non trivial in HW and can also result issues with memory access patterns. Alternatively you could apply an up front tile resolution Z test but this doesn't work well as the absence of per pixel Z values makes it difficult to reject based on the Z extents of anything other than objects that fully cover the tile.

John.