powerVR back on top ?!

[Thowe]

Zitat:

Originally posted by Ailuros
Quote Orgie

Genau, ich liebe Orgien

[Demirug]

Zitat:

Originally posted by Ailuros
Obwohl ich nicht absolut sicher bin, wuerde ich sagen dass es bei den micro-tiles zumindest so bleibt. Wenn die hierarchische Groessen von macro-tiles benutzen sollten, waerst Du sowieso verloren mit den Berechnungen oder nicht?

Macro Tiles sind eine Massnahme um die Bandbreite für das Binnig zu reduzieren.

Es wird an zwei stellen gespart:

1. Liegt ein Dreieck inerhalb einer Macro-Tile in mehr als einem Tile werden die Plane informationen nur einmal gespeichert und innerhalb der Tiles nur verwiessen.

2. Neben den reinen Dreiecksinformationen müssen ja auch noch steuerinformationen (welche Texturen, shader, usw) gespeichert werden. Da die Wahrscheinlichkeit das in benachtbarten Tiles Dreiecke mit den gleichem Setup liegen recht hoch ist müssen für jeweils bis zu 4 Tiles die Steuerdaten nur einmal gespeichert werden.

[Demirug]

Zitat:

Originally posted by Thowe
Erst einmal: Die Schreibmaske wird natürlich nicht gebinnt, sondern nach dem Wiederauslesen aus dem Speicher erzeugt. Im einfachsten Fall kann man diese Schreibmaske bestimmt als Startpixel und Endpixel eines jeden Polygons in einer Scanline betrachten. Genau das was auch beim Rasterizen in einem IMR passiert.

Das erinnert mich irgendwie aber eher an ein anderes TBDR Verfahren. AFAIR hat NVIDIA darauf ein Patent. Ich weis gar nicht warum du so zwanghaft die Brüfung der Ränder aus den Zellen raushaben möchtest. IMO sind sie dort bestens untergebracht weil sie sich dort niemals als flaschenhals wirken können.

Zitat:

Der große Vorteil eines TBDR ist meiner Meinung nach, das man es direkt vor dem HSR nur noch mit einem konstanten Strom von Polygonen zu tun hat, der keine backfacing, offscreen oder zu kleinen Polygone mehr enthält, denn die werden gar nicht gebinnt was man in den techdocs von ARM zum MBX nachlesen kann.

ja vor dem HSR ist der Strom konstant (ausser die Bandbreite reicht nicht) und das man was man sowieso nicht sieht beim binnig rauswirft ist auch klar. Das ist aber sekundär der Strom in die Pixelshader sollte konstant sein und das geht leider auch beim TBDR nicht immer. Wenn eine Tile mit vielen Dreiecken (z.b der Kopf eines Gegners) auf eine Tile mit einfachen Pixelen (Skybox only) folgt ist der Pixelshader schon fertig bevor die nächste Tile durchs HSR ist. Beide Verfahren habe da schwächen.

Zitat:

Nö, so arbeitet PVR nicht. Dies könnte theoretisch ja auch zu Stack-Overflows führen. IMHO hat Serie 2 so ähnlich gearbeitet.

Ja kann sein das ich das noch von Serie 2 habe. Hast du informationen wie das bei Serie 3 gelöst wird?

Zitat:

Aber zum vollständigen Verwerfen ist nur einer erforderlich.

Ja

Zitat:

Kleine Polygone bedecken auch weniger Tiles.

Auch richtig

Zitat:

Das ist richtig, aber das Ganze ist ja so konstruiert, das die HSR Einheiten stark überdimensioniert sind, damit sie nicht zum limitierenden Faktor werden. Da sie ja "billig" sind, kann man sich das ja leisten.

Und wenn man einen "integrated Shader" hat, dazu ausreichend viele HSR-Einheiten, kann man einen TBDR doch perfekt auslasten!

Ja aber sie können trotzdem wie ich oben aufgeführt habe den pixelstrom in die Pixelshader blockieren.

Zitat:

Aber nur eine schwache, die so ausgelegt ist, das die HSR-Einheiten nicht der limitierende Faktor sind.

Diese Kopplung ist genauso stark wie zwischen VS und PS beim IMR.

Zitat:

Genau das ist der Fall der i.d.R. auftreten sollte.

ja aber das ist halt leider nicht sicher zu gewährlieten.

Zitat:

Ich könnte mir durchaus vorstellen, das ein TBDR besser mit vielen kleinen Polygonen zurechtkommt als ein IMR.

Das muss man differenzierter sehen. Kleiner Dreiecke bedeuten ja auch mehr Dreiecke. Und damit werden es auch wieder mehr Dreiecke pro Tile. Ich weis das grosse Dreiecke sowieso auf mehr ale eine Tile aufgeteilt werden müssen. Wenn man nun ein Dreieck das voher auf zwei Tile verteilt war in 2 kleine zerlegt ist die wahrscheinlichkeit das man es genau auf der Tilegrenze teilt sehr gering. Es werden also 3 oder sogar 4 Fragmente nach dem Tilling daraus. Also steigt erst mal die Bandbreite fürs Binnig.

Solange im HSR noch reserven sind kann man die Dreiecke verkleiner ohne den Pixelstrom zu blockieren.

Bei Shadern mit 4 Texture und nur einer TMU ergibt sich folgendes:

32*16*4 = mindestens 2048 Takte bei einem Shader (1024 bei 2)

in 2048 takten könnte man 128 Fragmente prüfen (1024 = 64). werden es mehr läuft die Pixelpipeline leer.

64 Fragmente ohen overdraw ergeben 8 Pixel pro Fragment. Für den IMR renderer heist das folegendes: 8 Pixel bei 2 Shadern mit einer TMU heist das wir alle 16 Takte ein neues 8 Pixel Dreieck brauchen. In 16 Takten können 2 VS 32 Anweisungen abarbeiten womit sich schon was machen läst. Also kleine Dreiecken tun beiden Techniken weh und in beiden Fällen gilt: Kleiner Dreiecke führen zu Leerläufen im Pixelshader die für bessere Shadereffekte genutzt werden können.

[Thowe]

Zitat:

Originally posted by Demirug
Das erinnert mich irgendwie aber eher an ein anderes TBDR Verfahren. AFAIR hat NVIDIA darauf ein Patent. Ich weis gar nicht warum du so zwanghaft die Brüfung der Ränder aus den Zellen raushaben möchtest. IMO sind sie dort bestens untergebracht weil sie sich dort niemals als flaschenhals wirken können.

Wieso sollte NV da ein Patent drauf haben? Ist der Teil überhaupt patentierungswürdig? Die Ränder will ich raushalten, weil der Test pro Zelle überflüssig ist.

Zitat:

ja vor dem HSR ist der Strom konstant (ausser die Bandbreite reicht nicht)

Ich denke man wird das Ganze so auslegen, dass man beginnend beim Auslesen der Polygondaten bis zum Ende der HSR-Tests mit einem konstanten Durchsatz arbeiten kann, der an die verfügbare Bandbreite angepasst ist.

Zitat:

und das man was man sowieso nicht sieht beim binnig rauswirft ist auch klar. Das ist aber sekundär der Strom in die Pixelshader sollte konstant sein und das geht leider auch beim TBDR nicht immer. Wenn eine Tile mit vielen Dreiecken (z.b der Kopf eines Gegners) auf eine Tile mit einfachen Pixelen (Skybox only) folgt ist der Pixelshader schon fertig bevor die nächste Tile durchs HSR ist. Beide Verfahren habe da schwächen.

Wenn du bei einen IMR dieses Model auf eine SkyBox folgt, blockieren die PixelShader gerade die Z-Tester-Einheiten, das TriSetup, die VertexShader und sogar den AGP-Bus, wenn nicht zufällig genug Puffer zwischen den Einheiten zur Verfügung stehen.

Überleg doch mal, wieviele Triangles du bei gegebener (nicht zu grosser) Tiefenkomplexität und gegebener Tile-Größe sowie gegebener durchschnittlicher (kleiner) Triangle-Größe innerhalb eines Tiles so haben wirst. Wenn du da auf 1000 kommst, dann ist das schon viel und wenn die HSR-Einheit nur alle 2 Takte ein Triangle bearbeiten kann, ist sie damit nur 2000 Takte beschäftigt. So in der Größenordnung von 95% der Tiles werden sicher unter diesen 1000 liegen, auch bei sehr sehr kleinen Polygonen. Wird die Tiefenkomplexität größer spart ein TBDR an anderer Stelle Bandbreite.

Es geht hier ja nicht darum das ein TBDR immer an jeder Stelle vollkommen ausgelastet ist, sondern darum, dass es viel besser ist als ein IMR.

Zitat:

Ja kann sein das ich das noch von Serie 2 habe. Hast du informationen wie das bei Serie 3 gelöst wird?

Informationen habe ich nicht, aber ich denke das die Serie 3 bei Transparenzen hier ähnlich wie bei einem IMR arbeitet, nur halt komplett onChip.

Zitat:

Ja aber sie können trotzdem wie ich oben aufgeführt habe den pixelstrom in die Pixelshader blockieren.

Es wird eher selten passieren. Ich denke, dass dieser Fall immer nur dann gehäuft auftritt, wenn PixelShader nicht der limitierende Faktor sind. Dann ist es egal.

Zitat:

Diese Kopplung ist genauso stark wie zwischen VS und PS beim IMR.

Nein, überhaupt nicht. Weil die HSR-Einheiten eher für den WorstCase ausgelegt sind und wenn es bei 100 von 6000 Tiles mal anders ist, dann macht das aufs Bild hochgerechnet nicht viel aus.

Zitat:

ja aber das ist halt leider nicht sicher zu gewährlieten.

Warum nicht?

Zitat:

Das muss man differenzierter sehen. Kleiner Dreiecke bedeuten ja auch mehr Dreiecke.

Kleinere Dreicke bedeuten nur kleinere Dreiecke.

Zitat:

Und damit werden es auch wieder mehr Dreiecke pro Tile. Ich weis das grosse Dreiecke sowieso auf mehr ale eine Tile aufgeteilt werden müssen. Wenn man nun ein Dreieck das voher auf zwei Tile verteilt war in 2 kleine zerlegt ist die wahrscheinlichkeit das man es genau auf der Tilegrenze teilt sehr gering. Es werden also 3 oder sogar 4 Fragmente nach dem Tilling daraus. Also steigt erst mal die Bandbreite fürs Binnig.

Irgendwann sind die Dreicke so klein, das der Anteil der Null-Pixel-Großen immer stärker ansteigt. Diese Dreicke brauchen bei einem TBDR keine Bandbreite mehr, sodass sowas wie ein Sättigungseffekt eintritt. Andersherum, dürfte dann bei einem IMR immer mehr der Fall eintreten, das alles vom TriSetup an aufwärts sehr effizient an Null-Pixel-Großen Dreicken arbeitet.

Zitat:

Kleiner Dreiecke führen zu Leerläufen im Pixelshader die für bessere Shadereffekte genutzt werden können.

Genau! Aber ich denke, das ein TBDR da sogar insgesamt weniger darunter leidet.

[loewe]

Hi,

ich bemühe mich zwar sehe euch hier zu folgen, war halt nur mal knappe 20 h nicht hier, es gibt ja noch ein real life!, aber wie Ailuros schon sagt, es gelingt mir kaum noch zu verstehen worauf man sich hier bei welchem Quote gerade bezieht!

Aber zwei Punkte:

1. Ich denke auch, die HSR Einheiten sind recht einfach gehalten, AFAIK wird dort auf der Basis der infinite planes sehr effizient nur das vorderste undurchsichtige Pixel festgestellt und so nebenbei eine neue List mit den durchsichtigen logischer Weise gleich in richgtiger Reihenfolge fürs Blending bereit gestellt.

2. Die HSR Einheti wird so gross ausgelegt sein, dass sie unter "normalen" Umständen nicht zum beschränkenden Faktor wird.

[Demirug]

Zitat:

Originally posted by Thowe
Wieso sollte NV da ein Patent drauf haben? Ist der Teil überhaupt patentierungswürdig? Die Ränder will ich raushalten, weil der Test pro Zelle überflüssig ist.

Das Patent ist für einen Tiler der nicht nach dem Infinite Plane Verfahren arbeitet und deswegen im Prinzip mit einem ganz normalen Trisetup arbeitet welches nur an einer Stelle aufgesplitet ist und die Daten als Tiles ablegt. Infinte Plane und ein Scanline Trisetup vertragen sich nun mal nicht so gut.

Eine Test pro Zelle braucht man auf jeden fall und ich sehe keinen Vorteil die Maske vorher zu berechnen wenn es die HSR-Zelle mit 16 Takten pro Dreieck miterledigen können.

Zitat:

Ich denke man wird das Ganze so auslegen, dass man beginnend beim Auslesen der Polygondaten bis zum Ende der HSR-Tests mit einem konstanten Durchsatz arbeiten kann, der an die verfügbare Bandbreite angepasst ist.

Das Datenvolumen das der HSR-test maximal verarbeiten ist bekannt also legt man das Speicherinterface entsprechend aus. Alles andere ist unsinning.

Zitat:

Wenn du bei einen IMR dieses Model auf eine SkyBox folgt, blockieren die PixelShader gerade die Z-Tester-Einheiten, das TriSetup, die VertexShader und sogar den AGP-Bus, wenn nicht zufällig genug Puffer zwischen den Einheiten zur Verfügung stehen.

Ja die Pixelshader (eigentlich das Trisetup) blockieren den Rest sobald die Vertex-Buffer voll gelaufen sind. Sobald das Trisetup aber die letzten Pixel der Skybox weitergegeben hat wird sofort mit dem nächsten Dreieck weiter gemacht die Pixelpipelines sind dabei ständig unter last. Ich streite ja gar nicht ab das so etwas beim TBDR nicht passieren kann. Dafür gibt es dort halt andere Flaschenhälse. und ein unterbelasterer Vertextshader ist mir lieber als eine leere Pixelpipeline.

Zitat:

Überleg doch mal, wieviele Triangles du bei gegebener (nicht zu grosser) Tiefenkomplexität und gegebener Tile-Größe sowie gegebener durchschnittlicher (kleiner) Triangle-Größe innerhalb eines Tiles so haben wirst. Wenn du da auf 1000 kommst, dann ist das schon viel und wenn die HSR-Einheit nur alle 2 Takte ein Triangle bearbeiten kann, ist sie damit nur 2000 Takte beschäftigt. So in der Größenordnung von 95% der Tiles werden sicher unter diesen 1000 liegen, auch bei sehr sehr kleinen Polygonen. Wird die Tiefenkomplexität größer spart ein TBDR an anderer Stelle Bandbreite.

Die HSR braucht 16 Takte pro Triangle. Erhöht man die HSR Zellen kann man das reduzieren. Mit 128 Zellen kommen wir auf 4 Takte pro Dreieck. Das sind 4000 Takte. Bei 512 Pixel pro Tile müssen wir also 8 Takte pro Pixel verbraten um nicht die Pipeline leerlaufen zu lassen. Also sind viele Dreiecke (ob nun gross oder klein ist egal) mit einfachen Shadern pro Tile gift für die effektivität.

Der Vorteil bei erhöhter Tiefenkomplexität ist aber bei weitem nicht mehr so hoch wie zu Zeiten der reinen brute force IMR.

Zitat:

Es geht hier ja nicht darum das ein TBDR immer an jeder Stelle vollkommen ausgelastet ist, sondern darum, dass es viel besser ist als ein IMR.

Das hängt von zuvielen Faktoren ab um da eine generel aussage zu machen. Es gibt Situationen wo ein IMR besser abschneidet und andere die für ein TBDR besser sind. Da aber die mehrheit der Karten IMR sind wird auch darauf optimiert. Das darf man nicht vergessen.

Zitat:

Informationen habe ich nicht, aber ich denke das die Serie 3 bei Transparenzen hier ähnlich wie bei einem IMR arbeitet, nur halt komplett onChip.

Das wäre aber ungünstig weil man sich damit ja wieder eine Blockierung einbaut. Also muss das irgendwie anders gehen.

Zitat:

Es wird eher selten passieren. Ich denke, dass dieser Fall immer nur dann gehäuft auftritt, wenn PixelShader nicht der limitierende Faktor sind. Dann ist es egal.

na egal ist das nicht. wenn die HSR-Einheit schneller liefern könnte würden die FPS steigen. Nur wenn man die HSR einheit mit mehr Zellen ausstate werden diese häufiger unbenutzt sein. Dumme Sache.

Zitat:

Nein, überhaupt nicht. Weil die HSR-Einheiten eher für den WorstCase ausgelegt sind und wenn es bei 100 von 6000 Tiles mal anders ist, dann macht das aufs Bild hochgerechnet nicht viel aus.

Das glaube ich nun nicht die HSR einheit wird eher für den Default fall ausgelegt sein. Worst Case braucht viel zu viel DIE-Fläche.

Zitat:

Kleinere Dreicke bedeuten nur kleinere Dreiecke.

Du weist wie es gemeint war.

Zitat:

Irgendwann sind die Dreicke so klein, das der Anteil der Null-Pixel-Großen immer stärker ansteigt. Diese Dreicke brauchen bei einem TBDR keine Bandbreite mehr, sodass sowas wie ein Sättigungseffekt eintritt. Andersherum, dürfte dann bei einem IMR immer mehr der Fall eintreten, das alles vom TriSetup an aufwärts sehr effizient an Null-Pixel-Großen Dreicken arbeitet.

Ja das ist eine der Situationen in denen das Trisetup einfach keine Daten mehr liefert. Null-Pixel Dreiecken sind für einen IMR das reinste gift wenn sie in grosser folge hintereinader auftreten. Dem TBDR machen sie dagegen kaum was aus. Die Vertexshader laufen dort auch heiss.

Zitat:

Genau! Aber ich denke, das ein TBDR da sogar insgesamt weniger darunter leidet.

Naja kleine Dreiecke sind beim TBDR auch gift. Zum Beispiel für die Bandbreite da ja die Datenmenge beim Tilling nicht von der grösse abhängt sondern von der Anzahl der Tiles die betroffen sind und wir erinnern uns: "je mehr Dreiecke pro Tile desto mehr Takte im HSR" "je mehr takte im HSR desto höher die Gefahr das die Pixelpipeline leerläuft".

Beim IMR haben wir das gleiche Problem nur das uns dort kleine Dreicke die komplett verworfen werden relative wenig Bandbreite kosten da bei kleinen Dreiecken die aufeinader folgen die Lokalität der Pixel sehr hoch ist und damit gute Cachehits erlaubt. Dafür läuft die Pixelpipeline schnell leer.

Aber wie gesagt ohne genaue Daten und ein Simulationsmodel läst sich das rein theoretisch schwer ermitteln. Aber am ende ist immer ein Kompromiss notwending.

[Thowe]

Zitat:

Originally posted by loewe


2. Die HSR Einheti wird so gross ausgelegt sein, dass sie unter "normalen" Umständen nicht zum beschränkenden Faktor wird.

"Unnormale" Zustände werden auch eher sehr sehr selten sein.

[loewe]

Zitat:

Originally posted by Thowe


"Unnormale" Zustände werden auch eher sehr sehr selten sein.

Sag das nicht, wenn ich an Aquanox denke, besser an Aquamark, dort treten füe die HSR Einheit der K2 "unnormale" Zustände schon eher als der Regelfall auf.
Ok, ich weiß, K2 ist eigentlich nicht für solche "Spiele" gebaut worden.

[Thowe]

Zitat:

Originally posted by Demirug Infinte Plane und ein Scanline Trisetup vertragen sich nun mal nicht so gut.

Wie willst du denn ohne ScanLine TriSetup auskommen? Letztendlich musst du das Dreieck in ScanLines und Pixel zerlegen. Dabei hilft auch Infinite Planes nicht. Was das Patent angeht, dann dürfte auch ATi, VIA, Trident, 3DLabs usw. auch sowas nicht machen ohne Lizenzgeführen an NV zu zahlen.

Zitat:

Das Datenvolumen das der HSR-test maximal verarbeiten ist bekannt also legt man das Speicherinterface entsprechend aus. Alles andere ist unsinning.

Was jetzt an was angepasst wird, ist ja letztendlich egal.

Zitat:

Ja die Pixelshader (eigentlich das Trisetup) blockieren den Rest sobald die Vertex-Buffer voll gelaufen sind. Sobald das Trisetup aber die letzten Pixel der Skybox weitergegeben hat wird sofort mit dem nächsten Dreieck weiter gemacht die Pixelpipelines sind dabei ständig unter last.

Die Pixelpipelines sind dabei ständig unter Last, während die SkyBox gerendert wird. Sobald auch die kleinen Polygone folgen, ist das nicht mehr garantiert.

Zitat:

Ich streite ja gar nicht ab das so etwas beim TBDR nicht passieren kann. Dafür gibt es dort halt andere Flaschenhälse. und ein unterbelasterer Vertextshader ist mir lieber als eine leere Pixelpipeline.

Und eine leere Pixelpipeline wirst du bei einem TBDR viel viel seltener haben.

Stelle dir mal folgende Situation vor:
TileGröße: 512 Pixel
PolygonGröße: 2 Pixel
Anzahl der Polygone: 1024

dann hast du schon einen Overdraw von 4.
Wie verarbeitet ein TBDR das und wie ein IMR?

Zitat:

Die HSR braucht 16 Takte pro Triangle. Erhöht man die HSR Zellen kann man das reduzieren. Mit 128 Zellen kommen wir auf 4 Takte pro Dreieck. Das sind 4000 Takte. Bei 512 Pixel pro Tile müssen wir also 8 Takte pro Pixel verbraten um nicht die Pipeline leerlaufen zu lassen. Also sind viele Dreiecke (ob nun gross oder klein ist egal) mit einfachen Shadern pro Tile gift für die effektivität.

Und bei 256 Zellen sind es 2000 Takte und 4 Takte pro Pixel und 256 Zellen halte ich bei Serie 5 nicht für unmöglich.

Was denkst du wie oft diese Situation in der Praxis auftreten wird? Und wenn die bei vielen Tiles in einem Frame auftritt, welches Problem ist das?

Zitat:

Das hängt von zuvielen Faktoren ab um da eine generel aussage zu machen. Es gibt Situationen wo ein IMR besser abschneidet und andere die für ein TBDR besser sind. Da aber die mehrheit der Karten IMR sind wird auch darauf optimiert. Das darf man nicht vergessen.

Meiner Meinung nach sind Optimierungen für IMR meist auch Optimierungen für TBDR. Was interessiert es die Software, ob die Hardware die Polygone zwischendurch mal im RAM ablegt?

Zitat:

Das wäre aber ungünstig weil man sich damit ja wieder eine Blockierung einbaut. Also muss das irgendwie anders gehen.

Was dort wann, wie und wo gemacht wird, weiss ich leider auch nicht. Reden tun sie aber von einem OnChip-Z-Buffer.

Zitat:

na egal ist das nicht. wenn die HSR-Einheit schneller liefern könnte würden die FPS steigen. Nur wenn man die HSR einheit mit mehr Zellen ausstate werden diese häufiger unbenutzt sein. Dumme Sache.

Sie werden natürlich sehr oft ungenutzt sein, da die Anzahl der HSR-Einheiten an den WorstCase angepasst ist.

Zitat:

Das glaube ich nun nicht die HSR einheit wird eher für den Default fall ausgelegt sein. Worst Case braucht viel zu viel DIE-Fläche.

Vielleicht jetzt noch, aber warum sollte man das in Zukunft beibehalten? Zuviel DIE-Fläche braucht es glaube ich nicht.

Zitat:

Naja kleine Dreiecke sind beim TBDR auch gift. Zum Beispiel für die Bandbreite da ja die Datenmenge beim Tilling nicht von der grösse abhängt sondern von der Anzahl der Tiles die betroffen sind und wir erinnern uns: "je mehr Dreiecke pro Tile desto mehr Takte im HSR" "je mehr takte im HSR desto höher die Gefahr das die Pixelpipeline leerläuft".

Wenn du deine Dreiecke nur kleiner machts (ohne dabei den Overdraw zu steigern), dann wird es mit wachsender Dreieckszahl immer unwahrscheinlicher, das du noch Dreiecke erzeugst die nicht zwischen den SamplePoints durchrutschen. Bei einem Overdraw von 1 kannst du nur 512 Dreiecke in einem Tile haben und kein einziges mehr - selbst wenn du deine Dreiecke bis ins unendliche verkleinerst, es werden nicht mehr als diese 512, die von der Binnig-Engine überhaupt in den Speicher geschrieben werden.

Zitat:

Beim IMR haben wir das gleiche Problem nur das uns dort kleine Dreicke die komplett verworfen werden relative wenig Bandbreite kosten da bei kleinen Dreiecken die aufeinader folgen die Lokalität der Pixel sehr hoch ist und damit gute Cachehits erlaubt. Dafür läuft die Pixelpipeline schnell leer.

An wieviel verschiedene Dreiecken können denn die Pixelpipelines heutiger IMRs gleichzeitig arbeiten?

[loewe]

Zitat:

Originally posted by Demirug
Ja die Pixelshader (eigentlich das Trisetup) blockieren den Rest sobald die Vertex-Buffer voll gelaufen sind. Sobald das Trisetup aber die letzten Pixel der Skybox weitergegeben hat wird sofort mit dem nächsten Dreieck weiter gemacht die Pixelpipelines sind dabei ständig unter last. Ich streite ja gar nicht ab das so etwas beim TBDR nicht passieren kann. Dafür gibt es dort halt andere Flaschenhälse. und ein unterbelasterer Vertextshader ist mir lieber als eine leere Pixelpipeline.

Von der Sache her ist aber doch egal wo der Flaschenhals ist, wenn die Sache steht, dann steht sie.
Die HSR Einheit dürfte auf jeden Fall einfacher zu bauen sein als die Vertex- bzw. Pixelshader. So werden sie schon darauf achten, dass sie leistungsfähig genug ist.

Zitat:

Die HSR braucht 16 Takte pro Triangle. Erhöht man die HSR Zellen kann man das reduzieren. Mit 128 Zellen kommen wir auf 4 Takte pro Dreieck. Das sind 4000 Takte. Bei 512 Pixel pro Tile müssen wir also 8 Takte pro Pixel verbraten um nicht die Pipeline leerlaufen zu lassen. Also sind viele Dreiecke (ob nun gross oder klein ist egal) mit einfachen Shadern pro Tile gift für die effektivität.

Womit recht ihr denn hier?
1000 Dreiecke je Tile bedeuten bei gleichmäßiger Verteilung 1,5 Mill. Dreiecke je Frame, wobei jedes nur 2 Pixel gross wäre! Selbsrt wenn ich davon ausgehe, dass jedes Dreieck im Durchschnitt in drei Tiles kommt, gäbe es damit 500000 Dreiecke, die aber im Schnitt auch je nur 6 Pixel gross wären? Dabei sinkt doch aber die Wahrscheinlichkeit für eine Teilung auf mehrere Tiles auf einen sehr kleinen Wert, oder die Dreiecke sind größer womit der Overdraw steigt und der TBDR wieder einen klearen Vorteil hätte, wenn auch nicht mehr so viel wie früher.

Zitat:

Das hängt von zuvielen Faktoren ab um da eine generel aussage zu machen. Es gibt Situationen wo ein IMR besser abschneidet und andere die für ein TBDR besser sind. Da aber die mehrheit der Karten IMR sind wird auch darauf optimiert. Das darf man nicht vergessen.

So wird es wohl sein, als Vorteil für PowerVR könnte da durchaus die Doom3 Engine weggehen.

Zitat:

na egal ist das nicht. wenn die HSR-Einheit schneller liefern könnte würden die FPS steigen. Nur wenn man die HSR einheit mit mehr Zellen ausstate werden diese häufiger unbenutzt sein. Dumme Sache.

Deshalb wird wie auch bei KYRO die HSR Einheit eher größer ausgelegt werden, wie ich oben schon sagte wird der Pixelshader komplexer sein, womit man eher die HSR Einheit etwas vergrößern wird.

Zitat:

Aber wie gesagt ohne genaue Daten und ein Simulationsmodel läst sich das rein theoretisch schwer ermitteln. Aber am ende ist immer ein Kompromiss notwending.

zustimm!

[[ncp]EasyChiller]

da mann leider schon viel zu lange nix von PVR gehört hat isses mal wieder interessant wenigstens interessant Spekulatius zur Serie-5 zu lesen!

Aber ma ne andersweilige Frage an die Cracks: Wie sieht es mit der generellen Taktbarkeit für TBDR's aus? ... ist die im Grunde gleichzusetzen mit IMR's (im jeweiligen gleichen Herstellungsverfahren)?! ... oder gibt es (z.b. ausgehend von der HSR-Einheit) stärkere Beschränkungen? ???
(oder woran liegt es eigentlich, das die K2's selbst mit verdammt krassen Voltage-mods nicht zu viel mehr zu bewegen waren / sind?)

[Thowe]

Zitat:

Originally posted by [ncp]EasyChiller

Aber ma ne andersweilige Frage an die Cracks: Wie sieht es mit der generellen Taktbarkeit für TBDR's aus? ... ist die im Grunde gleichzusetzen mit IMR's (im jeweiligen gleichen Herstellungsverfahren)?! ... oder gibt es (z.b. ausgehend von der HSR-Einheit) stärkere Beschränkungen? ???

Nein.

Zitat:

(oder woran liegt es eigentlich, das die K2's selbst mit verdammt krassen Voltage-mods nicht zu viel mehr zu bewegen waren / sind?)

Die K2 war mit der SE für max. 200 Mhz ausgelegt und es gab auch nicht viele 180nm Karten die für einen höheren Takt ausgelegt waren (GF2U, nach Selektion).

[Börk]

Zitat:

Originally posted by Thowe

Die K2 war mit der SE für max. 200 Mhz ausgelegt und es gab auch nicht viele 180nm Karten die für einen höheren Takt ausgelegt waren (GF2U, nach Selektion). [/SIZE]

Die GeForce2 hatte aber auch wesentlich mehr transis!!!

[Demirug]

Da mir die Quotes langsam auch zu heftig werden jetzt mal ohne.

Es ist möglich ohen Scanline-trisetup festzustellen ob ein Punkt innerhalb eines Dreiecks liegt oder nicht. Das Verfahren passt auch perfekt zu dem Z-Berechnungsverfahren von PowerVr. Ohne ein Paar Bilder läst sich das aber schwer erklären. Darum bitte ich dich mir hier erst mal zu glauben.

Die rechungen wann wie eine Pipe leerläuft sind aber sowieso verdammt ungenau da man nicht weis an welcher stelle welche Cachespeicher in der Pipe sind. Deswegen ist das irgendwie alles zu theoretisch geworden.

Worauf wir uns glaube ich einigen können ist folgendes:

Der Vorteil einer TBDR ist heute nicht mehr so gross wie zu Zeiten des Kyros. Wie gross er nun genau ist können nur Tests mit echten Chips zeigen.

Die HSR-Einheit wird wohl mit sehr hoher warscheinlichkeit die grösste Leerlaufzeit haben.

Die Pixelshader eines TBDR werden gleichmässiger mit Pixel versorgt werden können. Dagegen können die Pixelshader eines IMR die Tatsache ausnutzen das immer eine grössere Menge Pixel mit den gleichen Settings direkt hintereinader gerendert werden.

Ein TBDR wird wohl mit weniger PS auskommen als ein IMR zum ausgleich braucht er aber mehr Cachespeicher für Texturen, Shaderprogramm, Konstanten da eine geringere Konstant als beim IMR aufweisen.

Ein TBDR wird DOOM III lieben. Wenige grosse Polygone mit aufwendigen Pixelshader und viele Stenciloperationen. PowerVRs Traum.

ein Quote muss jetzt aber noch sein:

Zitat:

An wieviel verschiedene Dreiecken können denn die Pixelpipelines heutiger IMRs gleichzeitig arbeiten?

Laut NVIDIA (von ATI gibt es dazu AFAIK keine aussage) kann der NV30 an 32 Pixel von 32 Polygone gleichzeitig arbeiten. Die Pixel können sogar von Dreiecken mit unterschiedlichen Shadern kommen weil NVIDIA wohl die Setupänderungen syncron zu den Daten mitschiebt. Angeblich machen sie das schon eine ganze Weile so.

[Thowe]

Zitat:

Originally posted by burk23

Die GeForce2 hatte aber auch wesentlich mehr transis!!!

Was aber beim Takt nicht unbedingt eine Rolle spielt. Da ist eher die Frage ob das Design Takt-optimiert ist o.ä.

[Thowe]

Einigen wir uns erst einmal darauf.

Zitat:

Originally posted by Demirug Laut NVIDIA (von ATI gibt es dazu AFAIK keine aussage) kann der NV30 an 32 Pixel von 32 Polygone gleichzeitig arbeiten. Die Pixel können sogar von Dreiecken mit unterschiedlichen Shadern kommen weil NVIDIA wohl die Setupänderungen syncron zu den Daten mitschiebt. Angeblich machen sie das schon eine ganze Weile so.

Das betrifft aber wohl die PipelineStages. Also anders gefragt, mit wievielen Polygonen können die PS ihre Arbeit gleichzeitig beginnen?

[Demirug]

Zitat:

Originally posted by Thowe

Das betrifft aber wohl die PipelineStages. Also anders gefragt, mit wievielen Polygonen können die PS ihre Arbeit gleichzeitig beginnen?

Mit so vielen wie das Trisetup pro Takt liefern kann. Wenn nun aber zwischen dem Trisetup und den Pixelshader noch ein Cache liegt kann das trisetup zwar nur Pixel pro Takt von einem Polygon hinzufügen aber die Pipelines könnte 8 entnehmen.

Soll heisen: Wenn der Pixel-Shader 8 Takte braucht könnten in dieser Zeit 8 neue Pixel in den Cache laufen. In 8 Takten werden beim NV30 wohl 2 Shaderops mit 32 Pixel durchgeführt. Sobald aber in den 8 Takten keine 8 Pixel von Trisetup kommen läuft eine Blase durch die Pipeline. Die Frage die bleibt ist ob diese Blase das Programm kommplett durchlaufen muss oder nur einmal durch die Shaderzelle (4 stufen) muss und dann durch einen Pixel ersetzt werden kann.

[Thowe]

Zitat:

Originally posted by Demirug


Mit so vielen wie das Trisetup pro Takt liefern kann. Wenn nun aber zwischen dem Trisetup und den Pixelshader noch ein Cache liegt kann das trisetup zwar nur Pixel pro Takt von einem Polygon hinzufügen aber die Pipelines könnte 8 entnehmen.

Soll heisen: Wenn der Pixel-Shader 8 Takte braucht könnten in dieser Zeit 8 neue Pixel in den Cache laufen. In 8 Takten werden beim NV30 wohl 2 Shaderops mit 32 Pixel durchgeführt. Sobald aber in den 8 Takten keine 8 Pixel von Trisetup kommen läuft eine Blase durch die Pipeline. Die Frage die bleibt ist ob diese Blase das Programm kommplett durchlaufen muss oder nur einmal durch die Shaderzelle (4 stufen) muss und dann durch einen Pixel ersetzt werden kann.

Und du meinst der Aufwand für den Cache, Hierarchical-Z usw. ist geringer als der für eine ausreichenede Anzahl HSR-Einheiten bei einem TBDR?

[Demirug]

Hierarchical-Z ist eigentlich recht einfach zu machen. Der Cache ist einfach braucht aber wohl etwas Platz auf dem DIE.

Was sollen NVIDIA und ATI aber den machen? Wenn die beiden einen TBDR bauen geht das wahrscheinlich genaus in die Hose wie ein Versuch von PowerVR eine IMR zu bauen. Beide würde es wohl hinbekommen aber die Performances des ersten Versuchs wäre wohl nicht so gut. Da sind einfach zuwenige erfahrungen vorhanden. Ein Technologie wechsel bedeutet das man fast alles was man hat wegwerfen kann.

[Thowe]

Eben und ich denke das ist der wahre Grund das sie noch keinen TBDR gebaut haben.