parhelia: kein mittel zum schonen der bandbreite ?

[mapel110]

stimmt das ?
trotz der vorhandenen bandbreite von mindestens 17gb/s machts doch trotzdem sinn, oder ?

das kann man doch bestimmt noch nachträglich in die treiber integrieren.

[aths]

Parhelia hat sowas etwas ähnliches, was bei der GeForce3 "Crossbar Memory Controller" heißt. Damit wird die Ineffizienz, die das breite Interface bedingt, erheblich gesenkt.

[mapel110]

das hab ich auch gelesen. aber nvidia hat lma 1 und 2. ati hat hyperz. powervr hat tile-based-rendering mit hsr.

matrox hat nix dergleichen. zumindest nach dezeitigem wissensstand. oder irre ich da ?

[Leonidas]

Korrekt. Stellt sich nun nur die Frage, welches dieser Mittel (außer Tiling) wirklich der Bringer ist. Da in der GeForce3 LMA1 + der Memory-Controller integriert sind, kann man nur spekulieren, welches von beiden nun das meiste bringt. Ich persönlich denke ja, das der Memory-Controller das wichtigste ist - und dies hat Matrox *wohl* auch.

*wohl* -> weil es derzeit nicht wirklich sicher ist

[Demirug]

Meiner Meinung nach vertragen sich Tiling und Displacement Mapping bzw N-Patches aber überhaupt nicht.

Sollte nun das DM den großen Erfolg erleben hätte man sich mit Tiling selbst reingelegt. Ob es allerdings ein Erfolg wird hängt wahrscheinlich davon ab ob NVidia, Ati, usw. es auch unterstützen werden

[nocturne]

Originally posted by Demirug
Meiner Meinung nach vertragen sich Tiling und Displacement Mapping bzw N-Patches aber überhaupt nicht.

Sollte nun das DM den großen Erfolg erleben hätte man sich mit Tiling selbst reingelegt. Ob es allerdings ein Erfolg wird hängt wahrscheinlich davon ab ob NVidia, Ati, usw. es auch unterstützen werden

Interessant, das mal von einem Entwickler zu hören. Kannst Du das näher ausführen?

[HOT]

Originally posted by Demirug
Meiner Meinung nach vertragen sich Tiling und Displacement Mapping bzw N-Patches aber überhaupt nicht.

Sollte nun das DM den großen Erfolg erleben hätte man sich mit Tiling selbst reingelegt. Ob es allerdings ein Erfolg wird hängt wahrscheinlich davon ab ob NVidia, Ati, usw. es auch unterstützen werden

Hmm... warum das denn nicht? es ist doch im Grunde das gleiche Rendering, nur dass der Z-Check vor dem rendering gemacht wird. Wieviele Polygone vorher gecheckt werden spielt doch eher eine untergeordnete Rolle; zumindest sind die Werte so hoch angesetzt, das da kaum einer rankommt (Der Kyro2 kann 180Mio Polygone Checken).

[Xmas]

Originally posted by HOT
Hmm... warum das denn nicht? es ist doch im Grunde das gleiche Rendering, nur dass der Z-Check vor dem rendering gemacht wird. Wieviele Polygone vorher gecheckt werden spielt doch eher eine untergeordnete Rolle; zumindest sind die Werte so hoch angesetzt, das da kaum einer rankommt (Der Kyro2 kann 180Mio Polygone Checken).
Wie kommst du auf diese Zahl (die zudem noch nicht zum Takt passt)?

Die Z-Check-Einheit braucht 16 Takte, um ein Polygonteil zu checken.
Bei einfacher Auslegung der Z-Check-Unit bedeutet das ca. 11 Mio. Polygonteile pro Sekunde bei 175 MHz, d.h. wenn ein Polygon im Durchschnitt zwei Tiles bedeckt sind es noch 5,5 Mio. Polygone pro Sekunde.

Problematisch ist aber auch nicht nur der Z-Check (den kann man sehr gut parallelisieren), sondern eher das Geometry Binning.
Andererseits könnten sich mit Tiling aber auch ganz neue Möglichkeiten eröffnen, z.B. HOS pixelgenau zu rendern.

[Unregistered]

Das ein fast Z Clear vorhanden ist.

Gruss Labberlippe

[Demirug]

@Hot & nocturne:

Dann wollen wir mal etwas rechnen:

Beim normalen Rendern brauchen wir:
40 bits Farbe
24 bits Z Read
24 bits Z Write

ergibt 88 bits

Wenn man nun mit Tilling arbeitet müssen die bei der Tesslation entstandehnen Dreiecke in den Grafikkartenspeicher übertragen werden.

Gehen wir davon aus der Tiller ist in der Lage auf Indexbasis zu arbeiten. Im Idealfall bedeutet das 1 berechneter Vertex pro Dreieck.

Bei DX8 ist der VS output (ohnetexturen) 448 bits gross.
Für die Texturen kommen nochmal 32 bit pro Texturkoordinate hinzu.

Für Polys mit 2*2D Texture ergeben sich 576 bits pro Vertex

Jetzt müssen wir für das Dreieck noch die Indices speichern (3*32 bits) und einen Verweis auf das zu Pixelshader setup (32 bits) = 128 bits

Jetzt muss der Index des Dreiecks noch in die Tiles eingetragen werden in dehnen es vorhanden ist. Idealfall genau 1 Tile = 32 bits

Pro Dreieck sind das also 576+128+32 = 736 bits

Da wir alles was wir rausschreiben auch wieder einlesen müssen ergibt sich eine bitmenge von 736*2 = 1472 bits.

1472 / 88 = 16.7 Pixel pro Dreieck

Daraus folgt das Tilebased rendering nur dann etwas bringt wenn die Dreiecke größer als 16.7 Pixel (Idealfall) sind. In der Praxis ist der Speicherbedarf pro Dreieck aber größer. Wenn dann auch noch mehr als 4 Texturkoordinaten verwendet werden steigt der Bedarf noch weiter.

Wenn nun das Dreick durch einen Z-Test verworfen wird ergibt sich folgende Rechnung.

1472 / 24 = 61.3 Pixel pro Dreieck (bei HyperZ noch mehr)

Werden die Dreicke nun kleiner braucht das tilebased mehr bandbreite als die normale renderlösung.

Folgende Problem beim Tilebased rendern kommen noch hinzu:
Die Transitoren Anzahl steigt.
Entweder ist der Chip ungleichmässig ausgelasted (Vertex und Pixel einheit im Wechsel) oder es wird mehr Speicher gebraucht.
Der Pixelshader muss häufiger umgeladen werden. (vorallem bei Transparenz effekten)


So das sollte als Grundlage erst mal reichen.

[wulfman]

http://forums.matroxusers.com/showthread.php?s=&threadid=33009

hier wird darüber gesprochen, dass depth adaptive tesselation nicht auf DM beschränkt ist, sondern auch auf normale objekte angewendet werden kann, wenn das spiel es unterstützt.

was haltet ihr davon? aths? ;)

mfg
wulfman

[Demirug]

Originally posted by wulfman
http://forums.matroxusers.com/showthread.php?s=&threadid=33009

hier wird darüber gesprochen, dass depth adaptive tesselation nicht auf DM beschränkt ist, sondern auch auf normale objekte angewendet werden kann, wenn das spiel es unterstützt.

was haltet ihr davon? aths? ;)

mfg
wulfman

Hört sich an wie trueform nur mit dem unterschied das der Tesslationsfaktor automatisch bestimmt wird. Wenn es Teil der DX9 Spec ist und die Randbedingungen sich in Grenzen halten werde ich es mit Freude benutzen.

[jedi]

Originally posted by Demirug
Werden die Dreicke nun kleiner braucht das tilebased mehr bandbreite als die normale renderlösung.


Das habe ich auch schon von anderen Entwicklern gehört. Bei steigender Polygonzahl ist also tilebased-rendering auf dem absteigenden Ast. Kein Wunder also, dass es um PowerVR/Kyro immer leiser geworden ist.

[Demirug]

Originally posted by jedi


Das habe ich auch schon von anderen Entwicklern gehört. Bei steigender Polygonzahl ist also tilebased-rendering auf dem absteigenden Ast. Kein Wunder also, dass es um PowerVR/Kyro immer leiser geworden ist.

Die Anzahl ist dabei nicht mal so das problem. Man erhöht dann eben etwas den Takt. Man wäre ja immer noch biliger als die anderen. Das Problem ist die größe.

Ein anderes Problem sind die Pixelshader. Bei Interesse kann ich das gerne etwas genauer ausfüheren.

[HOT]

Na ja, was die noch hervorzaubern lassen wir uns mal überraschen. Aber deshalb ist es wohl eher weniger "still" geworden. Es war eigentlich schon seit dem Launch des K2 "still" :D
Wenn jemand die PowerVR Lizenz zur Fertigung von Serie 4/5/6 Chips gekauft hat, werden diese Chips auch erscheinen.
@Demirug
deine Argumentation klingt einleuchtend. Wie sieht es denn jetzt aus, wenn PowerVR alles etwas "grösser" dimensioniert, würde dann TBR wieder funzen? Immerhin hat sich PowerVR für die Serie4 ein komplett neues Design einfallen lassen.... (auch wenn man darüber noch nix weiss).
Aber nochwas: würde das evtl. den extremen Leistungsgewinn der K2 bei der höhere Takt im Gegensatz zur K1 erklären? Bei vielen neueren Benches und Spielen im Zusammenhang mit einer guten CPU kann der K2 ja seine Leistung nahezu 1/1 gegenüber dem Takt erhöen. Immerhin bricht die K2 erst ab der 1024er Auflösung aufgrund der Speicherbandbreite ein, der K1 aber schon ab 800x600.

[jedi]

Originally posted by Demirug
Die Anzahl ist dabei nicht mal so das problem. Man erhöht dann eben etwas den Takt. Man wäre ja immer noch biliger als die anderen. Das Problem ist die größe.

Ein anderes Problem sind die Pixelshader. Bei Interesse kann ich das gerne etwas genauer ausfüheren.

Ja, bitte! Es ist doch gut, mal endlich einen Entwickler hier zu haben, der weiss wovon er redet.

[Demirug]

@Hot:

"grösser" dimensionieren müssten sie sowieso um den polydurchsatz zu schaffen. Wie ich aber schon gesagt habe ist die Anzahl der Dreiecke sekundär. Die Problem fangen dann an wenn man zum wegspeichern und wiedereinladen der Dreiecke mehr bandbreite benötigt als wenn man die Dreiecke direkt rendert. Unter umständen läst sich da noch etwas optimieren.

Wobei ich gerade noch einen Fehler in meiner Rechnung gefunden habe. Ich habe das AA nicht berücksichtigt. Dadurch verschiebt sich die Situation etwas zu gunsten des TBR. Meine Rechnung ging allerdings von gleichem Speichertakt aus was bei PowerVR normalerweise ja nicht der fall ist.

Ein anderes Problem bleibt jedoch. Bei gleichem Leistungsumfang braucht ein TBR Chip eine größere Fläche. Das heist dann auch teurer. Ob das durch die biligeren Speicher wieder eingespart werden kann weis ich nicht.

Unter umständen könnte man die Fläche bei den Vertexshader einsparen. Ich denke aber eher nicht da bei TBR die VS nicht optimal genutzt werden können.

[aths]

Demirug,

deine Rechnung ist falsch. Mit (mindestens) 40 Bit wird intern gerendert, der Framebuffer bleibt weiterhin 32-bittig.

[Demirug]

Originally posted by aths
Demirug,

deine Rechnung ist falsch. Mit (mindestens) 40 Bit wird intern gerendert, der Framebuffer bleibt weiterhin 32-bittig.

Ja du hast recht. habe mir gerade die DX9 DDK Folien angeschaut. Man benutzt jetzt das 10bpc Fromat.

Wenn ich das berücksichtige ergibt sich folgendes:

32 bits Farbe
24 bits Z Read
24 bits Z Write

ergibt 80 bits

1472 / 80 = 18.4 Pixel pro Dreieck

Das ist aber fürs TBR noch ungünstiger.

[Demirug]

Originally posted by jedi


Ja, bitte! Es ist doch gut, mal endlich einen Entwickler hier zu haben, der weiss wovon er redet.

Zuviel der Ehere. Was Chipdesign angeht bin ich vom Experten weit entfernt.

Natürlich ist es möglich einen VS für einen TBR Chip zu bauen. Die Problematik dabei ist nur das man dabei auf wesentlich mehr dinge aufpassen muss als bei einer "normalen" GraKa.

VS sind als Pipeline aufgebaut. Das bedeutet das die einzelnen Pixel (oder AA Sampels wie NVidia sie nennt) durchgeschoben werden. Pro Takt um eine Stufe weiter.

Bei einer "normalen" Karte wird der vorgang wahrscheinlich wie folgt aussehen.

1.Laden des PS Programms in die Pipeline (sehr aufwending)
2.Berechnen von vielen Pixeln
3.Leerlaufenlassen der Pipeline
4.Weiter bei 1 mit den nächsten PS.

Ein solches Verfahren ist relative günstig (chipfläche) zu implementieren. Bei TBR funktioniert das aber nicht. Da bei jedem Punkt der PS sich ändern könnte (OK im normalfall wird das nicht vorkommen) würden bei einem PS mit 5 Anweisungen mindestens 15 takte notwendig (eher mehr weil das laden wahrscheinlich mehr als 10 Takte erfordert). Bei Alphablending funktionen (sehr beliebt bei uns programmieren) vervielfacht sich dieser Wert.

Also muss man die PS Einheit bei TBR anders aufbauen. Was jetzt folgt ist nur eine spekulation. Es gibt wahrscheinlich auch noch andere wege.

Als erstes brauchen wir einen Cache im Chip für die PS Programme. Diese ständig aus dem Spiecher zu laden wäre kontraproduktiv und langsamer.

Abhängig von der Chipfläche die man bereit ist zu investieren kann man zwei wege einschlagen:

Sparsamer weg:
Daten und Anweisungen werden wechselweise über die Pipeline geleitet. das dürfte 3 oder mehr takte pro Anweisung brauchen.

Teurer weg:
Daten und Anweisungen werden parrallel über die Pipeline geleitet. das dürfte 2 Takte pro Anweisung brauchen.

Die länge der Pipeline ist bei TBR Chip auch von viel entscheidenerer Bedeutung da sie ja für jeden Pixel komplett durchlaufen werden muss.

Da bei TBR weniger Pixel brechnet werden müssen ist die reduzierte verarbeitungs Geschwindigkeit wahrscheinlich noch zu vertreten.

Meine Hauptsorge gilt allerdings der Chipgrösse. AGB GraKas haben nun mal eine 40W Grenze. Externe Netzteile sind zwar eine nette Idee treiben aber den Preis auch nach oben.

[Nr. 5]

Originally posted by Demirug


Zuviel der Ehere.ich glaube nicht.
bin eher "normaluser", lese aber gerne die posts der qualifizierteren member, poste dort aber so gut wie gar nicht wg. mangelenden fachwissen.
und ich denke, deine (grad mal) 20 posts haben gezeigt das du ganz schön was von der materie verstehst.

ich hoffe mal, dich auch in zukunft öfters hier zu sehen. :)
btw. der letzte member der mir genausofrüh auffiel, war zeckensack. *schleim* ;)


cu

[ram]

Originally posted by Demirug
Ein anderes Problem bleibt jedoch. Bei gleichem Leistungsumfang braucht ein TBR Chip eine größere Fläche. Das heist dann auch teurer.

Die Theorie geht nicht auf. Ein TNT2 ohne S3TC und ohne DX6/7 Shader hat 15 Millionen Transistoren, ein massiv schnellerer KYRO mit diversen Zusatzfeatres hat 12 Millionen.

[StefanV]

Originally posted by ram
Die Theorie geht nicht auf. Ein TNT2 ohne S3TC und ohne DX6/7 Shader hat 15 Millionen Transistoren, ein massiv schnellerer KYRO mit diversen Zusatzfeatres hat 12 Millionen.

Die TNT2 ist aber ein recht ineffizientes Design...

Der VSA-100 hatte schließlich nur 14MIO Transistoren und kann 'etwas' mehr als ein TNT kann...

[Quasar]

Ich glaube, daß bezog sich nur auf die zusätzliche Implementation eines Vertex-/Pixelshaders, welche lt. demirog bei einem Tiler/deferred Renderer umfangreicher ausfallen müssen.

Ob das nun den offenbaren T-Count Vorteil des grundlegenden Designs aufwiegt oder übertrifft, kann ja mal einer nachzählen ;)

[HOT]

Wir werden es denke ich dann ja bald erfahren, mit welcher Technik PowerVR daran gegangen ist. Es bleibt auf jeden Fall spannend, da dieser Chip trotz alle dem noch sehr interessant sein könnte.
Zu Deferred Renderen hab ich auch noch was zu sagen: wenn der Chip ein effizient laufender deferred Renderer ist braucht er im allgemeinen weniger Takt als seine Konkurrenz, was ihn schon wieder kälter werden lässt. Desweiteren ist es ja auch eine Frage des Fertigungsprozesses und wenn ich da jetzt an UMC Produktion in 130nm mit Kupferimplementation denke und dann auf den neuen Tridentchip blicke, ist da noch SEHR VIEL drin :)

Übrigens der Kyro ist auch immernoch schneller als ein VSA100 (V4), besitzt mehr Funktionen (BM) und ist trotzdem noch kleiner :D

[ram]

Originally posted by Stefan Payne
Die TNT2 ist aber ein recht ineffizientes Design...

Der VSA-100 hatte schließlich nur 14MIO Transistoren und kann 'etwas' mehr als ein TNT kann...

Man kann ja auch mit dem "effizienten" VSA-100 vergleichen. Das Teil ist mit 14 Millionen Transistoren deutlich langsamer als ein kleinerer KYRO. Gleiches gilt für andere Chips in der Grössenordnung (Savage2K, Rage128, etc.). Die Logik für Tiling und den ISP ist wirklich nicht gross.

Für Immediate Mode Renderer braucht man Logik, die man sich bei Tilern gleich sparen kann. Transistormässig aufwändige Tiefenspeicherkompression und Caches zum Auslasten von Brute-Force-Speicherinterfaces zum Beispiel.

[ow]

Originally posted by HOT

Aber nochwas: würde das evtl. den extremen Leistungsgewinn der K2 bei der höhere Takt im Gegensatz zur K1 erklären? Bei vielen neueren Benches und Spielen im Zusammenhang mit einer guten CPU kann der K2 ja seine Leistung nahezu 1/1 gegenüber dem Takt erhöen. Immerhin bricht die K2 erst ab der 1024er Auflösung aufgrund der Speicherbandbreite ein, der K1 aber schon ab 800x600.


Die Skalierung der Kyros mit dem Takt ist nicht besser als die anderer Chips. Das ist nur ein Gerücht, keine Ahnung woher. Alle Chips, die am Fillrate-limit betrieben werden skalieren linear mit steigendem Takt.

Kann ich sehr gut mit meiner RivaTNT, GF2MX, Radeon1 und Kyro1 auf XP1700 sehen. Der XP hat genug Power, dass all diese Grakas limitieren und nicht die CPU.

[HOT]

Ich erinnere hier nur an die Beyond3D Tests damals. Die haben das nachgewiesen. Desweitere gehe ich hier von einer Auflösung von 1024 aus, dort schnitt der K1 sowieso nie gut ab. Der K2 ist mit entsprechender CPU DEUTLICH schneller als eine K1.

[ram]

Bei DX8 ist der VS output (ohnetexturen) 448 bits gross.


Pro Vertex braucht man doch nur Positionsdaten (12 Byte), Normale (12 Byte) und vielleicht 2 Farbwerte (je 4 Byte). Dann abhängig von der Anzahl Texturen die Texturkoordinaten (je ca. 2 Byte). Macht ohne Texturen 256 Bits und mit 4 Texturen 320 Bits.


"grösser" dimensionieren müssten sie sowieso um den polydurchsatz zu schaffen. Wie ich aber schon gesagt habe ist die Anzahl der Dreiecke sekundär. Die Problem fangen dann an wenn man zum wegspeichern und wiedereinladen der Dreiecke mehr bandbreite benötigt als wenn man die Dreiecke direkt rendert.

Deine Rechnung ignoriert komplett den späteren Gewinn durch HSR (Vermeidung Overdraw, keine Framebufferzugriffe fürs Blending, etc.) und basiert auf der Annahme, dass HOS von künftigen Tilern genau gleich behandelt wird wie HOS auf traditionellen Grafikchips. Es gibt mittlerweile effiziente Algorithmen zum HSR von HOS.

[ram]

Bei TBR funktioniert das aber nicht. Da bei jedem Punkt der PS sich ändern könnte (OK im normalfall wird das nicht vorkommen) würden bei einem PS mit 5 Anweisungen mindestens 15 takte notwendig (eher mehr weil das laden wahrscheinlich mehr als 10 Takte erfordert).

Dafür hast du bei Immediate Mode Rendern das Problem, dass du viele Shader lädst und berechnest, die schlussendlich gar nicht sichtbar sind.

Bei Alphablending funktionen (sehr beliebt bei uns programmieren) vervielfacht sich dieser Wert.

Bei jedem Alphablending macht z.B. ein Immediate Mode Renderer immer zwei Speicherzugriffe mehr auf den Framebuffer als ein Tiler.

Unter umständen könnte man die Fläche bei den Vertexshader einsparen. Ich denke aber eher nicht da bei TBR die VS nicht optimal genutzt werden können.

Und wieso nicht?

[Demirug]

@Ram:
Hab im Moment gerade leider keine Zeit auf deine ganzen interesanten einwände und fragen einzugehen (muss für meine Brötchen arbeiten). Heute Nachmittag zwischen 17 und 18 Uhr werde ich aber gerne ein paar Sätze schreiben.

@All:
Wenn ich mir die Topic über diesem thread anschaue werde ich das gefühl nicht los das wir mittlerweile verdammt off-topic sind.

Vielleicht sollten wir die Diskussion im Technologie oder Spekulations Bereich fortsetzen. Titel: "Theoretische Performancebetrachtungen (Bandbreite, Taktrate und Chipfläche)bei DX8-DX9 TBR Chips"

Ok ist vielleicht etwas lang der Titel :D

[Demirug]

Ok beleiben wir erst mal hier.

Um es gleich mal vorweg zu sagen. Ich habe nichts gegen TBR. Als Programmierer ist es mir eigentlich egal wie der Chip arbeitet. Hauptsache er funktioniert mit einer API so wie diese es vorsieht.

@ram:


Pro Vertex braucht man doch nur Positionsdaten (12 Byte), Normale (12 Byte) und vielleicht 2 Farbwerte (je 4 Byte). Dann abhängig von der Anzahl Texturen die Texturkoordinaten (je ca. 2 Byte). Macht ohne Texturen 256 Bits und mit 4 Texturen 320 Bits.


Ich habe einfach mit der größe der Output register gerechnet. Du hast natürlich recht das man da noch etwas sparen. Bei der Verwendung von ps 2.0 reichen deine Bits aber auch nicht ganz und bei der Farbe bist du auch etwas geizig. Die Wahrheit liegt wohl irgendwo zwischen unseren Werten


Deine Rechnung ignoriert komplett den späteren Gewinn durch HSR (Vermeidung Overdraw, keine Framebufferzugriffe fürs Blending, etc.) und basiert auf der Annahme, dass HOS von künftigen Tilern genau gleich behandelt wird wie HOS auf traditionellen Grafikchips. Es gibt mittlerweile effiziente Algorithmen zum HSR von HOS.


Das Beispiel war zugegeben etwas zu simple. Ich kann aber auch ein etwas mehr an der praxis orintiertes Beispiel ausarbeiten. Aber nur wenns wirklich jemanden interesiert ist nähmlich etwas arbeitsintensive.

Was die HOS angeht würden mich die Algorithmen wirlich interesieren (hat jemand links). Habe leider keine Ahnung wie man HOS in Verbindung mit VS und TBR anders angehen könnte.


Dafür hast du bei Immediate Mode Rendern das Problem, dass du viele Shader lädst und berechnest, die schlussendlich gar nicht sichtbar sind.


Die Takte stimmen hinten und vorne nicht (sollte vielleicht doch etwas mehr schlafen). Ansonsten hat du recht. Ich war zu dem Zeitpunkt eher bei der Chipfläche als beim Speicherinterface.


Unter umständen könnte man die Fläche bei den Vertexshader einsparen. Ich denke aber eher nicht da bei TBR die VS nicht optimal genutzt werden können

Und wieso nicht?


Oh man ich brauche wirklich mehr schlaf. Was ich eigentlich sagen wollte ist folgendes. Die VS einheit braucht bei TBR und beim "normalen" Rendern die gleiche Fläche. Da aber TBR chips normalerweise einen langsameren Takt haben ist der durchsatz entsprechende geringer.

@All:
Bei allgemeinem interesse könnten wir im Spekulationsforum versuchen einen TBR chip (DX8 oder DX9) im Bezug auf seine Kenngrößen durchzurechnen.

Oder bin ich als neuer hier jetzt zu extrem für das Forum?

[ow]

Originally posted by HOT
Ich erinnere hier nur an die Beyond3D Tests damals. Die haben das nachgewiesen. Desweitere gehe ich hier von einer Auflösung von 1024 aus, dort schnitt der K1 sowieso nie gut ab. Der K2 ist mit entsprechender CPU DEUTLICH schneller als eine K1.


Und? Welche Aussage soll ich deinem Posting entnehmen?

Der TNT2 ist auch DEUTLICH schneller als ein TNT mit entsprechender CPU.

Und der K1 läuft auch sehr gut in der 1024er Auflösung bei mir.

[mapel110]

@demirug
macht nix, wenn der thread offtopic inhalt hat. das kommt hier öfter vor. ausserdem interessiert mich, was du erzählst ;)

man erfährt sonst nämlich recht wenig über die technischen hintergründe vor allem zum thema TBR.

[GloomY]

Interessante Diskussion. Hab' jetzt aber leider keine Zeit, mich zu äussern. Ich werde das am Montag machen, wenn ich von der Wochenend-LAN zurück bin...

Bis denne,

GloomY

[zeckensack]

Originally posted by Demirug
@Hot:

"grösser" dimensionieren müssten sie sowieso um den polydurchsatz zu schaffen. Wie ich aber schon gesagt habe ist die Anzahl der Dreiecke sekundär. Die Problem fangen dann an wenn man zum wegspeichern und wiedereinladen der Dreiecke mehr bandbreite benötigt als wenn man die Dreiecke direkt rendert. Unter umständen läst sich da noch etwas optimieren. Eine der Grundideen ist doch, daß man pro Kachel nur eine begrenzte, überschaubare Pixelanzahl bearbeiten muß, die (FSAA und Blending erstmal außen vor) mit der Anzahl der zu rendernden Dreiecke in der Kachel schlimmstenfalls identisch ist. Mehr Geometrie wird pro Kachel nicht dargestellt, sie würde sowieso überschrieben. Der Aufwand ist also begrenzt und vor allem gut berechenbar.
Wir sprechen doch hier von extrem hohen Polygonzahlen ... wobei zunehmend der Fall eintritt, daß ein Dreieck (laut den rasterization rules) null Pixel groß ist. Diese kann der Chip sofort nach der Transformation wegschmeißen, genauso wie gecullte Dreiecke.

Weiterführende Schnapsideen:
Dreiecke, die nur in einer einzigen Kachel existieren, können schon vor der eigentlichen Sortierphase in den richtigen Tile Bin geschmissen werden, und nicht erst in eine Display List. Im Fall von 1-Pixel-Dreiecken ließe sich sogar eine automatische Ersetzung durchführen, wenn das Dreieck von einem weiteren 1-Pixel-Monster überschrieben wird, wodurch Geometrie wiederum eliminiert wird und den Bus nicht mehr verstopfen kann.
Dann noch ein paar große Caches (1T-SRAM?) anbauen und das Ding sollte rennen. *eg*

edit: Alle verbleibenden Klarheiten beseitigt

[Legolas]

Originally posted by Stefan Payne


Die TNT2 ist aber ein recht ineffizientes Design...

Der VSA-100 hatte schließlich nur 14MIO Transistoren und kann 'etwas' mehr als ein TNT kann...

Wobei der VSA-100 auch kein recht effizientes Design sein kann, weil er ja noch auf dem Voodoo Graphics basiert und dann mit neuen Features aufgepeppt wurde, die im Originaldesign eigentlich nicht vorgesehen waren. Insofern braucht er wohl mehr Transistoren, als ein Chip, der von Grund auf für die verwendeten Features ausgelegt ist.

[Demirug]

Eine der Grundideen ist doch, daß man pro Kachel nur eine begrenzte, überschaubare Pixelanzahl bearbeiten muß, die (FSAA und Blending erstmal außen vor) mit der Anzahl der zu rendernden Dreiecke in der Kachel schlimmstenfalls identisch ist.

Das kann irgenwie nicht ganz stimmen. Ich kann mir durchaus Fälle vorstellen in dehen mehr Dreiecksteile als Punkte in einer Kachel liegen. Einer der extremste Fälle wären lauter 1 Pixel Teile mit 8 fach overdraw.

Mehr Geometrie wird pro Kachel nicht dargestellt, sie würde sowieso überschrieben. Der Aufwand ist also begrenzt und vor allem gut berechenbar.

Nicht dargestellt ist vollkommen richtig. aber berechneen und überprüfen muß man sie trotzdem.

Wir sprechen doch hier von extrem hohen Polygonzahlen ... wobei zunehmend der Fall eintritt, daß ein Dreieck (laut den rasterization rules) null Pixel groß ist. Diese kann der Chip sofort nach der Transformation wegschmeißen, genauso wie gecullte Dreiecke.

Was ist für dich extrem hoch?. Die Dreiecke kann man wegschmeisen die Vertices braucht man aber unter umständen noch. Wenn die Daten als Stripe übertragen wurden ist das prüfen etwas komplizierter (>Chipfläche)

Weiterführende Schnapsideen:
Dreiecke, die nur in einer einzigen Kachel existieren, können schon vor der eigentlichen Sortierphase in den richtigen Tile Bin geschmissen werden, und nicht erst in eine Display List.

Wie die PowerVR Chips im Moment ihere Daten ablegen weis ausser ihnen anscheinend sowieso niemand.

Was die Performance angeht ist eine Display List sowieso nicht so optimal. Ich würde alle Dreicksteile direkt den Kachel über einen Index zuweisen.

Im Fall von 1-Pixel-Dreiecken ließe sich sogar eine automatische Ersetzung durchführen, wenn das Dreieck von einem weiteren 1-Pixel-Monster überschrieben wird, wodurch Geometrie wiederum eliminiert wird und den Bus nicht mehr verstopfen kann.

Dann brauchst du aber wieder einen Z-Buffer. Dieser müste dann bei überprüfen der Kacheln mit eingeladen und berücksichtigt werden.

Dann noch ein paar große Caches (1T-SRAM?) anbauen und das Ding sollte rennen. *eg*

Wenn noch genung Chipfläche verblieben ist macht das Sinn.

[Thowe]

Originally posted by Demirug
Entweder ist der Chip ungleichmässig ausgelasted (Vertex und Pixel einheit im Wechsel) oder es wird mehr Speicher gebraucht.


Ich denke da machst du den gleichen Denkfehler wie andere TBR-Kritiker auch. Du gehst davon aus, dass die Vertex-Einheit und die Pixel-Einheit in zukünftigen TBR genau so synchronisiert werden wie beim Kyro. Alles was man aber braucht um das effizienter zu lösen, ist eine dynamische Speicherverwaltung für die Polygon-Daten. Wie PowerVR das in Zukunft etwa machen wird, kannst du in folgenden Patent nachlesen. -> http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=/netahtml/PTO/srchnum.html&r=1&f=G&l=50&s1='20020039100'.PGNR.&OS=DN/20020039100&RS=DN/20020039100

Auf diese Weise können Vertex- und Pixel-Einheit immer überlappend arbeiten, nur wenn in einer Einheit die Last extrem hoch wird, muss die andere warten. Die Last in den Einheiten wird aber hier im Gegensatz zum IMR viel besser verteilt. Eine Folge von Polygon die eine hohe Last in den Pixel-Einheiten erzeugt kann oder wird beim IMR die Vertex-Einheiten zum "Stallen" bringen, wenn der Puffer dazwischen voll ist.

Zum Thema Pixelshader: Ich erwähnte ja bereits in einem anderen Thread, das der P10 in etwa so aussieht, wie ich es vom Kyro III erhofft hätte. Um soviele Recheneinheiten in den PixelShadern effizient auszunutzen, muss man vor allen Dingen, wenn die Polygone kleiner werden auch dafür sorgen können, das die PixelEinheiten an verschiedenen Polygonen gleichzeitig arbeiten können. Der P10 erreicht dies durch internes Tiling. Der Unterschied zu einen echten TBR ist mehr oder minder nur, dass die Vertex-Daten nicht zwischendurch in den Speicher geschrieben werden.

Alles im allem glaube ich, dass deine Thesen genau umgekehrt zutreffen, also das Pixel- und Vertex-Einheiten sich bei TBR viel effizienter ausnutzen lassen als beim IMR.

Zum Thema Chipfläche eines TBR: Laut PDF von ARM zum MBX hat dieser etwa 600.000 Gates und ist im Prinzip ein vollwertiger PowerVR 3 Chip, wie der Kyro.


EDIT: fehlende Worte ergänzt :D

[Demirug]

Ich denke da machst du den gleichen Denkfehler wie andere TBR-Kritiker auch. Du gehst davon aus, dass die Vertex-Einheit und die Pixel-Einheit in zukünftigen TBR genau so synchronisiert werden wie beim Kyro. Alles was man aber braucht um das effizienter zu lösen, ist eine dynamische Speicherverwaltung für die Polygon-Daten. Wie PowerVR das in Zukunft etwa machen wird, kannst du in folgenden Patent nachlesen. -> http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=/netahtml/PTO/srchnum.html&r=1&f=G&l=50&s1='20020039100'.PGNR.&OS=DN/20020039100&RS=DN/20020039100

Auf diese Weise können Vertex- und Pixel-Einheit immer überlappend arbeiten, nur wenn in einer Einheit die Last extrem hoch wird, muss die andere warten. Die Last in den Einheiten wird aber hier im Gegensatz zum IMR viel besser verteilt. Eine Folge von Polygon die eine hohe Last in den Pixel-Einheiten erzeugt kann oder wird auch die Vertex-Einheiten zum "Stallen" bringen, wenn der Puffer dazwischen voll ist.


Ich stehe dem IMR-Rendering genauso kritisch gegenüber wie dem TBR. Und wenn PowerVR mir einen Chip designet der mit den aktuellen IMR Chips mithalten kann und ich als Programmierer keinen unterschied merke finde ich das auch gut.

Danke für den Link auf das Patent. Werde es mir bei geglegenheit durchlesen da ich im Moment nicht in der Stimmung bin mich durch Patentenglisch durchzuarbeiten. Was in diesem Zusammenhang interesant ist auch NVidia hat ein Patent im Bereich TBR. Hab die Nummer gerade aber nicht zu Hand.

Meine Aussage sollte in diesem Fall auch keinen Vergleich zum IMR darstellen. Es ging mir eher um die 2 primären Möglichkeiten einen TBR Chip zu betreiben.


Möglichkeit 1:
VertextEinheit PixelEinheit
Frame1
Frame1
Frame2
Frame2
...



Möglichkeit 2:
Frame1
Frame2 Frame1
Frame3 Frame2
...


Was anders als den zweiten weg zu gehen wäre Blödsinn. Die Vertexeinheit müsste dann entweder doppelt so gross sein oder die doppelte Taktrate wie die der Mitbewerber haben. Den Preis den man dafür zahlt ist das Immer die Polydaten für 2 Frames im Speicher liegen. Die Frage die sich dabei stellt ist wieviel Platz brauchen die Polydaten eines Frames bei einem zukünfitigen Spiel nach dem Tilen? Die PowerVR Jungs habe da aber durchaus Erfahrung diese Kompackt abzulegen. Desweiteren spart man ja den Z-Buffer und die AA-Sample Buffer ein. Müsste man mal nachrechnen.

Mit dem Stallen hat du vollkommen recht. Da die Vertex und Pixel Einheit lose gekoppelt sind müsste man als Programmierer nur noch darauf achten das der gesamte Vertexaufwand mit dem Pixelaufwand für einen Frame möglichst gleich ist. Beim IMR muss man das für jedes Poly tuhen was unmöglich ist. Eindeutig ein Punkt fürs TBR.

Einen Punkt im Bezug auf das Stallen hast du sogar noch vergessen. Da ich deinen persönlichen technischen hintergrund nicht kenne ist es natürlcih möglich das dir diese Problem aktueller IMR gar nicht bekannt ist.

Alle im moment verkauften IMR-Chips haben ein für uns Programmier sehr ärgerliches Problem. Werden mehrer Polys mit den gleichen Rendereinstellungen (Texturen, Blending, usw.) an den Treiber übergegebn werden diese in eine Pipeline gesetzt. Will ich jetzt aber eine Einstellung ändern fürt das unweigerlich zu einem Stallen im Treiber bis die Pipeline gelehrt ist. Das ist sehr bescheiden und IMO ein desginfehler der aktuellen IMR-Chips der zu lösen wäre.

Auch hier hätte der TBR einen vorteil da er Renderstate wechsel auf der Texelebene nur zur Kenntniss nimmt und für die Pixeleinheit wegspeichert. Bei den Renderstates auf Vertexebene könnte er natürlich die gleichen Probleme haben. Da Texelstates aber häufiger geändert werden müssen hat das TBR auch hier wahrscheinlich einen Vorteil.


Zum Thema Pixelshader: Ich erwähnte ja bereits in einen anderen Thread, das der P10 in etwa so aussieht, wie ich es vom Kyro III erhofft hätte. Um soviele Recheneinheiten in den PixelShadern effizient auszunutzen, muss man vor allen Dingen, wenn die Polygone kleiner werden auch dafür sorgen können, das die PixelEinheiten an verschiedenen Polygonen gleichzeitig arbeiten können. Der P10 erreicht dies durch internes Tiling. Der Unterschied zu einen echten TBR ist mehr oder minder nur, dass die Vertex-Daten nicht zwischendurch in den Speicher geschrieben werden.

Alles im allem glaube ich, dass deine Thesen genau umgekehrt zutreffen, also das Pixel- und Vertex-Einheiten sich bei TBR viel effizienter ausnutzen lassen als beim IMR.


Der P10 ist aber ein IMR und kann daher eigentlich kan nicht an meheren Polys gleichzeitig arbeiten. Meiner Meinung nach ist der Tiler eher dazu da die jedes einzelen Dreiecke möglichst geschickt zu zerlegen und auf die 4 Parralelen Texelpfade zu verteilen. Was mich dabei nur etwas wundert ist die Tatsache das die Visibletest einheit nich ebenfalls mehrfach ausgelegt wurde. Ich könnte aber auch total falsch liegen aber bei den alten 3dlabs lösungen war es die aufgabe des Tilers die Daten auf mehrer nachgeschaltet Chips zu verteilen.

Was aber nun die Architexture eines TBR Chips mit Pixelshader angeht so würde ich in der Pixeleinheit ebenfals auf eine lose Kopplung setzten. Eine Einheit bestimmt welcher Pixelshader (oder mehrer beim Alphablending) an welchem Punkt zum Einsatz kommt und übergibt dann dieses Datenpacket an die pixelshader einheit während sie selbst schon die nächste Tile durchrechnet. Mit dieser Lösung wäre es möglich die Einzelnen Pixel in der Tile nicht in der Rheienfolge wie sie im Speicher liegen zu berechnen sonderen die Berechnung in Abhängkeit der verwendeten Pixelshader durchzuführen. Dadurch könnten die aufwendigen Setups der Pixelshader minimiert werden. Auch das Alphablending wäre biliger zu bekommen. Wenn man dann diese beiden Einheiten auch noch mehrfach zur verfügung hätte (was bei den großen Auflösungen die man fürs AA intern rechnen muß Sinn macht) könnte man diese frei miteinander verschalten (Jeder Vorrechner darf jede Pixelshadereinheit benutzen die Frei ist) und die Gefahr des Stalles weiter verrinngern.

Als letze Einheit dann noch eine AA einheit dahinter und dann einen Store auf den Speicher. Aufgrund der Datenanordnung müsste man da gut den Burst nutzen können.


Zum Thema Chipfläche eines TBR: Laut PDF von ARM zum MBX hat dieser etwa 600.000 Transistoren und ist im Prinzip ein vollwertiger PowerVR 3 Chip, wie der Kyro.


Jetzt hat du aber extra den kleinsten genommen oder?:D

Ich persönlich finden dem MBX ganz tool. Man stelle sich ein Handy mit mehr 3D Power als eine PSOne vor.

Es ist aber nicht ganz einfach von diesem Chip rückschlüsse auf den PC Chip zu ziehen. Es fehlen einfach zu viele Teile und aufgrund der gringen RAM Menge wird er auch ein kleineres Memoryinterface brauchen.

Aber selbst wenn er größer wird ist würde das ja nur zum Problem wenn die 40W dann nicht mehr reichen oder die Mehrkosten für den Chip durch langsammer rams nicht mehr abgefangen werden können.

Meinen andere Kritikpunkt der ja zu dieser ganze Diskussion geführt hat das TBR mit den immer kleiner werdenden Dreiecken ineffiziernter wird werden ich im Grundsatz aber aufrecht erhalten. Dennoch werde ich ihn etwas abmildern da man wie NVidia ja sagt in Zukunft ja mehr wert auf die Pixelqualität legen wird ergibt sich für mich daraus der verstärkte Einsatz von AA. Durch AA werden die Dreiecke ja wieder in ihere größe aufgeblassen was dem TBR im Vergleich zum IMR zu gute kommt.

Für Matrox wäre ein TBR trotzdem wahrscheinlich keine gute wahl gewessen. Das Risiko wäre zu hoch ein IMR ist halt einfacher zu bauen. Desweiteren sind TBR Chips aus Marketing Sicht echt schlecht. Man kann einfach nicht so gut mit großen Zahlen aufwarten (Speichertakt und bandbreite, AA-Samples, usw)

Und wie bereits gesagt wenn ich einen konkurenzfähigen Karte zu einem Vernüpftigen Preis bekomme kaufe ich mir die auch. Aber es ist ja sehr still geworden um PowerVR im PC-Chip bereich.

[Thowe]

Originally posted by Demirug
Meine Aussage sollte in diesem Fall auch keinen Vergleich zum IMR darstellen. Es ging mir eher um die 2 primären Möglichkeiten einen TBR Chip zu betreiben.


Möglichkeit 1:
VertextEinheit PixelEinheit
Frame1
Frame1
Frame2
Frame2
...



Möglichkeit 2:
Frame1
Frame2 Frame1
Frame3 Frame2
...


Was anders als den zweiten weg zu gehen wäre Blödsinn. Die Vertexeinheit müsste dann entweder doppelt so gross sein oder die doppelte Taktrate wie die der Mitbewerber haben. Den Preis den man dafür zahlt ist das Immer die Polydaten für 2 Frames im Speicher liegen. Die Frage die sich dabei stellt ist wieviel Platz brauchen die Polydaten eines Frames bei einem zukünfitigen Spiel nach dem Tilen? Die PowerVR Jungs habe da aber durchaus Erfahrung diese Kompackt abzulegen. Desweiteren spart man ja den Z-Buffer und die AA-Sample Buffer ein. Müsste man mal nachrechnen.

Nein, was das Patent aussagt ist im Prinzip, dass sie das Frame in s.g. Macro-Tiles zerlegen, alle Polygondaten so abspeichern, dass sie nach dem Rendern des Macro-Tiles wieder freigegeben werden können. Falls also der Szenenbuffer einmal zu voll wird, braucht man nicht gleich das ganze Bild zu rendern, sondern nimmt erst einmal das Macro-Tile mit den meisten Polygonen, rendert dies, speichert den Zustand der Pixeleinheit (komprimiert) und gibt den Speicher frei. Ich schätze, dass dies sehr effizient ist, da Polygondaten wahrscheinlich nacheinander gehäuft an verschiedenen Stellen des Bildes "anfallen".


Mit dem Stallen hat du vollkommen recht. Da die Vertex und Pixel Einheit lose gekoppelt sind müsste man als Programmierer nur noch darauf achten das der gesamte Vertexaufwand mit dem Pixelaufwand für einen Frame möglichst gleich ist. Beim IMR muss man das für jedes Poly tuhen was unmöglich ist. Eindeutig ein Punkt fürs TBR.

Einen Punkt im Bezug auf das Stallen hast du sogar noch vergessen. Da ich deinen persönlichen technischen hintergrund nicht kenne ist es natürlcih möglich das dir diese Problem aktueller IMR gar nicht bekannt ist.

Genau, meins sollte auch nur ein Beispiel sein. :)


Alle im moment verkauften IMR-Chips haben ein für uns Programmier sehr ärgerliches Problem. Werden mehrer Polys mit den gleichen Rendereinstellungen (Texturen, Blending, usw.) an den Treiber übergegebn werden diese in eine Pipeline gesetzt. Will ich jetzt aber eine Einstellung ändern fürt das unweigerlich zu einem Stallen im Treiber bis die Pipeline gelehrt ist. Das ist sehr bescheiden und IMO ein desginfehler der aktuellen IMR-Chips der zu lösen wäre.

Auch hier hätte der TBR einen vorteil da er Renderstate wechsel auf der Texelebene nur zur Kenntniss nimmt und für die Pixeleinheit wegspeichert. Bei den Renderstates auf Vertexebene könnte er natürlich die gleichen Probleme haben. Da Texelstates aber häufiger geändert werden müssen hat das TBR auch hier wahrscheinlich einen Vorteil.

Ein TBR wird wahrscheinlich immer unproblematischer mit State-Changes umgegehen, denke ich zumindest da er dahingehend so designt sein muss das er diese verkraftet.


Der P10 ist aber ein IMR und kann daher eigentlich kan nicht an meheren Polys gleichzeitig arbeiten. Meiner Meinung nach ist der Tiler eher dazu da die jedes einzelen Dreiecke möglichst geschickt zu zerlegen und auf die 4 Parralelen Texelpfade zu verteilen.

Meinen wir da nicht das gleiche?


Was mich dabei nur etwas wundert ist die Tatsache das die Visibletest einheit nich ebenfalls mehrfach ausgelegt wurde.

Ich denke das gemeint ist, das die Visibletest-Einheit für 1 Polygon ausgelegt ist. Mehr braucht man nicht, da man wohl davon ausgehen kann, dass dort nicht mehr als 1 Polygon pro Takt anfällt.


Ich könnte aber auch total falsch liegen aber bei den alten 3dlabs lösungen war es die aufgabe des Tilers die Daten auf mehrer nachgeschaltet Chips zu verteilen.

Frage: Wie willst du 64 Recheneinheiten sonnst effizient mit Pixeldaten aus 1-2 Pixel grossen Polygonen füllen.


Was aber nun die Architexture eines TBR Chips mit Pixelshader angeht so würde ich in der Pixeleinheit ebenfals auf eine lose Kopplung setzten. Eine Einheit bestimmt welcher Pixelshader (oder mehrer beim Alphablending) an welchem Punkt zum Einsatz kommt und übergibt dann dieses Datenpacket an die pixelshader einheit während sie selbst schon die nächste Tile durchrechnet. Mit dieser Lösung wäre es möglich die Einzelnen Pixel in der Tile nicht in der Rheienfolge wie sie im Speicher liegen zu berechnen sonderen die Berechnung in Abhängkeit der verwendeten Pixelshader durchzuführen. Dadurch könnten die aufwendigen Setups der Pixelshader minimiert werden. Auch das Alphablending wäre biliger zu bekommen. Wenn man dann diese beiden Einheiten auch noch mehrfach zur verfügung hätte (was bei den großen Auflösungen die man fürs AA intern rechnen muß Sinn macht) könnte man diese frei miteinander verschalten (Jeder Vorrechner darf jede Pixelshadereinheit benutzen die Frei ist) und die Gefahr des Stalles weiter verrinngern.

Als letze Einheit dann noch eine AA einheit dahinter und dann einen Store auf den Speicher. Aufgrund der Datenanordnung müsste man da gut den Burst nutzen können.

Das Design heutiger Pixelshader erfordert doch, das jede Stage alle möglichen Operationen ausführen können müssen. Bei den 5 Stages des Matrox-Parhelia und den 4 Pipelines ist also alles 20x vorhanden. Glaubts du, dass das ein effizientes Design ist? Wenn in Zukunft in den Pixelshadern alles mit Floating Point Genauigkeit berechnet wird und diese noch mehr Operationen beherrschen, ganz bestimmt nicht mehr. Ich denke das wird sich eher in Richtung "MultiThreaded PixelShader-Core" entwickeln, genau wie beim Metagance DSP (von ImgTec, PowerVR). Aber wohl (leider) noch nicht beim nächsten Kyro.


Jetzt hat du aber extra den kleinsten genommen oder?:D

Nööööö, ok ok, gebe es zu, ja. :)


Ich persönlich finden dem MBX ganz tool. Man stelle sich ein Handy mit mehr 3D Power als eine PSOne vor.

Etwa 10x soviel Polygon-Leistung und höhere Rechengenauigkeit, bessere Texturfilter, FSAA4free usw. *schmacht*


Es ist aber nicht ganz einfach von diesem Chip rückschlüsse auf den PC Chip zu ziehen. Es fehlen einfach zu viele Teile und aufgrund der gringen RAM Menge wird er auch ein kleineres Memoryinterface brauchen.

Aber selbst wenn er größer wird ist würde das ja nur zum Problem wenn die 40W dann nicht mehr reichen oder die Mehrkosten für den Chip durch langsammer rams nicht mehr abgefangen werden können.

Aber es lassen sich gewisse Rückschlüsse ziehen. :)

Meinen andere Kritikpunkt der ja zu dieser ganze Diskussion geführt hat das TBR mit den immer kleiner werdenden Dreiecken ineffiziernter wird werden ich im Grundsatz aber aufrecht erhalten. Dennoch werde ich ihn etwas abmildern da man wie NVidia ja sagt in Zukunft ja mehr wert auf die Pixelqualität legen wird ergibt sich für mich daraus der verstärkte Einsatz von AA. Durch AA werden die Dreiecke ja wieder in ihere größe aufgeblassen was dem TBR im Vergleich zum IMR zu gute kommt.

Faktisch geht es doch nur darum, den VertexShader-Output im Speicher abzulegen. Ich denke der dabei anfallende maximale Datendurchsatz lässt sich ziemlich genau nach oben abschätzen und ist (vielleicht) gar nicht so hoch wie viele denken. Immerhin kann eine VertexShader-Einheit nicht mehr als 4 Floats pro Takt produzieren. In der Praxis wird der Wert deutlich darunter liegen, denn es werden ja nicht nur Werte durchgereicht, sondern ja auch etwas berechnet. Rechnet man das auf heute übliche Bandbreiten um, benötigt das nur einen relativ geringen prozentualen Anteil der Bandbreite.


Und wie bereits gesagt wenn ich einen konkurenzfähigen Karte zu einem Vernüpftigen Preis bekomme kaufe ich mir die auch. Aber es ist ja sehr still geworden um PowerVR im PC-Chip bereich.

Leider, aber das war bei Matrox ja auch so. Bei nVidia nach den nv1 auch und todgesagte leben ja bekanntlich länger. :)

[Demirug]

Nein, was das Patent aussagt ist im Prinzip, dass sie das Frame in s.g. Macro-Tiles zerlegen, alle Polygondaten so abspeichern, dass sie nach dem Rendern des Macro-Tiles wieder freigegeben werden können. Falls also der Szenenbuffer einmal zu voll wird, braucht man nicht gleich das ganze Bild zu rendern, sondern nimmt erst einmal das Macro-Tile mit den meisten Polygonen, rendert dies, speichert den Zustand der Pixeleinheit (komprimiert) und gibt den Speicher frei. Ich schätze, dass dies sehr effizient ist, da Polygondaten wahrscheinlich nacheinander gehäuft an verschiedenen Stellen des Bildes "anfallen".


Ok das ist eine optimierung meiner Idee die Grundsatz aber stimmt. Im worst Case fall muss man aber trotzdem damit rechnen das 2 Frames komplett im Speicher liegen müssen. In der Praxsis dürfte der Wert aber wahrscheinlich < 1.5 Framedaten sein.


Ein TBR wird wahrscheinlich immer unproblematischer mit State-Changes umgegehen, denke ich zumindest da er dahingehend so designt sein muss das er diese verkraftet.


Wie gesagt bei den Vertexstates habe ich da so meine Zweifel. Als mir das zum ersten mal aufgefallen ist (GF1) konnte ich es erst nich glauben und bis heute hat sich da scheinbar leider nichts geändert.


Meinen wir da nicht das gleiche?

Ich denke das gemeint ist, das die Visibletest-Einheit für 1 Polygon ausgelegt ist. Mehr braucht man nicht, da man wohl davon ausgehen kann, dass dort nicht mehr als 1 Polygon pro Takt anfällt.

Frage: Wie willst du 64 Recheneinheiten sonnst effizient mit Pixeldaten aus 1-2 Pixel grossen Polygonen füllen.


Diese Minidreicke sind beim IMR immer ein problem. Da ich mir jetzt nicht sicher bin ob sie die Einheiten beim P10 zu einer Pipeline verschalten lassen muß ich dir hier eine Antwort erst mal schuldig bleiben.


Das Design heutiger Pixelshader erfordert doch, das jede Stage alle möglichen Operationen ausführen können müssen. Bei den 5 Stages des Matrox-Parhelia und den 4 Pipelines ist also alles 20x vorhanden. Glaubts du, dass das ein effizientes Design ist? Wenn in Zukunft in den Pixelshadern alles mit Floating Point Genauigkeit berechnet wird und diese noch mehr Operationen beherrschen, ganz bestimmt nicht mehr. Ich denke das wird sich eher in Richtung "MultiThreaded PixelShader-Core" entwickeln, genau wie beim Metagance DSP (von ImgTec, PowerVR). Aber wohl (leider) noch nicht beim nächsten Kyro.


Bei den PS2.0 müssen die sich echt was einfallen lassen ich hoffe auf den Blockbildern wird man sehen wie sie die Probleme lösen. Was mir gar nicht gefallen würde ware wenn dort dann einfach nur noch ein Block mit dem text PS2.0 zu sehen ist.


Aber es lassen sich gewisse Rückschlüsse ziehen. :)


Sicher man müsste halt mal ein komentiertest DIE Photo nehmen und aufgrund der Fläche nachrechnen was die einzelnen Teile (AGB, Memory, VS, PS) im Moment so an transitoren brauchen.


Faktisch geht es doch nur darum, den VertexShader-Output im Speicher abzulegen. Ich denke der dabei anfallende maximale Datendurchsatz lässt sich ziemlich genau nach oben abschätzen und ist (vielleicht) gar nicht so hoch wie viele denken. Immerhin kann eine VertexShader-Einheit nicht mehr als 4 Floats pro Takt produzieren. In der Praxis wird der Wert deutlich darunter liegen, denn es werden ja nicht nur Werte durchgereicht, sondern ja auch etwas berechnet. Rechnet man das auf heute übliche Bandbreiten um, benötigt das nur einen relativ geringen prozentualen Anteil der Bandbreite.


Hier hast du zwei kleine Denkfehler gemacht.

1. Der Vertexshader muss nicht zwangsläufig bei jedem Takt einen Vertexdatensatz liefern. Bei Aufwendigen Programmen kann das auch länger dauern. Deswegen gibt es ja einen Cache für transformierte Vertexdaten.

2. Der Vertexdatensatz ist größer als 4 Floats, Neben der Position kommen noch Farbwerte, Nebel, Pixelsize, Texturepositionen und zwar alles als Floats.

Leider, aber das war bei Matrox ja auch so. Bei nVidia nach den nv1 auch und todgesagte leben ja bekanntlich länger. :)

Nur ist die Situation bei PowerVR eben ein wening komplizierter. Die müssen in der Regel jemanden finden der die Chips produzieren will und dieser muss dann jemanden finden der die Karten baut. Vielleicht wird es ja was mit VIA.

[Thowe]

Originally posted by Demirug


Ok das ist eine optimierung meiner Idee die Grundsatz aber stimmt. Im worst Case fall muss man aber trotzdem damit rechnen das 2 Frames komplett im Speicher liegen müssen. In der Praxsis dürfte der Wert aber wahrscheinlich < 1.5 Framedaten sein.

Nein, es liegen ganz genau maximal soviele Daten im Speicher, wie der Puffer gross ist. Ein Macro-Tile kann durchaus aus dem selben Frame stammen an dem der Vertex-Prozessor gerade arbeitet. Für den Vertex-Prozessor wird dann einfach ein neuer Speicherblock alloziiert, falls noch weitere Vertex-Daten anfallen. Die schon vorhandenen Daten werden vom Pixel-Prozessor gerendert und danach der Zustand gespeichert. Im Prinzip hast du also folgenden Ablauf:


Möglichkeit 3:
Frame1
Frame2 Frame1
Frame3 Frame2
Frame3 Frame3
Frame4 Frame3
Frame4 Frame4
Frame5 Frame4
Frame6 Frame5
...



In der Phase wo besonders viele Polygondaten auftreten, arbeiten Pixel- und Vertex-Prozessor also überlappend am selben Frame.


Diese Minidreicke sind beim IMR immer ein problem. Da ich mir jetzt nicht sicher bin ob sie die Einheiten beim P10 zu einer Pipeline verschalten lassen muß ich dir hier eine Antwort erst mal schuldig bleiben.

Die Antwort ist uns ja 3DLabs noch schuldig, ich denke aber das man diese beliebig einer Instruktion zuordnen kann.


Sicher man müsste halt mal ein komentiertest DIE Photo nehmen und aufgrund der Fläche nachrechnen was die einzelnen Teile (AGB, Memory, VS, PS) im Moment so an transitoren brauchen.

Naja, wenn diese dann nicht auch nur eine schematische Darstellung sind. Auf echten DIEs kann man IMHO eher nicht die einzelnen Einheiten unterscheiden.



Hier hast du zwei kleine Denkfehler gemacht.

1. Der Vertexshader muss nicht zwangsläufig bei jedem Takt einen Vertexdatensatz liefern. Bei Aufwendigen Programmen kann das auch länger dauern. Deswegen gibt es ja einen Cache für transformierte Vertexdaten.

2. Der Vertexdatensatz ist größer als 4 Floats, Neben der Position kommen noch Farbwerte, Nebel, Pixelsize, Texturepositionen und zwar alles als Floats.

Genau: Das sage ich doch auch, man kann den Maximaldurchsatz einer VertexShader-Einheit mit 4 Floats pro Takt nach oben abschätzen. Bei n Vertex-Einheiten ist er halt n-mal so gross. In der Praxis deutlich geringer, z.B. bei 4 Einheiten 64 Bytes. Das ist dann eine obere Grenze die immer gilt. Man muss dann nur noch die Speicherbandbreite und den Vertexdurchsatz so aufeinander abstimmen, das sich ein ausgewogenes Verhältnis ergibt. 64 Bytes pro Takt lassen sich bei einem 128Bit DDR-Bus noch in einem Takt schreiben. Also sehe ich hier kein Problem. Falls mehr Daten wie Texturekordinaten, Fog-Farbe oder sonstiges mit dem Vertexshader produzierst, wird er auch automatisch mehr Taktzyklen brauchen. Irgendwie balanciert sich das Ganze damit selber aus.


Nur ist die Situation bei PowerVR eben ein wening komplizierter. Die müssen in der Regel jemanden finden der die Chips produzieren will und dieser muss dann jemanden finden der die Karten baut. Vielleicht wird es ja was mit VIA.

Oder sie machen es endlich alles selbst, denke wäre die beste und sinnigste Lösung. Diese Abhängigkeiten über mehere Stationen sind meines Erachtens einfach ungesund.

[Demirug]

Nein, es liegen ganz genau maximal soviele Daten im Speicher, wie der Puffer gross ist. Ein Macro-Tile kann durchaus aus dem selben Frame stammen an dem der Vertex-Prozessor gerade arbeitet. Für den Vertex-Prozessor wird dann einfach ein neuer Speicherblock alloziiert, falls noch weitere Vertex-Daten anfallen. Die schon vorhandenen Daten werden vom Pixel-Prozessor gerendert und danach der Zustand gespeichert. Im Prinzip hast du also folgenden Ablauf:


Möglichkeit 3:
Frame1
Frame2 Frame1
Frame3 Frame2
Frame3 Frame3
Frame4 Frame3
Frame4 Frame4
Frame5 Frame4
Frame6 Frame5
...


In der Phase wo besonders viele Polygondaten auftreten, arbeiten Pixel- und Vertex-Prozessor also überlappend am selben Frame.


Ok werde mir das Patent wohl doch mal zu gemüte führen. Versteh nähmlich gerade nicht wie man bei dieser vorgehensweise ohne Z-Buffer auskommen soll.


Die Antwort ist uns ja 3DLabs noch schuldig, ich denke aber das man diese beliebig einer Instruktion zuordnen kann.


Ja das die Einheiten beliebige Instruktionen ausführen können ist schwer zu vermuten. Ob man die Einheiten zu einer Pipe ala DX PS zusammenschalten kann ist aber eine der grossen unbekannten.



Naja, wenn diese dann nicht auch nur eine schematische Darstellung sind. Auf echten DIEs kann man IMHO eher nicht die einzelnen Einheiten unterscheiden.


Warum nicht? Ich habe mal ein Bild von einem NVidia Chip gesehen auf dem die einzelnen Bereiche mit linien voneinader abgerenzt waren. Von CPUs gibts sowas ja auch.


Genau: Das sage ich doch auch, man kann den Maximaldurchsatz einer VertexShader-Einheit mit 4 Floats pro Takt nach oben abschätzen. Bei n Vertex-Einheiten ist er halt n-mal so gross. In der Praxis deutlich geringer, z.B. bei 4 Einheiten 64 Bytes. Das ist dann eine obere Grenze die immer gilt. Man muss dann nur noch die Speicherbandbreite und den Vertexdurchsatz so aufeinander abstimmen, das sich ein ausgewogenes Verhältnis ergibt. 64 Bytes pro Takt lassen sich bei einem 128Bit DDR-Bus noch in einem Takt schreiben. Also sehe ich hier kein Problem. Falls mehr Daten wie Texturekordinaten, Fog-Farbe oder sonstiges mit dem Vertexshader produzierst, wird er auch automatisch mehr Taktzyklen brauchen. Irgendwie balanciert sich das Ganze damit selber aus.


Jetzt verstehe ich deinen rechenansatz. Klar so kann man das auch ausrechnen. Was man allerding auf jeden Fall nicht vergessen darf ist mindestens die doppelete Bandbreite dafür zu veranschlagen da ja später alles wieder eingelesen werden muß.

Oder sie machen es endlich alles selbst, denke wäre die beste und sinnigste Lösung. Diese Abhängigkeiten über mehere Stationen sind meines Erachtens einfach ungesund.

Klar. Das problem ist nur das man dafür Geld braucht und das Risiko steigt. Die Frage ist halt ob der höhere mögliche Gewinn das Risiko rechtfertig. Wenn das zu wenige Leute glauben bekommt man das Geld eben nicht.

[zeckensack]

Ui, hätte den Thread doch etwas besser im Auge behalten sollen =)
Originally posted by Demirug
Wir sprechen doch hier von extrem hohen Polygonzahlen ... wobei zunehmend der Fall eintritt, daß ein Dreieck (laut den rasterization rules) null Pixel groß ist. Diese kann der Chip sofort nach der Transformation wegschmeißen, genauso wie gecullte Dreiecke.

Was ist für dich extrem hoch?. Die Dreiecke kann man wegschmeisen die Vertices braucht man aber unter umständen noch. Wenn die Daten als Stripe übertragen wurden ist das prüfen etwas komplizierter (>Chipfläche)Tristrips funktionieren anscheinend auch nur mit drei internen Vertex-Registern, die lediglich vertauscht addressiert werden. Es gibt durchaus Indizien dafür, daß die modernen Chips intern Strips und Triangle Soups nicht unterschiedlich verarbeiten.
(zB ist die Geforce 4Ti durch ihr Tri-Setup limitiert, deswegen erreicht man mit Soups einen höheren Poly-Durchsatz als mit Strips (http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/005940.html))

Das Dreieck kann man also doch wegschmeißen, die zwei aktuellsten Vertices fließen zwar ins nächste Dreieck ein, müssen aber nirgends abgelegt werden.

(PS: mit Triangle Soup meine ich nichts anderes, als massenhaft 'einzelne' Dreiecke)

[Thowe]

Originally posted by Demirug
Ok werde mir das Patent wohl doch mal zu gemüte führen. Versteh nähmlich gerade nicht wie man bei dieser vorgehensweise ohne Z-Buffer auskommen soll.

Man kommt auch nicht ohne zBuffer aus, dieser wird aber nicht zwingend für den ganzen Bildschirmbereich gebraucht und könnte auch dynamisch alloziiert werden.



Ja das die Einheiten beliebige Instruktionen ausführen können ist schwer zu vermuten. Ob man die Einheiten zu einer Pipe ala DX PS zusammenschalten kann ist aber eine der grossen unbekannten.

Ist das nicht egal? Die können doch einfach so genutzt werden, das die maximal mögliche Zahl parallel ausführbarer Instruktionen auch parallel ausgeführt werden.


Warum nicht? Ich habe mal ein Bild von einem NVidia Chip gesehen auf dem die einzelnen Bereiche mit linien voneinader abgerenzt waren. Von CPUs gibts sowas ja auch.

Ach, das sind nur Linien die wahrscheinlich nichts mit den wirklichen Einheiten zu tun haben. :) Teilweise schreiben sie ja sogar symbolische Darstellung drunter.


Jetzt verstehe ich deinen rechenansatz. Klar so kann man das auch ausrechnen. Was man allerding auf jeden Fall nicht vergessen darf ist mindestens die doppelete Bandbreite dafür zu veranschlagen da ja später alles wieder eingelesen werden muß.

Nicht alles. Was gecullt oder geclipt wird, muss weder geschrieben noch später wieder gelesen werden. Letztendlich denke ich, das 128 Bit DDR auch für 4 Vertexshader reichen würde.



Klar. Das problem ist nur das man dafür Geld braucht und das Risiko steigt. Die Frage ist halt ob der höhere mögliche Gewinn das Risiko rechtfertig. Wenn das zu wenige Leute glauben bekommt man das Geld eben nicht.

Leider.

[Demirug]

Man kommt auch nicht ohne zBuffer aus, dieser wird aber nicht zwingend für den ganzen Bildschirmbereich gebraucht und könnte auch dynamisch alloziiert werden.


... und auch noch im Burst lesen und schreiben was der Performance ja auch gut bekommt


Ist das nicht egal? Die können doch einfach so genutzt werden, das die maximal mögliche Zahl parallel ausführbarer Instruktionen auch parallel ausgeführt werden.


Im Prinzip ist es wirklich egal. 3dlabs oder wer auch immer muss halt nur einen Treiber schrieben der aufgrund eines DX Pixelshader programms diese Einheiten bestmöglichst ausnutzt.


Ach, das sind nur Linien die wahrscheinlich nichts mit den wirklichen Einheiten zu tun haben. :) Teilweise schreiben sie ja sogar symbolische Darstellung drunter.


Würde ich so nicht unbedient sagen. Was Logisch zusammen gehört wird von den Chip-Compiler auch räumlich zusammengelegt. Und die Stelle an der Cache dranstand war definitive Cache-Speicher.


Nicht alles. Was gecullt oder geclipt wird, muss weder geschrieben noch später wieder gelesen werden. Letztendlich denke ich, das 128 Bit DDR auch für 4 Vertexshader reichen würde.


Zumindestens bis der Bandbreitenhunger der Spiele nicht noch größer wird. Nur dann müssen die IMR auf 1024 bit oder qdr umsteigen:D.

[Thowe]

Originally posted by Demirug
... und auch noch im Burst lesen und schreiben was der Performance ja auch gut bekommt

Genau, und man kann auch die Daten auch besser komprimieren. In den Patent steht etwas von bis zu 128 fach.


Würde ich so nicht unbedient sagen. Was Logisch zusammen gehört wird von den Chip-Compiler auch räumlich zusammengelegt. Und die Stelle an der Cache dranstand war definitive Cache-Speicher.

Was machst du wenn das Wort "Cache" nicht mehr in dein Rechteck passt? Den Cache vergrössern oder das Rechteck. :)


Zumindestens bis der Bandbreitenhunger der Spiele nicht noch größer wird. Nur dann müssen die IMR auf 1024 bit oder qdr umsteigen:D.

Eine Andeutung auf deine Game-Engine ??? :D

[Demirug]

Tristrips funktionieren anscheinend auch nur mit drei internen Vertex-Registern, die lediglich vertauscht addressiert werden. Es gibt durchaus Indizien dafür, daß die modernen Chips intern Strips und Triangle Soups nicht unterschiedlich verarbeiten.
(zB ist die Geforce 4Ti durch ihr Tri-Setup limitiert, deswegen erreicht man mit Soups einen höheren Poly-Durchsatz als mit Strips (http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/005940.html))


Das hängt wohl ein bischen damit zusammen wo der flaschen hals jeweils genau ist. Wobei man Stripes ja gerne benutzt um bandbreite zu sparen. Ich muss aber zugeben das Stripes nicht unbedingt das beste Beispiel waren. Das Problem ist bei Indizierten Polys wesentlich stärker. Aber mir ist dazu in der Zwischenzeit auch schon eine Lösung eingefallen weswegen wir diese Punkt eigentlich abhacken könnten


Das Dreieck kann man also doch wegschmeißen, die zwei aktuellsten Vertices fließen zwar ins nächste Dreieck ein, müssen aber nirgends abgelegt werden.


Ablegen muß man sie schon und zwar für das nächste Dreieck wenn diese nicht ebenfalls entfernt wird. Mir ging es darum das man Vertexdaten die mehrfach benutzt werden (was ja heute sehr häufig vorkommt) nur einmal im Speicher zwischenspeichert. Bandbreite sparen so gut es eben geht.

[Demirug]

Genau, und man kann auch die Daten auch besser komprimieren. In den Patent steht etwas von bis zu 128 fach.


Ja in diesem Fall sollte das sehr gut gehen. Zum einen ligen die Z-Buffer werte innerhalb einer Tile meistens dich zusammen und zum anderen braucht man ja keine compression mit wahlfreiem Zugriff wie beim IMR.



Was machst du wenn das Wort "Cache" nicht mehr in dein Rechteck passt? Den Cache vergrössern oder das Rechteck. :)


Das Wort kleiner schreiben.:D


Eine Andeutung auf deine Game-Engine ??? :D


Ich bin nicht Carmark. Ich brauche keine 11 Texturen mit Fliesspunkt genauigkeit pro Pixel.

[Thowe]

Originally posted by Demirug
Das Wort kleiner schreiben.:D

Aber dann kann es ja keiner mehr lesen ??? Näää, lassen wir das, man sollte aber wirklich nicht allzuviel auf die Rechtecke geben.


Ich bin nicht Carmark. Ich brauche keine 11 Texturen mit Fliesspunkt genauigkeit pro Pixel.

Nicht? Oh, was brauchst du denn so. :D

[-|NKA|- Bibo1]

Macht weiter , das ist echt interessant :D

auch wenn ich noch nicht mal die hälfte verstehe.... ;)

[Leonidas]

Originally posted by Demirug


Oder bin ich als neuer hier jetzt zu extrem für das Forum?



Auf keinen Fall. Hochinteressante Materie.

[Xmas]

Originally posted by zeckensack
(zB ist die Geforce 4Ti durch ihr Tri-Setup limitiert, deswegen erreicht man mit Soups einen höheren Poly-Durchsatz als mit Strips (http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/005940.html))
Öhm, Tippfehler? ;)

[zeckensack]

Originally posted by Xmas

Öhm, Tippfehler? ;) Hmmm ...
Die Nummer mit dem Tri-Setup stimmt. Am Ende wird's aber falsch. Es hätte entweder
"deswegen erreicht man mit Soups einen höheren Vertex-Durchsatz als mit Strips" oder besser gleich
"deswegen erreicht man mit Soups den gleichen Poly-Durchsatz wie mit Strips" heißen müssen ;)

Oder ging's jetzt um die Unterscheidung von Dreiecken und Polys ???

[Xmas]

Originally posted by zeckensack
Hmmm ...
Die Nummer mit dem Tri-Setup stimmt. Am Ende wird's aber falsch. Es hätte entweder
"deswegen erreicht man mit Soups einen höheren Vertex-Durchsatz als mit Strips" oder besser gleich
"deswegen erreicht man mit Soups den gleichen Poly-Durchsatz wie mit Strips" heißen müssen ;)
Eben, das Tri-Setup schafft nur 60 Mio. Tri/s, deshalb bekommt man mit Strips nur 60 MVerts/s (mit 60 MTris/s), mit völlig unabhängigen Tris aber 136 MVerts/s (was allerdings nur 45 MTris/s entspricht).