3DS to be more powerful than Wii -- Not using Nvidia's Tegra

[Exophase]

FWIW, I've been commonly referring to Imagination's designs as 'TBDR', and as 'tilers' to the rest TBDRs which don't do overdraw elimination. Clearly that's rather arbitrary (and misleading), and I, too, have been considering fixing my terms. I'm considering going with:

* TBDR/OE for tiling/binning scene-capturers that do rigid overdraw elimination, and
* TBDR for tiling/binning scene-capturers in general.

By that convention Imagination's designs would be classified as TBDR/OE, and everybody else (GMA (sans 500), Z4xx/Adreno, etc) as TBDR. I'm also considering using 'just DR' (deferred renderer) for scene capturers in general.

I always thought the "deferred" part in TBDR referred to deferred shading/overdraw elimination approach by IMG (only ones I know of using the TBDR term), not deferred rendering necessitated by scene binning. I mean, now that I think about it I was obviously wrong, especially considering IMR is used as a contrasting term.. but it looks like we were using similar terminology.

Are tilers like Xenon, and by assumption Z4xx, really scene capturing? I mean, I might not understand the concept of operation completely, but it seems to me that instead of collecting all scene geometry then binning it it will render geometry immediately clipped against the tile boundaries, with the option to mark (or maybe remove entirely?) culled primitives and the requirement to render again for other tiles. It seems something in-between immediate and deferred, and also seems like something a modern IMR could mostly (entirely??) do, only lacking the explicit high speed tile memory, that might be serviced similarly with a framebuffer cache.

But I'm probably really showing my ignorance with this post

 

[Rys]

A 1VS, 2PS 6-series class GeForce isn't that far away from Tegra, functionally. The frequency is miles away, though.

 

[Rys]

Are tilers like Xenon, and by assumption Z4xx, really scene capturing? I mean, I might not understand the concept of operation completely, but it seems to me that instead of collecting all scene geometry then binning it it will render geometry immediately clipped against the tile boundaries, with the option to mark (or maybe remove entirely?) culled primitives and the requirement to render again for other tiles. It seems something in-between immediate and deferred, and also seems like something a modern IMR could mostly (entirely??) do, only lacking the explicit high speed tile memory, that might be serviced similarly with a framebuffer cache.

You're pretty much spot on.

 

[aaronspink]

I always thought the "deferred" part in TBDR referred to deferred shading/overdraw elimination approach by IMG (only ones I know of using the TBDR term), not deferred rendering necessitated by scene binning. I mean, now that I think about it I was obviously wrong, especially considering IMR is used as a contrasting term.. but it looks like we were using similar terminology.

There is a matrix.

DR
TBDR
TBR
IMR
etc

The deferred part specifically relates to deferring shading/color until order is known.

Are tilers like Xenon, and by assumption Z4xx, really scene capturing?

Xenon IS NOT a tiler. It is an IMR. The "tiling" comes from the limited framebuffer space due to the size of the embedded memory. The programmer is fully responsible for any tiling that takes place.

It seems something in-between immediate and deferred, and also seems like something a modern IMR could mostly (entirely??) do, only lacking the explicit high speed tile memory, that might be serviced similarly with a framebuffer cache.

No, xenon is fully an IMR.

 

[darkblu]

I always thought the "deferred" part in TBDR referred to deferred shading/overdraw elimination approach by IMG (only ones I know of using the TBDR term), not deferred rendering necessitated by scene binning. I mean, now that I think about it I was obviously wrong, especially considering IMR is used as a contrasting term.. but it looks like we were using similar terminology.

Well, I've always equated 'deferred' with 'capturing', whether it's for overdraw elimination or god-knows-what. Of course i'm not insisting that my side of the terminology is correct - on the contrary, i'm in search of the correct terminology.

Are tilers like Xenon, and by assumption Z4xx, really scene capturing? I mean, I might not understand the concept of operation completely, but it seems to me that instead of collecting all scene geometry then binning it it will render geometry immediately clipped against the tile boundaries, with the option to mark (or maybe remove entirely?) culled primitives and the requirement to render again for other tiles. It seems something in-between immediate and deferred, and also seems like something a modern IMR could mostly (entirely??) do, only lacking the explicit high speed tile memory, that might be serviced similarly with a framebuffer cache.

So what you suggest is clipping your primitives bin-by-bin without capturing? That spares you capturing but takes away from you on-tile blending and cheap FSAA resolves - hardly a good tradeoff, IMO. You could do that on a scene level on an IMR - ie. re-draw your entire scene and clip it bin-by-bin (see Xenos reference below), but that's hardly optimal vertex-wise.

AFAIK, Xenos and derivatives are not ovedraw-eliminating the way Imagination's are, but they are scene-capturing as much as Imagination's. Ok, in the case of the original Xenos - manual scene capturing ; ) ( or ; (, depending on whether you had to ship a product on that - I didn't). IIRC MS/ATI addressed that later into the lifecycle of the paltform with API augmentations.

Here's an ATI/AMD paper from some time ago discussing their idea of a TBR from back then: http://developer.amd.com/gpu_assets/gdc2008_ribble_maurice_TileBasedGpus.pdf - I believe it's quite relevant to Z4xx. Pay particular attention to the 'resolves' topic.

 

[MfA]

FWIW, I've been commonly referring to Imagination's designs as 'TBDR', and as 'tilers' to the rest TBDRs which don't do overdraw elimination. Clearly that's rather arbitrary (and misleading), and I, too, have been considering fixing my terms.

Pixelsquirt (and thus Broadcom) was also deferred I think.

 

[MfA]

Why would you try to capture your scene instead of rendering multiple times with different frustums?

 

[darkblu]

Why would you try to capture your scene instead doing two draw calls with different frustums?

Multiplicity of vertex work and related bandwidth expenditures.

 

[Exophase]

There is a matrix.

DR
TBDR
TBR
IMR
etc

The deferred part specifically relates to deferring shading/color until order is known.

If you consider it a TBDR to be a "tile based and deferred" renderer then yes, I agree. But if you consider it to be "tile based" and "deferred renderer" then I agree with darkblu. "Deferred" can logically apply to either deferred shading or scene capturing.

The problem with applying it only to deferred shading is that there's no opposite term for immediate mode rendering. Or maybe "DMR" should be used? You seem to be using the term "tiler" to include scene capturing for any sort, but that's incorrect because not all scene capturers do so with tiling.

Xenon IS NOT a tiler. It is an IMR. The "tiling" comes from the limited framebuffer space due to the size of the embedded memory. The programmer is fully responsible for any tiling that takes place.

Like here, you can see that you define tiler as being scene capturing/deferred rendering. By definition something that sorts a scene into tiles (with hardware) has to be, but is it authoritative that "tiler" has to mean that? Tiling could instead refer merely to the presence of high speed tile memory. I think "binning" is less ambiguous.

No, xenon is fully an IMR.

Xenon allows for the same basic data flow, in software, that a tile binning renderer would provide in hardware. I don't know precisely what it's clipping is (guard band only or if it can be done at the geometry level instead), which would say something about whether or not the manual rendering of geometry into separate tiles still counts as "rendering" when the geometry is off-tile. It seems at least slightly less black and white then you make it.

But ultimately all of this is just semantics, over terms that are not authoritatively governed. Seems like more focus should be spent on making sure it's understood how things operate and that people know what you're referring to, rather than arguing over what term should be used.

 

[aaronspink]

If you consider it a TBDR to be a "tile based and deferred" renderer then yes, I agree. But if you consider it to be "tile based" and "deferred renderer" then I agree with darkblu. "Deferred" can logically apply to either deferred shading or scene capturing.

It means exactly what a represents: a Tile Based Deferred Render. It defers the scene by binning it into sorted tiles for later rendering.

Like here, you can see that you define tiler as being scene capturing/deferred rendering. By definition something that sorts a scene into tiles (with hardware) has to be, but is it authoritative that "tiler" has to mean that? Tiling could instead refer merely to the presence of high speed tile memory. I think "binning" is less ambiguous.

Tiling itself simply refers to the hardware internally breaking down the scene into multiple smaller render regions.

Xenon allows for the same basic data flow, in software, that a tile binning renderer would provide in hardware. I don't know precisely what it's clipping is (guard band only or if it can be done at the geometry level instead), which would say something about whether or not the manual rendering of geometry into separate tiles still counts as "rendering" when the geometry is off-tile. It seems at least slightly less black and white then you make it.

By that argument ALL hardware renderers are tilers. ATI and Nvidia mainstream hardware have the functionality to clip outside the viewspace and you can set the viewspace to whatever you want.

I think it is fairly black and white. If you want to do any tiling with Xenon, you have to do it through software just like with an RV870 or GF100.

 

[thop]

It could be NEC too.

http://www2.renesas.com/mobile/en/emma_mobile/em_ev.html
http://www.imgtec.com/News/Release/index.asp?NewsID=546

 

[sfried]

It could be NEC too.

http://www2.renesas.com/mobile/en/emma_mobile/em_ev.html
http://www.imgtec.com/News/Release/index.asp?NewsID=546

What's with the IMG link?

 

[Ailuros]

It could be NEC too.

http://www2.renesas.com/mobile/en/emma_mobile/em_ev.html
http://www.imgtec.com/News/Release/index.asp?NewsID=546

I thought EMMA is using SGX530?

 

[darkblu]

It means exactly what a represents: a Tile Based Deferred Render. It defers the scene by binning it into sorted tiles for later rendering.

And so do TB-non-DRs.

The issue with the term TBDR (as used in the context of Imagination's products) is that the 'deferred' portion of it is meant to signify 'overdraw elimination' whereas it says something else - 'scene capturing'. The logical relation between 'deferred' and 'overdraw elimination' is not one of equality - you can be deferred and non-OE at the same time. It all depends on whether an explicit step of occlusion resolution follows the deferring, or not.

By that argument ALL hardware renderers are tilers. ATI and Nvidia mainstream hardware have the functionality to clip outside the viewspace and you can set the viewspace to whatever you want.

Well, duh, of course all hardware renderes could be turned into tilers. It's how efficient they'd be at the task. The reverse is true too - a tiler turns into a non-tiling scene capturer as long as you limit your output to the confines of a single tile.

I think it is fairly black and white. If you want to do any tiling with Xenon, you have to do it through software just like with an RV870 or GF100.

HAL/drivers are software. And I'm yet to see a TB(D)R that does not use software assist for things like binning overflow/emergency flushes. Does that mean TBRs don't exist in your black and white view?

 

[tangey]

I thought EMMA is using SGX530?

it does indeed, SGX530 if i remember correctly

 

[Svensk Viking]

Must the hardware in the 3DS really be that strong to be along the leagues of the PS3/360 when we take the lower resolution into consideration??

 

[sfried]

Must the hardware in the 3DS really be that strong to be along the leagues of the PS3/360 when we take the lower resolution into consideration??

I believe they mentioned something along the lines of "feature set". Whatever the case, hopefully the added flexibility would make it more appealing to developers than TEV (which, at the moment, only a few talented teams seem to grasp...most of them German).

In any case I still don't see how a rival chip supplier (IMG) could be a potential candidate for the Nintendo handheld, unless somebody could explain to me some business semantics that would allow them to do just that.

 

[Exophase]

In any case I still don't see how a rival chip supplier (IMG) could be a potential candidate for the Nintendo handheld, unless somebody could explain to me some business semantics that would allow them to do just that.

IMG is an IP supplier, not a chip supplier, although that's probably not what you meant. What are they rivaling exactly? The only other 3D product Nintendo would have on the market is Wii, which is very far removed from SGX, and I imagine so would Wii's successor.

Or are you saying this because of the rumor that PSP2 is using SGX? In that case, I think even iPhone having it would be considered competition. All three consoles are using CPUs made at least in part by IBM, so I don't really see what would make that sort of thing problematic for 3D.

 

[thop]

In any case I still don't see how a rival chip supplier (IMG) could be a potential candidate for the Nintendo handheld, unless somebody could explain to me some business semantics that would allow them to do just that.

Nintendo isn't in the chip business.

 

[DeanoC]

I think it is fairly black and white. If you want to do any tiling with Xenon, you have to do it through software just like with an RV870 or GF100.

Its not black and white though. Xenon GPU modifies the command buffer
on the first tile with screen space bounding areas so you don't need to use software tiling.
I.e. A valid Xenon GPU Command buffer is
Set Tile 0
Render *GPU calculates tile coverage*
Resolve
Set Tile 1
Render
Resolve

No CPU interaction is required for it to work.

Anything that is not in Tile 1 screen area will be skipped at the command buffer level (i.e. not submitted from the front end to the main GPU units).

So its somewhere in between... argueable the command buffer is a captured scene which the tile unit (actived when rendering Tile 0) writes back data about tile coverage for subsquent tiles.