ATI vs NVidia: Unsichtbare Texturen klauen FPS

[Sonicat]

Hallo,

für ein Spiel habe ich per D3D9-Hook die Bäume & Büsche in einem Spiel entfernt (Strides & NumVertices). Die ATI 800 Pro Graka hat konstante Frameraten, egal ob das Grünzeug im Spiel angezeigt wird oder nicht.
Die Nvidia 7900 (AGP Edition von Gainward) bekommt einen mächtigen FPS Boost sobald das Grünzeug ausgeblendet wird. Teilweise bei Maps in einem Wald verdoppelt sich die FPS gegenüber der ATI Karte von 30 auf ~60fps.

Mich würde mal interessieren warum dies so ist ?
Anscheinend "erkennt" die Nvidia GPU wenn ein Objekt gar nicht angezeigt wird und stoppt dann die Berechnungen für dieses Objekt.

André

[Gast]

Stichwort TBDR :D

[Cyphermaster]

Das ist Blödsinn. TBDR = Tile-Based, Deferred Rendering ("Kachel-basierendes, Verzögertes Rendern"). Die nV-Karten sind NICHT Kachel-basiert, bei denen laufen solche internen Routinen unter "HSR" = Hidden Surface Removal. Die ATI-Karte kann das aber genauso, nur benutzt sie eine leicht andere Methode.

[robbitop@work]

Das ist Blödsinn. TBDR = Tile-Based, Deferred Rendering ("Kachel-basierendes, Verzögertes Rendern"). Die nV-Karten sind NICHT Kachel-basiert, bei denen laufen solche internen Routinen unter "HSR" = Hidden Surface Removal. Die ATI-Karte kann das aber genauso, nur benutzt sie eine leicht andere Methode.

HSR ist ein Oberbegriff. Das kann schon bei der Engine durch Portale passieren, das kann aber auch in HW geschehen (PVR tut das, NV tut das seit dem NV20 und ATI tut das eingeschränkt schon seit R100).
Du meinst wahrscheinlich early-Z und Occlusion Culling.

Falls Interesse am Thema besteht, gibts einen schönen Artikel dazu: http://www.3dcenter.org/artikel/2002/11-14_a.php

[Ailuros]

Wenn die engine nicht (oder nicht gut) nicht-sichtbare Daten verwerfen kann, rettet ein TBDR auch nicht den Tag.

[robbitop@work]

Wenn die engine nicht (oder nicht gut) nicht-sichtbare Daten verwerfen kann, rettet ein TBDR auch nicht den Tag.
Puuuha doppelte Negierung... X-D
Wäre auf jeden Fall viel zu sortieren für die entsprechenden Einheiten. Jedoch wäre ein IMR damit ebenso gequält, da der die nicht sichtbaren Daten sogar noch im ungünstigen Fall rendern müsste.

Ansonsten haben TBDR abseits ihres hervoragenden HSRs noch einen enormen Bandbreitenvorteil, wie du weißt. Kein Z-Traffic, kein Blending Traffic und kein ständiges Lesen und Schreiben des FB während des gleichen Frames (dank Color und Z Caches, was ja nur bei einem TBDR in dieser Form funktioniert).

Abseits der Risiken einen TBDR zu konstruieren müssen die zusätzlichen Kosten für Sortierung der Geometrie und Caching (auch insbesondere des deutlich schwierigeren texture cachings) enorm hoch sein, so dass bei gleicher Transistorzahl anscheinend weniger Fläche für den Pixelteil zur Verfügung stünde. Oder anders herum: ein TBDR mit gleicher Ausführungseinheitenanzahl wie ein IMR wäre transistorintensiver, right?

[StefanV]

Wenn die engine nicht (oder nicht gut) nicht-sichtbare Daten verwerfen kann, rettet ein TBDR auch nicht den Tag.
Du meinst wie es bei Morrowind und Oblivion der Fall ist? ;)

[Wishnu]

Du meinst wie es bei Morrowind und Oblivion der Fall ist? ;)

Hm, war das bei Oblivion immer noch so? Ist mir diesmal gar nicht aufgefallen.
Wirklich schlimm war es auch bei DAoC (gleiche Engine... nur ältere Version). Da taugte das allerdings prima als Feindradar. Sprich wenn es plötzlich wie wild ruckelte, aber nix zu sehen war, dann wußte man, dass der Feind hinter dem nächsten Hügel lauerte. :)

[Gast]

Ja bei Oblivion ist es immer noch der gleiche Scheiß.

[Gast]

Und bei Prey und bei Q4...wo eigentlich nicht?

[Ailuros]

Puuuha doppelte Negierung... X-D
Wäre auf jeden Fall viel zu sortieren für die entsprechenden Einheiten. Jedoch wäre ein IMR damit ebenso gequält, da der die nicht sichtbaren Daten sogar noch im ungünstigen Fall rendern müsste.

KYRO verhielt sich nach meiner Erinnerung genauso schlecht wie IMRs in solchen Ausnahme-Faellen.

Ansonsten haben TBDR abseits ihres hervoragenden HSRs noch einen enormen Bandbreitenvorteil, wie du weißt. Kein Z-Traffic, kein Blending Traffic und kein ständiges Lesen und Schreiben des FB während des gleichen Frames (dank Color und Z Caches, was ja nur bei einem TBDR in dieser Form funktioniert).

Abseits der Risiken einen TBDR zu konstruieren müssen die zusätzlichen Kosten für Sortierung der Geometrie und Caching (auch insbesondere des deutlich schwierigeren texture cachings) enorm hoch sein, so dass bei gleicher Transistorzahl anscheinend weniger Fläche für den Pixelteil zur Verfügung stünde. Oder anders herum: ein TBDR mit gleicher Ausführungseinheitenanzahl wie ein IMR wäre transistorintensiver, right?


Im floating point Zeitalter wuerde ich an Deiner Stelle eine solche Frage erst gar nicht stellen; schon gar nicht wenn es sich um USCs handelt.

[Ailuros]

Du meinst wie es bei Morrowind und Oblivion der Fall ist? ;)

Nicht alle Faelle sind gleich aber hier mal ein quote aus der Vergangenheit:

This is most likely not a fillrate limited situation. The HSR of the Kyro may help a little, but not much. The problem lies in the method the Quake3 engine uses for hidden surface determination/removal. Usually, the engine itself is the best place to perform HSR, because the engine knows (should know) what it is about to draw. HSR in the videocard is HSR at the lowest level, performed if everything else has failed. That doesn't mean that it's useless but the videocard is simply "the last line of defense". So where is the problem in this particular scene?

To understand this better, one should know a little bit about HSR algorithms and how the Q3 engines makes use of them. The Q3 engine uses basically a combination of BSP (binary space partitioning) and PVS (potentially (or possible, whatever you prefer) visible set). The BSP is a tree structure that allows the engine to determine the polygons in the view frustum in order (back to front or front to back, whatever you want).

This sorting is done 'automatically' by parsing the BSP tree regarding the current position and direction of the camera (the player). The BSP does NOT store information about what is visible from a specific position and what is not (as long it lies into the view frustum). This means that if you are standing in front of a wall with zillions of polygons behind it (which can't be seen), the BSP doesn't give you any information that only the wall has to be drawn.

In this case, the whole bunch of polygons will be processed and thrown to the videocard. In the best case, all but the wall polygons are rejected by the ZBuffer. In the worst case, all of these polygons are drawn over another and finally they are all overdrawn by the wall. This cost some fillrate of course, but that shouldn't be that much of a problem as one may think.

A bigger problem is, that all these polygons need to be transformed, clipped, lit and projected...for nothing (because they are not visible). To reduce this overhead, the Q3 engine uses a PVS. This PVS contains information about which other parts (represented for example by the leafs of the BSP tree, but that goes into too much detail...) are potentially visible from the current position.

The problem is, that this information is precalculated and that it doesn't take the viewing direction into account (it wouldn't be possible to do this at a precalculation stage). Imagine yourself standing in your kitchen. You may see the living room and your bathroom from there, but you dont, because you are facing the kitchen wall with the living room and the bath room behind you. You ask your PVS and it says: "fine, you are in the kitchen, you may see the bathroom and the livingroom". Then you ask your BSP tree. Because you are facing away from both rooms, the BSP says: "No living room and no bathroom visible, because both rooms are behind you (and therefor not in the view frustum)".

This is the situation in your example when you are standing looking at the wall of the cave with the ladder behind you. Now, turn aorund in your kitchen. You are now facing the other wall, still unable to see the living room or the bathroom. The PVS again tells you "Living room, Bathroom". The BSP can't do any better if both rooms are into the view frustum (that means that they could be seen, if you would remove the kitchen wall). In your example, this is the case when facing the ladder. PVS and BSP can't determine that the whole cave complex is not visible in this situation. One question remains: why can't the PVS give you this information? Well, it can't do this, because it doesn't know anything about your specific position and the direction your are facing except that it does know, in which part of the level you are. This part seems to be the same in your example regardless if you are standing on top of the ladder or at the bottom.

To come to an end: In this particular situation, neither the PVS nor the BSP can determine that the rest of the cave is not visible. So the CPU has to process a lot of useless stuff. And finally, that may be a reason why John Carmack (author of the quake engines) is heading for portal brushes instead in the Doom3 engine. This way, the PVS is generated at runtime and takes the direction into account (a very brief description, but anyway...).

[loewe]

Wenn die engine nicht (oder nicht gut) nicht-sichtbare Daten verwerfen kann, rettet ein TBDR auch nicht den Tag.

Wenn da einer noch was leisten könnte, dann ein TBDR, siehe Ultima 9. Ist zwar schon sehr lange her, aber es gibt ja auch keine modernen TBDR. :)


Wäre auf jeden Fall viel zu sortieren für die entsprechenden Einheiten. Jedoch wäre ein IMR damit ebenso gequält, da der die nicht sichtbaren Daten sogar noch im ungünstigen Fall rendern müsste.

TBDRs sortieren gar nichts! Nur der Dreamcast Chip war fähig die durchsichtigen Pixel in Hardware selbst zu sortieren, für PC ist das entfernt worden.

Abseits der Risiken einen TBDR zu konstruieren müssen die zusätzlichen Kosten für Sortierung der Geometrie und Caching (auch insbesondere des deutlich schwierigeren texture cachings) enorm hoch sein, so dass bei gleicher Transistorzahl anscheinend weniger Fläche für den Pixelteil zur Verfügung stünde. Oder anders herum: ein TBDR mit gleicher Ausführungseinheitenanzahl wie ein IMR wäre transistorintensiver, right?


Wie wäre es mit Virtual texturing, das hilft sieh dir die aktuelle PowerVR Hardware an. ;)
Das Problem besteht darin, alle Teile jeder Zeit nahezu mit 100% laufen zu lassen. PowerVR hat das gelöst, ich erinnere an METAGENCE.

Gerade mit USCs ist ein TBDR von Vorteil. Auch die Verteilung der Arbeit auf die Einheiten will erst einmal (nach Möglichkeit taktgenau) beherrscht werden, PowerVR kann es, fast immer. :)

Nein ein TBDR (von PowerVR) wäre nicht transitorintensiver, aber mehr als ein Drittel kann er sicher auch nicht einsparen, ist aber viel effizienter.

[RavenTS]

Und woran könnte das Problem nun abseits all der theoretischen Diskussion liegen? Fehler in den Treibern, Hardwarebesonderheiten,.?!

[Gast]

Und bei Prey und bei Q4...wo eigentlich nicht?

Unsinn. Q4 und Prey benützen Portale und cullen sehr viel weg. (r_showtris 3 in der Konsole).

[d2kx]

Bei BF2 habe ich mal gehört, dass auch unterirdisches Wasser immer mitgerendert wurde...

[Gast]

Unsinn. Q4 und Prey benützen Portale und cullen sehr viel weg. (r_showtris 3 in der Konsole).

So dann starte mal das Demo und schaue im Klo an die äußere und innere Wand, beidesmal selbes Bild nur halbe fps. Getestet mit Ati 95p

[KayCee]

@d2kx:
Kannste mal die Quelle angeben bzw. heraussuchen!? Das würde mich auch interessieren...

@Ailuros:
Was sind USC's!?

[loewe]

@Ailuros:
Was sind USC's!?
unified shader core

[MadManniMan]

Jetzt mal zurück zur Sache: warum Framedrop bei ATi und bei nV nich?

[Spearhead]

Jetzt mal zurück zur Sache: warum Framedrop bei ATi und bei nV nich?

ähm, also wenn ich den Threadstarter nicht falsch verstanden habe war es gerade umgekehrt ;)
ATI = konstante FPS
nVidia = FPS-Anstieg mit der Änderung

Edit: Obwohl.... Bei näherer Überlegung könnten wir beide das gleiche meinen X-D Nur in anderer Weise *g*

[robbitop@work]

TBDRs sortieren gar nichts! Nur der Dreamcast Chip war fähig die durchsichtigen Pixel in Hardware selbst zu sortieren, für PC ist das entfernt worden.
Sie sortieren natürlich die Geometrie. Sonst wäre ein Color-Tile-Buffer am Ende der Pipeline nutzlos.


Wie wäre es mit Virtual texturing, das hilft sieh dir die aktuelle PowerVR Hardware an. ;)
Virtual Texturing hilft gegen Texturwechsel stalls? Wie soll das funktionieren?


Das Problem besteht darin, alle Teile jeder Zeit nahezu mit 100% laufen zu lassen. PowerVR hat das gelöst, ich erinnere an METAGENCE. Gerade mit USCs ist ein TBDR von Vorteil. Auch die Verteilung der Arbeit auf die Einheiten will erst einmal (nach Möglichkeit taktgenau) beherrscht werden, PowerVR kann es, fast immer. :)
Wir werden mit G80/R600 sehen, wie gut andere das hinbekommen.
ATI hantiert mit USCs immerhin seit Jahren (R400 wurde vor 5-6 Jahren angefangen). Nvidia ähnlich lange (NV50 geht auf das Jahr 2001/02 zurück).


Nein ein TBDR (von PowerVR) wäre nicht transitorintensiver, aber mehr als ein Drittel kann er sicher auch nicht einsparen, ist aber viel effizienter.
Ich meine nicht bei gleicher Leistung sondern bei gleicher Anzahl an Recheneinheiten und Bussen (also Anzahl ALUs/TMUs/Caches/gleichgroßes Speicherinterface ect). Beim TBDR kommt zur Rendering Pipeline ja noch die HSR Engine (oder wie auch immer das Teil heißt, welches den Z Pass in Hardware erledigt).

[robbitop@work]

Jetzt mal zurück zur Sache: warum Framedrop bei ATi und bei nV nich?
Das könnte auch auf einen Bug in der Engine oder sonstwo zurückzuführen sein.
Den einzigen Vorteil, den ATI in ihrer Methode hat, ist, dass große Flächen eines nicht sichtbaren Bereiches auf einmal verworfen werden können.
(sobald aber auch nur ein Pixel in diesen Bereich fällt, der sichtbar ist, verliert die Radeon ein paar Takte und geht auf eine nächstkleinere Tilesize zum testen und verwerfen). IMO sollte das Verwerfen aber nicht sonderlich bremsen, da das pro Pixel in einem einzigen Takt geschieht und pro Pixelpipeline bei NV ein Quad verworfen werden kann. Bei 16 Pipelines wären das 64 verworfene Pixel pro Takt. Bei 400MHz und 1280x1024 wären das knapp 20.000 komplette Frames (komplett Overdraw 1x), die in einem Takt verworfen werden könnten. Das sollte nirgends limitieren.

[Ailuros]

Sie sortieren natürlich die Geometrie. Sonst wäre ein Color-Tile-Buffer am Ende der Pipeline nutzlos.

Nein und abermals nein.


Ich meine nicht bei gleicher Leistung sondern bei gleicher Anzahl an Recheneinheiten und Bussen (also Anzahl ALUs/TMUs/Caches/gleichgroßes Speicherinterface ect). Beim TBDR kommt zur Rendering Pipeline ja noch die HSR Engine (oder wie auch immer das Teil heißt, welches den Z Pass in Hardware erledigt).

KYRO hatte 16 Z/stencil Einheiten pro Pipeline. Ich sehe weder einen Grund warum man auch heute mehr brauchen wuerde (wobei "pipeline" auch so eine Sache fuer sich ist bei USCs), noch sehe ich einen besonderen Grund warum das Zeug (was heute uebrigens macro tiling engine heisst) besonders grossen Platz einnehmen sollte.

Erstens braucht man kein gleichgrosses Speicherinterface weil eben der Bandbreiten-bedarf generell niedriger ist und zweitens gibt es genug theoretische Stellen wo ein IMR viel mehr Transistoren fuer caches und onboard Speicher verplempern koennte um die sich gegen die Vorteile eines TBDR messen zu koennen. So aus der Luft kann man das nicht so einfach greifen ausser man haette tatsaechlich Einzelheiten ueber chip-internas die normalerweise nicht bekannt sind.

Wir werden mit G80/R600 sehen, wie gut andere das hinbekommen.
ATI hantiert mit USCs immerhin seit Jahren (R400 wurde vor 5-6 Jahren angefangen). Nvidia ähnlich lange (NV50 geht auf das Jahr 2001/02 zurück).

Da sich IMG momentan nur mit "Kleinkram" beschaeftigt, muessen erstmal ATI/NVIDIA es schaffen etwas besseres und zur gleichen Zeit kleineres als SGX auf den Markt zu schieben, wozu es sowieso schon zu spaet ist. Und das nur weil es eher unmoeglich ist dass IMG je den high end Markt beruehrt. Jetzt kommt aber die brennende Frage, warum verplempert im kleinsten Format ein TBDR nicht mehr Transistoren bzw. Strom als konkurrierende IMRs? Das laecherlichste ist dass selbst wenn der Stromverbrauch auf gleichem Nivaeu momentan liegt, sind die MBX/SGX in Funktionalitaeten, Features und Effizienz den direkten Konkurrenten so ueberlegen dass es nicht mal der Rede wert ist.

[robbitop@work]

Nein und abermals nein.
Es ist kein Sortieren per se. Es ist ein Sammeln und entfernen von dieser vor der Pipeline. Wichtig ist jedenfalls, dass die Geometrie vor dem Rendern bekannt ist und das meinte ich mit sortieren. Mea culpa.


KYRO hatte 16 Z/stencil Einheiten pro Pipeline. Ich sehe weder einen Grund warum man auch heute mehr brauchen wuerde (wobei "pipeline" auch so eine Sache fuer sich ist bei USCs), noch sehe ich einen besonderen Grund warum das Zeug (was heute uebrigens macro tiling engine heisst) besonders grossen Platz einnehmen sollte.
Diese Einheiten inklusive Cache würden schon etwas kosten.


Erstens braucht man kein gleichgrosses Speicherinterface weil eben der Bandbreiten-bedarf generell niedriger ist und zweitens gibt es genug theoretische Stellen wo ein IMR viel mehr Transistoren fuer caches und onboard Speicher verplempern koennte um die sich gegen die Vorteile eines TBDR messen zu koennen.
Ein TBDR braucht deutlich mehr Caches. Der Tile-Z und der Tile-Color Cache sind allein schon TBDR exklusiv bisher. Hinzu kommen größere Texturcaches wegen der Texturwechsel beim Rendern.



Da sich IMG momentan nur mit "Kleinkram" beschaeftigt, muessen erstmal ATI/NVIDIA es schaffen etwas besseres und zur gleichen Zeit kleineres als SGX auf den Markt zu schieben, wozu es sowieso schon zu spaet ist. Und das nur weil es eher unmoeglich ist dass IMG je den high end Markt beruehrt. Jetzt kommt aber die brennende Frage, warum verplempert im kleinsten Format ein TBDR nicht mehr Transistoren bzw. Strom als konkurrierende IMRs? Das laecherlichste ist dass selbst wenn der Stromverbrauch auf gleichem Nivaeu momentan liegt, sind die MBX/SGX in Funktionalitaeten, Features und Effizienz den direkten Konkurrenten so ueberlegen dass es nicht mal der Rede wert ist.
Mir geht es um die Aulastung der Recheneinheiten. Auf welcher Plattform das ist, ist doch ersteinmal egal. Man müßte schauen, wie gut das Load Balancing auf G80/R600 ist. Diesen relativen Wert könnte man durchaus mit dem Wert der Serie5 (in welcher Form auch immer) vergleichen.

Was die PDA GPUs angeht: NV/ATI haben dort sehr wenig R&D reingesteckt. Aber mal abseits davon ist ein TBDR bei gleicher Transistoranzahl IMO immer besser. Er kommt besser mit engen Grenzen zurecht, da er effizienter ist (das möchte ich nicht bestreiten!).
Aber was das reine Loadbalancing angeht, traue ich auch NV/ATI ein gutes Verfahren zu. Zumindest so gut, dass sich ein USC lohnt. Wie gut, das weiß noch keiner. Ergo: abwarten ;)

[Ailuros]

Es ist kein Sortieren per se. Es ist ein Sammeln und entfernen von dieser vor der Pipeline. Wichtig ist jedenfalls, dass die Geometrie vor dem Rendern bekannt ist und das meinte ich mit sortieren. Mea culpa.

Zuerst wird aber Geometrie verworfen bevor es erstmal zur Sammlung kommt und weder/noch hat irgendwas mit Sortierung zu tun. Zu was denn ueberhaupt sortieren?

Diese Einheiten inklusive Cache würden schon etwas kosten.

Wieviel genau? Oder siehst Du irgendein Monstrum im KYRO im Vergleich zur GF2 MX (die zugegeben auch eine T&L Einheit hat, aber auch andere bescheidenere Specs).

Ein TBDR braucht deutlich mehr Caches. Der Tile-Z und der Tile-Color Cache sind allein schon TBDR exklusiv bisher. Hinzu kommen größere Texturcaches wegen der Texturwechsel beim Rendern.

Sagt wer genau? PS und VS sind auf TBDRs als weiteres Beispiel total entkoppelt, was bei theoretischen non-USCs auch gleich mal wieder weniger "intermediate" caches heissen kann.


Mir geht es um die Aulastung der Recheneinheiten. Auf welcher Plattform das ist, ist doch ersteinmal egal. Man müßte schauen, wie gut das Load Balancing auf G80/R600 ist. Diesen relativen Wert könnte man durchaus mit dem Wert der Serie5 (in welcher Form auch immer) vergleichen.

Serie5 PC waere nach richtiger Finalisierung eher NV4x Vergleichsmaterial gewesen. Wie JohnH schon auf B3D sagte versucht mal auf einem IMR in 1024*768 64xFSAA + 64bpp HDR zu quetschen. Noch laecherlicher ist dass das Ding nur schaetzungsweise 1/3 der NV40 Bandbreite gehabt haette und weniger insgesamt Chipkomplexitaet bzw. Anzahl der Einheiten (obwohl auf S5 die Einheiten wohl ziemlich "dick" waren).

Was die PDA GPUs angeht: NV/ATI haben dort sehr wenig R&D reingesteckt. Aber mal abseits davon ist ein TBDR bei gleicher Transistoranzahl IMO immer besser. Er kommt besser mit engen Grenzen zurecht, da er effizienter ist (das möchte ich nicht bestreiten!).
Aber was das reine Loadbalancing angeht, traue ich auch NV/ATI ein gutes Verfahren zu. Zumindest so gut, dass sich ein USC lohnt. Wie gut, das weiß noch keiner. Ergo: abwarten ;)

Abwarten auf was? Der Zug von OGL_ES2x (nicht 2.0!) scheint mir schon abgefahren zu sein. Das mit den Resourcen Aufwand fuer den PDA/mobile Markt stimmt zwar schon aber es aendert sich trotzdem nichts dran dass es beide verdammt schwer haben werden dem SGX nahe zu kommen.

[robbitop@work]

Zuerst wird aber Geometrie verworfen bevor es erstmal zur Sammlung kommt und weder/noch hat irgendwas mit Sortierung zu tun. Zu was denn ueberhaupt sortieren?
Natürlich wird nicht sichtbare Geometrie verworfen. Im Prinzip ein Z-Firstpass in Hardware.


Wieviel genau? Oder siehst Du irgendein Monstrum im KYRO im Vergleich zur GF2 MX (die zugegeben auch eine T&L Einheit hat, aber auch andere bescheidenere Specs).
Schwer zu sagen. Kyro2 hatte nur 2 TMUs und kein TnL, wie du schon sagtest. Die Kyro2 Combiner sind allerdings etwas flexibler als die der NV11 (sie beherrschen EMBM).


Sagt wer genau?
Das ist prinzipbedingt.
Ein TBDR braucht einen Onchip Z-Cache und er besitzt einen OnChip Colorcache. Auch für die hässlichen Texturwechsel braucht man einen größeren Texturcache um nicht hässlichen Stalls beim Neu-einlesen der Texturen zu verfallen.


PS und VS sind auf TBDRs als weiteres Beispiel total entkoppelt, was bei theoretischen non-USCs auch gleich mal wieder weniger "intermediate" caches heissen kann.
Könntest du diesen Punkt ein wenig erläutern?

R580 besitzt auch entkoppelte Pixelshaderalus. VS wüßte ich nicht, dass die gekoppelt wären.





Serie5 PC waere nach richtiger Finalisierung eher NV4x Vergleichsmaterial gewesen. Wie JohnH schon auf B3D sagte versucht mal auf einem IMR in 1024*768 64xFSAA + 64bpp HDR zu quetschen. Noch laecherlicher ist dass das Ding nur schaetzungsweise 1/3 der NV40 Bandbreite gehabt haette und weniger insgesamt Chipkomplexitaet bzw. Anzahl der Einheiten (obwohl auf S5 die Einheiten wohl ziemlich "dick" waren).
Nochmal: ich bezweifle die Vorteile von TBDRs und dessen Effizienz nicht. Ich bin sogar ein Verfechter dieser. Nur fiel es mir stark auf, dass man bei TBDRs versucht durch Effizienz einen Rohleistungsnachteil auszugleichen. Mich würde aber viel mehr interessieren, was ein TBDR mit gleicher Rohleistung wie ein Top-IMR ausrichten könnten. Vermutlich deutlich mehr. Nur ist für mich die Frage, ob es auch mehr Transistoren kosten würde.



Abwarten auf was? Der Zug von OGL_ES2x (nicht 2.0!) scheint mir schon abgefahren zu sein. Das mit den Resourcen Aufwand fuer den PDA/mobile Markt stimmt zwar schon aber es aendert sich trotzdem nichts dran dass es beide verdammt schwer haben werden dem SGX nahe zu kommen.
Abwarten auf G80/R600 und sich dessen Einheitenauslastung anschauen.
Im PDA Markt kann wohl derzeit niemand PVR das Wasser reichen, aber darum ging es mir auch gar nicht. ;)

[Gast]

VS wüßte ich nicht, dass die gekoppelt wären.

Was soll man da auch koppeln? Es gibt keine VS-TMUs auf R5xx ;)

[ShadowXX]

R580 besitzt auch entkoppelte Pixelshaderalus. VS wüßte ich nicht, dass die gekoppelt wären.

Bist du dir da wirklich so sicher (und wenn, in welchen Grad)? Ich würde die ATI-Marketingpapiere/aussagen nicht zu hoch bewerten.

Demi deutet mal an, das das r580-Design wesentlich "traditioneller" ist, als uns ATI gerne weismachen würde.

[robbitop@work]

Bist du dir da wirklich so sicher (und wenn, in welchen Grad)? Ich würde die ATI-Marketingpapiere/aussagen nicht zu hoch bewerten.

Demi deutet mal an, das das r580-Design wesentlich "traditioneller" ist, als uns ATI gerne weismachen würde.
Das deutete er in der Tat mal an. Die Radeons seit dem R300 arbeiten jedoch AFAIK nicht nach dem Phasenprinzip. In welcher Intensität nun eine Entkopplung vorhanden ist, weiß ich natürlich nicht.

[Gast]

Die Radeons seit dem R300 arbeiten jedoch AFAIK nicht nach dem Phasenprinzip.

Aber sicher tuen sie das (R3xx und R4xx auf jeden Fall). Daraus resultiert ja auch das dependend texture read limit von den Teilen.

[ShadowXX]

Aber sicher tuen sie das (R3xx und R4xx auf jeden Fall). Daraus resultiert ja auch das dependend texture read limit von den Teilen.
Juppss....das war ja gerade einer der großen unterschiede zu den nVs.

[robbitop@work]

Aber sicher tuen sie das (R3xx und R4xx auf jeden Fall). Daraus resultiert ja auch das dependend texture read limit von den Teilen.
Es war aber (was ich bisher gelesen habe) nicht so arg gekoppelt, wie das NV40 Phasenkonzept.

Könntest du auf die dependend texture Problematik bitte etwas genauer eingehen?

OT: warum posten eigentlich ständig Forenmitglieder anonym?

[Gast]

Es war aber (was ich bisher gelesen habe) nicht so arg gekoppelt, wie das NV40 Phasenkonzept.

NV40 hat kein Phasenkonzept.

Könntest du auf die dependend texture Problematik bitte etwas genauer eingehen?

R300 und R400 können nur eine bestimmte Anzahl an Phasen (ich glaube 4 oder 8), d.h. es können nur so oft Texturen in Abhängigkeit von Berechnungen adressiert werden. Im Prinzip gleich wie bei R200, nur dass es da sogar explizit 2 Programmteile waren.

OT: warum posten eigentlich ständig Forenmitglieder anonym?

Weils mich ankotzt dass hier Member diskriminiert werden, während Gäste tun und lassen dürfen was sie wollen?

[robbitop@work]

NV40 hat kein Phasenkonzept.
Sondern?


Weils mich ankotzt dass hier Member diskriminiert werden, während Gäste tun und lassen dürfen was sie wollen?
Also gleiches mit gleichem bekämpfen? o.O
Member werden nicht diskrimiert, solange sie sich benehmen und auffällige Gastpostings werden "moderiert" ;)

[Gast]

Sondern?

Ein Rampage-Konzept :)
Die Instructions werden direkt aus dem Speicher geladen und die TMUs stallen halt die Pipeline wenn ne Tex-Instruction kommt.

Also gleiches mit gleichem bekämpfen? o.O

Jopp. Pech dann. Ich bin einfach unzufrieden was hier läuft...

[Gast]

Ein Rampage-Konzept :)
Die Instructions werden direkt aus dem Speicher geladen und die TMUs stallen halt die Pipeline wenn ne Tex-Instruction kommt.
danke für die Erleuchtung :)



Jopp. Pech dann. Ich bin einfach unzufrieden was hier läuft...
Ach Coda, sowas hast du doch gar nicht nötig.

[Gast]

Ach Coda, sowas hast du doch gar nicht nötig.

Scheiß feste IP hier :tongue:

[robbitop@work]

Scheiß feste IP hier :tongue:
*läl* selbst ohne IP merkt man es extrem an deinem Schreibstil X-D

[loewe]

Sie sortieren natürlich die Geometrie. Sonst wäre ein Color-Tile-Buffer am Ende der Pipeline nutzlos.
Ailuros hat ja schon einiges dazu gesagt.
Der TA schmeißt etwa 50% der Geometrie raus, bevor sie überhaupt in die Displaylisten kommt, dann erst geht es in die HSR Einheit. Dort wird jedes Dreieck je Tile genau einmal angefaßt und für 32 Pixel je Takt erledigt (Serie3), bei KYRO war dann ein Dreieck immer in maximal 16 Takten fertig. Das Ergebnis ist hier ein z-Buffer und die exakte Kenntnis über die Sichtbarkeit des Dreiecks je Pixel. Durchsichtige Dreiecke werden je Pixel in einer Liste extra erfasst.
Sortiert wird zu keinem Zeitpunkt.
Virtual Texturing hilft gegen Texturwechsel stalls? Wie soll das funktionieren?
http://www.graphicshardware.org/previous/www_1999/presentations/v-textures.pdf
Es wird nur der Teil der Textur geladen, der gebraucht wird, immer bedenken ein Tile ist maximal 32x32 Pixel groß.
Einziges Problem sind Rotationen, aber IMRs mögen das auch nicht wirklich.

Wir werden mit G80/R600 sehen, wie gut andere das hinbekommen.
ATI hantiert mit USCs immerhin seit Jahren (R400 wurde vor 5-6 Jahren angefangen). Nvidia ähnlich lange (NV50 geht auf das Jahr 2001/02 zurück).
Ja da bin auch auch recht gespannt.

Ich meine nicht bei gleicher Leistung sondern bei gleicher Anzahl an Recheneinheiten und Bussen (also Anzahl ALUs/TMUs/Caches/gleichgroßes Speicherinterface ect). Beim TBDR kommt zur Rendering Pipeline ja noch die HSR Engine (oder wie auch immer das Teil heißt, welches den Z Pass in Hardware erledigt).
Wir haben uns da schon verstanden. Die Cores sind einfach zu verschieden, um sie einfach zu vergleichen.
Sagen wir es mal so, bei gleicher Chipfläche, gleiche Technologie mal vorausgesetzt, ist PowerVR bei etwa 50% weniger Fläche noch schneller, reicht das? ;)

[loewe]

PS und VS sind auf TBDRs als weiteres Beispiel total entkoppelt, was bei theoretischen non-USCs auch gleich mal wieder weniger "intermediate" caches heissen kann.

Der VS liegt auf der Seite des TA und arbeitet somit an Frame n.
Der PS liegt hinter der HSR Einheit und beschäftigt sich dor mit Frame n+1.

Sicher müssen die Daten der Displaylist vorliegen bevor es in den PS gehen kann, aber sie arbeiten ja beide gleichzeitig, nur eben an verschiedenen Frames. Sollte der TA und somit der VS mit Frame n nicht schnell genug fertig werden, bekommen sie mehr Rechenzeit als der Rest und dann sind sie fertig, Multitasking eben. :)

[Gast]

Der VS liegt auf der Seite des TA und arbeitet somit an Frame n.
Der PS liegt hinter der HSR Einheit und beschäftigt sich dor mit Frame n+1.



dann würde es aber zu problemen kommen wenn das prerendering auf 0 steht.

[Gast]

Sagen wir es mal so, bei gleicher Chipfläche, gleiche Technologie mal vorausgesetzt, ist PowerVR bei etwa 50% weniger Fläche noch schneller, reicht das? ;)
Rechen mal bitte vor wie das zustanden kommen soll.

[loewe]

Rechen mal bitte vor wie das zustanden kommen soll.
Nein! :)

[loewe]

dann würde es aber zu problemen kommen wenn das prerendering auf 0 steht.
Sicher kann es in zu Problemen führen wenn der PS denn VS beeinflußt, aber IMRs sehen da auch nicht gut aus.

Im Normalfall sollte das kein Problem sein.

[Ailuros]

Natürlich wird nicht sichtbare Geometrie verworfen. Im Prinzip ein Z-Firstpass in Hardware.

Ein Z-Firstpass ist eine andere Geschichte.

Schwer zu sagen. Kyro2 hatte nur 2 TMUs und kein TnL, wie du schon sagtest. Die Kyro2 Combiner sind allerdings etwas flexibler als die der NV11 (sie beherrschen EMBM).

GF2MX hatte auch "nur" 2 TMUs; jetzt versuch mal Bandbreiten-schonende Techniken die heute vorhanden sind in eine GF2MX hinzuzufuegen und dann sehen wir ja wie schnell die Transistoren-fressende "These" der hohen Anzahl von Z/stencil Einheiten auf einem TBDR zum Fenster rausfliegt.

Das ist prinzipbedingt.
Ein TBDR braucht einen Onchip Z-Cache und er besitzt einen OnChip Colorcache. Auch für die hässlichen Texturwechsel braucht man einen größeren Texturcache um nicht hässlichen Stalls beim Neu-einlesen der Texturen zu verfallen.

Ach und Du weisst rein zufaellig wie gross jegliche caches sowohl auf einem TBDR oder IMR genau sind?

Könntest du diesen Punkt ein wenig erläutern?

Heutige GPUs sehen natuerlich kein Problem weil dafuer die engineers auch gesorgt haben; haetten sie es nicht getan brauchst Du nur einen sehr langen PS und einen sehr kurzen VS kombinieren und das Resultat waere ein sehr netter stall, denn man musste natuerlich warten bis der PS bearbeitet wird. Die Loesung sind dann natuerlich spezifische Optimierungen u.a. auch caches die solche Unannehmlichkeiten dann eliminieren.

Es gibt auf beiden Seiten Vor- und Nachteile; d.h. aber nicht dass man unbedingt jede Kacke die Kerle wie Kirk zeitlich auftischen auch so interpretieren muss wie es gerade passt. Gilt genauso fuer "jack of all trades-master of none" und jetzt zeig mir mal G80 pffff ;)

R580 besitzt auch entkoppelte Pixelshaderalus. VS wüßte ich nicht, dass die gekoppelt wären.

Von VS Koppelung war gar nicht die Rede (siehe oben). Bei dem Transistoren-aufwand des R580 wuerde ich das Ding als Beispiel erstmal gar nicht erwaehnen.


Nochmal: ich bezweifle die Vorteile von TBDRs und dessen Effizienz nicht. Ich bin sogar ein Verfechter dieser. Nur fiel es mir stark auf, dass man bei TBDRs versucht durch Effizienz einen Rohleistungsnachteil auszugleichen. Mich würde aber viel mehr interessieren, was ein TBDR mit gleicher Rohleistung wie ein Top-IMR ausrichten könnten. Vermutlich deutlich mehr. Nur ist für mich die Frage, ob es auch mehr Transistoren kosten würde.

Wenn Du den obrigen Teil noch ein paar mal durchliest, entdeckst vielleicht Dein eigenes Oxymoron. Wenn man Effizienz so ausnutzen kann dass das Endresultat konkurrenzfaehig aber billiger ankommt, wird man dieses auch ausnutzen. Das einfachste Beispiel: wuerde es heute einen high end TBDR geben der gegen G80/R600 konkurrieren sollte, gib mir einen guten Grund warum man es mit genausoviel Bandbreite ausruesten wuerde und das faengt von der Busbreite an, ueber kompliziertere Speichercontroller und teureren Speicher mit hoeherer Frequenz.

Ich koennte mir leicht eher vorstellen dass wenn so ein chip sagen wir mal auf 500MHz getaktet waere, dass selbst 500MHz GDDR3@256bit vollkommen ausreichen wuerde und das Ding koennte sogar viel mehr AA-samples mit float HDR verpacken. Schmeiss noch ein paar MRTs in die Mischung (dass ebenso on-chip auf einem TBDR ist) und man waere schoen bloed wenn man ~90 oder mehr GB Bandbreite verpacken wuerde.


Abwarten auf G80/R600 und sich dessen Einheitenauslastung anschauen.
Im PDA Markt kann wohl derzeit niemand PVR das Wasser reichen, aber darum ging es mir auch gar nicht. ;)

Da es momentan die einzigen TBDRs mit >SM3.0 sind, sind wohl die Kleinkram Maerkte der einzige moegliche Vergleich. Woher aber die Logik kommt dass man wenn man <700M Transistoren verbrennt auch mehr Effizienz erreicht, kann ich bei bestem Willem nicht verstehen. Mir ist dann die These lieber dass wenn man solche Unterschiede bei sehr kleinen Formfaktoren sehen kann, dass man dieses auch genauso leicht rein theoretisch auf high end GPUs auch anwenden koennte.

[Ailuros]

Rechen mal bitte vor wie das zustanden kommen soll.

Die Frage wird Dir wohl keiner so leicht beantworten; ein Hint waere:

http://www.beyond3d.com/forum/showpost.php?p=94270&postcount=10

Ist natuerlich nicht so, aber mehr kann man auch nicht dazu sagen.

[Coda]

Das wird soweit ich weiß bei SFR aber vom Treiber gemacht. Ich vermute nVIDIA überprüft die Vertexshader auf Standard-Transformation und erzeugt Bounding-Volumes von den Static-Meshes die der Treiber dann verwirft wenn die eine Karte es gar nicht zeichnen muss.

Anders kann man die Geometrieleistung kein Stück optimieren im SFR-Fall.

[robbitop@work]

GF2MX hatte auch "nur" 2 TMUs; jetzt versuch mal Bandbreiten-schonende Techniken die heute vorhanden sind in eine GF2MX hinzuzufuegen und dann sehen wir ja wie schnell die Transistoren-fressende "These" der hohen Anzahl von Z/stencil Einheiten auf einem TBDR zum Fenster rausfliegt.
Sie hatte 4 TMUs (2 Pipelines mit je 2 TMUs). Hast mich dennoch überzeugt.


Ach und Du weisst rein zufaellig wie gross jegliche caches sowohl auf einem TBDR oder IMR genau sind?
Ja. Die Texturcaches vom DeltaChrome sind bsw 8 kiB groß. Kann man recht einfach mit dem Archmark messen.
Wie groß die Texturcaches in einem TBDR sind kann ich nicht sagen. Virtualtexturing scheint das Problem der Texturwechsel zu mildern. Ohne dieses müßte man mehrere Texturen im Cache halten.
Hinzu kommt ein Colorbuffer und ein Z Buffer mit je 32x32 Pixeln bei 32 Bit Farbe * Anzahl an Subsamples (für AA). (bei 4xMSAA wären das bei mir 32 kiB SRAM)



Gilt genauso fuer "jack of all trades-master of none" und jetzt zeig mir mal G80 pffff ;)
War doch eine spitzen Veralberung, right? ;)



Von VS Koppelung war gar nicht die Rede (siehe oben). Bei dem Transistoren-aufwand des R580 wuerde ich das Ding als Beispiel erstmal gar nicht erwaehnen.
Da hast du allerdings Recht :)



Wenn Du den obrigen Teil noch ein paar mal durchliest, entdeckst vielleicht Dein eigenes Oxymoron. Wenn man Effizienz so ausnutzen kann dass das Endresultat konkurrenzfaehig aber billiger ankommt, wird man dieses auch ausnutzen.
Naja das Oxymoron war nicht beabsichtigt.
Als angehender Wirtschaftsingenieur kann ich verstehen, dass man lieber die Effizienz nutzt, um in etwa gleichzuziehen oder ein bisschen schneller zu sein, und dabei zu sparen. Sonst versaute man sich ja die Margen.
Jedoch würde ich rein hypothetisch gern sehen, wie ein aktueller IMR gegen einen aktuellen TBDR aussehen würde, bei gleichen Vorraussetzungen (also gleiche Transistorzahl und gleicher Takt).



Ich koennte mir leicht eher vorstellen dass wenn so ein chip sagen wir mal auf 500MHz getaktet waere, dass selbst 500MHz GDDR3@256bit vollkommen ausreichen wuerde und das Ding koennte sogar viel mehr AA-samples mit float HDR verpacken. Schmeiss noch ein paar MRTs in die Mischung (dass ebenso on-chip auf einem TBDR ist) und man waere schoen bloed wenn man ~90 oder mehr GB Bandbreite verpacken wuerde.
Ja ist mir klar, dass ein TBDR kaum Bandbreite braucht. Aber dennoch wollte ich in meinem hypothetischen Fall sehen, was unter fast exakten Voraussetzungen (unabhängig vom wirtschaftlichen Aspekt) dabei herauskommen würde. ;)




Da es momentan die einzigen TBDRs mit >SM3.0 sind, sind wohl die Kleinkram Maerkte der einzige moegliche Vergleich. Woher aber die Logik kommt dass man wenn man <700M Transistoren verbrennt auch mehr Effizienz erreicht, kann ich bei bestem Willem nicht verstehen. Mir ist dann die These lieber dass wenn man solche Unterschiede bei sehr kleinen Formfaktoren sehen kann, dass man dieses auch genauso leicht rein theoretisch auf high end GPUs auch anwenden koennte.
Natürlich nicht, das ist einfach das Gesetz des abnehmenden Grenzertrages. Vergleichbar wären die nicht wirklich. Aber ich sage mal anhand grober Auslastungswerte der ALUs beim G80/R600 ließe sich schon ableiten, ob NV/ATI das Loadbalancing auch beherrschen oder eben nicht.

[Ailuros]

Sie hatte 4 TMUs (2 Pipelines mit je 2 TMUs). Hast mich dennoch überzeugt.

Ooops tatsaechlich.

Ja. Die Texturcaches vom DeltaChrome sind bsw 8 kiB groß. Kann man recht einfach mit dem Archmark messen.
Wie groß die Texturcaches in einem TBDR sind kann ich nicht sagen. Virtualtexturing scheint das Problem der Texturwechsel zu mildern. Ohne dieses müßte man mehrere Texturen im Cache halten.
Hinzu kommt ein Colorbuffer und ein Z Buffer mit je 32x32 Pixeln bei 32 Bit Farbe * Anzahl an Subsamples (für AA). (bei 4xMSAA wären das bei mir 32 kiB SRAM)

Schoen und da wir jetzt mit der GF2MX fertig wurden, versuch mal GoForce5500@200MHz mit MBX@50MHz zu vergleichen.

Ich bin jetzt zu faul die relevanten MBX Dokumente auszugraben, aber AR1x hier:

http://www.nvidia.com/page/handheld.html

Nur OGSS auf AR1x was wohl total nutzlos ist, keinen echten Geometrie-Prozessor (vs. VS1.1 fuer VGP und ja das Ding hat noch zusaetzlichen SRAM) und so verdammt Fuellraten-bedingt mit verdammt hohem Stromverbrauch ohne jeglichen Speicher (~350mW).

Mit dem wahren Featureset von AR1x (und nicht dem angegebenen Marketing-Quatsch) und dessen echte 3D Leistung muesste das Ding nicht nur niedriger als MBX getaktet sein sondern auch um einiges kleiner und Stromsparender sein. Nichtdestominder ist der Anteil an SRAM viel zu gross, wobei hier mit dem stacked RAM etwas nachgeholfen wird (deshalb auch weniger SRAM auf 5500 als auf 4800). Nur eben liegt dieses stacked RAM nicht im obrigen Stromverbrauch ;)

Ich will ja einsehen dass NV nicht viel Resourcen in das Ding geworfen hat, aber fuer einen chip der eigentlich nur fuer multimedia Schnickschnack geeignet ist, muss man nicht unbedingt nicht so viel Transistoren verschwenden. Und obwohl ich die extra Faehigkeiten vom 5500 nicht uebersehen kann (audio usw.) ist das Ding immer noch zu verdammt fett als chip im Vergleich zu konkurrierenden SoCs die viel mehr bei weniger Komplexitaet zu Stande bringen.


Naja das Oxymoron war nicht beabsichtigt.
Als angehender Wirtschaftsingenieur kann ich verstehen, dass man lieber die Effizienz nutzt, um in etwa gleichzuziehen oder ein bisschen schneller zu sein, und dabei zu sparen. Sonst versaute man sich ja die Margen.
Jedoch würde ich rein hypothetisch gern sehen, wie ein aktueller IMR gegen einen aktuellen TBDR aussehen würde, bei gleichen Vorraussetzungen (also gleiche Transistorzahl und gleicher Takt).

Wie gesagt momentan gibt es nur den PDA/mobile Markt.

Ja ist mir klar, dass ein TBDR kaum Bandbreite braucht. Aber dennoch wollte ich in meinem hypothetischen Fall sehen, was unter fast exakten Voraussetzungen (unabhängig vom wirtschaftlichen Aspekt) dabei herauskommen würde. ;)

Es macht aber keinen Sinn; es wuerde im Grunde gegen die Logik stossen ein TBDR System zu verwenden.


Natürlich nicht, das ist einfach das Gesetz des abnehmenden Grenzertrages. Vergleichbar wären die nicht wirklich. Aber ich sage mal anhand grober Auslastungswerte der ALUs beim G80/R600 ließe sich schon ableiten, ob NV/ATI das Loadbalancing auch beherrschen oder eben nicht.

Wenn Du nur rein theoretisch die wahren Nachteile eines konkurrierenden TBDRs ausrechnen willst (was ich mir sowieso schwer vorstellen kann ohne jegliche Erfahrung im Gebiet), werden dann ebenso die Vorteile faellig. Vergleichbar wird es in Kleinformat schon sein wenn NV/ATI endlich mit einer OGL_ES2.0 Loesung ausruecken. Sowohl diese als auch SGX werden wohl zwangsmaessig ALUs haben.