Xenos hardware tesselator

[3dcgi]

Oh, another question about the tesselator... Wich kind of inputs does it accepts? Can I for example send a nurbs mesh to it, so it does its magic and create a polygonal mesh based on that?

It tessellates polygons.

I think these sort of things could be very great modeling wise, you could store a nurbs surface (wich unless i'm mistaken takes less space than a high poly model) and still manage to use a very detailed model in the scene.

(and if you could control in wich direction you tesselate, the vertices would concentrate on the areas more close to the camera, and in theory no matter how close you get, they would still be very rounded right? (not by increasing the poly size, just adjusting so they are more dense where needed))

It would be very nice if all 360 games were like that, because when played on 720, they all could get even better, because it would run with higher poly counts... (ok i'll land back on earth now )

The tessellator doesn't perform adaptive tessellation like this on it's own (it's not automatic). A first pass vertex shader can calculate factors that are input to the tessellator on the second pass. The tessellator will use these factors to determine how to tessellate.

 

[Shifty Geezer]

It tessellates polygons.

It had no HOS support directly? So HOS needs to be handled by the CPU and sent as data to tesselate and displace a polygon mesh?

How does this relate to PSP? IIRC PSP has inbuilt support for NURBS patches. Does that work the same way only on the CPU (which makes support of NURBS as a feature moot as any processor can do that!), or does it have a hardware tesselator of sorts? What are the results for NURBS in PSP? Do they work well and point to a feature other devices would benefit from? Or are they a pointless addition that no-one touches (and if so, for what reasons)?

 

[3dcgi]

It had no HOS support directly? So HOS needs to be handled by the CPU and sent as data to tesselate and displace a polygon mesh?

How does this relate to PSP? IIRC PSP has inbuilt support for NURBS patches. Does that work the same way only on the CPU (which makes support of NURBS as a feature moot as any processor can do that!), or does it have a hardware tesselator of sorts? What are the results for NURBS in PSP? Do they work well and point to a feature other devices would benefit from? Or are they a pointless addition that no-one touches (and if so, for what reasons)?

I don't know the capabilities of the PSP and I'm rusty on the Xenos tessellator though I don't remember NURBS being mentioned as a scenario. NURBS aren't as popular as subdivision surfaces these days anyway. I've never worked with NURBS, but it might be possible to convert them to polygons in the first pass vertex shader and then feed them to the tessellator. Maybe someone else can give some more detail here.

Edit: I looked it up and NURBS are not mentioned in the docs. Polygon based HOS like SubDs and patches are supported.

 

[Lazy8s]

PSP apparently has hardware accelerated tesselation of bezier patches and B-splines.

It's limited to a fixed LOD between adjacent patch edges -- otherwise seams open up -- and limited to integral tesselation; it's not likely to serve as a blueprint for future curved surface processing implementations.

 

[Cal]

Cal, The depth pass, I have a vague memory of reading that the depth fill only pass was required (or at least strongly recommended) when using tiling.. Is this correct? Help out what tile geometry gets binned iirc

No, the pre-zpass is not required by predicted tiling. The main purpose of pre-zpass is to generate hierarchical Z data. To utilize the early pixel quad rejection via Hi-Z, you must implement a pre-zpass. According to XDK, predicted tiling will automatically use the Hi-Z data to gain performance if there are pre-zpasses in each tile.

As for pre-zpass, X360 D3D implemented a couple of routines called BeginZPass and EndZPass which can be nested within BeginTiling and EndTiling calls. BeginZPass and EndZPass record the command buffer for any draw calls between them, and then automatically run a zpass and an actual rendering pass. But you cannot get the correct result via an automatic pre-zpass when things like alpha test is presented.

The tiling mechanisms are different between the situations with and without automatic pre-zpass. When there're no auto pre-zpass in predicted tiling, the screen extent captures (screen space rectangles which determine each draw call's extent) will be calculated during the rendering of the first tile. The GPU then stores these captures into a separate buffer for speeding up the rendering of succeeding tiles. When an auto pre-zpasses is applied in each tile, the screen extent captures are done within the pre-zpass, which somewhat can increase the performance for the succeeding actual rendering pass.

 

[Lazy8s]

Tiling techniques and the balance of graphics workloads should keep memory requirements for binning manageable for TBDRs. Utilizing a hierarchy of tiles, only a fraction of the scene needs to be binned at a time. Polygon rates aren't excessive anyway, and their growth has already plateaued.

TBDR does trade latency for performance, but the results from products like PowerVR's processors show the approach to be a win-win.

 

[Cal]

It had no HOS support directly? So HOS needs to be handled by the CPU and sent as data to tesselate and displace a polygon mesh?

How does this relate to PSP? IIRC PSP has inbuilt support for NURBS patches. Does that work the same way only on the CPU (which makes support of NURBS as a feature moot as any processor can do that!), or does it have a hardware tesselator of sorts? What are the results for NURBS in PSP? Do they work well and point to a feature other devices would benefit from? Or are they a pointless addition that no-one touches (and if so, for what reasons)?

Of course you can implement HOS on X360. The hardware tessellator does not take the response for calculating the actual XYZ position of each new generated vertex, but gives a UV position related to the original input vertices instead. It's the succeeding vertex shader which calculates the actual XYZ position for new generated vertices. That means you can implement HOS in your vertex shader.

The following text are direct from the SDK:
"Higher-Order Surface Support
The GPU supports higher order surfaces using a tessellation unit. The tessellation occurs before vertex shading. The tessellation unit supports discrete or continuous tessellation of N-patches, triangular patches, and rectangular patches. The tessellation unit does not actually compute positions; instead, parametric values are passed to the vertex shader. More complex higher order surfaces such as adaptive tessellation, NURBs, and subdivision surfaces can be implemented either using multiple shader passes or using the CPU to do part or all of the processing."

In addition, the vertex shader on Xenos has ability to randomly access input vertex stream and index stream via a set of vfetch instructions, just like pixel shader can randomly access a texture via a set of tfetch instructions. The N-Patch example in XDK uses vfetch to caculate vertex position.

 

[Graham]

Wow that's way more information than I was expecting
Answers a lot of smaller questions I had.

But I can't help wondering if you are actually allowed to post that

 

[pipo]

But I can't help wondering if you are actually allowed to post that

I was wondering the same thing. Lovin' the info, hate to see you MIA dude...