P10 Patente

[Demirug]

US2002130886 Antialias mask generation
US2002130874 Vector instruction set
US2002130863 Tile relative origin for plane equations
US2002126133 Fast anisotropic/anisotropy sensitive single MIPmap sampled filtering
US2002126126 Parameter circular buffers
US2002126124 Planar byte memory organization with linear access
US2002118202 Same tile method

Einsehbar in einer entsprechende Patentdatenbank.

Nach einer ersten durchsicht muss ich bestätigen das 3Dlabs hier wirklich neue Konzepte benutzt hat. Wie bei Patenten aber üblich muss man sich das ganze mehrfach anschaue um ganz durchzusteigen (was ich immer noch nicht bin).

Im übrigen habe ich jetzt einen ganz leisen Verdacht wie Slipstream funktioniert.

[micki]

Original geschrieben von Demirug
Im übrigen habe ich jetzt einen ganz leisen Verdacht wie Slipstream funktioniert.

dann erzähl!

*g*

MfG
micki

[mapel110]

Original geschrieben von micki
dann erzähl!

*g*

MfG
micki

lieber nochmal überdenken lassen. wir sind hier nicht im speku forum ;)

[micki]

dann soll er das halt da posten.... *wissenwill*

MfG
micki

[Demirug]

Spammt mir den Thread nicht so zu ich schreibe ja was dazu aber dafür muss ich etwas weiter ausholen und dafür fehlt mir gerade die Zeit und Muse

[Modulor]

Endlich!
Danke!

Ist das die gleiche Internetadresse des Patentamtes in dem auch die PowerVR TBR patente einsehbar sind (Adresse habe ich auf die Schnelle nicht greifbar...) ?

[Demirug]

Wenn du das Europäische Patentamt meinst ja: http://ep.espacenet.com/

[Modulor]

Danke,habe das US Amt gefunden...
Mir fehlt da doch gehörig an technischem Grundwissen,aber sowas wie "dual P10 System" macht Lust auf mehr...
Freue mich schon auf deine Ausführungen :up:...

[Demirug]

Analyse der Patente zum P10 von 3dLabs. Teil1

Vorbemerkung: Da diese Patente nicht unbedingt immer sehr genau sind ist es durchaus möglich das mir einige Fehlinterpretationen unterlaufen sind.

1. 3dLabs verzichtet beim P10 weitgehend auf Feste Funktionen im Chip. Dadurch wird eine sehr hohe flexibilität erreicht. Allerdings hat das ganze auch einen Preis. Bestimmte Features in der Renderpipeline die bei anderen Chips ohne Performancesverlust hinzugeschaltet werden können haben beim P10 Design direkte auswirkungen auf die Performance. 3dlabs selbst sieht den P10 als einen Chip im mittleren Performance Segment.

2. Das T&L Subsytem (Vertexshader):
Der P10 hat 16 Vertexshader welche alle syncron das gleiche Programm für 16 Verticens ausführen. Ein Solches Programm kann bis zu 256 Instruktionen lang sein und darf Schleifen und Unterprogramme enthalten. Eine Aussage ob die Anzahl der Schleifendurchläufe pro Vertice oder pro Object gesetzt wird gibt es nicht. Für alle die jetzt denken 16 Vertexshader = Wahnsinn muss nun gesagt werden das ein P10 Vertexshader nicht einem R300 Vertexshader entspricht. Ein R300 Vertexshader arbeitet mit Vector4 (= 4 Fliesspunktwerte) Datentypen ein P10 Vertexshader kennt nur den Fliesspunktdatentyp. Für eine Vertor4 Operation welche ein R300 in einem Takt ausführt braucht der P10 4 Takte. Bei Vertor4 Operationen entsprechen die 16 VS des P10 also den 4 VS des R300. Werden aber nun Vector3 Operationen ausgeführt kann der R300 weiterhin nur 4 pro Takt davon ausführen. Der P10 kommt hierbei aber auf 5,3 Operationen Pro Takt. Die P10 Architecktur erlaubt also eine bessere Ausnutzung der Vertexshader unabhängig von den benutzten DatenTypen.

3. Tilebased Rasterisation
Während des Trisetups wird jedes Dreieck in 8*8 Pixel grosse Tiles Zerlegt. Auf dieser Ebene wird auch ein erster schneller Z-Test (Min Max Test) durchgeführt. Mit einer weiteren Zerlgung in Pixel wird eine Abdeckungsmaske erzeugt und die notwendigen Z-Tests durchgeführt. So wie es nun aussieht speichert der Chip für jeden (Sub)Pixel in der Tile einen Verweiss auf die Daten für das dazugehörige Dreieck.

4. Tile Cache.
Das Trisetup und die Renderpipelines sind über einen Tilecache entkoppelt. Dadurch können auch weiterhin Dreiecke berechnet werden auch wenn die die Pixelpiplines gerade tätig sind. Das Funktioniert natürlich nur solange diese Dreiecke vollständig in den Zwischengespeicherten Tiles liegen.

5. Die Pixelpiplines.
Hier ging 3DLabs nun mal einen komplett anderen Weg. Jede Pixelpipline ist absolute Identisch und unabhängig von den anderen. Normale Pipelines arbeiten ja immer an einem Pixelblock aus dem gleichen Dreieck Paralle. Die Pixelpiplines beim P10 bearbeiten alle Pixels in einer Tile. Da bei jeder Tile der Rechenaufwand jaunterschiedlich sein kann ist auch eine asyncrone Arbeitsweise notwendig. In diesem Fall heist das einfach das jedesmal wenn eine Pipeline meldet das sie Fertig ist wird aus dem Tilecache eine Tile ausgewählt und der Pipeline zur Berechnung übergeben. Das Verfahren nach dem gewählt wird ist nicht ersichtlich. Der Vorteil diese Verfahrens ist das man die Pixelpipelines hervorragen auslasten kann und das man einen Chip mit Fehlerhaften Piplines nicht wegwerfen muss. Solange mindestens eine Pipeline funktioniert ist der Chip lauffähig. Man muss lediglich sicherstellen das den defekten Pipelines keine Tiles zugeteilt werden.

Auf die Arbeitsweise innerhalb der Pixelpiplines gehe ich dann noch später ein (da blicke ich selbst noch nicht ganz durch)

Noch ein Wort zu dem Texturefilter. Es scheint so als hätte der P10 trilinare Filter im gegensatz zu den bilinearen Filtern der Mitbewerber.


Zum P9-Slipstream:

Erweitert man einen P10 so das er den Tilecache in den Grafikspeicher auslagern kann so können viel mehr tiles vor der übergabe in die Pixelpipeliens zwischengespeichert werden. Der Vorteil dabei ist das wenn nur einfache Pixel gerendert werden müssen reicht der OnChip cache aus. Werden die Pixel nun komplexer und das Trisetup liefert schneller Pixel als sie verarbeitet werden können würde ein P10 das Trisetup in dem Moment blockieren wenn auf eine Tile zugegriefen werden muss die nicht im Cache liegt. Beim P9 wird in diesem Fall dann einfach eine Tile aus dem Cache in den Speicher koppiert und in dem nun freien Platz im Tilecache entwender eine neue angelegt oder falls vorhanden die bestehende aus dem Tilespeicher geholt. Der P9 würde also erst dann blockieren wenn der Tilecache und der Tilespeicher voll sind. Man könnte das ganze natürlich auch so auslegen das mit den Pixelshading erst angefangen wird wenn der Tilespeicher einen bestimmten Füllgrad erreicht hat wobei ich das nicht unbedingt für sinnvoll halte.

[robbitop]

hört sich vielversprechend, innovativ und potentialreich an

[micki]

ist es nicht auch so, dass einige einheiten universel sind, sodass man im treiber einstellen kann, ob mehr Leitung in TnL oder in Shading gesteckt werden soll?

unter "Slipstream" könnte ich mir vorstellen, dass die nicht nur den cache auslagern, sondern dynamisch die einheiten umkonfigurieren, sodass bei füllrate limitierung mehr pixelshader-leistung zugewiesen wird und bei polygon intensiven momenten das TnL leistung bekommt, sodass der cache immer eine optimale füllung beibehällt.


naja, das ist nur meine fantasie, dass es so laufen könnte... aber dass der chip die rechenleistung manuel im treiber verteilen kann, das hab isch irgendwo im benchmark mal gesehen.

MfG
micki

[Demirug]

Original geschrieben von micki
ist es nicht auch so, dass einige einheiten universel sind, sodass man im treiber einstellen kann, ob mehr Leitung in TnL oder in Shading gesteckt werden soll?

Beim P10 defintive nicht. Der Vertexshader und der Pixelshader sind zwei physikalsich getrennte Einheiten.

unter "Slipstream" könnte ich mir vorstellen, dass die nicht nur den cache auslagern, sondern dynamisch die einheiten umkonfigurieren, sodass bei füllrate limitierung mehr pixelshader-leistung zugewiesen wird und bei polygon intensiven momenten das TnL leistung bekommt, sodass der cache immer eine optimale füllung beibehällt.


naja, das ist nur meine fantasie, dass es so laufen könnte... aber dass der chip die rechenleistung manuel im treiber verteilen kann, das hab isch irgendwo im benchmark mal gesehen.

MfG
micki

Wie gesagt ist beim P10 keine Umverlagerung vorgesehen. Das man im Treiber etwas umstellen kann habe ich auch schon gesehen aber ich vermute mal das es sich dabei nur um eine Ansteuerungssache handelt. Bei den Quadrokarten von nvidia optimiert der Treiber ja auch mehr in richtung Polygonen durchsatz.

[micki]

http://www.de.tomshardware.com/graphic/20020624/wildcat_vp-03.html

und
zitat aus
http://www.tilebase.de/reviews/VP560/VP560_03.html

"Äußerst interessant schien kurz nach_Erscheinen des ersten reviews der VP-Karten im Sommer diesen Jahres das Pipeline Optimierungsmenü. Mittels eines ohne Zwischenstufen versehenen Schiebereglers läßt sich die VPU auf maximale Geometrie - oder Texturleistung einstellen, wobei möglicherweise Taktraten,Cachestategien und -größen verändert sowie auch einige Prozessoren mehr für den jeweiligen Aufgabenbereich zugeschaltet werden.Nach einem reboot ist die Einstellung aktiv.
Hier einige Beispiele welche Auswirkungen die beiden Einstellungen auf div. benchmarks mit der VP560 zeigen..."


da wird eindeutig erwähnt, dass einzelne "prezessoren" für andere bereiche eingeschaltet werden...
interpretiere ich das falsch?


MfG
micki

[Demirug]

Original geschrieben von micki
http://www.de.tomshardware.com/graphic/20020624/wildcat_vp-03.html

und
zitat aus
http://www.tilebase.de/reviews/VP560/VP560_03.html

"Äußerst interessant schien kurz nach_Erscheinen des ersten reviews der VP-Karten im Sommer diesen Jahres das Pipeline Optimierungsmenü. Mittels eines ohne Zwischenstufen versehenen Schiebereglers läßt sich die VPU auf maximale Geometrie - oder Texturleistung einstellen, wobei möglicherweise Taktraten,Cachestategien und -größen verändert sowie auch einige Prozessoren mehr für den jeweiligen Aufgabenbereich zugeschaltet werden.Nach einem reboot ist die Einstellung aktiv.
Hier einige Beispiele welche Auswirkungen die beiden Einstellungen auf div. benchmarks mit der VP560 zeigen..."


da wird eindeutig erwähnt, dass einzelne "prezessoren" für andere bereiche eingeschaltet werden...
interpretiere ich das falsch?


MfG
micki

Ich kenne die entsprechenden Dialoge.

Aber wie gesagt ist es laut den Patenten nicht möglich die Vertexshader für Pixelberechnungen oder umgekehrt zu benutzten. Scheinbar gibt es aber einige möglichkeiten was die Organisation der Interen Vertexbuffer angeht und damit könnte das ganze dann durchaus etwas zu tun haben.

[Modulor]

Die Betonung lag auf "möglicherweise" - aber nachdem ich mir einige Grafiken der Patente sowie v.a. das offizielle Schema des P10 näher angeschaut habe kann man das mit der Zuweisung von Prozessoren aus dem Vertex array für Pixelberechnungen und umgekehrt wohl ausschliessen.
Zudem ist der einzige sichtbare registry Parameter der sich mit der Geometrie- und Pixeloptimierung verändert "AltClockSpeed" - es wird also lediglich die Geschwindigkeit der beiden Einheiten verändert und gleichzeitig müssen die entsprechenden Puffer dem gestiegenen bzw. gesunkenen Datenaufkommen angepaßt werden.Das geht leider nicht on the fly sondern erst mit einem reboot.

Mit Slipstream dürfte das aber alles weniger zu tun haben - ein bisschen buffer resizing und Geschwindigkeitserhöhung kann das nicht erreichen was Slipstream erreicht.
Wenn man sich das Blockdiagramm des P10 (http://www.3dcenter.de/artikel/2002/05-05_pic1.php) ansieht fällt auf,daß bei diesem das tiling und die anschließende Sichtbarkeitsprüfung erst nach dem T&L stattfindet. Was liegt also näher als die Vermutung anzustellen, daß der P9 diese Schritte als ersten Prozess stattfinden läßt?

[micki]

wie sortiert man geometry in bildsegmente ohne sie vorher transformiert zu haben?

MfG
micki