Is AMD's tessellation still way behind Nvidia?

[Jaydip]

Sweet mother of god, compression does not come from adding AREA. My god, you send the GPU a small bit of information in the form of a rough map, the GPU decompresses this information into a LARGE amount of information in the form of a smooth map. You send it a small amount of data, it comes out with a large amount of data.



GPU takes a small bit of information and makes it into a large amount of information in the manner that the graphics dev intended. This is the textbook definition of compression.



Your end product, the smooth map, has MORE BITS THAN THE ORIGINAL REPRESENTATION.

This is what compression is.

As you quoting from this site

http://www.nvidia.com/object/tessellation.html

just read through and you will understand that more vertices does improve tessellation.I just don't understand where you guys got that compression thing from?

 

[sushiwarrior]

You are completely confused at this moment.Take a moment to read what you are typing.

As you quoting from this site

http://www.nvidia.com/object/tessellation.html

just read through and you will understand that more vertices does improve tessellation.I just don't understand where you guys got that compression thing from?

No, I'm not confused whatsoever, there's just a herd of fools in show here who don't understand

A. What tessellation is
and
B. What compression is

Situation not using tessellation: In order to render a perfect sphere with polygons, TONS of polygons are sent to the GPU to be rendered, taking a large amount of bandwidth, a large source model, etc. (very bandwidth/data intensive)

Situation using tessellation: I send the GPU a very rough model (say, for example, a cube), tell the GPU to extrapolate this into a circle (ie. create many many many vertices), hence I send the GPU very little (rough shape and a command to follow) and the GPU creates an entire, detailed, smooth sphere for me, all while using very little bandwidth (very GPU intensive)

If you've got an issue with this, explain it with your big boy words instead of "no".

If you can honest to god look at this

And think that the image on the left does not take less bits to represent than the image on the right (using polygons, and not tessellation), feel free to explain what kind of logic defying magic is at work in your universe which could possibly cause that. With tessellation, these two images take essentially the same amount of bandwidth to produce.

 

[Jaydip]

So according to you Tessellation is compression because it is extrapolating a cube to a sphere? I believe our notion of compression varies greatly.

 

[sushiwarrior]

So according to you Tessellation is compression because it is extrapolating a cube to a sphere? I believe our notion of compression varies greatly.

Oh my god you are unbelievable.

Situation not using tessellation: In order to render a perfect sphere with polygons, TONS of polygons are sent to the GPU to be rendered, taking a large amount of bandwidth, a large source model, etc. (very bandwidth/data intensive)

Situation using tessellation: I send the GPU a very rough model (say, for example, a cube), tell the GPU to extrapolate this into a circle (ie. create many many many vertices), hence I send the GPU very little (rough shape and a command to follow) and the GPU creates an entire, detailed, smooth sphere for me, all while using very little bandwidth (very GPU intensive)

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

Storing data in a format that requires less space than usual.

In computer science and information theory, data compression, source coding,[1] or bit-rate reduction involves encoding information using fewer bits than the original representation.

A technique in information technology by which the same amount of data is transmitted by using a smaller number of bits

The technique of reducing the number of binary digits required to represent data.

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"

 

[boxleitnerb]

I think it's a matter of definition. If you just think of the process that is happening on the GPU, it's not compression. If you think of the process as a whole including the data transfer, then it is.

 

[sushiwarrior]

I think it's a matter of definition. If you just think of the process that is happening on the GPU, it's not compression. If you think of the process as a whole including the data transfer, then it is.

By your definition lossless compression is literally impossible. You have the wrong definition. Compression can be done at any stage in the process. In this example, compression is used so the model requires less data to store..

Key word being the model is stored with less data. In the exact same way that a song is stored with less data when saved as a FLAC.

Christ, remind me to never bother trying to explain basic concepts again.

 

[Piroko]

I was under the impression that
- decompression is a lossless restoration of compressed data. If said data was compressed in a lossy or lossless manner is irrelevant for decompressing. The same decompression on a different machine should get the same result.
- tesselation creates new data out of a given polygon mesh and a given displacement map. The amount of data created is variable and the result may differ between different tesselators. That should make it closer to how AA or post processed film grain improve subjective quality.

 

[ocre]

decompression does not equal compression!
Just as tessellation does not equal compression!

your looking at it completely warped and backwards. This prevents you from seeing what tessellation offers and the massive possibilities it is capable of.

This leads to mindset such as this:

What does tessellation give you that simply drawing more triangles wont .

That wasn't the question , nor does it contract my point which is tessellation is nothing but compression.

hmmmm. Your line of thinking has resulted in such a paradox. Why did so many incredibly smart people waste so much time on such a worthless feature? Perhaps you too are missing the benefits due to the view you have chosen to stick to.

Tessellation is much older than computer gaming and it exist all around you. But if we focus specifically on computation, your questions really dont make sense to me.
Its kind of like saying, what does the equation give you that you cant calculate with arithmetic? Think on that a minute while i will attempt to address this backwards logic.

So far the implementation of tessellation in games has been very limited but this is only because it is being developed as an after thought. No one has compressed down a brick wall only to have tessellation decompress the wall back to its full figure. BUT- even if they did, tessellation would be decompression, expanding, extracting not compressing or compression which implies shrinking down, reducing, shrinking. They are quite the opposite, and its very hard for me to see how you come to this???
Its wrong, completely.
So back to tessellation as an afterthought. So far developers have used tessellation to build up environments that were initially very basic. Most were designed flat and exist as flat surfaces with color to add depth. So far we have seen a very limited usage of tessellation that doesnt offer much as far as interaction. It is purely eye candy. It was not a scene that was compressed, but a scene that "grows" detail out of simple surfaces according to the amount of tessellation. It mostly has been added after the game is far into development to grow detail into the plain landscapes, to spice up the game somewhat for PC.
But tessellation offers a lot more than this. Instead of using tessellation to build up a dull environment, it can be used in a much more interactive way where a complex structure can be reduced down as it is tore apart by interactions in the environment. The possibilities are endless really. I think you should revisit the subject more in depth when you get time.

 

[RussianSensation]

The interesting part is that evil Nvidia is not using their advantage at extreme tessellation to bully AMD,

which can't be said about AMD and their GPGPU advantage.
Global Illumination anyone? So much oomph used and for literally nothing.

Blame how demanding global illumination is, not AMD's GPGPU advantage. Without using DirectCompute for global illumination, the performance is even worse. Your complaint should be targeted at how GPU intensive next generation effects like global illumination are. Current generation of 28nm GPU is simply too weak for next gen effects like this. The same is true for game developers to start using adaptive tessellation everywhere. Fingers crossed that 20nm and 14nm GPUs are much improved to handle these effects so that we see more of them in games. When HDR debuted, sure 6800GT/U could run it in theory but in practice they were dog slow. Same with HD5870 and tessellation. It takes a couple generations of GPUs to run new next gen graphical effects.

 

[sushiwarrior]

I was under the impression that
- decompression is a lossless restoration of compressed data. If said data was compressed in a lossy or lossless manner is irrelevant for decompressing. The same decompression on a different machine should get the same result.
- tesselation creates new data out of a given polygon mesh and a given displacement map. The amount of data created is variable and the result may differ between different tesselators. That should make it closer to how AA or post processed film grain improve subjective quality.

Decompression is simply getting "roughly the same thing" out of the original data. MP3 is extremely lossy, and lops off all of the extreme high and low end frequencies, and doesn't care much about frequencies that aren't in vocal range (phone compression is a more extreme example of this). Sound waves that an mp3 file produce are different than the original, yet they are "acceptably" close to the original, to the extent that we don't care. In the same manner, taking our sphere and making it look like a hexagon instead of an octagon is compression, it is just very noticeable. Tessellation is not some hand-wavey, weird process - it is a standard mathematical operation that a GPU performs. Unless something goes horribly wrong (ie. driver meddling), Nvidia and AMD should both perform the operation the same way - last I checked, AMD and Intel CPU's don't create different .rar files for example.

decompression does not equal compression!
Just as tessellation does not equal compression!

your looking at it completely warped and backwards. This prevents you from seeing what tessellation offers and the massive possibilities it is capable of.

This leads to mindset such as this:



hmmmm. Your line of thinking has resulted in such a paradox. Why did so many incredibly smart people waste so much time on such a worthless feature? Perhaps you too are missing the benefits due to the view you have chosen to stick to.

Tessellation is much older than computer gaming and it exist all around you. But if we focus specifically on computation, your questions really dont make sense to me.
Its kind of like saying, what does the equation give you that you cant calculate with arithmetic? Think on that a minute while i will attempt to address this backwards logic.

So far the implementation of tessellation in games has been very limited but this is only because it is being developed as an after thought. No one has compressed down a brick wall only to have tessellation decompress the wall back to its full figure. BUT- even if they did, tessellation would be decompression, expanding, extracting not compressing or compression which implies shrinking down, reducing, shrinking. They are quite the opposite, and its very hard for me to see how you come to this???
Its wrong, completely.
So back to tessellation as an afterthought. So far developers have used tessellation to build up environments that were initially very basic. Most were designed flat and exist as flat surfaces with color to add depth. So far we have seen a very limited usage of tessellation that doesnt offer much as far as interaction. It is purely eye candy. It was not a scene that was compressed, but a scene that "grows" detail out of simple surfaces according to the amount of tessellation. It mostly has been added after the game is far into development to grow detail into the plain landscapes, to spice up the game somewhat for PC.
But tessellation offers a lot more than this. Instead of using tessellation to build up a dull environment, it can be used in a much more interactive way where a complex structure can be reduced down as it is tore apart by interactions in the environment. The possibilities are endless really. I think you should revisit the subject more in depth when you get time.

Tessellation is literally just making more polygons, as everything rendered by a GPU is polygons if you want to be technical Tessellation lets you render more polygons without being incredibly bandwidth intensive, data intensive, game designer intensive, etc.

At least in it's current implementation, tessellation is nothing radically different like ray tracing or something. Without tessellation, you render a bunch of polygons and get an image. With tessellation, you create polygons in the GPU instead of in the source model, hence you save game designers tons of time, and make it possible to make pretty games very easily.

Tessellation is also inferior to high polygon models in a situation like another model being pressed up to it, is it not? For example if a foot stepped on a tessellated surface, it would float rather than deforming to, for example, the cobblestone surface... correct me if I am wrong.

 

[cmdrdredd]

Blame how demanding global illumination is, not AMD's GPGPU advantage. Without using DirectCompute for global illumination, the performance is even worse. Your complaint should be targeted at how GPU intensive next generation effects like global illumination are. Current generation of 28nm GPU is simply too weak for next gen effects like this. The same is true for game developers to start using adaptive tessellation everywhere. Fingers crossed that 20nm and 14nm GPUs are much improved to handle these effects so that we see more of them in games. When HDR debuted, sure 6800GT/U could run it in theory but in practice they were dog slow. Same with HD5870 and tessellation. It takes a couple generations of GPUs to run new next gen graphical effects.

UE4 is using Global Illumination and it doesn't halve the frame rate like some other examples.

 

[boxleitnerb]

By your definition lossless compression is literally impossible. You have the wrong definition. Compression can be done at any stage in the process. In this example, compression is used so the model requires less data to store..

Key word being the model is stored with less data. In the exact same way that a song is stored with less data when saved as a FLAC.

Christ, remind me to never bother trying to explain basic concepts again.

No reason to get all upset. I just viewed the process on the GPU as isolated and didn't take the original model into account, that's all. I know full well what compression is.

 

[sushiwarrior]

No reason to get all upset. I just viewed the process on the GPU as isolated and didn't take the original model into account, that's all. I know full well what compression is.

Just too many things being called wrong in a row for my taste, it makes the sushi agitated ()

 

[Piroko]

Decompression is simply getting "roughly the same thing" out of the original data. MP3 is extremely lossy, and lops off all of the extreme high and low end frequencies, and doesn't care much about frequencies that aren't in vocal range (phone compression is a more extreme example of this). Sound waves that an mp3 file produce are different than the original, yet they are "acceptably" close to the original, to the extent that we don't care. In the same manner, taking our sphere and making it look like a hexagon instead of an octagon is compression, it is just very noticeable. Tessellation is not some hand-wavey, weird process - it is a standard mathematical operation that a GPU performs. Unless something goes horribly wrong (ie. driver meddling), Nvidia and AMD should both perform the operation the same way - last I checked, AMD and Intel CPU's don't create different .rar files for example.

My point is, decompression isn't about getting roughly the same thing out of the original mp3/stream of data, it's about getting exactly the same thing bit for bit, no matter if you decompress on your ipod or your PC. You can't just decompress your data a bit or decompress more than there was before you compressed it. The only point where you can influence the amount of data is while compressing it.

Whereas Tesselation can tesselate a bit, slightly more or even more. You can influence how much data you want to handle in a much later stage if you wanted to (e.g. by reducing the tesselation level in realtime if the scene complexity increases, should be technically doable even if it's not done yet). You can even create more data than there was originally.
Also, DX11 tesselation does not specify a specific hardware algorithm of how to tesselate afaik. The implementation may vary just like the implementation of AF or AA may vary, which may lead to different results.

 

[ocre]

i am sorry but I dont think your definition is a good one at all. I dont know any game that is using tessellation to save bandwidth although i am not arguing that it could. I am saying that you could be missing the many possibilities tessellation brings. if you keep that limited view.

The current application in gaming is very limited and doesnt offer us anything much that couldnt be done in traditional ways but tessellation doesnt have to be limited to this and could be used for much more. That is really my point. I think that tessellation can be much more useful than "compression" although its usage in games have been very limited up into this point. I believe as long as it is an afterthought add in feature, its never gonna amount to much. There is so much more that can be done if we integrate it into games on an interactive level.

 

[sushiwarrior]

My point is, decompression isn't about getting roughly the same thing out of the original mp3/stream of data, it's about getting exactly the same thing bit for bit, no matter if you decompress on your ipod or your PC. You can't just decompress your data a bit or decompress more than there was before you compressed it. The only point where you can influence the amount of data is while compressing it.

Whereas Tesselation can tesselate a bit, slightly more or even more. You can influence how much data you want to handle in a much later stage if you wanted to (e.g. by reducing the tesselation level if the scene complexity increases, should be technically doable even if it's not done yet). You can even create more data than there was originally.
Also, DX11 tesselation does not specify a specific hardware algorithm of how to tesselate afaik. The implementation may vary just like the implementation of AF or AA may vary, which may lead to different results.

You are interpreting compressed data wrong. An "MP3 sphere" takes the original, seamless "sphere", and cuts out enough polygons that it looks close enough to a sphere for the human eye to say "yeah, that's a sphere". An "MP3-128" sphere is pretty obviously blocky, an "MP3-320" sphere is pretty hard to tell apart from the seamless sphere. Just as in music, this is "slightly more, or even more" compression.

In a song, any MP3 does NOT reproduce the original exactly. It is lossy, data is lost. It is an approximation. It is not the same as the original.

With tessellation, you are essentially creating new data based on instructions. This is like saying "given this 50x50pixel diagram, and based on the fact it is an image of a man standing on a house, draw me a 500x500pixel image". This process is performed mathematically through an algorithm, and the end result uses less data (only 50x50px plus instructions) compared to what a 500x500px image would take.

MP3 is the equivalent to saying "eh, the man is too small so we don't need him, the sky is roughly a blue blob, the house is a big rectangle, let's cut all of that detail out". It loses detail, and hence it's 500x500px image uses less data than the original 500x500px image.

Each gives you a large image in the end, it's just the difference between cutting out details and adding details. In this case, adding details can save you tons of work, and tons of time, at the cost of processing power.

i am sorry but I dont think your definition is a good one at all. I dont know any game that is using tessellation to save bandwidth although i am not arguing that it could. I am saying that you could be missing the many possibilities tessellation brings. if you keep that limited view.

The current application in gaming is very limited and doesnt offer us anything much that couldnt be done in traditional ways but tessellation doesnt have to be limited to this and could be used for much more. That is really my point. I think that tessellation can be much more useful than "compression" although its usage in games have been very limited up into this point. I believe as long as it is an afterthought add in feature, its never gonna amount to much. There is so much more that can be done if we integrate it into games on an interactive level.

I don't think your definition even exists, I can't recall you stating anything that tessellation is actually possible of doing that hasn't been done yet.

 

[ocre]

My point is, decompression isn't about getting roughly the same thing out of the original mp3/stream of data, it's about getting exactly the same thing bit for bit, no matter if you decompress on your ipod or your PC. You can't just decompress your data a bit or decompress more than there was before you compressed it. The only point where you can influence the amount of data is while compressing it.

Whereas Tesselation can tesselate a bit, slightly more or even more. You can influence how much data you want to handle in a much later stage if you wanted to (e.g. by reducing the tesselation level in realtime if the scene complexity increases, should be technically doable even if it's not done yet). You can even create more data than there was originally.
Also, DX11 tesselation does not specify a specific hardware algorithm of how to tesselate afaik. The implementation may vary just like the implementation of AF or AA may vary, which may lead to different results.

Just because you can use tessellation to get the around the same results using less data doesnt reduce it to just some kind of compression. Talk about trying to force something into a can. Tessellation is so much more than a way to save bandwidth and taking such a view surely results in a limited appreciation of the possibilities tessellation brings us.

 

[sushiwarrior]

Just because you can use tessellation to get the around the same results using less data doesnt reduce it to just some kind of compression. Talk about trying to force something into a can. Tessellation is so much more than a way to save bandwidth and taking such a view surely results in a limited appreciation of the possibilities tessellation brings us.

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.

 

[RussianSensation]

UE4 is using Global Illumination and it doesn't halve the frame rate like some other examples.

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.

 

[Piroko]

You are interpreting compressed data wrong. An "MP3 sphere" takes the original, seamless "sphere", and cuts out enough polygons that it looks close enough to a sphere for the human eye to say "yeah, that's a sphere". An "MP3-128" sphere is pretty obviously blocky, an "MP3-320" sphere is pretty hard to tell apart from the seamless sphere. Just as in music, this is "slightly more, or even more" compression.

In a song, any MP3 does NOT reproduce the original exactly. It is lossy, data is lost. It is an approximation. It is not the same as the original.

No, you are mixing up compression and decompression there. Those are two very different tasks. While compressing you decide how much you compress, how 'unround' your sphere will be. Then you send said information to a third party who decompresses it. Said third party can do nothing to get more (or less, for that matter) 'roundness' out of what you sent them while decoding. Even the exact orientation of your edges is predefined, it will stand in a very specific angle on a very specific edge.

Now with Tesselation you as the 3d modeler can create a fairly unround sphere, create a drawing of how round it should be and send both informations to a third party. They may then decide for themselves if they want to keep it more blocky (don't bother tesselating, or tesselate with a low factor), make it as round as you intended (tesselate with the factor that was given), or interpolate even more roundness out of the drawing (tesselate even more). This will lose the exact orientation of your edges though.

It's a different thought process of how data is handled and delivered.

 

[itsmydamnation]

I went to sleep and wow

your looking at it completely warped and backwards. This prevents you from seeing what tessellation offers and the massive possibilities it is capable of.

This leads to mindset such as this:

what? a mind set of calling it want it is. Your reducing setup and data transfer until a point where you hit a fixed function unit which then adds more geometry but at the same time is bound by the initial geometry pretesselation.

hmmmm. Your line of thinking has resulted in such a paradox. Why did so many incredibly smart people waste so much time on such a worthless feature? Perhaps you too are missing the benefits due to the view you have chosen to stick to.

Who said anything about it being worthless, could you imagine how video games would run without compression. Infact i think you would be insulting said smart people for considering compression as worthless.

Tessellation is much older than computer gaming and it exist all around you. But if we focus specifically on computation, your questions really dont make sense to me.

its quite simple there is nothing you can do with tessellation that you cant do with simply setting up more geometry.

So far the implementation of tessellation in games has been very limited but this is only because it is being developed as an after thought. No one has compressed down a brick wall only to have tessellation decompress the wall back to its full figure. BUT- even if they did, tessellation would be decompression, expanding, extracting not compressing or compression which implies shrinking down, reducing, shrinking. They are quite the opposite, and its very hard for me to see how you come to this???

only if you look at the process in its final state, someone still needs to go and create all that geometry in the first place.

Its wrong, completely.

no it isn't, only if you want to get hung up on differentiating the compressing and the decompressing parts of the process.

So back to tessellation as an afterthought. So far developers have used tessellation to build up environments that were initially very basic. Most were designed flat and exist as flat surfaces with color to add depth. So far we have seen a very limited usage of tessellation that doesnt offer much as far as interaction. It is purely eye candy. It was not a scene that was compressed, but a scene that "grows" detail out of simple surfaces according to the amount of tessellation. It mostly has been added after the game is far into development to grow detail into the plain landscapes, to spice up the game somewhat for PC.
But tessellation offers a lot more than this. Instead of using tessellation to build up a dull environment, it can be used in a much more interactive way where a complex structure can be reduced down as it is tore apart by interactions in the environment. The possibilities are endless really. I think you should revisit the subject more in depth when you get time.

Yet your still bound by your initial geometry and there is nothing there that you cant do by just creating more geometry. We dont do it with raw geometry because of the cost, that's all tessellation is trying to address, lowering the cost of certain types of geometry.

i would answer in more detail but i need to go to work :'(

 

[sushiwarrior]

No, you are mixing up compression and decompression there. Those are two very different tasks. While compressing you decide how much you compress, how 'unround' your sphere will be. Then you send said information to a third party who decompresses it. Said third party can do nothing to get more (or less, for that matter) 'roundness' out of what you sent them while decoding. Even the exact orientation of your edges is predefined, it will stand in a very specific angle on a very specific edge.

Now with Tesselation you as the 3d modeler can create a fairly unround sphere, create a drawing of how round it should be and send both informations to a third party. They may then decide for themselves if they want to keep it more blocky (don't bother tesselating, or tesselate with a low factor), make it as round as you intended (tesselate with the factor that was given), or interpolate even more roundness out of the drawing (tesselate even more). This will lose the exact orientation of your edges though.

It's a different thought process of how data is handled and delivered.

It's different thought process, but it doesn't change the fact that all that tessellation in it's current incarnation does is take a rough map, apply some algorithms, and get a more detailed model out the other end.

Let me go over this very, very slowly. That final picture? It's a BIG picture - it takes LOTS of data. The information sent to the GPU? It is MUCH SMALLER than the big picture - it's tiny (Nvidia docs suggest that displacement mapping is ~5-10x smaller mesh size than high poly counts). The GPU takes this, and recreates the "original artist's idea", which is a BIG picture.

Big picture -> small data -> big picture

It doesn't matter where the compression or decompression happens, that is simply semantics (and problems with my analogy). The indisputable fact is that tessellation compresses visual geometry.

This is a pretty succinct summary.

 

[Piroko]

Well, to a layman the difference between analog and digital communication is just semantics as well, both do sound -> electromagnetic wave -> sound...

 

[blackened23]

I think AMD is on par. I don't care about synthetic benchmarks, I know tessmark favors nvidia but there are others favoring AMD? Anyway, if you look at tess heavy games they tend to be pretty close between the 680-770-7970GE. Some titles that come to mind being crysis 2, 3, metro 2033, among others. I do know the tess performance of the Cayman series was weak, but the Tahiti improved it by a ton IMO.

 

[sushiwarrior]

Well, to a layman the difference between analog and digital communication is just semantics as well, both do sound -> electromagnetic wave -> sound...

To be more clear, here's some filesize examples from that presentation I linked:

Tessellation level: Level 8 Level 16 Level 32 Level 64
Regular Triangle Mesh:         16MB 59MB 236MB 943MB

Displaced Subdivision Surface: 1.9MB 7.5MB 30MB 118MB