Xenos hardware tesselator

Discussion in 'Console Technology' started by Graham, Nov 23, 2006.

  1. 3dcgi

    Veteran Subscriber

    Joined:
    Feb 7, 2002
    Messages:
    2,493
    Likes Received:
    474
    It tessellates polygons.

    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.
     
  2. Shifty Geezer

    Shifty Geezer uber-Troll!
    Moderator Legend

    Joined:
    Dec 7, 2004
    Messages:
    44,106
    Likes Received:
    16,898
    Location:
    Under my bridge
    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)?
     
  3. 3dcgi

    Veteran Subscriber

    Joined:
    Feb 7, 2002
    Messages:
    2,493
    Likes Received:
    474
    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.
     
    #103 3dcgi, Dec 2, 2006
    Last edited by a moderator: Dec 2, 2006
  4. Lazy8s

    Veteran

    Joined:
    Oct 3, 2002
    Messages:
    3,100
    Likes Received:
    19
    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.
     
    #104 Lazy8s, Dec 3, 2006
    Last edited by a moderator: Dec 3, 2006
  5. Cal

    Cal
    Newcomer

    Joined:
    Oct 7, 2006
    Messages:
    58
    Likes Received:
    12
    Location:
    Shanghai
    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.
     
    #105 Cal, Dec 4, 2006
    Last edited by a moderator: Dec 4, 2006
    Jawed likes this.
  6. Lazy8s

    Veteran

    Joined:
    Oct 3, 2002
    Messages:
    3,100
    Likes Received:
    19
    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.
     
  7. Cal

    Cal
    Newcomer

    Joined:
    Oct 7, 2006
    Messages:
    58
    Likes Received:
    12
    Location:
    Shanghai
    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.
     
    TheAlSpark likes this.
  8. Graham

    Graham Hello :-)
    Veteran Subscriber

    Joined:
    Sep 10, 2005
    Messages:
    1,480
    Likes Received:
    210
    Location:
    Bend, Oregon
    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 :shocked:
     
  9. pipo

    Veteran

    Joined:
    Jun 8, 2005
    Messages:
    2,628
    Likes Received:
    30
    I was wondering the same thing. Lovin' the info, hate to see you MIA dude...
     
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...