Lug und Trug, die übernächste ;)

[Unregistered]

http://216.12.218.25/domain/www.beyond3d.com/reviews/visiontek/nvidia_gf4ti4600/index2.php

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 (Nvidia PR): 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.

verses

http://216.12.218.25/domain/www.beyond3d.com/forum/viewtopic.php?t=474

Kristof (PowerVR): 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.

[Exxtreme]

:bounce: :rofl: ;D :bounce:

Sooooo geil, echt. Das nenne ich Marketing.
LOL

Gruß
ALex

[Unregistered]

irgendqwie müssen die vielen unregisterd doch langsam verwirrend werden ;) ich glaub ich melde mich auch an

[Xmas]

Öh, hallo? Wieviele Monate ist das Thema schon alt???

Beide Aussagen sind eigentlich falsch. Weder sortiert der VillageMark die Polygone, noch ist das richtig: "VillageMark is rendered like any game: at random.". Game Engines machen sehr wohl eine Tiefensortierung.

[b23YY>]

kommt wohl auf das Spiel darauf an. Die Serious-Engine macht beispielsweise keine Sortierung. Das ist auch sinnvoller. Die CPU hat wohl besseres zu tun als Polygone zu sortieren.

[GloomY]

Auch wenn es schon alt ist, würde mich schon interessieren, ob oder in wie fern der VM sortiert...

Weisst du das genaueres, XMAS?

[mapel110]

ich meine gehört zu haben, das game-engines nichts vorsortieren. die haben in der tat besseres zu tun, als den overdraw zu killen.

[Quasar]

Na bei den heutigen CPU-Boliden....

Da werden doch zwei oder dreihundert MHz abfallen, um ein paar zehntausend dreiecke sortieren zu können.
Jedenfalls grafisch aufwendige Games sollten das tun.

Aber was das Sorting angeht....
GL_extreme (1024x32):

GF2TI: GF3Ti200: Kyro2:
OD 8, b2f: 56.74 74,26 228,81
OD 8, f2b: 89.99 263,99 228,88
OD 8, random: 78.85 163,63 228,87


VM v1.19 (1024x32):

GF2TI: GF3TI200: Kyro2:
37 55 132


Für mich sehen die Verhältnisse eher in Richtung b2f-sorting aus. Ansonsten dürfte die Kyro-2 nicht so einen Vorsprung von 140% im Villagemark haben, sondern eher in Richtung 40% Mehrleistung tendieren.

Zum Topic:
Da wird eine Aussage gegen eine andere gestellt.

[Xmas]

Originally posted by mapel110
ich meine gehört zu haben, das game-engines nichts vorsortieren. die haben in der tat besseres zu tun, als den overdraw zu killen.
Hast du vielleicht auch schon mal etwas von einem ominösen Ding namens BSP-Tree gehört? ;)

Und je nachdem wie Graka-lastig die Engine ist, wird die Engine in der Tat nichts besseres machen können als den Overdraw zu killen.

[HOT]

Originally posted by Quasar
Na bei den heutigen CPU-Boliden....

Da werden doch zwei oder dreihundert MHz abfallen, um ein paar zehntausend dreiecke sortieren zu können.
Jedenfalls grafisch aufwendige Games sollten das tun.

Aber was das Sorting angeht....
GL_extreme (1024x32):

GF2TI: GF3Ti200: Kyro2:
OD 8, b2f: 56.74 74,26 228,81
OD 8, f2b: 89.99 263,99 228,88
OD 8, random: 78.85 163,63 228,87


VM v1.19 (1024x32):

GF2TI: GF3TI200: Kyro2:
37 55 132


Für mich sehen die Verhältnisse eher in Richtung b2f-sorting aus. Ansonsten dürfte die Kyro-2 nicht so einen Vorsprung von 140% im Villagemark haben, sondern eher in Richtung 40% Mehrleistung tendieren.

Zum Topic:
Da wird eine Aussage gegen eine andere gestellt.


Dann frage ich mich doch echt, warum Radeon Karten einen so guten Villagemark Wert abliefern....
Da ist garnichts sortiert. Das erkennt man schon an dem Hintergrund, dass es überhaupt nicht nötig ist, eine Z-Vorsortierung einzubauen, am traditionelle Rednerer bei der Bench auszustechen.
Wie war das? Die Villagemark hat einen Overdraw von 5-8? und nutzt 3 Texturlagen pro Polygon? Geometrie spielt absolut keine Rolle? Das ist schon allein worst Case für traditionelle Renderer!

[ow]

Originally posted by HOT



Dann frage ich mich doch echt, warum Radeon Karten einen so guten Villagemark Wert abliefern....
Da ist garnichts sortiert. Das erkennt man schon an dem Hintergrund, dass es überhaupt nicht nötig ist, eine Z-Vorsortierung einzubauen, am traditionelle Rednerer bei der Bench auszustechen.
Wie war das? Die Villagemark hat einen Overdraw von 5-8? und nutzt 3 Texturlagen pro Polygon? Geometrie spielt absolut keine Rolle? Das ist schon allein worst Case für traditionelle Renderer!



Wie wuerdest du denn dann eine Steigerung von "worst case" bezeichnen???

Also unsortiert ist "second worst case", b2f ist "worst case" und f2b ist "best case".
Fuer traditionelle Renderer natuerlich.

Der Overdraw des VM liegt teilweise ueber 10 AFAIK.
Ob sortiert wird weiss ich nicht, aber der Verdacht des b2f sorting liegt nahe.

[Legolas]

Vergleichswerte einer Radeon wäre interessant.. bei b2f-Sortierung müsste sie ja auch entsprechend wegbrechen...

[ow]

Das wird sie sicher tun.
Allerdings duerfte ATis HyperZ effizienter sein als NVs Methode.

[aths]

Die Radeon kann pro Pipeline 16 Pixel zurückweisen, der NV2x nur 4 Pixel. nVidia behauptete irgendwo, dass die Technik bei ATI primitiver sei, was ich allerdings für Sülze halte. Angeblich sei die ATI-Lösung speziell für den VM gut, ansonsten aber natürlich weniger. (Übliches Gerede, rrrr) (Ich glaub das war im GF4-Test auf beyond3d zu lesen.)

Interessant wird es beim AA. Nützt early z occlusion bei 4x überhaupt noch was?

[GloomY]

Wie groß ist der Performanceunterschied zwischen einer GF2 Ultra und einer GF3 (normal) beim VM?

Laut Nv dürfte der Performanceunterschied ja nur durch Z-Buffer Compression und Crossbar zustandekommen, wenn man mal vom höheren Chiptakt der Ultra absieht.

Und wenn ich mich richtig erinnere, war der Unterschied nämlich doch erheblich, so daß ich mir schlecht vorstellen kann, daß das ohne Z-occlusion culling zustande kommt...

[Quasar]

In 16Bit ist der Unterschied nicht sehr groß...

Unter 32Bit hingegen schon.
D3D-Villagemark v1.19, 1024x768

GF2TI GF3TI200 GF4MX440 KyroII
16Bit 52 46 53 134
32Bit 37 55 45 132


So, ich bin sicher, das freut die Kyro-Indiander, oder?

GF2TI und GF3Ti200 sind relativ analog der GF3/GF2u, imho. Die Relationen werden sich jedenfalls nicht groß verschieben.

[Iceman346]

Originally posted by Quasar
In 16Bit ist der Unterschied nicht sehr groß...

Unter 32Bit hingegen schon.
D3D-Villagemark v1.19, 1024x768

GF2TI GF3TI200 GF4MX440 KyroII
16Bit 52 46 53 134
32Bit 37 55 45 132


So, ich bin sicher, das freut die Kyro-Indiander, oder?

GF2TI und GF3Ti200 sind relativ analog der GF3/GF2u, imho. Die Relationen werden sich jedenfalls nicht groß verschieben.

irgenwie seltsam daß die GF3 Ti 200 unter 32bit schnelle wird im gegensatz zu den anderen Karten. Kann ich irgendwie nicht ganz glauben ;)

[Quasar]

Arg....das hatten wir gestern schon mal.

Das liegt daran, daß in D3D in 16Bit Teile der LMA, insbesondere das HSR nicht genutzt werden.
Glaub's ruhig, es stimmt so ;)

[GloomY]

Originally posted by Quasar
In 16Bit ist der Unterschied nicht sehr groß...

Unter 32Bit hingegen schon.
D3D-Villagemark v1.19, 1024x768

GF2TI GF3TI200 GF4MX440 KyroII
16Bit 52 46 53 134
32Bit 37 55 45 132
Danke für diese Infos, Quasar :)
Originally posted by Quasar
So, ich bin sicher, das freut die Kyro-Indiander, oder?Darum geht es nicht. Ich möchte hier näher herausfinden, welche der beiden Aussagen mehr zu glauben ist.

Ich fasse das ganze also mal selbst in einer kleinen Tabelle zusammen:
GF2Ti GF3Ti200 GF4MX400

Frames (32Bit) 37 55(+48%) 45(+22%)

Fillrate (GigaPixel) 1000 800(-20%) 400(-60%)
Fillrate (GigaTexel) 2000 1600(-20%) 800(-60%)

Speicherbandbreite (GB/Sek.) 6,0 5,2(-13,3%) 6,0(+-0%)

Wie Quasar richtig erwähnte, sind die rohen Leistungsdaten (Fillrate und Speicherbandbreite) von Gf2Ti und GF3T200 sehr ähnlich (die der Ti200 etwas niedriger).

Trotzdem ist die Performance der GF3ti200 aber fast 50% höher als bei der GF2Ti. Die LMA scheint also doch sehr effizient zu arbeiten.
Aufgrund dieser Daten kann ich aber schlecht glauben, daß +48% Frames allein durch Crossbar und Z-Buffer Compression zusammenkommt...
Ich weiß zwar, daß gerade der Crossbar relativ effizient arbeitet, aber imho muß für so eine Leistungssteigerung auch das Z-Occulison Culling mitwirken.

Andere Meinungen?

[GloomY]

*schieb*

Interessiert das niemanden?

[Quasar]

In 32Bit wirken ja auch ALLE Teile des LMA mit, sprich CBMC, Z-OccC, Z-Comp, etc.

Nur in 16Bit eben nicht, ich glaube, da ist was falsch rübergekommen.

[GloomY]

Hmm, die Farbtiefe ist doch egal. Es ging doch darum, ob Z-OccC beim VM durch besonders "geschicktes" Sortieren (b2f) nicht wirken kann oder eben doch...

Imho handelt es sich nicht um b2f-Sorting, wie oben bereits erläutert (leicht geringere Rohpower, aber +50% Frames).

P.S.: Wen interessiert denn noch 16 Bit ?

[Quasar]

Sorry, da hab ich wohl etwas den Faden verloren. Ich dachte du bezögst dich noch darauf, daß der GF3 in 16Bit langsamer im VM ist als in 32Bit. 16Bit interessiert wirklich keinen mehr, Sorry!

[Quasar]

DOH. *AnnKoppSchlach*

Weiste, was wir beide übersehen haben?

VM nutzt 3 Texturen....

[GloomY]

Originally posted by Quasar
Sorry, da hab ich wohl etwas den Faden verloren. Ich dachte du bezögst dich noch darauf, daß der GF3 in 16Bit langsamer im VM ist als in 32Bit. 16Bit interessiert wirklich keinen mehr, Sorry! No Problem =)Originally posted by Quasar
DOH. *AnnKoppSchlach*

Weiste, was wir beide übersehen haben?

VM nutzt 3 Texturen.... Axo, shit...

GF2 braucht Multipass, während die GF3 alles in einem Pass erledigen kann. :(
Kann man das Loopback der GF3 nicht irgendwie per Registry ausschalten, um vergleichen zu können?

[Quasar]

Nicht, daß ich wüßte....mal gucken, was die Registry so hergibt.