Is AMD's tessellation still way behind Nvidia?

[cmdrdredd]

Does Global Illumination in UE4 run faster with DirectCompute or without? If Dirt 3 is poorly coded, that's a different argument entirely. Also, we don't know the performance hit in FPS in UE4 with and without global illumination unless you have a link to benches? You are also assuming Global Illumination in 1 game equals another. Just like tessellation is game dependent, so is GI. Hitman has Global Illumination but the performance hit is not at all like it is in Dirt 3.

As far as I know it's all done in directcompute in their demos, at 60fps, at 1080p, with a 680.

 

[HeadlessKnight]

Hello!

This is my first post in Anandtech.

I have an old benchmark with Crysis 2 with both GTX 670 OCed and HD 7950 OCed. It might be useful to this discussion.

BTW I don't own the GTX 670 anymore.

The GTX 670 is tested in Windows 7 with 306.63 drivers @ 1328/7452 (golden card)
Drivers are a bit old, so is the picture (Oct 2012) but I doubt the newer drivers increased the performance drastically in Crysis 2.

I got these scores .



HD 7950 tested in Windows 8 @ 1185/6500 (pretty average overclock) . Also the font is bigger due to DPI @ 125%. using latest beta driver.



I think real world Tessellation performance based on this test is roughly the same this generation between AMD and Nvidia. And considering Crysis 2 was always a game that runs better on Nvidia hardware, HD 7950 results are not too shabby at all .

 

[ocre]

Itsmydamnation,

there is nothing you cant get with adding and subtracting that you can get with multiplication.

 

[ocre]

Tessellation is awesome because it allows devs to create very detailed environments very easily. Tessellation is not some kind of magical process that will somehow make ray tracing possible or change it into being anything different than making polygons out of shapes. It is more than just saving bandwidth, what it isn't is anything magical.

I can agree with you. Tess is not magical. I am just saying it can be much more than a compression method. It can save bandwidth but it could be far more useful.

I believe we will see this after next gen consoles take hold

 

[itsmydamnation]

Itsmydamnation,

there is nothing you cant get with adding and subtracting that you can get with multiplication.

that's not a valid comparison because there are things you can do with normal geometry that you cant do with tessellation. kind of like how you can do integration without doing calculus but you cant do calculus without integration.

 

[Jaydip]

Oh my god you are unbelievable.



Situation 2 takes LESS BANDWIDTH than situation 1. What else do you call it when you perform the SAME TASK with LESS BANDWIDTH?









Using tessellation creates the original representation, the sphere, with fewer bits than the original representation.

Please take a moment to consider how inept you are to call tessellation "not compression"

How?(we can create a sphere in many ways) We can use every single vertex and use tessellation on it which would be computationally very intensive.There is no compression going on here.

 

[ocre]

that's not a valid comparison because there are things you can do with normal geometry that you cant do with tessellation. kind of like how you can do integration without doing calculus but you cant do calculus without integration.

wrong. You got it backwards...... again

in my comparison Tessellation is the multiplication.

 

[itsmydamnation]

wrong. You got it backwards...... again

in my comparison Tessellation is the multiplication.

im not wrong at all, Tessellation is limited by the initial geometry. If initial geometry is addition or subtraction then tessellation is NOT multiplication because there are things you simply can not create with tessellation from the base geometry regardless of what you do, which you could do by simply adding more geometry.

In that regard i am completely correct in my assertion that you quoted. Which still has little to do with my initial point anyway, that tessellation is nothing but a form of compression. If someone wanted to create a jersey barrier like the tessellated ones from crysis 2 there is nothing stopping it. All that tessellation has done is delivered that barrier at a far cheaper cost to parts of the GPU pipeline.

 

[serpretetsky]

Besides saving bandwidth, doesn't tesselation also allow for seamles LOD (level of detail) which means it's much easier to allow the video card to not render unnecessary geometry that is far away?

 

[Piroko]

im not wrong at all, Tessellation is limited by the initial geometry. If initial geometry is addition or subtraction then tessellation is NOT multiplication because there are things you simply can not create with tessellation from the base geometry regardless of what you do, which you could do by simply adding more geometry.

In that regard i am completely correct in my assertion that you quoted. Which still has little to do with my initial point anyway, that tessellation is nothing but a form of compression. If someone wanted to create a jersey barrier like the tessellated ones from crysis 2 there is nothing stopping it. All that tessellation has done is delivered that barrier at a far cheaper cost to parts of the GPU pipeline.

You can't do this dynamically with a standard geometry model. Especially the adaptive part where it tesselates less on surfaces that are facing you compared to these that are at an angle.

It's a different cause and effect chain. Tesselation isn't a form of compression, but something similar to compression can be achieved by using tesselation. It's close to how post processed film grain works - that simply isn't the film grain that was recorded, but a movie with removed film grain is easier to compress and adding some back randomly after decompressing will give a video that looks very nearly the same. Still, it's not compression, but a way to increase perceived quality after decompressing.

edit: another case: This guys' original model never had the amount of geometry that tesselation added. Tesselation is not limited by the original geometry, but may create more geometry by the way of displacement functions. Also see how tesselated snow in AC3 works, another case where more geometry is created than there ever was.

 

[serpretetsky]

I think what itsmydamnation and sushiwarrior are saying is this:

From my (very) limited understanding of game design, typically, game artists will first create a high polygon count model of a game prop. From that high poly count, they then extract displacement maps, and then reduce the model to a much lower count. They may even use displacement maps to make the original high poly model, but it seems like it would be easy for them to simply output a final high poly model if they wanted without any displacement maps if they wanted.

Now they send the low poly model to the video card, along with the displacement map. The video card tesselates the model, making it a higher poly count, and then applies the displacemnt map, making it look like the original high polygon model they could have outputted.

Here's where the question comes in:
If we ignore LOD benefits (since most of these arguments haven't seemed to include LOD yet) then why does the artist bother even creating the low poly model to begin with. Why doesn't he simply submit the high poly model and be done with it. The video card will still need to render a high poly model either way. So what benefit is their to doing tesselation+displacement instead of just sending all of the high poly geometry. Piroko, in your last example you showed a guy's original sphere which was low poly, and then showed the tesselated model that was smooth. But wouldn't it be very easy for a modeler to simply apply the same smoothing algorithm that tesselators perform on the model to make it a high poly count one? And then simply render that?

 

[sontin]

Because you need to send the high poly model from the CPU to the rasterizer for every frame.
A example: Your model has 100k triangles and 300k vertics. So you need to calculate for every frame the vertics on the cpu and the 300k vertics on the vertex shaders stage even when the rasterizer will throw triangles away.
And one model is not enough. For certain perspectives to the camera/player your model could have to much or to less polys. At least you need three different models (close, middle, far) and so 3x times the texture size in the memory.

With tessellation your pre rasterize workload will be much lower. Instead of 100k triangles you could use only 1k - 1/100 of the high poly model. It reduces the gpu and cpu workload, allows for less textures in the memory and gives the possibility to do a better lod because you can scale up the model from low to high poly based on the distance to the camera/player.

 

[Piroko]

Piroko, in your last example you showed a guy's original sphere which was low poly, and then showed the tesselated model that was smooth. But wouldn't it be very easy for a modeler to simply apply the same smoothing algorithm that tesselators perform on the model to make it a high poly count one? And then simply render that?

In that case, yes, it would be easy (albeit performance would be abysmal). But a similar displacement function can be applied to moving water, lava, hair, any kind of cloth. Or how about dynamically altering structures like snow. That's stuff that is typically very hard on your computation resources and almost impossible to premodel. With Tesselation you can do some very minor adjustments to your snow layer for example, altering the z coordinates of a few fairly large polygons only and let Tesselation still make it look good. As a bonus you don't even have to have a high polygon count base model in that example.

 

[jimhsu]

I do graphics as a hobby and will try to explain some things:

Mapping of additional detail on flat and non-flat surfaces exists in a continuum. Bump mapping came first with the ability to simulate normals on a flat surface to, well, produce bumps. Normal mapping is a more advanced technique that utilizes smoothly varying, orthogonal normal directions to basically increase the accuracy of the calculation at larger angles of incidences. Parallax mapping further increases realism by varying displacement relative to view angles (hence the name "parallax"), again allowing for larger incident angles. Variants like steep Parallax mapping simply add occlusion into the mix, further increasing realism. Tessellation and displacement mapping is simply a logical extension that perturbs actual mesh geometry instead of the normals, again allow for greater realism at larger angles of incidences.

A demonstration: http://graphics.cs.brown.edu/games/SteepParallax/index.html

This is basically the reason why some things clearly benefit more from tessellation than others. At low angles of incidence (head on), all of the techniques basically look identical. As you get steeper, you have to take into account occlusion, which makes the later techniques superior.

 

[jimhsu]

I think what itsmydamnation and sushiwarrior are saying is this:

From my (very) limited understanding of game design, typically, game artists will first create a high polygon count model of a game prop. From that high poly count, they then extract displacement maps, and then reduce the model to a much lower count. They may even use displacement maps to make the original high poly model, but it seems like it would be easy for them to simply output a final high poly model if they wanted without any displacement maps if they wanted.

Now they send the low poly model to the video card, along with the displacement map. The video card tesselates the model, making it a higher poly count, and then applies the displacemnt map, making it look like the original high polygon model they could have outputted.

Here's where the question comes in:
If we ignore LOD benefits (since most of these arguments haven't seemed to include LOD yet) then why does the artist bother even creating the low poly model to begin with. Why doesn't he simply submit the high poly model and be done with it. The video card will still need to render a high poly model either way. So what benefit is their to doing tesselation+displacement instead of just sending all of the high poly geometry. Piroko, in your last example you showed a guy's original sphere which was low poly, and then showed the tesselated model that was smooth. But wouldn't it be very easy for a modeler to simply apply the same smoothing algorithm that tesselators perform on the model to make it a high poly count one? And then simply render that?

Using an artist generated highpoly model would clearly be superior. But the problem is not so much performance (as alluded to in the next post, simply because modern systems *do* have the bandwidth to handle such models) as it is artist workload (manually creating all the high, intermediate, and low LOD models wastes a ton of tremendously expensive artist time, that could be used for "MOAR CONTENT"). And to avoid LOD popping, you need all of those models. Tessellation w/ displacement mapping is a compromise to try to achieve the same thing with much less artist time.

 

[ocre]

compression?

http://www.youtube.com/watch?v=cdrkHuIbka8
http://www.youtube.com/watch?v=LzULTgyn-3U

 

[Carfax83]

Impressive is that Radeons can still do well against Geforces in this game, even with max tesselation.

You know I forgot something. Doesn't AMD have that optimized tessellation feature in the driver panel?

Doesn't it limit the amount of tessellation to increase performance?

So if this setting is enabled in the driver, does that mean AMD cards are using less tessellation than NVidia cards?

 

[sushiwarrior]

You know I forgot something. Doesn't AMD have that optimized tessellation feature in the driver panel?

Doesn't it limit the amount of tessellation to increase performance?

So if this setting is enabled in the driver, does that mean AMD cards are using less tessellation than NVidia cards?

Could be, however I'm sure that would have been picked up on very early on. The setting was an option, as far as anyone knows the driver option was never enabled for any games (if it was, there would be obvious performance gains).

 

[Carfax83]

Could be, however I'm sure that would have been picked up on very early on. The setting was an option, as far as anyone knows the driver option was never enabled for any games (if it was, there would be obvious performance gains).

So that setting isn't enabled by default? I thought it was, as when I was reading the frame pacing driver reviews, there were some screenshots of the driver panel. From the PC Perspective review:

From the Anandtech article:

The HWC review also had it turned on as well apparently..

Link

 

[sushiwarrior]

So that setting isn't enabled by default? I thought it was, as when I was reading the frame pacing driver reviews, there were some screenshots of the driver panel. From the PC Perspective review:

From the Anandtech article:

The HWC review also had it turned on as well apparently..

Link

That's AMD optimized, which from what I read is supposed to be a "limit" of 64x - essentially the highest it should ever be? 64x is quite high.

 

[Red Hawk]

So that setting isn't enabled by default? I thought it was, as when I was reading the frame pacing driver reviews, there were some screenshots of the driver panel.

Yes, it's turned on by default, and you have to specifically switch it off in the driver control panel if you don't want it. I tested the setting with a Radeon HD 5770 in Tomb Raider, with everything else turned down to the "Normal" level to make sure there wasn't anything bottlenecking besides tessellation. There was no difference between having tessellation in the drivers set to "Use Application Settings" or "AMD Optimized". So it may just limit the game to a tessellation factor of 64, which is still way too high to help the tessellator in the 5770.

(And on that note, tessellation for the 5770 is just pathetic...I ran the benchmark at 1440x900; the 5770 had an average frame rate of 78.9 on normal without tessellation, but was chopped down to an average frame rate of 47.5 just from turning tessellation on. D: It went from 50.2 to 33.8 when doing the same test with "High" settings instead of "Normal")

Edit: I did a little further investigating with my 7870. On Ultimate settings, TressFX off, the "AMD Optimized" driver tessellation setting makes no difference for the in-game benchmark. Now Tomb Raider is a Gaming Evolved title, so it occurred to me that it may already have what AMD considers "optimized tessellation" so the drivers won't do anything. So I decided to run the benchmark on Batman: Arkham City, a TWIMTBP title with fairly extensive tessellation. Still no difference between "Use Application Settings" and "AMD Optimized". So I'm confused. AMD's tessellation optimization seems to do nothing for either the emaciated tessellator in the 5770, nor for the beefier tessellator in the 7870. What, then, is the point of the setting? If nothing else it means leaving the setting on by default is essentially harmless.