Forums | MacLife

Mr. T wrote:

It's great to see Windows 7 performing so well.  It took a while for the drivers to adapt to the new display model, but it seems like it's finally there, and it shows.

I've been running Vista exclusively for the past couple of months, after initially shunning it (and justifiably so).  I'm still not thrilled with Vista's resource usage (search topping the list), but after disabling UAC and the majority of the services, I now have a lean, mean, gaming OS --just as good as XP in single-card setups, and significantly faster in SLI.

Too bad, in a way, you run Intel/NV. AMD's Fusion utility not only makes OCing a breeze, it makes Vista like XP in disabling unneeded services at (game) runtime, then reverting when gametime's over. Mysteriously, it only works with AMD/ATi stuff. Funny about that... look it up an AnandTech.

My only gripe with Vista, at this point, is DX10.  It still runs slower than DX9, while providing little to no improvement in image quality.  And after reading up on DX11, I'm skeptical of it, as well.  Only time will tell if my suspicions are justified.

Heathen. Anyway, DX10 was gimped when NV refused to support some key features, and MS caved. ATi had already designed in support, part of the reason they 'lost' '07, esp. with the 2900XT, which NV is now paying for- they didn't put ATi away, and now they're behind. MS played hardball this time, which helps explain why ATi is ahead on DX11 parts- partial support (visible in 10.1 support, which most NV DX10 parts will forever lack) is already in, and the rest was that much easier.

Akb25 and I both look forward to 11, myself especially. I think it's notable one or more major titles are already announced for DX11, several more following shortly. I can't remember such quickness since perhaps DX3, if then. What's not to like?.. compute shaders, tris and patches both supported as primitives, D3D11 is a strict superset of 10 and 10.1, hardware tesselation. You'll love it once NV gets their troubled GT300 part out the door in quantity. Elite Bastards overview is a good starting point; mustn't OD on details too quickly.

We'll skin those eyes eventually, if it takes 10-bit panels to do it. [sigh]

Everything about DX11 is good.  The GPGPU stuff is good, but doesn't target games, per-se.  Tessellation is good, in that it improves both resource usage and image quality in engines with no or naive tessellation.  For engines that already support software tessellation, the improvement will save some VRAM, but I don't expect a significant difference in image quality. 

Multithreading is a point often overlooked.  As it stands, when there's multiple GPUs, the driver is forced to split up the rendering at runtime.  Since each card is rendering slightly different versions of essentially the same data, each card MUST contain nearly identical copies of the same data.  So, if you're like me, and you have two 512MB cards, then your total SLI VRAM is still 512MB.  Now, if the rendering tasks are split up at compile time, each card would then be working on something different.  So you should only need to keep enough common data in each card's VRAM to satisfy the rendering dependencies for each task.  So, in theory, two 512MB DX11 cards in SLI/Crossfire should provide more than 512MB VRAM (pure speculation on my part).

Where was I?  Oh yeah, I was trying to defend my "skepticism" of DX11.  What I mean is, there's a lot to love about DX11, especially from a developer's / enthusiast's point of view.  There's a major architectural improvement in DX11, and one can't help but stand back in awe of MS' accomplishment.  But as far as DX11's ability to enhance the real-world gaming experience, I think folks are getting a little overexcited.  Its goal is not so much about improving image quality; it's more about improving resource usage and scalability.

Last edited by Mr. T (2009-08-23 1:56 pm)

GPGPU does allow advances in gaming. For example, it allows you to run physics on the GPU. Also, it allows you to have more realistic shaders. Even with higher instruction limits, there's some things you can't do with current shaders because they aren't general purpose enough. Tessellation allows smoother LOD transitions and reduces popping. As I said before, developer's won't be able to suddenly take advantage of all this right away, but as hardware improves more and more will be practical. Graphical improvements are evolutionary, and eventually we're going to run into limits of our current feature set even when we have faster hardware. This allows the next step in that evolution to take place.

From what I understand about multi-threaded rendering, it's not going to allow you to double your VRAM with SLI cards. They still need all the data they're rendering their portion of the screen with. What it allows the developer to do is record some draw calls in one thread, then combine the results in order with other draw calls from another thread. In other words, you can put different chunks of rendering on separate threads and then combine the chunks on the main thread. This doesn't provide any real new functionality in that developers could have implemented it themselves (look at Left4Dead, which has multi-core rendering), but it makes it so the developer doesn't have to implement it themselves, and it can also be more optimized since the all draw calls will be managed by DirectX itself on every level.

GPGPU does allow physics processing on the GPU, but I'd rather dedicate all of my GPU resources to graphics while gaming.  NV supports hardware PhysX, and I keep it disabled for that reason.  As you say, when cards become more powerful, priorities might shift a bit.

Tessellation does offer smother LOD changes, but quality software tessellation looks great, already.  id has been using software tessellation and bezier surfaces since Quake III.  That's why Quake III looks so "curvy" compared to UT99.  But yeah, the majority of games use the old fashioned method of storing multiple models.  These games will certainly improve.  It won't be nearly as dramatic a change, as when devs began to use shaders for the first time.  But I look forward to this more than any other DX11 feature.  In fact, I'm going to have to disagree with you a little bit:  I think hardware tessellation will be practical from day one.

Re: Multi-GPU rendering, I was careful not to claim "double," I just said "more than 512MB."  But now that you mention it, I'm having a hard time imagining a situation in which the "dependencies" (using my words) are less than "everything."  Maybe you could break it down into models and environment, as long as everything is opaque.  Vertex-related stuff (like depth buffer, projection matrix, and so forth) could be shared, and maybe that would work... maybe...

akb825 wrote:

What it allows the developer to do is record some draw calls in one thread, then combine the results in order with other draw calls from another thread. In other words, you can put different chunks of rendering on separate threads and then combine the chunks on the main thread. This doesn't provide any real new functionality in that developers could have implemented it themselves (look at Left4Dead, which has multi-core rendering), but it makes it so the developer doesn't have to implement it themselves, and it can also be more optimized since the all draw calls will be managed by DirectX itself on every level.

That's definitely true.  As it stands, some games (like Crysis in SLI) are doubled in performance with the addition of a second card, while others (like FSX) don't seem to benefit at all. The ability to hand-optimize is indeed very useful.

The problem with not sharing resources between cards is you want the resources to stay resident the cards so you don't waste bandwidth sending the same data over to the card constantly. The way SLI normally works now is one graphics card renders one part of the screen while the other graphics card renders the rest. Since you're essentially splitting up the screen, not the graphics objects, you need to duplicate those resources.

I just took a look at this paper from AMD. It appears that they were using tessellation to increase the detail for their high LOD, then for their lower LODs fell back to normal rendering to make it perform acceptably. So it appears that there may still need to be multiple meshes in order to use tessellation at every LOD level: one for the high LOD that still has a relatively high number of control points, and another for lower LODs that has much fewer control points. I'm disappointed that they didn't offer any comparisons with a mesh that had as many triangles as the final tessellated output, though, so we can see the cost of the tessellation itself.

akb825 wrote:

The problem with not sharing resources between cards is you want the resources to stay resident the cards so you don't waste bandwidth sending the same data over to the card constantly. The way SLI normally works now is one graphics card renders one part of the screen while the other graphics card renders the rest. Since you're essentially splitting up the screen, not the graphics objects, you need to duplicate those resources.

You're referring to split frame rendering (SFR).  Most of today's games use alternate frame rendering (AFR) on the NV side, but that's besides the point.  I must admit that I really don't know how DX11's multi-GPU features work, but I interpret it as something that's different from both of these.  On the other hand, I can't find anything on the interweb that confirms my theory, so maybe it's exactly like SFR with more developer control.

I just took a look at this paper from AMD. It appears that they were using tessellation to increase the detail for their high LOD, then for their lower LODs fell back to normal rendering to make it perform acceptably. So it appears that there may still need to be multiple meshes in order to use tessellation at every LOD level: one for the high LOD that still has a relatively high number of control points, and another for lower LODs that has much fewer control points. I'm disappointed that they didn't offer any comparisons with a mesh that had as many triangles as the final tessellated output, though, so we can see the cost of the tessellation itself.

They mentioned that tessellation can dynamically reduce the geometry of tessellated characters, such that all of the tessellated characters in any given scene does not exceed some specified number of polygons (page 22).

If there are more than M such characters in the view frustum, this scheme will divide the tessellated triangles evenly among them.  While this can lead to slight visual popping as the size of the crowd changes dramatically from one frame to the next, in a lively scene with numerous animated characters this popping is very hard to perceive.

Here, they're dynamically scaling the tessellated geometry to satisfy the given formula.  It seems just as possible to assign each tessellated object a weight based on z-depth.  I don't know why they don't do that here (performance issues, perhaps?).  Even if multiple meshes are necessary, at least they can be generated at startup from the one base mesh.

Last edited by Mr. T (2009-08-23 6:08 pm)

akb825 wrote:

Mr. T wrote:

They mentioned that tessellation can dynamically reduce the geometry of tessellated characters, such that all of the tessellated characters in any given scene does not exceed some specified number of polygons (page 22).

If there are more than M such characters in the view frustum, this scheme will divide the tessellated triangles evenly among them.  While this can lead to slight visual popping as the size of the crowd changes dramatically from one frame to the next, in a lively scene with numerous animated characters this popping is very hard to perceive.

Here, they're dynamically scaling the tessellated geometry to satisfy the given formula.  It seems just as possible to assign each tessellated object a weight based on z-depth.  I don't know why they don't do that here (performance issues, perhaps?).  Even if multiple meshes are necessary, at least they can be generated at startup from the one base mesh.

They were using the normal triangulated mesh as the basis for their tessellation, so the lowest level of detail they could get to was their original mesh. You can only get your base mesh for tessellation down so far before you're going to lose quality for your high level of detail. It's really unfortunate that they don't give any information as to the cost of the tessellation itself, since that will give us a better gage of its practicality on current hardware..

I don't know about tessellating a bezier patch with fewer polygons.  It seems like it ought to be possible, but I can imagine how lower detail levels might look weird if you tessellate down.  I think you're on to something, here.

As for performance, this is pretty enlightening.  This gives actual code capable of rendering a bezier patch from a Quake 3 map.  The patch is first tessellated by the CPU, and then rendered by the GPU using vertex arrays.  The tessellation process actually doesn't look as complicated as I originally imagined.  Though this isn't the official algorithm used by id, it's clear from all the multiplications that this isn't something you'd want to do frequently.  But how frequently is "too frequently?"  Is modern hardware capable of supporting depth-based LOD transitions?  That is the $64,000 question.

The answer is YES!  Quake III (and subsequent engines) does, in fact, use tessellated bezier patches for LOD transitions.  This is from a map-maker's perspective.

One of the nice things about curved surfaces is the level-of-detail (LOD) rendering used by Quake 3. At far distances, curves are rendered using fewer polygons (lower level-of-detail) so that the total number of polygons drawn is minimized.

This goes on to explain that LOD scaling only works on a per-patch basis, and won't work on adjacent patches (since the different approximations won't line up seamlessly).  This means that if you're designing a large map you'll want to break up the tessellated patches with other structures.  In closed environments, this is fairly easy to accomplish; in outdoor environments, it requires a bit of creativity.  For characters and world objects, there's' obviously no issue.

Back to my original point, I don't think that hardware tessellation offers a significant advantage over software methods.

Here's John Carmack on the subject

I’m still not a big believer in hardware accelerated curve tessellation.
I’m not going to go over all the reasons again, but I would have rather
seen the features left off and ended up with a cheaper part.

source.  That one's from 2001.  This is from 2008.

PCPER: Is AMD’s tessellation engine that they put in the R600 chips anywhere close to what you are looking for?

CARMACK: No, tessellation has been one of those things up there with procedural content generation where it’s been five generations that we’ve been having people tell us it’s going to be the next big thing and it never does turn out to be the case.  I can go into long expositions about why that type of data amplification is not nearly as good as general data compression that gives you the data that you really want.  But I don’t think that’s the world beater; I mean certainly you can do interesting things with displacement maps on top of conventional geometry with the tessellation engine, but you have lots of seaming problems and the editing architecture for it isn’t nearly as obvious.  What we want is something that you can carve up the world as continuously as you want without any respect to underlying geometry.

source

Of course, hardware tessellation should still be of benefit to engines that don't already support it.   I just don't think it's a killer feature; yet it's the one I'm most looking forward to.  Ironic, isn't it...

Last edited by Mr. T (2009-08-24 3:03 am)

Without taking more time than I have, I'll mention a couple of things in passing.

1) I too remember various folks pushing for thing like Bezier curves & other higher-level surfaces ca. 1999 and earlier. But the ivory-tower types and lovers of their own copy () were pushing too far ahead.

2) The 360 has a hardware tesselator in it, and it's hard to get info on what games use it. That's an ATi chip, and ATi vidcards of the HD series all have it. DX11 tesselation is beyond that, but it does at least open the possibility of getting some benefit from it under DX11, tho not full. Seems at least possible some console games have been held back from PC ports until it's a better-supported feature (i.e. until DX11 cards become somewhat common from both makers, making that mode at least an option).

Now announce H3 PC when 7 and DX11 launch, you MS bassids! :shakefist:

Bat wrote:

Without taking more time than I have, I'll mention a couple of things in passing.

1) I too remember various folks pushing for thing like Bezier curves & other higher-level surfaces ca. 1999 and earlier. But the ivory-tower types and lovers of their own copy () were pushing too far ahead.

2) The 360 has a hardware tesselator in it, and it's hard to get info on what games use it. That's an ATi chip, and ATi vidcards of the HD series all have it. DX11 tesselation is beyond that, but it does at least open the possibility of getting some benefit from it under DX11, tho not full. Seems at least possible some console games have been held back from PC ports until it's a better-supported feature (i.e. until DX11 cards become somewhat common from both makers, making that mode at least an option).

Now announce H3 PC when 7 and DX11 launch, you MS bassids! :shakefist:

Ya but only if M$ doesn't epic fail again and make H3 only work on 7...similar to what they did with H2 and Vista. If it works with Vista/7 then i'm happy as i'm stuck with Vista till Ultimate 7 upgrade discs are cheap and plentiful.