Xenos hardware tesselator

Believe it or not, pre-render CGI can reach upwards of 256xAA.

 

the digital cinematographers currently use 4k progressive.



http://en.wikipedia.org/wiki/Digital_cinematography

 

It's a good thing we don't have those huge screens then...

 

I imagine that this'll be something of a holy grail. Higher resolutions have no benefit in the screen sizes these 1080p sets get to. 8xAA would elliminate much of the jaggyness. You could probably stop at 1080p 8xMSAA and put all efforts into shading etc., rather than upping the resolution and AA to little obvious effect (if any noticeable effect).

 

Yes.

Jawed

 

You can do very fast instancing of particles for example.

Yes, you can do adaptive tesselation with memexport and then feed the tesselator. It's pretty flexible.

It's very hard to compare at this stage. I would expect that current DX10 GPUs are not optimised for a large fan out from the geometry shader (when you basically produce more primitives than the primitives coming in), which is exactly where you want to use the hardware tesselator. But I can also expect that the mere raw power of a DX10 GPU can more than make up for it.

No need to thank me

 

This patent application has some nice diagrams that give an overview of the methods:

Unified Tessellation Circuit and Method Therefor

and there's this too:

Method and Apparatus for Dual Pass Adaptive Tessellation

Jawed

 

Well actually, at least one dev (MotoGP3) has gone with 1280x1024. With the formula from the Xenos article that'll give you...

Question is... Is scaling from a 5:4 pixel to a 16:9 pixel better or worse than scaling a 4:3 pixel to 16:9? Keep in mind that the former needs only vertical scaling and the latter requires scaling on two dimensions... (assuming 720p output)

 

Ugh, why every thread about 360 strayed to predicted tiling, and then someone directly connected deferred shadowing with deferred shading to mess up things further, even these two are totally irrelevant.

Back to the topic, I haven't test the N-Patch performance on my 360 kit. But one thing I can ensure you is that displacement map via tessellation + vertex texture is far better than those relief/occlusion/parallax/horizon/whatever mapping, quality wise. Those micro-surface raytracing techs will just give you a full screen of jaggies. On performance side, thinking about how many possible passes a mesh have to be rendered: a pre-zpass, a shadow pass, an actual rendering pass, some potential additional passes for things like subsurface scattering. In each of them you have to use tessellator to ensure the correct result. If the engine does not take care things like avoiding to produce too many vertices, matching shadow pass's tessellation exactly with rendering pass's to get correct self-shadow, then you're screwed. So I think using tessellator is a big risk on performance.

 

What kind of post processing are you referring to? The tiles in EDRAM are resolved back to the system memory after rendering and the post processing can be done with the whole framebuffer (in system memory) as a fullscreen texture (no tiling during the post-processing rendering).

 

Thanks Cal. That is exactly what I thought.

 

Depending of definition, human acuity is limited to ½ or 1 arc minute of angular resolution. That means that you won't even detect jaggies if you're sitting 3-5 meters from a 42" 1080 panel.

What is very easily detectable however is moire and other lack of filtering artifacts.

Of course doing a 8x super sampling of the picture would resolves much of that

But effort is probably better spent on improving filtering (AF and in-shader filtering)

Cheers

 

I don't suppose one of you 360 devs could run an AF testing program ala the one used to compare the G80 to previous GPUs... Just curious as to how good it is with angles.

 

I can't imagine that looking better than 2xMSAA, because the diagonal sample placement helps a lot. It would be a lot more expensive too.

 

On NEC's 45nm EDRAM process (2009 is their plan), 64MB of EDRAM is only 45mm2. That's only going to be maybe 10% of the total silicon in a console. If we can get 100 GPix/s alphablending, that's good enough reason for me. "Execution logic" can only do so much in certain tasks.

Regarding the holy grail, I'd say 4xAA is plenty for a console at 1080p, and 32bpp is plenty for HDR, so that's why I used 64MB.

 

This is off topic of the tessellator, but I looked this up and the caveat was this might be slow because you might perform the same memexport twice, but the docs didn't say it can't be done.

 

D3D will fire an assert if you try.

 

The cost of a wide external bus or die area for embedded DRAM are not the only resources to trade against to solve the bandwidth issue. The rendering pipeline could afford some deepening to offer a more optimal approach.