Nvidia Instancing demo on x800

[digitalwanderer]

Is this 'the big thing' some people were *COUGHING* about?

No.

Deano, thank you!

 

[Farid]

My understanding is that this uses hardware registers and and few other thing, but is software assisted (althought that may be the case for a normal implementation - I don't know). It should benefit any R300/R420 based hardware if its coded for, however as its primary task is to remove some of the CPU overhead with vertex batches, so you are going to see the benefits more on higher end boards.

Do you know, Dave, if this software does rely "heavily" on the CPU?

 

[Dave Baumann]

I would say that the difference in the demo here would suggest not.

I don't know the extent of it, however I don't think the overhead is particularly great. But, the main element is that the registers used are in the hardware.

 

[digitalwanderer]

OT-Happy 7k Dave. 8)

 

[Humus]

I think MS must have made a conscious decision that SM3.0 = orthogonal FP support (blending, filtering, etc) + instancing, etc.

Well, if they wanted to do that it would mean nVidia couldn't expose SM3.0 since the 6800 doesn't support either of blending or filtering on FP32.

 

[Humus]

They start bundling completely unrelated features because even though there called shader models there really now just grades of hardware.

And that's exactly what's wrong. There is no such thing as grades of hardware. It's not nearly that linear. It's sort of like when you put people's different political view and opinions on the left-right scale, which artificially ties completely unrelated views to each other, which does nothing but rationalizes people's prejudice against those on the other side of the scale.
It's sort of linear within an IHV though I guess, but not entirely linear there either. Features occasionally gets dropped from hardware. But it's certainly not particularly linear when you take all the IHVs into account.

Now I'm fine with a packaging model with loads of functionality bound into it, IFF it also allows you to poke in the details if you care. I think the OpenGL model is good. For many apps you can just check the OpenGL version, and if you have say 1.5 you have a large package of features you can use. But if you want more precise details, you can query the extensions, and if you want even more detail, query the capabilities within the extensions.

 

[DeanoC]

For many apps you can just check the OpenGL version, and if you have say 1.5 you have a large package of features you can use. But if you want more precise details, you can query the extensions, and if you want even more detail, query the capabilities within the extensions.

Why is OpenGL bundling any better than D3D?

Both systems make mistakes, from the shadow buffer stuff in OpenGL to D3D vertex instancing.

If anything bundling capabilities is something OpenGL has made more mistakes with than D3D so far. The shadow buffer issue makes a great example.

Shadow buffers are part of OpenGL 1.4 (I think) but aren't supported on all hardware natively. Its not an inherit capability of most non NVIDIA hardware and they have to emulate it via fragment programs. This caused a big mess when ARB_Fragment_Program came about, as you need fragment programs to do both on ATI hardware but you can mix fragment program and shadow buffers freely on NVIDIA.

NVIDIA was quite rightly pissed that enabling fragment programs disabled a logically seperate part of the API (its basically the same as connecting geometry instancing to shader model) and wouldn't support it (they have claimed ATI rushed it through the ARB spec process without proper reviews on that particular part).

Not a great success for bundling, shadow buffer should have remained a IHV extension with NV_Shadow_Buffer working regardless of fragment program, and ATI_Shadow_Buffer not working with fragment programs. Of course when ATI get very long shaders (so can support shadow maps with any shaders) they could have supported NV_Shadow_Buffer.

 

[Johnny Watson]

eh. I will get doom3 but its no biggy if i can only get 60fps

The game is clamped at 60 fps to prevent synching errors that were present in Quake 3, so that's the highest anyone will get.

(Yes, I know the benchmarks go higher than 60, but the benchmarks aren't the game)

 

[Pete]

Great discussion, guys. Keep it up.

Dave, when you say "vertex stream frequency/geometry instancing," do you mean they're two different terms for the same thing, or just two different but important VS improvements in terms of CPU usage? They sound different at face value, but I'm guessing they're not?

BTW, does anyone care to reply to my second question, whether this nV demo was purposefully "badly" coded (very high frequency?) to exaggerate instancing's improvement? I mean, do X800s and 6800s really drop down to 4fps rendering a bunch of rocks?

 

[Bouncing Zabaglione Bros.]

BTW, does anyone care to reply to my second question, whether this nV demo was purposefully "badly" coded (very high frequency?) to exaggerate instancing's improvement? I mean, do X800s and 6800s really drop down to 4fps rendering a bunch of rocks?

IIRC, it's a worst case scenario. Nvidia demoed it at their launch events with the same kind of massive differences, like 5 fps without instancing, and 50 with instancing on 6800U.

 

[Ostsol]

BTW, does anyone care to reply to my second question, whether this nV demo was purposefully "badly" coded (very high frequency?) to exaggerate instancing's improvement? I mean, do X800s and 6800s really drop down to 4fps rendering a bunch of rocks?

Drawing each rock individually would result in a CPU limitation, so yeah I'd say that the comparison is valid. Of course, no developer in their right mind would code a game that drew that many objects individually. They'd used other alternatives. . . like instancing.

 

[Simon F]

Great discussion, guys. Keep it up.

Dave, when you say "vertex stream frequency/geometry instancing," do you mean they're two different terms for the same thing, or just two different but important VS improvements in terms of CPU usage? They sound different at face value, but I'm guessing they're not?

I would assume they are implying the same thing: the vertex stream frequency allows you to do geometry instancing (and other things for that matter).

 

[Ylandro]

eh. I will get doom3 but its no biggy if i can only get 60fps

The game is clamped at 60 fps to prevent synching errors that were present in Quake 3, so that's the highest anyone will get.

(Yes, I know the benchmarks go higher than 60, but the benchmarks aren't the game)

As far as I understood, the game phyics is operating at 60fps. So that running, jumping etc work independend of framerate.
The actual graphics rendering is not clamped, and can be running at any framerate.

 

[Veridian3]

BTW, does anyone care to reply to my second question, whether this nV demo was purposefully "badly" coded (very high frequency?) to exaggerate instancing's improvement? I mean, do X800s and 6800s really drop down to 4fps rendering a bunch of rocks?

It is a bit of a worst case scenario (rather than badly coded), yes. Thats kind of the point though, test the worst case scenario you can to see what the real benefits can be.

On a slightly different note, Tommti removed all the CPU limiting code the new stats are:
6800GT @ Ultra... 3.4fps with off and 47.2 with on

X800XTPE... 4.46fps with off and 50.21 with on

 

[Martin Eddy]

eh. I will get doom3 but its no biggy if i can only get 60fps

The game is clamped at 60 fps to prevent synching errors that were present in Quake 3, so that's the highest anyone will get.

(Yes, I know the benchmarks go higher than 60, but the benchmarks aren't the game)

AFAIK The AI and physics is clamped at 60FPS not the actual framerate of the game.

 

[Simon F]

Great discussion, guys. Keep it up.

Dave, when you say "vertex stream frequency/geometry instancing," do you mean they're two different terms for the same thing, or just two different but important VS improvements in terms of CPU usage? They sound different at face value, but I'm guessing they're not?

I would assume they are implying the same thing: the vertex stream frequency allows you to do geometry instancing (and other things for that matter).

 

[jvd]

So what else is instancing good for beisdes rocks , trees and grass ?

 

[nelg]

So what else is instancing good for beisdes rocks , trees and grass ?

Rendering a nude beach

 

[Scott_Arm]

Instancing

I find it strange that instancing is only being added to specs now .... you'd think this would have been an obviously beneficial technology early on. So many games repeat geometry.

Does instancing only work for static geometry, like trees? Or say if you were making a Star Wars game, and you were fighting hordes of storm troopers, could instancing be used for those enemies? I'm just wondering if there's any limitations to how it works. If it can be used for enemies, it seems like it would be very useful for games like Serious Sam, where you're swarmed by seemingly endless hordes of monsters.

 

[Farid]

Re: Instancing

I find it strange that instancing is only being added to specs now .... you'd think this would have been an obviously beneficial technology early on. So many games repeat geometry.

On Ati hardware? If yes, then it's because Ati's Instancing is some kind of software trick (that mainly use the Radeon hardware, and very little CPU, if i understood correctly), and logically it wasn't available from day one...
Maybe, Ati decided to "work on it", when they saw Nvidia creating a buzz around instancing, with their "little dude rendering"