Comments on Nv engineer words?

[Sinister]

www.beyond3d.com/reviews/visiontek/nvidia_gf4ti4600/index2.php

Please, someone care to elaborate?

NV engineer: Z occlusion culling only benefits geometry, unfortunately. Here's why--we only get a savings if the object is completely occluded (and hence can throw out the entire object). But we already render normal occluded pixels at the maximum rate, so we don't save anything compared to just sending the original object. In fact, we may use *more* fillrate, because the bounding box is only a conservative bound, and hence bigger than the object in screen space. And as you said, if the object is visible, then you definitely lose, because you've now rendered stuff twice (fortunately, the bounding box is cheap to render).

Pardon for my ignorance, but I thought Z-oclusion culling was done on a per pixel basis...

and,

NV engineer: Villagemark is a near worst-case for non-tile-renderers. It lies somewhere between random sorting and back-to-front sorting of geometry (and yes, I've stepped through it polygon by polygon). It's possible that ATI is doing something like reordering geometry in the driver to boost their scores here. Also, ATI's hardware can reject 64 pixels per clock. Their hardware for doing this is not very sophisticated from what I understand, and it may break down in certain complex situations, but it's sufficient for Villagemark.

so, he´s suggesting something is being done partially in software (driver) in the R200?

Rodrigo

 

[croc_mak]

Funny you bring this up...seems like the NVEngineer doesn't know what he is talking about...scary when the data from the mktg guy looks more genuine than the engineer

AFAIK the z occlusion culling that Nv talks about is just an early Z reject type of thing and it helps fillrate. The bounding box test based on visibility query is another optimization altogether - this optimization may only help in some specific cases.

 

[ERP]

Actually what he's talking about is the Occlusion Query stuff, not early Z reject.
The concept is that you render a low level of detail conservative aproximation for a complex piece of geometry just into the ZBuffer with just Z reads enabled. The hardware can tell you if any pixels would be rendered, and then you decide based on the result weather you should draw the complex model.
As he states it's only real use is to reduce the amount of geometry you send to the card, it will never save you fillrate.

 

[Simon F]

Disclaimer: This post might not reflect the opinions of my employer etc...

www.beyond3d.net/reviews/visiontek/nvidia_gf4ti4600/index2.php
(Ed: Fixed link - from .com to .net)
Please, someone care to elaborate?

: Z occlusion culling only benefits geometry, unfortunately. Here's why--we only get a savings if the object is completely occluded (and hence can throw out the entire object). But we already render normal occluded pixels at the maximum rate, so we don't save anything compared to just sending the original object. In fact, we may use *more* fillrate, because the bounding box is only a conservative bound, and hence bigger than the object in screen space. And as you said, if the object is visible, then you definitely lose, because you've now rendered stuff twice (fortunately, the bounding box is cheap to render).

Pardon for my ignorance, but I thought Z-oclusion culling was done on a per pixel basis...

As ERP pointed out, this clearly refers to some form of object/Object Hierarchy visibility culling where your have an overall bounding box for a set of objects (post Transform) and 'invisibly' render the bounding box. A flag is set if any part of the box would be visible. The software reads the flag and then only sends the data through the T&L if necessary.

The system would thus benefit if you had a number of very simple but large objects that you rendered first, followed by a lot of small but complex objects. I assume the idea is to save precious T&L / Vertex Shader time and bandwidth.

and,

Villagemark is a near worst-case for non-tile-renderers. It lies somewhere between random sorting and back-to-front sorting of geometry (and yes, I've stepped through it polygon by polygon). It's possible that ATI is doing something like reordering geometry in the driver to boost their scores here. Also, ATI's hardware can reject 64 pixels per clock. Their hardware for doing this is not very sophisticated from what I understand, and it may break down in certain complex situations, but it's sufficient for Villagemark.

To the best of my knowledge, there is NO deterministic sorting of the houses etc in VillageMark - AFAIK i'm certain it's not arranged in Back-to-Front order. The houses are simply sent in to the hardware in the order that they are in the "database list" - this would not change as the camera moves around the circuit.

Interesting to see that it's been 'analysed' so much though. That should give the author a laugh - I'll send him this link. BTW the author contacted Nvidia to ask for the recommended method of using their T&L to make sure the bench was not unfair.

 

[mboeller]

Also, ATI's hardware can reject 64 pixels per clock. Their hardware for doing this is not very sophisticated from what I understand, and it may break down in certain complex situations, but it's sufficient for Villagemark

nice FUD )


Since when are engineers paid for marketing

 

[LittlePenny]

nice FUD )


Since when are engineers paid for marketing

I found that statement funny as well. Sounded more like the man's pride to me.

 

[Livecoma]

nice FUD )


Since when are engineers paid for marketing

I found that statement funny as well. Sounded more like the man's pride to me.

How do we know for sure that statement is not true to some degree?

 

[OpenGL guy]

lol

Also, ATI's hardware can reject 64 pixels per clock. Their hardware for doing this is not very sophisticated from what I understand, and it may break down in certain complex situations, but it's sufficient for Villagemark

This guy should give an example of when it can "break down". If there is no such example, then I would assume it doesn't "break down".

Also, nvidia _still_ hasn't implemented PS 1.4 and this guy wants to talk about hardware that "is not very sophisticated"?

 

[3dcgi]

I noticed when I first read the interview that the marketing guy and engineer interpreted the question differently. Both seemed to answer the interpreted question correctly. I agree that the engineer was only talking about occlusion query. As for VillageMark the engineer has probably never run it. I was also under the impression that VillageMark was sorted back to front. I got this impression from reviews. When review sites use VillageMark they state that the scene is sorted from back to front.

Also, when the engineer mentions that ATI's hardware breaks down in certain complex situations he is correct. Although breaks down is a wierd way to put it. I believe he is just stateing that in certain scenes the hierarchical method might lose some of its effectiveness. In this situation a per pixel early z reject might be better, but its just a tradeoff like any other design decision. The designer at nVidia and ATI each chose the tradeoff they thought would win most often.

 

[Reverend]

The "NV Engineer" was a (generally) respected participant in our old forums. However, all that's left behind in this new forum of ours is his ghost.

Just so you all know.

 

[LittlePenny]

The "NV Engineer" was a (generally) respected participant in our old forums.

My guess is Colourless. I guess you couldn't tell us which one though huh?

 

[Reverend]

I don't think Colourless is with NVIDIA but I could be wrong. That means it's not Colourless .

I've already dropped a hint on who "NV Engineer" is.

 

[Nil Einne]

Did there used to be someone called NV Engineer in these forums?

 

[nAo]

Sim Dietrich? Even if he's more a sw guy...

 

[Simon F]

I don't think Colourless is with NVIDIA but I could be wrong. That means it's not Colourless .

I've already dropped a hint on who "NV Engineer" is.

And a damned big one at that. The penny dropped for me when I went back and read your previous post and I finally understood the "pun" in the posters name. My guess is that he had a bit of "jealousy"

 

[nAo]

Now it's clear I didn't know he's a nvidia engineer...

 

[JF_Aidan_Pryde]

I think -- has taught me more on the subject of 3D, especially in 64bit colour needs and scalable architectures than anything else I've read.

I wish he would come back and post..even if under a different name.

*sigh*

This doesn't have to do with company secrets. This is general design theory, and more, it's about education! Educating wannabies like me, bored out of my guts in Computing Engineering, just dieing to be the next sum[G.T, S.S., R.S.,] etc.
(Yes, I do realise it's a idealistic/naive wet dream, but a bit of idealism will sure help make this world a little bit more interesting)

respects,
Aidan Pryde
aidan_pryde@iprimus.com.au

 

[LeStoffer]

Indeed. The input of [..] has been awesome. At one point I actually saved a big comment on his part on the very subject of HSR. Who should have thought that he worked for nVidia. Interesting.

 

[Dave Baumann]

You two are on the wrong track.

 

[JF_Aidan_Pryde]

We are? Darn, o well, I still owe a bucket load to good'old SA.

Is it possible to know whether he's ex-3dfx?