Hey merc...good idea with this thread.  It's been discussed down below a few times and there is some confusion.

If you could, could link the above post?  I have a funny feeling where the information comes from :P

Here's a good overview of the architecture of Fermi: http://www.anandtech.com/...oc.aspx?i=3721&p=2

I am not an expert by any stretch of the imagination.  However, it's pretty clear what Nvidia has done to improve tessellation performance.  And, accordingly, is in the hardware itself.  The ATI description is a bit misleading as it makes people think there is a separate 'chip' so to speak.  No, it's just another collection of shaders with fixed functions.  Essentially, the same thing as what Nvidia does...but in ATI's case it's outside their 'cores' so to speak.  Nvidia put them inside the the GPC.

First, from Hardware Canucks article:

"By now you should all remember that the Graphics Processing Cluster is the heart of the GF100. It encompasses a quartet of Streaming Multiprocessors and a dedicated Raster Engine. Each of the SMs consists of 32 CUDA cores, four texture units, dedicated cache and a PolyMorph Engine for fixed function calculations. This means each GPC houses 128 cores and 16 texture units. According to NVIDIA, they have the option to eliminate these GPCs as needed to create other products but they are also able to do additional fine tuning as we outline below."

See, Fermi breaks down things into 'clusters' so to speak. GPC has 4 SM's.  In each SM, you have 32 'cores'...each with their own hardware 'tessellator' (read above, look at polymorph engine).  In short, it essentially a mini-CPU (taken from the Anandtech article).

Right.  We all here?

Okay, so in effect Nvidia has broken down the GPU into what amounts to a cluster of mini-CPU's so to speak.  Each having it's own hardware implemented tesselator (well, geometry unit...but tessellator will work).  What does this provide?

Simple.  Parallel processing.  ATI uses a fixed function geometry processor which is outside their SM's (or whatever you care to call them) which is serial in nature.  Nvidia took a drastically different approach. They essentially subdivided that monolith bit and placed it where the work is done...in the SM's.  It's still hardware implemented, just very different than the 'traditional' method.  What you're seeing here is basically what would amount to almost a farm of processors (including the tessellator).  This, of course, will increase throughput and speed of really heavy computations.  Think in terms of a small render farm for lack of better analogy.

So, in reality, while we are being told that ATI is using a dedicated 'chip' for tessellation...it's sort of misleading.  Nvidia is as well, it's just implemented very differently than ATI (and, in theory, should offer better performance for geometry based calculations).  

Now...here's something that is interesting.  http://www.anandtech.com/...oc.aspx?i=3721&p=2

See, I don't know much about hardware details...but I do know about parallel processing.  In short, what Nvidia did is very, very difficult.  Anandtech does a good job of explaining out of order processing.  This is where I think some of the 'hardware vs. software' confusion comes from.  In short, to make this all work...the PE's need to be in communication with each other.  If one instruction is out of order, the whole thing goes splat.  There are 16 of these things on the 480 card so you can just imagine how difficult that is to work with.  If anything, you gotta give Nvidia credit...that stuff is not frigging easy.  In fact, it's brutal.  ATI's design is a lot simpler and far easier to implement than what Nvidia did.

Now, the question is what will happen when you turn up AA/AF?  Well, as I read it, the SM's will handle all this still...leaving the geometry calculations outside to be processed by the polymorph engine.  Fine. Dandy.  But will this crush the performance?  I don't know but I certainly would think if they are being processed separately performance shouldn't be drastically reduced (compared to how ATI does it of course).

ATI essentially frees up more shaders for pixel rendering so I suppose anything can happen though ;>)

I think this pretty much sums up what's going on...from the HC article: 

"As we already mentioned, the HD 5000 series isn’t tailor-made for a DX11 environment while NVIDIA’s architecture was designed from the ground up to do just that."

At least that's how I read it.  Perhaps an EVGA tech wants to chime in and explain in better detail?  Purty please?

 

Yeah, I can't wait to see how Fermi plays out in real life. The architecture is impressive and the level of parallel processing is something to behold.

I still think there is still likely some issues to work out on the software side to handle all the new tech. If tessellation programming in the Polymorph engine can be update with new drivers -- there is likely some big performance gains yet to be engineered.

Just like the ATI 58xx has benefited greatly from refined drivers, including 10.3 beta which has even more gains from 10.2. I think the GF100 drivers will be a great source of continued improvement.

I'm loving all of this both the ATI and moreso the NVIDIA. Can't wait to re-upgrade to Fermi later this year. The 5870s are amazing. If Fermi is more impressive... Wow, look out.

fanboy

I don't know if i fully understand it or not but say a game has basic code for tessellation and the way Nvidia made the GF100 does it mean they have to write software in the driver to handle that code say for each game like Sli profiles as to break it down and send it were it needs to go so everything runs smooth or it's not going to know what to do with it..

In a way. Most of the code will be client-side in the shader initiation. This means that most of the code will correspond to whatever hardware DX11 set as a standard to program for. In this case if Nvidia or ATI wants to have SLI or Crossfire efficient Tessellation, then they'd have to likely do that via the driver. However as a game maker you can also choose how that code itself speaks to the driver. On the game makers part they can also control which bits are sent to which GPU.


A lot of engines now days like Unreal and Source use Multi-GPU "$commands" set on materials, particles, geometry sometimes that can be rendered on the second GPU. It's not as easy as touching these things based on which engine you're using, but in example:

1. I program Tessellation code into my engine.
2. I set which objects are effected by said technology (Videocard). Now this is the tricky part. I can leave it as is, basic, nothing more than just simple tessellation. Or, I can choose to have specific objects that are often real-time, and easier to split per-GPU be rendered by the second GPU.
3. If I took the second, I'd go with having my NPC's or physics props handled by the second GPU, allowing the 1st GPU to worry about world rendering. However then I'd be wasting a hefty amount of GPU power, and would be putting too much stress on a single card. Instead I could create parallel code to handle tessellation on both GPUs at once. This would mean sending the information and splitting it onto both GPU's, and then having it computed, and sent back finally.
4. If both GPUs handled world rendering globally, you'd see huge performance increases with tessellation on. However I'd be doing a lot of heavy calculating that round, to make sure each GPU gets the right amount of divided information. Nvidia's GPUs do this per GPU, rather than on multi GPUs. This might be tricky to do unless Nvidia pulls off some magic on their end. 

Because of how tricky it might be exactly, I'd go with having more objects overall on the 2nd GPU if I could. Static props, Dynamic Props, NPC's, Animated objects via shaders. This in theory could also allow a game developer to have extremely highly detailed NPC's if the engine saw a 2nd GPU, and put all the rendering of said objects on the 2nd GPU. I hope I've given you guys some insight into how this works.

Great post, MTVC.  Thank you for that.

So if we talk about Ati's way of doing it then the basic code for tessellation threw the DX 11 API as wrote by the game developer is less work unless you program it for more detail which Ati has in say a game like Dirt 2 ..but the heaven benchmark is just running basic code for tessellation on Ati hardware where as Nvidia tweaked there driver for more performance gains in tessellation .. is that right?

rjohnson11

Guys you know we can't talk about fermi too much but what I will tell you is that drivers can only improve performance to a certain degree and that goes for both ATI and NVIDIA. From there on it's hardware that determines performance and that's all I can say at this time.

Yep.  Understood and thanks for taking part ;>). 

The original discussion was about how Fermi handles tessellation vs. how ATI handles it.   Hence, we basically are sticking to what has already been published by Nvidia themselves (and all the previews the various hardware sites have put out).  I would imagine even EVGA could chime in as it is already released information about Fermi.

I like this thread.  Calm, cool, collected.  This is good.  

Interesting discussion, I agree however that the quoted post in the OP should be properly linked and referenced. 

In any case, I'd point out first and foremost the author of that post makes it seem as if the performance penalties of the domain and hull shader are unexpected.  He seems to be surprised the hull/domain shaders aren't fixed function and are in fact programmable, but also share from the common resource pool of the unified pixel/vertex shaders.  This is by design, as the trend continues it should be obvious that there is a move from fixed-function to programmable and this continues with DX11 where unified shaders need to be able to handle hull/domain/pixel/vertex shaders.

Here's a great primer on DX11 and the new Tesselation pipeline, you'll see it does show clearly programmable hull/domain shaders with a tesselator inbetween: http://www.anandtech.com/showdoc.aspx?i=3507&p=6

And on the next page, it discusses the pros/cons of fixed-function hardware, which can basically summarized as speed at the expense of low-utility vs. flexibility with the benefit of high-utility: http://www.anandtech.com/showdoc.aspx?i=3507&p=7

AnandTech

The argument between fixed function and programmable hardware is always one of performance versus flexibility and usefulness. In the beginning, fixed function was necessary to get the desired performance. As time went on, it became clear that adding in more fixed function hardware to graphics chips just wasn't feasible. The transistors put into specialized hardware just go unused if developers don't program to take advantage of it. This made a shift toward architectures where expanding the pool of compute resources that could be shared and used for many different tasks became a much more attractive way to go. In the general case anyway. But that doesn't mean that fixed function hardware doesn't have it's place.

And this balance is what brings us full circle to why Nvidia's implementation of GF100's tesselator/geometry engine is so brilliant.  Instead of just tacking on a separate fixed-function tesselator, they rebuilt the entire engine to incorporate their tesselator into each SM cluster, putting it physically closer to the hull/domain shaders, giving it OoO execution capabilities, and making it programmable to the extent it can be used for both tesselation AND standard geometry using the same transistors.

http://www.anandtech.com/video/showdoc.aspx?i=3721&p=3

AnandTech

To put things in perspective, between NV30 (GeForce FX 5800) and GT200 (GeForce GTX 280), the geometry performance of NVIDIA’s hardware only increases roughly 3x in performance. Meanwhile the shader performance of their cards increased by over 150x. Compared just to GT200, GF100 has 8x the geometry performance of GT200, and NVIDIA tells us this is something they have measured in their labs.

So basically, Nvidia took a traditional weakness that had long been neglected (geometry shader), increased it eight-fold, moved it closer to the dependent functional units, made it programmable and out-of-order, all while maintaining DX11 compliance with regard to tesselation.  To further clarify, they took two traditionally fixed-function units, geometry and tesselator, and combined them, so instead of having 2 groups of fixed-function hardware they now have those resources combined to be used for either, or as needed.  The practical benefit is obvious, there's nothing wasting away as fixed-function, whatever the scene needs it has all of that geometry+tesselator transistor budget at its disposal. 

While impressive on paper, will it make a huge difference in every game?  No.  It will show benefits with regard to tesselation and perhaps some gains in games that were bottlenecked with regard to geometry.  The latter will be harder to gauge in real world performance, but if you start seeing some abnormally high increases in certain games in upcoming benchmarks, the redesign of the geometry engine might be the cause.

MrTwoVideoCards
 
Because of how tricky it might be exactly, I'd go with having more objects overall on the 2nd GPU if I could. Static props, Dynamic Props, NPC's, Animated objects via shaders. This in theory could also allow a game developer to have extremely highly detailed NPC's if the engine saw a 2nd GPU, and put all the rendering of said objects on the 2nd GPU. I hope I've given you guys some insight into how this works.

What you're describing is incorrect....this is how Hydra handles multi-GPU rendering, SLI uses simple AFR (alternate frame rendering) where each GPU renders the entire scene independently of the other.  While Hydra sounds great on paper, load balancing or selective rendering of objects based on API calls has its own set of issues, you can read about them here: http://www.anandtech.com/video/showdoc.aspx?i=3713&p=4

So far, good thread, i have linked the source under the original post, yes i know, it's that website, but that was about the most interesting post i ran across while practicing google fu.

I have never liked that anandtech article. It really sounds like too much nVidia marketing speak. 


"As we already mentioned, the HD 5000 series isn’t tailor-made for a DX11 environment while NVIDIA’s architecture was designed from the ground up to do just that." 


Really?? That sound like something that could come out of the mouth of a nVidia tech?


Now that being said. Its sort of like the PS3. "The Cell can do graphics too." In this case GF100 does need a separate tessellation area when the entire chip can do it. It plays to nVidia's strength too which is software. ATi having also been hardware, its no surprise that they would have a hardware based and not software based solution. One wonders how much drivers could improve tessellation on 5000 series. Probably not much. I would imagine just enough to get the chip at least comparable to GF100 in the level of tessellation that most DX11 games will do. Most I don't think are going to go as far has what we have seen from nVidia. Games are made for consoles and then ported to PC's remember :). However to an no where near the potential of the GF100. 

I"ll also add that no developer is going to heavily tessellate a game from the outset. One developer may -- and it'll end up like Crysis did. Chokes on any and every machine it runs on until 3 years after release. Exaggeration -- yes, but you get the point.

Tessellation will be ideal for limited usage -- hair, intricate and player focused complex objects, fluid dynamics, etc. The point isn't to tessellate everything like those plastic surgery addicts you hear about. It's for the right things, in the right places. That's how reasonable budget savvy developers will utilize it. Especially as long as games are console based and ported. Hopefully, that trend will find a way to reverse itself as better hardware makes it into consoles.

Tessellation its more hardware driven not software like rj said software/drivers will only do so much. Here is an actual example of what Tessellation is so you can view it with your own eyes. It GREATLY  depends on your hardware, on top of it you take the nvidia demo with the hair, each stand of hair has a rig basically an invisable bone system. But before I go off on a long tangent it is hardware dependent, what nvidia or ati has done is able to make Tessellation with thier gpus go alot smoother  within the confines of thier own programming for thier hardware, I guantee if i pump up the Tessellation like I have in these examples in that tech demo the gpu would start to chug.


Here in Maya at not the highest level of Tessellation I could go I could do 600x600 or higher but Yeah I dont want to wait for my computer to take that long to tessalte that much of the model.


Here is the the Tessellation at a lower lvl than the first screen shot I took, notice how it gets a little blocky



Here is tessellation set to its lowest lvl




Now what nvidia and ati has done is this able to convert parts of the model"aka hair grass etc" at its bending points able to tessellate in real time. But once again Like rj said drivers/software can only do so much its more about the cpu or in ati/nvidias case have the gpus do it all. Even in the 3d app I used it also depends on the gpu, due to how much it can display as the model tessellates. Say if I gave that entire nurbs model model a tessellation of 600x600 in the U and V div factors, it would take it a couple minutes for it to make those tessellation calculations. as it divides the nurbs model up in more places make it more bendable, smoother in appearance.

 

Heh, it's pretty cool seeing software I design posted here :)

To touch base on more of the tesselation pipeline and some things that donta pointed out, DX11 uses our (Maya's) catmull clark subdivision surface model as a means of calculating the tesselation.  The SDK currently for DX11 supports this information through the FBX file format which can then be converted using a runtime converter and then displayed in the runtime environment on the GPU.  The advantages here aren't just tesselation for deformations but also for things like creasing, holes and other subdivision surface enhancements that go beyond what a typical polygonal object can do.  Edge creasing is probably one of the bigger things that people can do here and it's by far the best method to use when doing things like hard surface modeling such as cards or rigid objects.

For people looking to experiment with this stuff you can grab Maya or 3dsmax and use either the Smooth Mesh Preview in Maya or Turbosmooth in 3dsmax to get the results and then export out using FBX 2010.  If you grab the March 2010 DX11 SDK there should be some code in there you can compile for the DX11 runtime previewer I believe so you can actually load up your mesh in the runtime and tesselate it on the fly to see what sort of performance you get.

I'm at GDC this week but I'll be following this thread closely and hopefully I can provide more insight on the tesselation pipeline if people are interested as I've been working with it for some time now and it's great seeing the hardware really grow into this tech.  I'll check and see if I can post more info too to show the entire process from DCC to Runtime on the card.  I've actually been meaning to put together a blog post on our corporate site about all of this and the workflows as well.

While most of it is way over my head, I gotta say this has been one of the best threads in a long time.  Lots of great information here!  As fred suggested, the OP should get a blue ribbon for starting it.

merc.man87

Sweet goodness! I didn't even realize i got a BR. Again, can't wait until actual form members can get there hands on some ferbie goodness so we can do an apples to apples comparison across a broad range.

I'll be honest...I recommended you for a BR.  Why?  Because you bring a serious discussion up...and it remains logical..without the normal FUD associated w/ fermi. 

IMHO, we need more threads like this.