So What's a Tessellator?

This has been covered before now in other articles about DirectX 11, but we first touched on the subject with the R600 launch. Both R6xx and R7xx hardware have tessellators, but since these are proprietary implementations, they won't be directly compatible with DirectX 11 which uses a much more sophisticated setup. While neither AMD nor the DX11 tessellator itself are programmable, DX11 includes programmable input to and output from the tesselator (TS) through two additional pipeline stages called the Hull Shader (HS) and the Domain Shader (DS).

The tessellator can take coarse shapes and break them up into smaller parts. It can also take these smaller parts and reshape them to form geometry that is much more complex and that more closely approximates reality. It can take a cube and turn it into a sphere with very little overhead and much fewer space requirements. Quality, performance and manageability benefit.

The Hull Shader takes in patches and control points out outputs data on how to configure the tessellator. Patches are a new primitive (like vertices and pixels) that define a segment of a plane to be tessellated. Control points are used to define the parametric shape of the desired surface (like a curve or something). If you've ever used the pen tool in Photoshop, then you know what control points are: these just apply to surfaces (patches) instead of lines. The Hull Shader uses the control points to determine how to set up the tessellator and then passes them forward to the Domain Shader.

The tessellator just tessellates: it breaks up patches fed to it by the Hull Shader based on the parameters set by the Hull shader per patch. It outputs a stream of points to the Domain Shader, which then needs to finish up the process. While programmers must write HS programs for their code, there isn't any programming required for the TS. It's just a fixed function block that processes input based on parameters.

The Domain Shader takes points generated by the tessellator and manipulates them to form the appropriate geometry based on control points and/or displacement maps. It performs this manipulation by running developer designed DS programs which can manipulate how the newly generated points are further shifted or displaced based on control points and textures. The Domain Shader, after processing a point, outputs a vertex. These vertices can be further processed by a Geometry Shader, which can also feed them back up to the Vertex Shader using stream out functionality. More likely than heading back up for a second pass, we will probably see most output of the Domain Shader head straight on to rasterization so that its geometry can be broken down into screen space fragments for Pixel Shader processing.

That covers what the basics of what the tesselator can do and how it does it. But do you find your self wondering: "self, can't the Geometry Shader just be used to create tessellated surfaces and move the resulting vertices around?" Well, you would be right. That is technically possible, but not practical at this point. Let's dive into that a bit more.

Going Deeper: The DX11 Compute Shader and OpenCL/OpenGL Tessellation: Because The GS Isn't Fast Enough
Comments Locked

109 Comments

View All Comments

  • epyon96 - Sunday, February 1, 2009 - link

    That's very insightful. Can you go into more detail?

    I am confused because there appeared to be significant differences between Dx9C and Dx9B since NVidia made it sound like the difference was like the difference between Dx8.1/2/3 and Dx8.4 which did seem very significant if memory serves me right.

    The difference between 8.4 and 9 seemed minimal in quality of the final output.
  • GourdFreeMan - Monday, February 2, 2009 - link

    The guidelines I spoke of were mentioned on the MSDN Forums circa 2003 regarding how changes to Direct3D would affect DirectX versioning, but seem to have been abandoned in favor of the bimonthly SDK updates following the DX 9.0c release. Bimonthly updates led to faster bug fixes, which in prior versions of DirectX sometimes required a letter update.

    If you are interested in the exact technical changes between DirectX versions, I suggest downloading the old SDK versions prior to the move to bimonthly updates and looking at the Changes section of the documentation.

    Regarding the move between DirectX 8 and DirectX 9, Shader Model 2.0 was introduced making way for games such as Far Cry (admittedly Far Cry was a DX 9.0b game, but the changes from 9.0 to 9.0b mainly involved SM 2.0a and SM 2.0b which for Far Cry meant enhanced performance on ATi and nVIDIA cards). Far Cry would later be patched to support DX 9.0c and SM 3.0, adding features like HDR, but I would argue that the unpatched game still looked considerably better than DX8 titles.

    (Incidentally there is no DirectX 8.3 and 8.4 -- there was 8.1a and 8.1b in the progression instead).
  • epyon96 - Saturday, January 31, 2009 - link

    I wish the article had more background on what you just hypothesized (obviously with some substantiated facts) instead instead of the unnecessary vista bashing. It wound satisfy an actual curiosity.

    I remember that's one of the reasons why the in depth analysis of the development cycle of R770 was so well liked.
  • gamerk2 - Saturday, January 31, 2009 - link

    The issue with DX11 is this: You need to supply a DX10 codepath for those who won't update GFX cards (you can't release a game no one has hardware for), but also would need a DX9 codepath for XP.

    Why would anyone release a game with three seperate grpahics code paths? Its for that reason I see a slow use of DX11, as long as XP holds 15-20% market share.
  • ltcommanderdata - Saturday, January 31, 2009 - link

    If I remember those OS market share reports correctly, as of the end of last year Windows XP had about 65% market share, Vista has about 20% after 2 years, and Mac is nearing 10%. Even if Windows 7 is a roaring success, XP just has too much built-up market share to disappear overnight, so XP and DX9 compatibility will be required for at least another 2 years. The other thing that works against Windows 7 is that even if it isn't released until next year, it's introduction looks to be right in the middle of this economic recession, since things probably won't really pick up until late 2010 or 2011. When the economy does pick up again, there will be huge demand as companies finally switch from XP which would be 10 years old by then, but the first year of Windows 7 sales will probably be slow.
  • bobvodka - Saturday, January 31, 2009 - link

    Well, to be fair, you don't have to have a DX10 path and a DX11 path as such. A few important features work on DX10 cards anyway, such as the multi-threaded rendering stuff, so you need a DX11 and a DX9 path at most; you just have to do some feature detection to find out if you are on a DX11, DX10 or DX10.1 card.

    Still a slight pain, but not as much as 3 real code paths.
  • DarkMadMax - Saturday, January 31, 2009 - link

    And main reason is consoles. There are practically no PC exclusives anymore among large budget titles (e.g. the ones who concentrate on graphics) . So all games target xbox360 hardware (if they dont they are ps3 exclusives). So until new generation of consoles appears there will be no progress in graphics. Period

  • haukionkannel - Saturday, January 31, 2009 - link

    To me, this article mostly talks about new features of DX11 and that some fundamental fealtures can benefit allso dx10 and dx10.1 hardware...
    To me it seems that the Vista part was only there to say why there are not any real DX10 games now, even the features are there. I didn't read it as an Vista hate like many people here seems to think of it.
    All in all it was very good article abou how DX11 can allow those promises that DX10 promised to flourish better this time.
  • scruffypup - Saturday, January 31, 2009 - link

    That though this article was supposed to be about DirectX 11, Derek's bias and opinion about Vista overshadowed the subject of the article,...

    This article shows poor writing at its finest,.. afterall doesn't writing 101 teach one to make the article about the subject you are writing about and not something else?

    Again I say,... Derek does a disservice to anandtech with this bias. If you want to put in your bias towards an unrelated subject,.. at least show clearly the links (relevancy) to your intended subject material and how you come by a conclusion to support that claim other than just spouting off needlessly,... for that is what you have done essentially, as it held no relevance to the subject material the way you wrote the article.
  • chizow - Saturday, January 31, 2009 - link

    Article summary:

    1)DX11 offers nothing new over DX10, as quoted in the article its just a strict superset that builds on and adds features to DX10 capability.
    2)Vista and DX10 sucked because no one wanted to use them.

    Derek, like many others I disagree with your assessment of Vista's importance in the overall OS hierarchy, here's just a quick list:

    1) First OS to bring 64-bit support to the mainstream.
    2) First OS to offer multi-threaded driver improvements. Look at Rel 180 and 8.12 Hot Fix, where multi-threaded drivers are all the rage.
    3) First OS to offer DX10 support. We're finally seeing some of the performance benefits we were promised in DX10 with multi-threaded drivers and improved AA with reading of the multi-sample depth buffer.
    4) Much better OS stability compared to XP. It wasn't always the case, but contrary to your article, most of the problems were fixed in July/August with the various video hot fixes (Ryan Smith can probably confirm or deny this).

    I think Win7 just emphasizes how good Vista is, and how many light years ahead both are compared to XP. You could say Win7 is like Mojave SE, not Vista SE, as you can clearly see all the Vista-haters who are running Win7 glowing about all the features and stability they've missed out on for at least a year (since Vista SP1).

Log in

Don't have an account? Sign up now