Greetings:
This is possibly a dumb question that came to mind reading about the tessellation shader: Is the TCS really needed?
Here’s where I am coming from. The TES can see the all the output vertices per-patch coming from the TCS. So, if the TCS simply passed on its input vertices to the the TES, then couldn’t the TES process the input to the TCS in exactly the same way the TCS meant to? Meaning that the TCS is redundant beyond passing its input on to the TES. Ok, the tessellation levels are set in the TCS too but this function could easily be transferred to the TES.
Can you give me an application which needs one to program TCS in an essential way?
The TCS is optional. You can use a TES without a TCS.
That would mean that the TES performs any per-patch calculations for every invocation. If a TCS is used, it can perform any per-patch calculations (e.g. converting Bezier control points to polynomial coefficients) so that the TES doesn’t have to perform those calculations for every vertex.
Note the the use of the term “vertices” to describe non-“patch” TCS outputs is … nonsense, basically. They typically aren’t vertices in any meaningful sense of the word. The TCS’ outputs are per-patch or per-invocation. The point of having per-invocation outputs is to allow the calculations performed by the TCS to be parallelised.
If a TCS does nothing but pass on its inputs (and the tessellation level is fixed), there’s no reason to use one.
No it couldn’t. The number of tessellation levels is required to determine the number of TES invocations and the gl_TessCoord values passed to them.
Thanks a lot, GClements.
I did know that the TCS is optional. What I was wondering if it is at all needed. So here’s what I understand from what you say:
The TES could potentially do all of the computing that the TCS does but it wouldn’t be able to parallelize this computation. This is because the TCS can parallelize calculations over invocations (one per output vertex or output patch member, however you call it), while if this work were to be done in the TES it would have to be done serially in the TES’s main. The TES, on the other hand, can parallelize over its invocations, which is one per tessellation vertex produced by the TPG.
So, the main premise of the 2-part tessellation shader architecture is enabling parallelization separately over two sets of invocations (one in the TCS and one in the TES).
Correct?
PS. Yes, the TCS determines as well the tessellation levels for the TPG. As also the TES configures the TPG with its layout(primitive, …) command. My point here is that even though the TCS and TES combine to configure the TPG, the specs could easily be modified to allow the TES alone to do this - because it has access to all the data that the TCS has access to.
It’s not so much that it won’t be parallelised, it’s that it will have to be re-done for every TES invocation.
The TCS allows parts of the computation which are per-patch to be performed only once. Effectively, it allows some computations to be moved out of the “loop”.
Being able to split the work across multiple parallel TCS invocations is a bonus, but is not required in order for the TCS/TES separation to be useful. Even if you use a single TCS invocation (vertices=1) with all outputs being per-patch, it still allows you to reduce the amount of computation which needs to be performed by each TES invocation.
[QUOTE=chachacha;1281327]
My point here is that even though the TCS and TES combine to configure the TPG, the specs could easily be modified to allow the TES alone to do this - because it has access to all the data that the TCS has access to.[/QUOTE]
The answer is still “no”. The fact that the TCS and TES have (or could have) access to the same data isn’t relevant; they do different jobs. The TCS is run a fixed number of times per patch, generating a fixed set of outputs each time, along with the tessellation levels which determine how many times the TES is run for that patch and with which gl_TessCoord values.