Beyond3D's review of the VisionTek XTASY GeForce4 Ti4600

[Reverend]

Beyond3D review of the VisionTek XTASY GeForce4 Ti4600 (http://216.12.218.25/domain/www.beyond3d.com/reviews/visiontek/nvidia_gf4ti4600/index1.php)

Discussions and comments welcomed here.

[LittlePenny]

I had an idea to test the vertices thing. On paper the value of pi can be calculated more accurately by breaking a circle into smaller and smaller triangles. So you would go from say a hexagon, to an octogon and so on. To get the the point, if we drew a circle in OpenGL and slowly increased the number of vertices required to draw it, would this be a sufficient test for a video cards triangle upper bound?

[Oompa Loompa]

One thought, though. Scale is oh-so-important when graphing results. Even though intelligent humans are supposedly-capable of considering numbers and disregarding visual stimuli, I still question whether:
http://216.12.218.25/domain/www.beyond3d.com/reviews/visiontek/nvidia_gf4ti4600/villagemark.jpg
accurately reflects reality. There isn't much difference at all, but the scale you've chosen suggests that there is.

In any case, thanks. If you want to become even more critical and aggressive I would have no objections.

[nggalai]

Good morning, Reverend,

what Oompa Loompa said--this graph is quite misleading if only studied at a quick glance. I would have liked some more research into the Z occlusion culling parts of the NV25, too. We had a discussion about the NV20's technique in the old B3D forums (http://www.beyond3d.com/messageview.cfm?start=21&catid=3&threadid=1576), and things are still not too clear, I'd say.

Apart from that, I liked the review. Thanks for including the Q&A part, too. Well done.

ta,
.rb
________
buy vaporizer (http://vaporizers.net/)

[Mize]

One thought, though. Scale is oh-so-important when graphing results. Even though intelligent humans are supposedly-capable of considering numbers and disregarding visual stimuli, I still question whether:
http://216.12.218.25/domain/www.beyond3d.com/reviews/visiontek/nvidia_gf4ti4600/villagemark.jpg
accurately reflects reality. There isn't much difference at all, but the scale you've chosen suggests that there is.

In any case, thanks. If you want to become even more critical and aggressive I would have no objections.

I second this concern. What is the point of a graphical representation of data if it is not representative? The aforementioned graph (and numerous others on all hardware sites it seems) indicates graphically that 119 is roughly 1/2 as much as 128...come on Rev!
:)

Mize

[JohnH]

The graphs are only misleading if you don't bother to read the scale at the bottom! But then again someone just skimming the review could be mislead.

Oh, someone might also like to refute the NV comments regarding Villagemark and its ordering of polys...

John.

[Kristof]

VillageMark and Poly order :

http://www.paraknowya.com/specials/faq/show.shtml?whyjnBvG

With the bandwidth saving functionalities, do you know how come "Villagemark" is still comparatively slow on the GF series compared to both KYRO and Radeon8500?
Tony: Villagemark happens to have been designed to be the "best case" poster child for Kyro's style of rendering. It is a high depth complexity scene, with very little geometric complexity, sorted back to front. Back to font sorting is the worst case method of sorting for all traditional graphics processors, as it requires every pixel to have a z-read, a z-write, a color-read and a color-write, for every layer of depth complexity. Even randomly sorted (ie. not sorted) applications will be faster. Since the first layer of depth complexity will always be the same, but subsequent layers will require a z-write and color-write only 50% of the time (ie. 1/2 as much bandwidth for each layer of depth complexity beyond 1 compared to the back-to-front model). Real applications don't sort back to front for the entire scene because of this, it's just slow on everthing. Back-to-front also means that occlusion culling in GeForce4 provides no benefit, since each subsequent pixel recieved is always going to be visible, so no rendering can be saved.
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.

VillageMark as indicated in the FAQ uses no sorting, actually spending any energy on sorting could potentially hurt KYRO (since it would require CPU resources) and would not be a good idea. VillageMark is rendered like any game: at random.

About stepping through the scenes poly by poly, this is definitely possible but its highly doubtfull that he has done this for every poly and for every frame. Point is nothing special is in the code. Also remember that Villagemark is very old, its been around for ages.

K-

[jb]

Actually I like the review and graphs are fine as I do read the graphs :)

Did I happen to miss some screen shots? Thoes would have been nice as well as some FSAA screen shots. I wanna see if the 4S mode hanles thoes Alpha textures any better...


BTW that graph backs up what Garry T. said back in the old 3DFX days where sometimes CPUs can provide faster TnL then hardware.

[Doomtrooper]

I agree with Thomas. some screen shots of MDK2 would be great to see Alpha Texture support with the hybrid FSAA.
I too have a problem with graph scaling although Revs are not near as bad some sites.

[Xmas]

VillageMark is rendered like any game: at random.
While I agree on the rest of your post, you really should know that this is simply not true. Games do sorting, at least to a certain extent.

[Kristof]

Games do indeed do sorting but not front to back. Games do sorting on textures and renderstates and even NVIDIA advises this over front to back since they very well know that flipping textures and renderstates all the time is much worse than the average overdraw of todays games (switiching vertex format, vertex buffer, index buffer and vertex shader also comes to mind).

Developers create a game engine and data(base) format and they use this to render, some use structures that allow some form of sorting but usually this is limited (as in not valid for all geometry). In most cases the front to back sort destroys the other state sorts. So basically you can select between several semi-bad cases : front to back with tons of state and texture changes, random with sorted states/textures, etc. Games
"might" aim to sort some "objects" front to back but this is not trivial to do unless you contructed your game to do so and this usually rules out some parts of your scene (landscape, special objects, special effects, etc).

Villagemark is designed to just draw this village, it does not use a complex scene format/database and as such does not execute any special sorting, except the normal common sense state/texture sorts.

Do we know of any game doing a serious effort to sort geometry other than by state/texture ?

K~

[Rodéric]

if villagemark use an Octree or Quadtree it does some sort of sorting too.

I don't plan to do full sorting for opaque surfaces, the card SHOULD work fast even with random order (and SHOULD take care of transparency too, but that's another story)

[ben6]

Hrm do we know this mystery Nvidia engineer???

[Mize]

Actually I like the review and graphs are fine as I do read the graphs :)


Huh? I read graphs too. Graphs are supposed to be graphical representations of data, not graphical sensationalism of data. You'll note that all other graphs are properly scaled and yet the one that demonstrates how important this feature is...well it's sensational!

As the author of several dozen technical papers I can assure you that presenting data like that at a research forum would be totally unacceptable. It looks like it came from the No TnL marketing department!

The only place you'll ever see that kind of graph is in marketing or economics (those "scientists" who didn't have to take calculus).

Mize
(IMHO of course)

[Humus]

Games do indeed do sorting but not front to back. Games do sorting on textures and renderstates and even NVIDIA advises this over front to back since they very well know that flipping textures and renderstates all the time is much worse than the average overdraw of todays games (switiching vertex format, vertex buffer, index buffer and vertex shader also comes to mind).


Well, Matt Craighead (driver writer at nVidia) didn't think so:
http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/005776.html
He clearly advices on putting primary effort on sorting by depth.


Do we know of any game doing a serious effort to sort geometry other than by state/texture ?

Well, just about every BSP based game should do this for static geometry. With a BSP tree it's very easy to draw strictly front-to-back, which is something I do in my GameEngine demo I posted here some weeks ago.

[Dave Baumann]

He clearly advices on putting primary effort on sorting by depth.


Well, now they would, as thats when their hardware gets the best performance probably!

[ram]

Aquanox does front to back sorting of objects.

Here is a translated piece out of an interview (http://www.3dconcept.ch/interviews/Massive/6.htm) with one of the 3d engine coders:


We do per-object sorting and draw front to back. This mustn't be very accurate to benefit of early z-checks and therefore can done very efficiant and fast. Just for semi-transparent surfaces it has to be more accurate and back to front. [...]

[Kristof]

I mentioned per object sorting. Static geometry is a possibility but do you render it before or after the other objects ? The whole thing is not as trivial as it might look at first sight.

Now I am no export on BSP trees but how accurate is it ? Isn't such a system still area/zone based or is each poly inserted seperatly into the tree and thus sortable ?

My info about NVIDIA advising not to bother too much with Z sorting comes from Richard Huddy, one of their main Dev Rel guys, during one of his otpimisation talks. And his advise is try to sort objects but make sure that all the other essential sorts come first (like texture, states, vertex shaders, vertex buffers/indices, batching). Believe me there are lots of things that can go wrong if you put ultimate effort in your sort. A "rough" per object sort is not a bad thing but anything more is most likely overkill, and only if your game engine database is designed for it from the ground up.

The link given to the opengl discussion evolves around Z sort or texture sort, as said above there is much more going on than just textures. He also stress that the CPU load might be a problem.

My point of view remains that its all semi-bad choices. The Zsort does buy you fillrate, no doubt, but the breaks in states and textures will hurt as well.

And sorting remains a complex problem, hence we still have Z-buffers...

K-

[NTD]

Didn't anybody find interesting that Tamasi and the engineer had completely opposite answers to the Z-occlusion culling question? Or did I just not understand it correctly...?

[pcchen]

I think they were talking about different things. Tamasi talked about the general Z occlusion detection built in the chip (the "improve fillrate" part), but the "engineering guy" talked about the occlusion query (which saves geometry).

[Humus]

I mentioned per object sorting. Static geometry is a possibility but do you render it before or after the other objects ? The whole thing is not as trivial as it might look at first sight.

Now I am no export on BSP trees but how accurate is it ? Isn't such a system still area/zone based or is each poly inserted seperatly into the tree and thus sortable ?


BSP trees are very accurate. You can do it the other way around too, drawing strictly back-to-front and do away with the Zbuffer all together, but that's of course both slower and will not work when you put models in there since you'd need the depth values from the static geometry.
A pure BSP based solution is not area/zone based, but you can combine BSP tree with such approaches too, in my engine I put every polygon into the same tree. It makes everything very easy, sort of like

* Draw opaque polys in BSP front to back
* Draw models
* Draw translucent polys in BSP back to front

You can do it even better by sorting in the models into the BSP to get even better, but I'm not sure how much gain this will give. I'm not doing that yet, I'm not even sorting models yet, will do that later on though. For models though it's overkill to do some polygon sorting.

[Humus]

I think they were talking about different things. Tamasi talked about the general Z occlusion detection built in the chip (the "improve fillrate" part), but the "engineering guy" talked about the occlusion query (which saves geometry).

You can certainly use occlusion query to save fillrate too. For instance in some kinds of portal engine you can use occlussion query on the portals to see if you need to draw stuff that's behind the portal.