10

It seems counter intuitive that calculating more vertices instead of just reading more from vram would be faster. But if memory bandwidth is the issue that makes tessellation worth it, then why do things like displacement mapping exist? In the tessellation shader, if you read from a texture, you accessing vram more anyway. Are texture look ups less expensive than more original vertices? Why is tessellation fast?

Say you had an vertex amplification of 32 with a very low polygon model. Would this be faster than say a higher polygon model with only a tessellation vertex amplification of 8 or something. Or in other words, do you linearly gain performance with the more you tessellate?

Thomas
  • 6,032
  • 6
  • 41
  • 79
  • Are there any games that can be used to compare frame rates with tessellation enabled / disabled? Tomb Raider (2013 version) includes tessellation, but it's tied with more realistic hair movement (similar to Alice Madness Returns hair movement), so the frame rate ends up slower. – rcgldr Jul 17 '14 at 02:02
  • @rcgldr i think you can use this benchmark https://unigine.com/products/heaven/ – JAre Jul 17 '14 at 02:08
  • 1
    Remember that displacement mapping was used *before* the cards supporting tesselation appeared. Fast tesselation requires hardware support, but when you have it, it's indeed very efficient. – Bartek Banachewicz Jul 17 '14 at 08:49

4 Answers4

8

There is no single point that gives tessellation better performance in every possible instance. Different benefits and trade offs apply in every use case. Some things that might contribute to making tessellation faster than alternatives:

  • Memory Bandwidth: Modern computers are largely limited by memory speeds. Even if you use textures, a single read could be as low as 4 bytes instead of the 32+ bytes typically required to store vertex data.
  • Level of Detail (LOD): With tessellation shaders you can avoid having areas that too detailed while still insuring that the rest of the scene has sufficient detail.
  • Fewer Verticies: Means fewer executions of the vertex shader and every stage of the pipeline before that.
  • Less CPU Overhead: Potentially requires fewer draw calls, especially if you no longer have to do LOD on the CPU.

There are probably other factors that I have missed...

fintelia
  • 1,201
  • 6
  • 17
5

There's always a trade off between processor and memory. Tessellation is a way that you can save memory and bandwidth but at the cost of GPU performance.

Why you should use tessellation: Tessellation with displacement maps significantly reduces memory bandwidth for animated or multi-instance objects in the scene. But its not very useful for static single objects.

Lets say you have a sprite that is running across the screen. If the sprite is a high detail (1 million plus vertices) then each time the animation routine moves/deforms the mesh, all 1 million vertices are transformed and reloaded to the GPU each frame.

However if you use a low detail model (50-100k vertices) with tessellation and displacement. Then you store the displacement map on the gpu once. you update the 50k mesh for animation and reload significantly less mesh each frame, then the GPU tessellates up to 4-5 million virts using the displacement map which is already loaded.

The end result is that you get 2-4x the mesh detail with 1/20th the memory bandwidth. Now imagine you have 20-30 of these sprites on screen at a time.

Why you should not use tessellation: To add this detail on the fly the gpu has to burn up processing power in order to calculate the 3d position of each tessellated vertex before it starts running all the other shaders.

The major distinction you need to watch out for is that this only helps you when you are instancing and/or animating geometry.

If you have a high detail static mesh that never moves and only have one instance of it on the screen, then it is faster to upload the geometry in full detail. Tessellation would just add complexity and eat up cycles in the pipeline.

There is a trade-off: There is a slight memory bandwidth perk you get by using tessellation for static meshes. Because vertices need 3 coordinates of floating point to be understood by the gpu. But sampling a displacement map uses 1 coordinate of fixed point data to be useful. Because the displacement map is normalized against adjacent vertices. So it calculates the extra data on the fly. But this calculation is performed every frame for each tessellated vertex. This eats up shader time that would not be needed if you used static mesh.

However if you turn the tessellation down or off for LOD purposes it SAVES shader time for objects that don't need detail, compared to a high detail static mesh.

So tessellation is always a good idea for improving detail on dynamic/instanced meshes.

But for static meshes or singleton meshes, its a trade off between LOD capability and pipeline complexity. A high detail mesh in the distance is burning up more compute time then a tessellated mesh with tessellation turned off. But a high detail mesh in the foreground takes up less compute time than a tessellated mesh with tessellation turned up.

One big thing to consider however is that slowly turning up the tessellation as an object gets closer, looks way better than instantly replacing a low detail mesh with a high detail mesh. So when smooth LOD is a big concern then definitely go with tessellation. ...or use tessellation to a certain point, then replace it with a high detail mesh. But that's only a good idea if you are not worried about running out of memory and keep both versions on the gpu at all times. Otherwise you will be burning up bandwidth again swapping them around.

Again, always a trade off between memory usage and processor usage.

guymella
  • 291
  • 3
  • 3
1

The point of tessellation is that you use more vertexes where it is useful (close to the camera) and fewer vertexes where it is less useful (distant from camera). So you can get the effect of much more detailed geometry without having to use it everywhere in the scene.

Chris Dodd
  • 119,907
  • 13
  • 134
  • 226
  • I know tessellation has the benefit of LOD like you say, but I also read that tessellation improves performance of rendering models even if it's going to be at full detail anyway. True or false? And like my question is asking, if true then why. – Thomas Jul 17 '14 at 03:27
  • 1
    @Blaz: I think the key is that processing performed before tessellation works on a reduced number of vertices, so there's less work. Later it is expanded to the full number of polygons, so there's no saving on processing steps after tessellation. – Ben Voigt Jul 17 '14 at 03:50
  • @BenVoigt Could you make an answer and explain this a little further perhaps? If you have a typical lightweight vertex shader that just multiples by a matrix, this would be about the same cost math wise compared to interpolating between vertices as with tessellation. – Thomas Jul 17 '14 at 15:56
  • @BlazArt: The point of tessellation is that its NOT going to be at full detail (maximum LOD) everywhere -- geometry far from the camera will be at reduced LOD. If you bypassed/disabled the tessellation so that everything was at full LOD, obviously there would be no benefit because you're disabling it. – Chris Dodd Jul 17 '14 at 19:02
  • Actually I think tessellation is worth for performance only if you are limited by other factors: dynamic LOD limited by CPU? tessellation can move the load to GPU. Integrated GPU with no dedicated memory severely limited by BUS bandwith? Tessellation generates vertices on the CPU cache => high number of vertices with low bandwith on the BUS. You don't have enough VRAM? generates on the fly vertices without having to pre-store them. You need special effects like waving grass or waves in water? => tessellation make it easy and realistic – CoffeDeveloper Jul 18 '14 at 15:45
1

(In the context of OpenGL) As others have already stated, the use of tessellation can be thought of as a trade between gpu compute time being increased, and a reduction in bandwidth between the application and OpenGL.

Which makes sense when you think about it right? If you're not sending all of the vertices over, there must be some method available to obtain their positions.

Most modern applications define a model(a collection of vertices etc etc.) somehow, and then send it over to the gpu. One time, thereby negating the majority of use cases in which you would want to prefer Tessellation to increase "performance" (performance being higher framerate/ lower execution time I'm assuming) So long as you have enough available memory left on the GPU do this.

In the case of animation, you do not have to send up the modified vertices of the model replacing the information already in gpu-memory. Most modern applications use a collection of bones, and weights that can even exist on the gpu. You send up a uniform variable like time,and that is all that the application is required to do. The rest is done on the GPU.

Even a statically predefined set of LOD meshes can be uploaded to the GPU before you enter into a main display / rendering loop. The trade off is that you will not be able to control the granularity of detail even nearly as closely as you would be able to with tessellation.

So if we can modify the data on the gpu without sending more data from the application than if we were using tessellation, why or when would we EVER want to use tessellation?

  1. As others have already stated, absolute control over LOD is one good reason.
  2. Dynamic content generation. It is a whole lot more efficient (faster in frames/execution time) to let the gpu ADD vertices in place than to send over a whole new mesh you generated on the CPU or even new "bits" of the mesh from the application.
  3. When you have already filled up every iota of memory on the gpu and you simply can't store anything else in buffers.

A simple conclusion in summation. How can tessellation increase performance?

When it is impossible to define and upload vertex data from an application to a gpu BEFORE you begin rendering. That is the only time tessellation is the right decision. More often than not, this is untrue.

user134143
  • 13
  • 3