NV30 vs. NV2A

I recall that Nvidia/MS said NV2A would have some of the geometry features of the NV30, thus Nvidia/MS said NV2A was basicly a NV27.5.

It's quite remarkable that NV2A turned out to be something LESS than even the NV25. :rolleyes: a virtual NV22.5 :(
 
BoddoZerg said:
http://www.nvidia.com/docs/IO/3666/SUPP/large01.jpg

hehehehehe, funny that nVidia disses the Xbox in favor of NV30.

that's how it looks on my radeon9700pro right now ;)
 
It's quite remarkable that NV2A turned out to be something LESS than even the NV25.
I wouldn't really consider it something less. All it lacks in comparison to the GF4 is basically LMAII and Accuview, but it keeps the quad-cache and gains certain geometry features that are present in the NV30 (one I know of being the ability to make signed stencil buffer additions). I also believe the NV2A may have more static instructions and constants.

I've heard that the NV25 is not capable of collision detection on-chip using vertex shaders. I do remember the devs for Wreckless saying that the NV2A's vertex shaders could in fact be used for collision detection, something that the NV30 is able to do.
 
Are the vertex shader's on the NV2A in fact capable of collision detection? Any comments ERP?

Update: I found a Wreckless developer interview on the following link: http://spin.s2c.ne.jp/dsteal/wreckless.html

Here is an interesting snippet:

"Nagaya: Actually even now we researched on Xbox whether you can make it do collision detection with vertex shaders. We ended up not doing that, but it seems like it can do it. So the collision is dependant upon the polygon mesh's form, but because they are divided into tristrips for optimization, for example the strips flowing out of DMA, it seems like you can do stuff like set fixed registers to have a texel in the upper left corner read out which polygon was hit. This time because the GPU was being used for drawing, it's not like when the CPU was to perform a collision detection the GPU was free."

Any comments?
 
DeathKnight said:
I wouldn't really consider it something less. All it lacks in comparison to the GF4 is basically LMAII and Accuview, but it keeps the quad-cache and gains certain geometry features that are present in the NV30 (one I know of being the ability to make signed stencil buffer additions). I also believe the NV2A may have more static instructions and constants.

Isn't signed stencil buffer 2 sided stencil? As far as I know, Xgpu doesn't support it, anyway, I would like to see any link. Oh, and 1 more thing, XGPU does have a slightly longer vertex instruction than that of NV25 (136 as opposed to 128), but its constant register is the same 192 (96 per vertex shader for GF4), though the maximum value allowed by DX8 is just 96.
 
embargiel said:
Isn't signed stencil buffer 2 sided stencil?
No. Two-sided stencil means stencil operation is dependent on whether the polygon ist front-facing or back-facing. This allows rendering of shadow volumes in one pass instead of doing one pass with backface-culling, changing the stencil function, and then doing another pass with "frontface culling".
 
Xmas said:
No. Two-sided stencil means stencil operation is dependent on whether the polygon ist front-facing or back-facing. This allows rendering of shadow volumes in one pass instead of doing one pass with backface-culling, changing the stencil function, and then doing another pass with "frontface culling".

What?? So what does "signed stencil buffer" mean? I thought the idea of it was the same. Here's the idea of signed stencil buffer that I quoted from somewhere else:

"Two-sided lighting determines whether polygon adds or subtracts 1 from stencil buffer".

It's exactly the same with your definition. Whether the polygon is front-facing or back facing in 1 pass.
 
I think "signed stencil buffer" just means the wrap mode of stencil operations (which can avoid overflow on volumetric shadow computation). Many chips support it (including RIVA TNT). There is no signed stencil comparison support in DX9 IIRC.
 
pcchen said:
I think "signed stencil buffer" just means the wrap mode of stencil operations (which can avoid overflow on volumetric shadow computation). Many chips support it (including RIVA TNT). There is no signed stencil comparison support in DX9 IIRC.

If many chips were to be supporting it, then how could people say that it be the NV2A advantage over NV25?

DeathKnight said:
I wouldn't really consider it something less. All it lacks in comparison to the GF4 is basically LMAII and Accuview, but it keeps the quad-cache and gains certain geometry features that are present in the NV30 (one I know of being the ability to make signed stencil buffer additions).
 
embargiel said:
What?? So what does "signed stencil buffer" mean? I thought the idea of it was the same. Here's the idea of signed stencil buffer that I quoted from somewhere else:

"Two-sided lighting determines whether polygon adds or subtracts 1 from stencil buffer".

It's exactly the same with your definition. Whether the polygon is front-facing or back facing in 1 pass.
I'm not sure why anyone would call this "signed stencil buffer".
Anyway, two-sided stencil of course allows any combination of two stencil functions, not just incr and decr.
 
pcchen said:
I think "signed stencil buffer" just means the wrap mode of stencil operations (which can avoid overflow on volumetric shadow computation). Many chips support it (including RIVA TNT). There is no signed stencil comparison support in DX9 IIRC.

DX9 has both wrapped and clamped stencil. From the docs:

D3DSTENCILCAPS_INCRSAT 0x00000008L Increment the stencil-buffer entry, clamping to the maximum value.
D3DSTENCILCAPS_DECRSAT 0x00000010L Decrement the stencil-buffer entry, clamping to zero.
D3DSTENCILCAPS_INCR 0x00000040L Increment the stencil-buffer entry, wrapping to zero if the new value exceeds the maximum value.
D3DSTENCILCAPS_DECR 0x00000080L Decrement the stencil-buffer entry, wrapping to the maximum value if the new value is less than zero.
 
Of course, they are also available in DX7 IIRC.
However, the stencil operations (comparisons) are still on unsigned numbers. That is, the numbers are still 0 ~ 255, not -128 ~ 127.
 
You're matching a bit-pattern. If you imagine that being a signed integer or unsigned integer is up to you.
 
Stencil operations can be set to greater or less than against a reference value, so signed number and unsigned number are different.
 
True, you're right. Ah, haven't used stencil in a long time. :)

Anyway, signed stencil could still easily be emulated by clearing stencil to 128 instead of 0 and compare to 128 + ref.
 
[quote="Humus]Anyway, signed stencil could still easily be emulated by clearing stencil to 128 instead of 0 and compare to 128 + ref.[/quote]

The thing is, is there any advantage by doing that? And will the performance hit be great?
 
Back
Top