Evening all,

So I got back from the summit on Friday lunchtime and have, or so it seems, spent my entire weekend ironing work clothes for Monday. Figured it was about time I updated my journal and had a play around with some coding.

As I posted about last time I spent the previous week (1st to 4th March) in Seattle, in particular the Monday and Tuesday at the Microsoft campus in Redmond. It's the third time I've been out to the campus and I've encountered the DX team in 3 different buildings (9, Millenium and 85) which seem to be in completely different geographical locations. To say the campus is large would probably be an understatement! Struck me, like previously, that the offices are very quiet on the MS campus - but that could just be that I'm coming from a large open plan office where the only P&Q I get is after everyone else has gone home...

Anyway, the real point was to visit the DirectX team ([cool]) and not just chill out in empty meeting rooms drinking coffee (enjoyable as that is). Myself, Richard (legalize), Matt (MJP) and Gilad (Sirob) as well as occasional guest visits by other DX/XNA MVP's (inc. remigius) spent most of the two days holed up in a meeting room with the PM's, designers and developers of all aspects of the core Direct3D software. It was a really awesome couple of days, so I'll say a big thank-you to the Microsoft DirectX guys for spending a whole two days with us - we didn't have to resort to hunting the corridors and dragging them out kicking-n-screaming [grin]

I can't pass on what I learnt (thanks to our NDA) but I doubt I'm revealing anything by saying that they'll be announcing things over the next few releases/conferences/whenever that will be worth listening to and well worth checking out. In particular I'm very pleased that the summit wasn't just about us hassling them with questions and there was a definite two-way dialog where they seemed genuinely interested in our thoughts. Regardless of whether they act on our recommendations I'm confident that they will have at least taken our input and used it to form whatever action they want. In my case the opinions and recommendations I voiced are largely influenced by the members of this community and the many threads on the forums so I hope the wider community likes the outcome [smile]

One of my more selfish moments in these two days is when I monopolised the Q&A to deep-dive into tesselation, and Amar (one of the designers on the HW/IHV side) did an excellent job of walking through the new pipeline units. I attended with a list of very specific questions and problems and left that meeting with a good feeling that I'd had them answered, which should mean I can take my broken tesselation sample and bash it into shape. I'll be working on making a sample/article out of this information as and when time permits, but I also stressed to MS that if they want procedural/tesselation based graphics to take off that they need to put out some simpler samples. Even Matt, who created the SubD11 sample, admitted it had been a little challenging!

Without further ado, my newly acquired tesselation knowledge:

1. Indexed geometry works just the same for control meshes as traditional triangles.
   When using the correct IA topology you can now send much more arbitrary lists of control points (up to 32) down to the programmable units using just the same indexing as you'd like to use. Whilst this should've been obvious it was good to get it confirmed.
   
   
2. The Hull Shader can amplify data.
   It is perfectly valid to feed in a triangle control mesh (=3 CP's) and emit ten new control points (as in the Curved PN Triangles paper). However, the only data visible further down the pipeline is that emitted by the HS. If you don't emit the original three CP's then they are lost forever more.
   
   
3. There is no specific semantic for defining which field gets tesselated post-HS.
   I got a little stuck with this one as I thought I might need to indicate which data (e.g. which float3 from a Pos+Norm+Col output). My confusion was in over-estimating the fixed-function tesselator - it really doesn't do anything very clever! The control points are irrelevant to the FF unit and really only for the shader writer's algorithm and do not need to be used by the tesselator (hence no special semantic). Everything is done by the SV_TessFactor and SV_InsideTessFactor outputs from the HS constant function which allows the FF unit to tesselate on a completely abstract barycentric coordinate space. It's much easier understand with diagrams [wink]
   
   
4. Control point output ordering from the Hull Shader is maintained and guaranteed.
   The Domain Shader can see the outputs of the Hull Shader (which, as mentioned above, does not necessarily contain the original control points fed in by the IA) and if you output them in a known order in the HS then that order is still the same in the DS. You can do float3 cp = p[3]; in the DS to obtain the result of the HS invocation for SV_OutputControlPointID = 3.
   
   
5. The float3 barycentric coordinate received by the Domain Shader is a new vertex.
   Your code is responsible for using that position and the control points created by the Hull Shader to determine a new vertex.
   
   
6. The Domain Shader (or, like in D3D10 the Geometry Shader) now takes on much of the responsibility that the Vertex Shader used to have.
   For the longest time the sole purpose of a VS was to map whatever inputs to a projection space output (as POSITION/SV_Position) but now this is pushed down to the Domain Shader, or the Geometry Shader (likely to be more efficient in the DS than GS).
   
   
7. The above point also serves to highlight that you have FULL control over the coordinate spaces
   Prior to emitting to the SV_Position semantic pre-rasterization you can pass control point or new vertex data around in whatever space you want - tangent, model, world or projection.
   
   
8. The CullMode and FillMode rasterizer states will work as expected
   The name, 'rasterizer state', gives it away a little - they occur after all tesselation and are thus independent of this pipeline configuration - tesselated or traditional. Thus with a HS/DS kicking in you should see the wireframe mesh for the newly generated triangles and not just the input control mesh.
   
   
9. Curved PN triangles can be implemented in D3D11's HS and DS
   BUT there is a caveat that the cubic position interpolation and quadratic normal interpolation don't easily fit. So you either need to make them both cubic or both quadratic or, possibly, output 16 control points (0-9 = position, 10-15 = normal) for the 10+6 variations and decode accordingly in the DS.
   
   
10. Debugging tesselation.
    Unsurprisingly PIX for Windows will eventually allow for shader debugging and/or pipeline debugging, but for now thats not even slightly useful. I really pressed the team for some debugging ideas:
    
    • Use the SO stage in conjunction with the GS.
      Absolutely genius idea this one - simply pipe each triangle to memory via Stream Out and analyse it back on the CPU via usual printf debugging. Tedious for large data sets, but for a simple two-triangle quad like mine its not a problem. More abstractly you can start using SO as a sort of log file for the pipeline - why not append various intermediary outputs to the HS/DS dataset and decode them on the app? The only case you should get no output is if you're culling geometry, which should only really happen if you're setting SV_TessFactor and/or SV_InsideTessFactor to zero.
      
      
    • Be guided by the device queries
      Apparently it should be possible to track the number of VS/HS/DS/GS/PS invocations from the application regardless of what the IHV's want you to (not) know. D3D11 exposes D3D11_QUERY_PIPELINE_STATISTICS as a query that returns the appropriate counts via a D3D11_QUERY_DATA_PIPELINE_STATISTICS struct. In my current case where my pipeline was literally outputting NOTHING this information could be useful to see what was(n't) actually active. PIX will eventually replace this, but for now a neat trick I hope!
      
      
    • Implement in Direct3D 10 with the Geometry Shader, as per the SubD10 SDK sample.
      This only really works for algorithmic development (e.g. working off a SIGGRAPH paper) and not debugging a proper 11 pipe, but worth noting nonetheless.
      
    
    
11. Diagrams are your friends
    Finally, and possibly a little obviously - draw diagrams of the pipeline. Or if you can't be bothered, wait for me to publish my Visio diagram. Visualising the flow of inputs and outputs between stages as well as drawing the data as it passes through is incredibly useful. When Amar drew all over the whiteboard and annotated it with all my questions it became a lot more intuitive.
    

Hope the above is useful - I've noted that so sparse is the tesselation information that my journal is featuring quite highly in search results now!! Maybe the above tidbits of info will help you get up and running with what, imo is one of two cool new parts of D3D11 (the other being multithreading).