A Few Notes on Future NV Hardware

DaveBaumann said:
I've just got back from NVIDIA's "Dusk-till-Dawn" developer event. I'll have an article with an overview up of the event sometime, but here a a couple of little hardware details picked up from the event:

  • W-Buffer support dropped from future NV hardware (use FP calculations if you want higher precision).

  • Btw, I'd just like to make one last point on this.

    If they're going to remove W-buffer support, they could at least implement a higher-precision z-buffer. This sounds, to me, more like a crappy attempt to not have to implement as much in the way of z-buffer bandwidth savings type stuff (similar to ATI's). But Dave, you said "future hardware," do you think this relates to NV3x or further into the future?

    As a quick side note, I would really like to see some true 32-bit z-buffer support. The stencil buffer should go somewhere else...
 
Bomb scare?

Ah, that's why Kings Cross was blocked off last night then. Right pain in the arse getting home yesterday.



I'm also, ahem, interested in seeing what DS has to say about the dropping of W-buffer support.
 
Oop. Just going back and answering a few more questions...

MuFu said:
Did they mention anything or did you pick up any "hints" regarding their next-gen, unified shading model?

It was a reasonably open, non-NDA even, so they wouldn't go into anything like that. I was even surprised to see how little CineFX/NV30 centric the event was.

Tahir said:
Did you get a GFFX Ultra too? :)

heh. No, I was invited along as press so I don't get a board (although I didn't have to pay either! :))

pocketmoon_ said:
Where you the one dancing on the bar with the girls ?

heheh. No, I kept back where I could watch the "entertainment"! ;) :D

Chalnoth said:
If they're going to remove W-buffer support, they could at least implement a higher-precision z-buffer. This sounds, to me, more like a crappy attempt to not have to implement as much in the way of z-buffer bandwidth savings type stuff (similar to ATI's). But Dave, you said "future hardware," do you think this relates to NV3x or further into the future?

What gets me that if you want a higher precision Z buffer you have to create it through the shader pipe anyway, which also uses all the Z-Cull optimisations.

Anyway, given the nature of the even I would certianly assume this to be apllicable to NV3x

Gerry said:
Ah, that's why Kings Cross was blocked off last night then. Right pain in the arse getting home yesterday.

Where you there (D2D) as well?
 
pocketmoon_ said:
The whole FP16/32 issue is very confusing - the presenter struggled with a LOT of the information he was trying to get across.

Did the word twitchy come to mind under the presentation? ;)
 
DaveBaumann said:
Where you there (D2D) as well?

Wish I was, instead of just earning my crust in my job at the Angel. It would have been far more interesting believe me. My normal commute back home just got a bit disrupted, that's all.
 
LeStoffer said:
pocketmoon_ said:
The whole FP16/32 issue is very confusing - the presenter struggled with a LOT of the information he was trying to get across.

Did the word twitchy come to mind under the presentation? ;)

Can't say I blame him, I'm not sure they know whats going on. I get the feeling that certain things are not being decided purely for technical reasons. Which makes dev rels job very hard, i.e. he's having to explain something that he knows doesn't make sense.

The whole 16 bit float thing is a classic example, there own CG manual (CG Toolkit, User Manual, December 2002) on page 203 under DirectX Pixel Shader 2.x Profiles states

"
- float data type is implemented as IEEE 32-bit single precision.
- half, fixed and double data types are treated as float.
half data types can be used to specify partial precision hint for pixel shader instructions.
"

So the guys writing CG don't know what there own DirectX drivers are doing? So CG ps_2_0 profile currently only writes correct code for ATI DirectX drivers :)
 
DeanoC said:
Can't say I blame him, I'm not sure they know whats going on. I get the feeling that certain things are not being decided purely for technical reasons.

Do you think that this stems from vNidia being a bit, well, twitchy about whether they wanted to target 'ordinary' consumers with int and FP16 paths vs FP32 for the prof/dev market with the FX architecture?
 
Chalnoth said:
As a quick side note, I would really like to see some true 32-bit z-buffer support.

For 32-bit z-buffers to be of any real use you are pretty much forced to use doubles instead of floats when you send them to the graphic card. The graphic card must also have precision higher than normal 32bit floats in the vertex pipeline too. Otherwise, the error introduces in the vertex pipeline will really make those extra 8bit to nothing but noise.
 
Numerous references to "Second texture runs at full speed". Mmmmm...

I have no idea what that's in reference to...anyone care to speculate? (Or could you elaborate, Dave...or should I just wait for the article...)
 
Sigh...

What really bugs me right now is HarcOCP still has a GeForceFX and is being fed stuff from nVidia to "test"....and you guys...who would put it through its proper paces like you do with all new cards...are still waiting for one...

I find it disturbing that HardOCP is not trying to get to the bottom of the 4x2 / 8x1 issue. They have the hardware and the tests that could, if nothing else, rule out a few possibilities that we're speculating on...
 
Humus said:
Chalnoth said:
As a quick side note, I would really like to see some true 32-bit z-buffer support.

For 32-bit z-buffers to be of any real use you are pretty much forced to use doubles instead of floats when you send them to the graphic card. The graphic card must also have precision higher than normal 32bit floats in the vertex pipeline too. Otherwise, the error introduces in the vertex pipeline will really make those extra 8bit to nothing but noise.

That's not quite true. You'l get useful information in there for very small Z's, but yes, once you start getting over a 256'th of your range the bottom bits start becoming useless.

(FP32 is 24-bit mantissa. 32-bit is....well... 32-bits. Difference in size is 8-bits, therefore one 256th)
 
LeStoffer said:
Do you think that this stems from vNidia being a bit, well, twitchy about whether they wanted to target 'ordinary' consumers with int and FP16 paths vs FP32 for the prof/dev market with the FX architecture?

I think its much simplier - performance, they made a bet that 32 bit float aren't needed much so it was o.k. for them to run much slower (50% of the speed).

Along came ATI and produce 24 bit floats, which have the best of both worlds - as fast as 16 bit floats and have the precision to be really useful. Because they were first (by a big margin) they effectively set the minimum spec.

Which leaves them trying desperate (and in this case stupid) things to get some performance back.

There is no reason for them to force DirectX devs to use 16 bit floats! We can specify partial precision, so they just have to educate us to use it when we can.
 
Gerry said:
DaveBaumann said:
Where you there (D2D) as well?

Wish I was, instead of just earning my crust in my job at the Angel. It would have been far more interesting believe me. My normal commute back home just got a bit disrupted, that's all.

OT - good time for me to be off on gardening leave then :)
 
I do not understand... W-buffer, as far as I can remember, doesn't have the problem that regular Z-buffer has meaning it distributes linearly over the distance while Z-buffer has a non-linear distribution over the same range...

I do not know how using a FP Z-buffer can replace W-buffering...

FP numbers do not have a linear distribution of precision over the range either...

BTW, if they totally eliminate W-buffering ( which is weird as in a paper they were talking about DOOM III shadowing method and how useful W-buffering would have been ;) ) they could go with 3x3 Matrix transforms and simplify the architecture of their shaders ( you only need 3 parallel FMACs... )...
 
Joe DeFuria said:
What really bugs me right now is HarcOCP still has a GeForceFX and is being fed stuff from nVidia to "test"....and you guys...who would put it through its proper paces like you do with all new cards...are still waiting for one...
Life is like that, Joe. Putting things through its "proper paces" usually is a tough decision on both parties.
 
Life is like that, Joe. Putting things through its "proper paces" usually is a tough decision on both parties.

Tougher decision for some than others, apparently.

Rev, do you approve of [H]'s and other web-sites testing GeForceFX with detonator drivers that are not available to the public?
 
I would be more conerned about your own opinion Joe...thats all the matters. You seem to have, and always have shown a level headed amount of ethics in your posts, that's all that matters.
 
Back
Top