powerVR back on top ?! [Archiv]

Ailuros

2002-12-07, 09:54:20

Originally posted by Exxtreme

Err, ich schrieb nichts von einem Deferred Renderer. ;)
AFAIK macht die R300 auf Tiling wenn FSEAA aktiviert wird. Tiling und IMR schliessen sich nicht gegenseitig aus.

Mit dem staendigen Marketing-Wirrwarr von z.B. Trident ist es moeglich dass man die Defination eines "Tilers" nicht richtig interpretiert. ATI hat ihre back buffer tiling Optimierungen seit der R100 nie vermarktet, was bei NVIDIA auch nicht anders ist. Wobei der Durchschnitts Verbraucher unter Tiler einen TBDR versteht, unter IMR dann "traditionelle" Architekturen.

Ich setz mich jetzt nicht hin und analysiere die Unterschiede zwischen einer memory tiling storage Optimierung und TBR, aber was FSAA betrifft, war Supersampling schon auf KYRO "Bandbreiten-frei". Da Multisampling "Fuellraten-frei" auf R300 und GF4 ist, kannst Du dreimal raten was der Unterschied zu einer Multisampling Implementation auf einem TBDR waere.

Kleiner Ausschnitt:

In the case of tilers, the pixel color can be computed once and applied to the visible samples in the pixel based on the sample's z values. When the tile is done, the filter can be applied to the tile and the results written to the frame buffer.

Du kannst frei Data auf dem Netz nachsuchen wie eine SDRAM R100 mit Supersampling aussah. Wenn mich mein Gedaechtnis nicht betruegt, war die KYRO II um ungefaehr 60% schneller mit SSAA, wenn nicht mehr, wobei (obwohl primitiver) memory tiling und hierarchical Z schon damals da war.

ActionNews

2002-12-07, 12:20:20

Originally posted by Quasar
Sie schreibt ge-tiled in den Framebuffer, aber zu einer kompletten TBR-Lösung gehört, afaik, noch ein bißchen mehr.

Stimmt! Diese "ge-tiled in den Framebuffer schreiben" konnten IMHO schon die Ur-Voodoos :)!

CU ActionNews

ActionNews

2002-12-07, 12:29:19

Originally posted by Ailuros

(...)
ImgTec ist eine Firma die IP verkauft (siehe Intellectual Property). Jeder Design peilt mehr als nur einen Markt an. Wenn es einen Partner geben sollte, der will und es auch kann in den PC Markt zu investieren, dann ja.

In jedem anderen Fall kann eine Variante des Designs nur als integrierte Loesung, PDA chip oder auch console chip landen ohne es je in den PC zu schaffen.

Die kuendigen mit Sicherheit nichts an, bis sie fast vor Massen-Produktion stehen. Daher wuerde ich eher sagen: abwarten und Tee trinken.

Ich hoffe ja immernoch, dass ImgTec/PowerVR aus dem STMicro-Desaster gelernt hat, und die Chips endlich selber produziert! Sie wären dadurch unabhängiger und auf der sicheren Seite. STMicros Marketing, Verlässlichkeit und Produktplazierrung (Low-Cost) waren einfach miserabel und ich möchte sowas lieber nicht mehr erleben! Aber naja, es geht ja nicht nach mir sondern ImgTec muss das entscheiden. Wenigstens scheinen sie schon mal zu überlegen erste Samples Notfalls auch bei einer Halbleiterfirma wie TSMC oder UMC unabhängig von einem Lizensnehmer zu fertigen. Zumindest meine ich sowas aus dem EE Times Interview mit John Metcalfe herausgelesen zu haben :)!

CU ActionNews

Demirug

2002-12-07, 13:26:10

Ailuros, bezüglich deiner Frage aus dem anderen Thread

Another advantage TBDR has is that vertex and pixel processing is completely decoupled, the vertex and pixel shaders work on completely different scenes meaning that there is a significant reduction of the chance that the vertex shader will stall the pixel shader (complex vertex shader with simple pixel shader) or the other way around (simple vertex shader with very complex pixel shader). Reducing the idle time of pipeline components is yet another way to be more efficient.

Es ist zwar richtig das es keine direkte Kopplung von Vertex und Pixelshader gibt dafür aber eine indirekte. Dasss soll heisen wenn zum Beispiel der Pixelshader aufwand in Frame 1 höher ist als der Vertexaufwand in Frame 2 läuft der Vertexshader auch im idle. Umgekehrt gilt das selbe. Da beim TBDR aber die Kopplung schwächer ist als bei einem IMR (welche ja über entsprechende Caches auch entkoppeln) ist immer noch ein Vorteil zu erwarten wie Kristof schon sagt.

Dafür entstehen in einem TBDR aber andere Kopplungen die ein IMR nicht kennt. So ist zum Beispiel das Trisetup (welches bei einem TBDR einfacher als beim IMR ist) mit einer Binning Einheit und diese ist wiederrum mit dem Speicherinterface verbunden. Das Binning von Komplexen Dreiecken (viele Texturkoordinaten) dürfte aufwendiger sein, allerdings kommt dem Binning hier die Tatsache engegen das komplexe Dreiecke auch komplexe Shaderprogramme haben und das Trisetup dadurch sowieso weniger Dreiecke an das Binnig liefert. Das Memoryinterface ist aber schon wieder ein ganz anderes Thema. PowerVr arbeitet ja mit dem Plane Prinzip. Das heist das pro zu interpolierenden Wert 3 Fliesspunktwerte gebraucht werden. Es müsste aber IMO möglich sein jeweils 2 davon mit einer geringeren Präzäsion zu speichern. Also pro Plane sollten 8 Byte anfallen. Ein Dreieck mit Z-Werten und 2 2D Texturkoordinaten braucht 6 Planes (=48 Byte). Das Memoryinterface kann sich also durchaus als Bremse auswirken.

Auf der anderen Seite haben wir auch wieder eine Kette von gekoppelten Einheiten:

Speicher->HSR-Einheit->Pixelshader->Speicher

Beim Einlesen der getillten Daten kann sich der Chip zuerst nur auf die Begrennzungs und Z-Plane beschränken. (=16 Byte). Die HSR-Einheit besteht AFAIK aus 32 Einheiten. Pro Takt können also 32 AA-Sample positionen überprüft werden. Vorteil bei dieser Technik ist das auch ohne AA alle Einheiten benutzt werden können. Ein Nachteil ist allerdings das sobald ein Dreieck in einer Tile liegt auch die gesamte Tile überprüft werden muss. Also selbst wenn nur ein AA-Sample bedeckt wird müssen alle geprüft werden. Mit einer entsprechenden Optimierung liese sich das im besten Fall auf die Anzahl der benutzen Einheiten reduzieren. Sobald nun alle Dreiecke einer Tile durch das HSR gelaufen sind müssen für die nicht aussortierten Pixel die Texturkoordinaten bestimmt werden. Und dann geht es ab in den Pixelshader. Also haben wir wieder 3 stellen die sich gegenseitig blockieren können. Befinden sich weninge Dreiecke in einer Tile könnte es passieren das das HSR schon fertig ist bevor die Texturkoordinaten der vorherigen Tile berechnet sind. Genauso kann eine Tile mit vielen Dreiecken dazu führen das die dahinterliegenden Einheiten leerlaufen.

Also man sieht das es auch noch in einem TBDR genügend Stellen gibt die sich gegenseitig blockieren können.

Im Vergleich zu dem neuen IMR verliert ein TBDR immer mehr von seinen Vorteilen. Die Framebufferkompression reduziert den Bandbreitenvorteil beim AA. HSR auf Z-Buffer Basis verringert die Anzahl der Pixel die unnötig durch den Pixelshader müssen. Z-Buffer Kompression verkleinert den Bandbreitenbedarf bei den IMR. Kleiner und komplexere Dreiecke erhöhen in beim TBDR. Stencil Buffer Kompression verkleinern ebenfalls den Bandbreitenbedarf. Beim TBDR sind Stencil Operationen nach wie vor ohne Speicherbandbreiten bedarf. Sogesehen dürfte sich PowerVr freuen das DOOM III sehr viel mit Stencilops rendert.

Es bleibt also zu sagen das man bei einem TBDR heute in ähnliche Bereiche, was den Coretakt und die Bandbreite angeht, bewegen muss um Konkurrenzfähig zu sein.

Ailuros

2002-12-07, 15:54:13

Es bleibt also zu sagen das man bei einem TBDR heute in ähnliche Bereiche, was den Coretakt und die Bandbreite angeht, bewegen muss um Konkurrenzfähig zu sein.

Ich bezweifle dass auch jemand das Gegenteil behauptet hat.

Netter post uebrigens.

Lies mal dieses Patent durch:

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

(obwohl es eigentlich generell erscheint) und sag mir ob es in gewissen Stellen die von Dir aufgefuehrten negativen Anhaltspunkte uebergehen koennte. Ich nenne es meistens "hierarchical tiling scheme" mit einer Moeglichkeit es mit Z-Kompression zu kombinieren.

Auch Gigapixel war schon so weit mit hierarchicalZ und Z Kompression zu arbeiten. Sage II der auf Fear sollte hatte eine geringe Anzahl von "dedicated ram" fuer binning. Ich hab allen ernstes keine Ahnung ob bei PVR nun in naechsten Produkten der Geometrie Prozessor integriert ist (a la Mojo), oder ob er immer noch eine unabhaengige Einheit sein wird (wie bei Series 2, 3 und 4 nicht im PC space natuerlich ausser dem letzten).

Mehr kann ich leider nicht oeffentlich ausspucken, als mich nur an offiziel veroeffentlichte Kleinigkeiten halten. Tiler haben den Nachteil dass man Wiedergabe schlecht vorraussehen kann, denn ich kann mir vorstellen dass die Geschichte wie bei KYRO nicht allzu aendern wird (nicht absolut konstante Wiedergabe in allen Applikationen), wobei die Applikationen hoechstwahrscheinlich auch eine Rolle spielen.

Wie Du weisst konnten Tiler bis jetzt zwar Bandbreite auf 1/4 reduzieren, jedoch war deren groesstes Problem Vertex Bandwidth dass bis zu 2.5x Mal aufzusteigen vermochte. Mit diesem Nachteil und der fehlenden Geometrie/T&L Einheit konnten sich selbst budget Tilers gegen die Konkurrenz schwer bestaetigen "across the board". Wenn aber diese Limitation beseitigt wird (ob es nun obere vorgeschlagene alternative tiling Methoden sind oder andere) und die Spezifikationen gleich sind wie auf einem konkurrierenden IMR, koennen Vorteile schon da sein. Was uebrig bleibt, ist dass sie es endlich zu beweisen versuchen.

Ich hab zwar gefragt im Interview ob es eine Moeglichkeit gibt dass eine Art "Amalgamation" von IMR's und TBR's stattfinden koennte, aber es war verstaendlich dass die Frage eine elegante stereotype "Neben-Antwort" bekam.

Demirug

2002-12-07, 16:58:47

Originally posted by Ailuros
Ich bezweifle dass auch jemand das Gegenteil behauptet hat.

Da bin ich mir nicht so sicher. Die geringere Bandbreite und der Coretakt werden nach wie vor gerne als Argument für TBDR aufgeführt.

Lies mal dieses Patent durch:

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

(obwohl es eigentlich generell erscheint) und sag mir ob es in gewissen Stellen die von Dir aufgefuehrten negativen Anhaltspunkte uebergehen koennte. Ich nenne es meistens "hierarchical tiling scheme" mit einer Moeglichkeit es mit Z-Kompression zu kombinieren./SIZE]

Ja das patent kenne ich. Es geht dabei um die Lösung von zwei Probleme von TBDR.

1.: wenn sich ein Dreieck über mehr als eine Tile erstreckt müssen die Planedaten für jede Tile einzelen gespeichert werden. Das verbraucht natürlich Bandbreite. Die in dem Patent aufgeführte Makrotile Technik reduziert diesen zusätzlichen Speicherbedarf in dem die Planedaten nur einmal für mehrer Tiles abgelegt werden und in den Tiles selbst nur ein Verweis gespeichert wird.

2.: Das viel grössere Problem eines TBDR ist das im der Tilespeicher ausgehen kann. Die Technik in dem Patent versucht das zu umgehen in dem sobald der Tilespeicher ein gewisses Volumen ereicht eine Tile ausgewählt und gerendert wird um wieder speicher freizugeben. Allerdings muss für diese Tile dann ein Z-Buffer gepeichert werden da ja noch weitere Dreiecke für diese Tile kommen könnten. Ich habe diesen Punkt jetzt nicht mehr genau im Kopf aber vorzugsweise sollte man diesen komprimierten Z-Buffer direkt wieder im Tilespeicher ablegen. Dadurch kann er wenn die Tile noch einmal bearbeitet werden muss direkt mit den Tiledaten eingeladen werden. Zudem muss dann kein eigener Speicherbreich mehr angelegt werden.

Die Technik mit einem Tilespeicher mit fester grösses hat auch noch den Vorteil das man den Tilespeicher ohne Probleme über einen eigenen Memorycontroller anbinden kann oder sogar embeded RAM benutzen könnte.

[SIZE=1]Auch Gigapixel war schon so weit mit hierarchicalZ und Z Kompression zu arbeiten. Sage II der auf Fear sollte hatte eine geringe Anzahl von "dedicated ram" fuer binning. Ich hab allen ernstes keine Ahnung ob bei PVR nun in naechsten Produkten der Geometrie Prozessor integriert ist (a la Mojo), oder ob er immer noch eine unabhaengige Einheit sein wird (wie bei Series 2, 3 und 4 nicht im PC space natuerlich ausser dem letzten).

Vorzugsweise sollte man immer alles auf so wenigen Chips wie nur möglich unterbringen.

[Mehr kann ich leider nicht oeffentlich ausspucken, als mich nur an offiziel veroeffentlichte Kleinigkeiten halten. Tiler haben den Nachteil dass man Wiedergabe schlecht vorraussehen kann, denn ich kann mir vorstellen dass die Geschichte wie bei KYRO nicht allzu aendern wird (nicht absolut konstante Wiedergabe in allen Applikationen), wobei die Applikationen hoechstwahrscheinlich auch eine Rolle spielen.

Wie Du weisst konnten Tiler bis jetzt zwar Bandbreite auf 1/4 reduzieren, jedoch war deren groesstes Problem Vertex Bandwidth dass bis zu 2.5x Mal aufzusteigen vermochte. Mit diesem Nachteil und der fehlenden Geometrie/T&L Einheit konnten sich selbst budget Tilers gegen die Konkurrenz schwer bestaetigen "across the board". Wenn aber diese Limitation beseitigt wird (ob es nun obere vorgeschlagene alternative tiling Methoden sind oder andere) und die Spezifikationen gleich sind wie auf einem konkurrierenden IMR, koennen Vorteile schon da sein. Was uebrig bleibt, ist dass sie es endlich zu beweisen versuchen.

Ich hab zwar gefragt im Interview ob es eine Moeglichkeit gibt dass eine Art "Amalgamation" von IMR's und TBR's stattfinden koennte, aber es war verstaendlich dass die Frage eine elegante stereotype "Neben-Antwort" bekam.

Ja die durch die Vertex daten verbrauchte Bandbreite ist eines der Hauptprobleme der TBDR. Aber mit der Bandbreite haben ja auch die IMR zu kämpfen. Bei der Fillrate dagegen haben die TBDR weniger Probleme da ja in den Pixelshadern nur noch das ankommt was wirklich zu sehen ist. Doch wie schon gesagt haben da die IMR schon gute fortschritte gemacht. Der andere Knackpunkt beim TBDR ist die HSR Leistung. Ich will sie jetzt mal mit Dreiecksfragmente/s bezeichnen. Diese Fragmente werden bei der HSR Prüfung in AA-Samples zerlegt und davon entstehen bei einem TBDR viel mehr als bei einem IMR. Im Gegenzug lassen sie die HSR Einheiten aber besser nutzten als die AA-Sampler beim IMR. Alles in allem ist es recht schwer Leistungsaussagen ohne Simulationsmodel zu machen.

Zum leztzen Punkt: Ich denke das es durchaus möglich ist das sie die TBDR gewisses Dinge bei den IMR entleihen werden. Den beide Techniken (IMR und TBDR) habe in der reinen Form Nachteile.

GloomY

2002-12-07, 18:14:38

Originally posted by mapel110
We intend to (re-)establish PowerVR technology as a performance leader in the PC Market
http://www.pvrgenerations.co.uk/cgi-bin/viewarticle.cgi?page=/articles/2002/kristof1102&printer=0&pagenum=1
da gibts ein interview !

so wie es aussieht, wird uns wohl bald ein dx9 TBR beglücken :) Das Interview ist echt mega cool :D

("it's our third plant since we have somehow managed to depress the previous two", "Actually any company where every Wednesday is a 'donut'-day has to be a good company to work for") :lol:

Zum Inhalt:
"At this moment in time high quality and high performance anisotropic filtering have become a key element for new products, we are aware of this and there is no problem handling this demand."

Hört sich schon mal nicht schlecht an. =)

Und dann gibt's da ja auch noch einen neuartiges Texturkompressionsverfahren (PVR-TC), das nur noch die hälfte der Größe von DXTC haben soll. Klingt auch vielversprechend. =)
Originally posted by Demirug
Da bin ich mir nicht so sicher. Die geringere Bandbreite und der Coretakt werden nach wie vor gerne als Argument für TBDR aufgeführt.Ein TBR braucht auf Grund der höheren Effizienz einfach weniger Rohpower, daher ist das an sich schon ein Vorteil wenn es um Resourcen (Füllrate, Bandbreite, Die-Größe) geht.

Allerdings hast du schon Recht, wenn du sagst, dass man zumindest IN DIE NÄHE der Leistungsdaten eines IMRs kommen sollte. Damit meine ich nicht sowas wie KyroII gegen GF2 Ultra (350 gegen 2000 MegaTexel Füllrate). Wenn es um solche Verhältnisse geht, bekommt ein TBDR natürlich schon seine Probleme...

Unregistered

2002-12-07, 20:14:44

Originally posted by ActionNews
STMicros Marketing, Verlässlichkeit und Produktplazierrung (Low-Cost) waren einfach miserabel und ich möchte sowas lieber nicht mehr erleben!

David Harolds war jedoch sehr zufrieden über die zusammenarbeit und sagte dass STM ein guter Partner war, und das nachdem ST bekannt gegeben ht PVR loszuwerden wollen.
Ich weiss allerdings nicht inwieweit er da die Warheit sagen darf.

loewe

2002-12-07, 20:28:39

Originally posted by Demirug
Die HSR-Einheit besteht AFAIK aus 32 Einheiten. Pro Takt können also 32 AA-Sample positionen überprüft werden. Vorteil bei dieser Technik ist das auch ohne AA alle Einheiten benutzt werden können. Ein Nachteil ist allerdings das sobald ein Dreieck in einer Tile liegt auch die gesamte Tile überprüft werden muss. Also selbst wenn nur ein AA-Sample bedeckt wird müssen alle geprüft werden.

AFAIK gilt diese Aussage mit den 32 parallelen Einheiten des ISP nur für KYRO I+II. Schon KYRO III hätte hier eine Verdoppelung gebracht und weiter zu erhöhen ist nicht unbedingt schwierig, aber vielleicht nicht sinnvoll.
Es ist ja allgemein bekannt, dass der ISP des KYRO nicht für die zukünftigen Dreiecksmengen ausreichend ist, da wird es mit Sicherheit eine Änderung geben, deshalb würde ich hier keinen Flaschenhals sehen wollen.

Das Testen der ganzen Tile geschieht bei KYRO in 16 Takten je Dreieck, bei einer Veränderung des ISP entsprechend noch schneller, weshalb sollte das ein Problem sein?

Es bleibt aber dabei, damit ein TBDR in jeder Situation ähnlich Leistungen bringen kann, wie die IMRs muss er auch ähnliche Leistungsdaten haben, d.h. die Chips der Serie5 werden ähnlich komplex und groß und natürlich auch mit entsprechendem Speicher bestückt sein.

Egal ob PowerVR jemden finden wird der die Serie5 in den PC Markt bringt, es wird auf jeden Fall einige Chips für Testzwecke geben und da sollten wir recht gespannt sein, wie diese sich schlagen werden.

loewe

2002-12-07, 20:31:40

Originally posted by Unregistered

David Harolds war jedoch sehr zufrieden über die zusammenarbeit und sagte dass STM ein guter Partner war, und das nachdem ST bekannt gegeben ht PVR loszuwerden wollen.
Ich weiss allerdings nicht inwieweit er da die Warheit sagen darf.

Marketing,

STM bleibt einer der größten Partner was den MBX anbelangt und damit natürlich auch einer der Geldgeber, da hätte ich auch nichts anderes gesagt! =)

Demirug

2002-12-07, 20:36:51

GloomY, da kann ich dir nur begrenzt zustimmen:

Im Vertexbereich gibt es überhaupt keinen Unterschied.

Von den Transitoren wird der unterschied auch nicht mehr so gross sein. Ein TBDR kann zwar einen Teil der Pixelpipelines einsparen dafür muss aber die aufwändige Tilling und HSR Logic untergebracht werden.

Ein NV30 kann theoretisch 16 G AA-Samples verarbeiten. Dafür gibt es 32 AA-Sampler. Auch ein TBDR braucht auch eine art AA-Sampler. Diese sind aber in der HSR Logic untergebracht. Das dumme dabei ist nur das beim TBDR Verfahren viel mehr AA-Samples als beim IMR verfahren erzeugt werden.

IMR: AA-Samples = Summe aller Pixelfragmente die nicht durch Early Z im trisetup entfernt werden. Fragmente die erst durch das EarlyZ in der Pixelpiepline entfernt werden zählen weil sie ja für diesen Takt den AA-Sampler blockieren.

TBDR: AA-Samples = Anzahl der Dreiecksfragmente * Anzahl der AA-Samples pro Tile. btw. Early Z macht beim TBDR keinen Sinn.

Die Kyros haben 32 dieser HSR Einheiten. Das wird für eine highend Karte aber nicht mehr reichen. 1024*768 4xAA braucht bein einer Tile grösse von 32*32 Samples 3072 Tiles. gehen wir nun von einer halben million Dreiecke pro Frame aus kommen wir auf ca 165 Fragmente pro Tile (bei gleichmässiger Verteilung). Das heist wir müssen 165*3072*32*32 = 519.045.120 AA-Samples pro Frame prüfen. Wir wollen mindestens 75 FPS also 38.928.384.000 AA-Samples/s. Bei 400 MHZ Core brauchz man 98 HSR Zellen. Die Anzahl muss aber ein vielfaches der Tilebreite sein also 128 Zellen. Bei 500 MHz kommmt man mit 96 Zellen aus.

165 Fragmente pro Tile heist 165*(32*32)/128 = 1320 Takte oder 165*(32*32)/96 = 1760 Takte für die HSR Prüfung. Daraus ergibt sich das pro Pixel (4xMSAA) 5,16 bzw. 6,88 Takte für den Pixelshader zur Verfügung stehen. Benutzen wir nun nur 4 PS ergeben sich ca 21 Takte bzw. 28 Takte. Damit läst sich was anfangen. Werden mehr Takte benötigt was bei der Verwendung von AF wahrscheinlich ist wird das HSR blockiert bei weniger Takten läuft der PS leer. Ein ähnliches Problem ergibt sich wenn weniger Fragmente in der Tile sind denn das bedeutet weniger Takte für den Pixel oder blockieren des HSR.

Also ein TBDR kämpft mit ähnliche Problemen wie ein IMR. Beim IMR ist der kritische Faktor Pixel/Dreieck beim TBDR ist er Fragmente/Tile.

Demirug

2002-12-07, 21:12:27

Originally posted by loewe

AFAIK gilt diese Aussage mit den 32 parallelen Einheiten des ISP nur für KYRO I+II. Schon KYRO III hätte hier eine Verdoppelung gebracht und weiter zu erhöhen ist nicht unbedingt schwierig, aber vielleicht nicht sinnvoll.
Es ist ja allgemein bekannt, dass der ISP des KYRO nicht für die zukünftigen Dreiecksmengen ausreichend ist, da wird es mit Sicherheit eine Änderung geben, deshalb würde ich hier keinen Flaschenhals sehen wollen.

Ja ich gehe ja wie gesagt von mindestens 96 aber eher 128 oder noch mehr einheiten aus. Wobei mir 128 ein guter Mittelweg zu sein scheint.

Das Testen der ganzen Tile geschieht bei KYRO in 16 Takten je Dreieck, bei einer Veränderung des ISP entsprechend noch schneller, weshalb sollte das ein Problem sein?

Da gibt es kein Problem. Es müssen halt wie schon gesagt nur mehr HSR-Zellen vorhanden sein um mit den Polys fertig zu werden.

Es bleibt aber dabei, damit ein TBDR in jeder Situation ähnlich Leistungen bringen kann, wie die IMRs muss er auch ähnliche Leistungsdaten haben, d.h. die Chips der Serie5 werden ähnlich komplex und groß und natürlich auch mit entsprechendem Speicher bestückt sein.

Meine Reden. Viel sparen läst sich mehr.

Egal ob PowerVR jemden finden wird der die Serie5 in den PC Markt bringt, es wird auf jeden Fall einige Chips für Testzwecke geben und da sollten wir recht gespannt sein, wie diese sich schlagen werden.

Wie soll man ohne Partner Karten bauen? PowerVR macht doch nur das LogikDesign.

loewe

2002-12-07, 21:15:58

Originally posted by Demirug
Wie soll man ohne Partner Karten bauen? PowerVR macht doch nur das LogikDesign.

Nein!

loewe

2002-12-07, 21:21:54

Originally posted by Demirug
Ja ich gehe ja wie gesagt von mindestens 96 aber eher 128 oder noch mehr einheiten aus. Wobei mir 128 ein guter Mittelweg zu sein scheint.

PowerVR rechnet eigentlich immer ganz gut bevor sie bauen, KYRO war für seine Zeit konzipiert, da waren 100.000 Dreiecke genug.
Für Serie5 muss also neu festgelegt werden, wobei zwei Gründe auf jeden Fall für 128 Einheiten sprechen:

1. Es ist die Zeit der Spiele mit 500.000+ Dreiecken, die Serie5 wird sicher mindestens bis 2005 bestehen müssen. Die bringen nicht jedes Jahr einen völlig neuen Chip!

2. Sie wollen Highend und da brauche ich immer etwas mehr als notwendig.

Könnte auch sein das sie noch höher gehen, für einzelne Chips der Serie kann man dann ja ein wenig abspecken.

Demirug

2002-12-07, 21:32:11

Originally posted by loewe
Könnte auch sein das sie noch höher gehen, für einzelne Chips der Serie kann man dann ja ein wenig abspecken.

laut einer Aussage in einem Interview soll es ja sowieso ein sehr variables Design werden. Ich denke da mal an austauschbare Pixelshader. Von den ganz einfachen reinen MT Shader bis hoch zu einem PS 3.0 nach DX9 Spec.

Möglicherweise erhöht man auch nicht einfach nur die Anzahl der Zellen sonder baut die Logic so auf das mehr als eine Tile gleichzeitig bearbeitet werden kann.

loewe

2002-12-07, 21:34:28

Originally posted by Demirug
Möglicherweise erhöht man auch nicht einfach nur die Anzahl der Zellen sonder baut die Logic so auf das mehr als eine Tile gleichzeitig bearbeitet werden kann.

AFAIK steckte genau das schon in KYRO III, dort waren wohl zwei ISPs vorgesehen.

Thowe

2002-12-07, 21:52:08

Originally posted by Demirug
... die aufwändige Tilling und HSR Logic untergebracht werden.

Wie kommst du darauf, dass das aufwändig ist? Ich denke eher nicht.

Ein NV30 kann theoretisch 16 G AA-Samples verarbeiten. Dafür gibt es 32 AA-Sampler. Auch ein TBDR braucht auch eine art AA-Sampler. Diese sind aber in der HSR Logic untergebracht. Das dumme dabei ist nur das beim TBDR Verfahren viel mehr AA-Samples als beim IMR verfahren erzeugt werden.

IMR: AA-Samples = Summe aller Pixelfragmente die nicht durch Early Z im trisetup entfernt werden. Fragmente die erst durch das EarlyZ in der Pixelpiepline entfernt werden zählen weil sie ja für diesen Takt den AA-Sampler blockieren.

TBDR: AA-Samples = Anzahl der Dreiecksfragmente * Anzahl der AA-Samples pro Tile. btw. Early Z macht beim TBDR keinen Sinn.

Die Kyros haben 32 dieser HSR Einheiten. Das wird für eine highend Karte aber nicht mehr reichen. 1024*768 4xAA braucht bein einer Tile grösse von 32*32 Samples 3072 Tiles. gehen wir nun von einer halben million Dreiecke pro Frame aus kommen wir auf ca 165 Fragmente pro Tile (bei gleichmässiger Verteilung). Das heist wir müssen 165*3072*32*32 = 519.045.120 AA-Samples pro Frame prüfen. Wir wollen mindestens 75 FPS also 38.928.384.000 AA-Samples/s. Bei 400 MHZ Core brauchz man 98 HSR Zellen. Die Anzahl muss aber ein vielfaches der Tilebreite sein also 128 Zellen. Bei 500 MHz kommmt man mit 96 Zellen aus.

165 Fragmente pro Tile heist 165*(32*32)/128 = 1320 Takte oder 165*(32*32)/96 = 1760 Takte für die HSR Prüfung. Daraus ergibt sich das pro Pixel (4xMSAA) 5,16 bzw. 6,88 Takte für den Pixelshader zur Verfügung stehen. Benutzen wir nun nur 4 PS ergeben sich ca 21 Takte bzw. 28 Takte. Damit läst sich was anfangen. Werden mehr Takte benötigt was bei der Verwendung von AF wahrscheinlich ist wird das HSR blockiert bei weniger Takten läuft der PS leer. Ein ähnliches Problem ergibt sich wenn weniger Fragmente in der Tile sind denn das bedeutet weniger Takte für den Pixel oder blockieren des HSR.

Also ein TBDR kämpft mit ähnliche Problemen wie ein IMR. Beim IMR ist der kritische Faktor Pixel/Dreieck beim TBDR ist er Fragmente/Tile.

Falls das zuviele "HSR-Tests" pro Takt sein sollten, spricht doch nichts dagegen, die Tests wie beim IMR auch zu machen. Andererseits, wenn die HSR-Einheiten sehr günstig in Bezug auf Transistorzahl sind, dann spricht doch nichts dagegen jedes Sample eines Tiles gleichzeitig bei einem Fragment zu testen.

Beim IMR ist die Anzahl der möglichen Early-Z-Tests immer noch durch die Bandbreite beschränkt. Ausserdem kann auch eine Early-Z-Einheit nicht an mehreren Polygonen gleichzeitig arbeiten.

Thowe

2002-12-07, 22:00:51

Originally posted by Thowe

Falls das zuviele "HSR-Tests" pro Takt sein sollten, spricht doch nichts dagegen, die Tests wie beim IMR auch zu machen. Andererseits, wenn die HSR-Einheiten sehr günstig in Bezug auf Transistorzahl sind, dann spricht doch nichts dagegen jedes Sample eines Tiles gleichzeitig bei einem Fragment zu testen. [/SIZE]

Was mir noch einfällt: Oder wie wäre es damit nur die notwendigen Scanlines innerhalb des Tiles zu testen.

Demirug

2002-12-07, 23:16:31

Originally posted by Thowe
Wie kommst du darauf, dass das aufwändig ist? Ich denke eher nicht.[/SIZE]

Eine HSR Zelle ist komplexer als ein AA-Sampler. In einer solchen Zelle läuft immerhin folgendes ab. Teilweise nur bei Bedarf oder wenn bestimmt Bedingungen erfüllt sind:

Eine Fliesspunkt-Addition für die Randbegrenzung
Eine Fliesspunkt-Addition für den Z-Wert
Zwei Fliespunktvergleich für den Dreiecksrand (Der Randwert muss in einem bestimmten Bereich liegen)
Ein Fliespunktvergleich für den Z-Wert
Ein Wertvergleich für den Stencil
Eine Stenciloperation
Austausch des Z-Werts
Schreiben eines Verweis auf den Pixelstack
Löschen des Pixelstacks

und was ich jetzt noch vergessen haben

und von diesen Zellen braucht man eine ganze Menge.

Falls das zuviele "HSR-Tests" pro Takt sein sollten, spricht doch nichts dagegen, die Tests wie beim IMR auch zu machen. Andererseits, wenn die HSR-Einheiten sehr günstig in Bezug auf Transistorzahl sind, dann spricht doch nichts dagegen jedes Sample eines Tiles gleichzeitig bei einem Fragment zu testen.

Wie gesagt von der Transitorenanzahl müssten sie grösser als ein AA-Sampler sein. Was meinst du mit wie beim IMR?

Beim IMR ist die Anzahl der möglichen Early-Z-Tests immer noch durch die Bandbreite beschränkt. Ausserdem kann auch eine Early-Z-Einheit nicht an mehreren Polygonen gleichzeitig arbeiten.

Es gibt ja zwei Arten von Early-Z. Early-Z im trisetup und in der Pixelpipeline.

Es hängt jetzt aber stark von dem genauen aufbau des Trisetup und der Pixelpipeline ab in wie weit durch Early-Z fillrate verbraucht wird. Solange im Pixelshadercache noch Pixelauf die Bearbeitung warten ist das Early-Z im Trisetup ohne verlust an fillrate möglich. Erfolgt der Early-Z Test in der Pipeline ebenfalls vor dem Cache gilt das gleiche. Bei der Prüfung nach dem Cache kostet eine erfolgreiche Prüfung ein Pixel Füllrate. Ist der Pixelcache dagegen leer kostet jede erfolgreiche Early-Z Prüfung soviele Pixel Füllrate wie Pipes vorhanden sind. Das ganze ist aber unabhägig davon wie viele Pixel ausgeschlossen werden. Und hier kommen wir zum nächsten Punkt benutzt man einen Z-Buffer mit genügend ebene kann man ein Dreieck komplett in einem Takt verwerfen. Die Bandbreite ist natürlich ein Argument. Beim Z-Test braucht man ja die Z-Werte (2 pro Kachel) für alle ebenen die man prüft. Die genaue Bandbreite die man damit verbraucht ist aufgrund von Kompression, Anzahl der Ebenen, Cachehits schwer zu bestimmen. Sie liegt zwischen 0 und grösse eine Z-Werts pro AA-Sample für jedes Sample. Also die Bandbreite würde ich hier nicht als primär limitierend sehen.

Ein IMR der nur ein Trisetup hat kann immer nur an einem Dreieck pro Takt arbeiten die Anzahl der maximal pro Takt verwerfbaren AA-Samples hängt von den Z-Ebenen ab. Beim TBDR können maximal soviele Samples pro Takt verworfen werden wie Zellen verfügbar sind. Wobei die Anzahl der Samples ja wie gesagt höher ist.

Was mir noch einfällt: Oder wie wäre es damit nur die notwendigen Scanlines innerhalb des Tiles zu testen.

Das HSR Verfahren von PowerVr bassiert ja darauf das man auf alle Dreiecksfragmente Takt für Takt nacheinader in die Zellen schiebt und dabei wird dann immer von Zelle zu Zelle weitergeschoben. Damit das ohne Probleme funktioniert muss jedes Fragment durch jede position innerhalb der Tile laufen. Mit der entsprechenden Logic bekommt man das hin das man ein Fragment in eine bestimmte Scanline in die Zellen einschleust und in einer anderen wieder heraus nimmt und den freien Zellenplatz durch ein anderes Fragment nutzt. Ist sicher eine Interesante Sache die entsprechende Logic zu designen den Aufand kann ich jetzt aber nicht so ganz abschätzen.

Thowe

2002-12-07, 23:41:00

Originally posted by Demirug

Eine HSR Zelle ist komplexer als ein AA-Sampler. In einer solchen Zelle läuft immerhin folgendes ab. Teilweise nur bei Bedarf oder wenn bestimmt Bedingungen erfüllt sind:

Eine Fliesspunkt-Addition für die Randbegrenzung
Eine Fliesspunkt-Addition für den Z-Wert
Zwei Fliespunktvergleich für den Dreiecksrand (Der Randwert muss in einem bestimmten Bereich liegen)
Ein Fliespunktvergleich für den Z-Wert
Ein Wertvergleich für den Stencil
Eine Stenciloperation
Austausch des Z-Werts
Schreiben eines Verweis auf den Pixelstack
Löschen des Pixelstacks

und was ich jetzt noch vergessen haben

und von diesen Zellen braucht man eine ganze Menge.

Der Kyro hatte 32 davon, also werden sie wohl nicht so aufwändig sein.

Wie gesagt von der Transitorenanzahl müssten sie grösser als ein AA-Sampler sein. Was meinst du mit wie beim IMR?

Na ganz normal wie beim IMR, mit Z-Buffer onChip.

Es gibt ja zwei Arten von Early-Z. Early-Z im trisetup und in der Pixelpipeline.

Was meinst du mit Early-Z im TriSetup?

Es hängt jetzt aber stark von dem genauen aufbau des Trisetup und der Pixelpipeline ab in wie weit durch Early-Z fillrate verbraucht wird. Solange im Pixelshadercache noch Pixelauf die Bearbeitung warten ist das Early-Z im Trisetup ohne verlust an fillrate möglich. Erfolgt der Early-Z Test in der Pipeline ebenfalls vor dem Cache gilt das gleiche. Bei der Prüfung nach dem Cache kostet eine erfolgreiche Prüfung ein Pixel Füllrate. Ist der Pixelcache dagegen leer kostet jede erfolgreiche Early-Z Prüfung soviele Pixel Füllrate wie Pipes vorhanden sind. Das ganze ist aber unabhägig davon wie viele Pixel ausgeschlossen werden. Und hier kommen wir zum nächsten Punkt benutzt man einen Z-Buffer mit genügend ebene kann man ein Dreieck komplett in einem Takt verwerfen. Die Bandbreite ist natürlich ein Argument. Beim Z-Test braucht man ja die Z-Werte (2 pro Kachel) für alle ebenen die man prüft. Die genaue Bandbreite die man damit verbraucht ist aufgrund von Kompression, Anzahl der Ebenen, Cachehits schwer zu bestimmen. Sie liegt zwischen 0 und grösse eine Z-Werts pro AA-Sample für jedes Sample. Also die Bandbreite würde ich hier nicht als primär limitierend sehen.

Bei großen Polygonen würde ich es schon so sehen, das die Bandbreite limitierend ist. Alleine das lesen von 32 Z-Werten bei 32Bit Genauigkeit und einer Kompression von 4:1 benötigt 32Byte und evtl. müssen diese auch noch zurückgeschreiben werden. Bei kleineren Polygonen werden die Z-Check-Einheiten immer schlechter ausgenutzt.

Ein IMR der nur ein Trisetup hat kann immer nur an einem Dreieck pro Takt arbeiten die Anzahl der maximal pro Takt verwerfbaren AA-Samples hängt von den Z-Ebenen ab.

Bei 2 Dreiecken müsste man zumindestens sicher stellen das sie sich nicht überschneiden.

Das HSR Verfahren von PowerVr bassiert ja darauf das man auf alle Dreiecksfragmente Takt für Takt nacheinader in die Zellen schiebt und dabei wird dann immer von Zelle zu Zelle weitergeschoben.

Das Verfahren der Kyro beruht darauf. Bei der Serie 2 war es noch anders und was für die Serie 5 optimal ist, das wird PVR schon rausgefunden haben.

Damit das ohne Probleme funktioniert muss jedes Fragment durch jede position innerhalb der Tile laufen. Mit der entsprechenden Logic bekommt man das hin das man ein Fragment in eine bestimmte Scanline in die Zellen einschleust und in einer anderen wieder heraus nimmt und den freien Zellenplatz durch ein anderes Fragment nutzt. Ist sicher eine Interesante Sache die entsprechende Logic zu designen den Aufand kann ich jetzt aber nicht so ganz abschätzen.

Ja genau, was im Bezug auf Transistorkosten am günstigsten ist, werden die Leute bei PVR sicher irgendwann mal ermittelt haben. Es gibt aber wohl immer mehrere Möglichkeiten und im einfachsten Fall kann man den Rendering-Teil bei PVR ja immer als IMR betrachten, der ein ganz kleines Bild komplett OnChip berechnet. Ein Vorteil wäre dabei immer noch, das man es hier nur noch mit sichtbaren Polygonen zu tun hat.

Demirug

2002-12-08, 00:24:08

Originally posted by Thowe
Der Kyro hatte 32 davon, also werden sie wohl nicht so aufwändig sein.

Ich hab das Spielzeug zum durchrechen von Digitalschaltungen nicht hier. Also lasse ich das erst mal offen.

Na ganz normal wie beim IMR, mit Z-Buffer onChip.

Da braucht man aber viel Speicher um den ganzen Z-Buffer im Chip zu halten. Oder habe ich dich jetzt falsch vertstanden?

Was meinst du mit Early-Z im TriSetup?

ATI nennt das ganzen Hierarchical-Z. Jeder Early-Z Verfahren das mehr als ein Pixel auf einmal verwerfen kann muss im trisetup durchgeführt werden.

Bei großen Polygonen würde ich es schon so sehen, das die Bandbreite limitierend ist. Alleine das lesen von 32 Z-Werten bei 32Bit Genauigkeit und einer Kompression von 4:1 benötigt 32Byte und evtl. müssen diese auch noch zurückgeschreiben werden. Bei kleineren Polygonen werden die Z-Check-Einheiten immer schlechter ausgenutzt.

Du hast hier aber das Early-Z im TriSetup nicht berücksichtigt. Dort müssen nur zwei Werte für eine Kachel besorgt werden. Und da bei aufeinanderfolgenden Dreieicken eine hohe räumliche Lokalität zu erwarten ist dürften die Cachehits ebenfalls sehr hoch. Wobei dieser ganzen Aufwand mit dem Z-Buffer beim TBDR natürlich nicht anfällt. Dieser hat dafür aber die Binning Informationen zu speichern und wieder einzuladen. Und da sind kleine Dreiecke auch nicht sehr gerne gesehen.

Bei 2 Dreiecken müsste man zumindestens sicher stellen das sie sich nicht überschneiden.

ja richtig oder noch eine Einheit dahinter haben die sich um eine eventuelle überscheidung kümmert. Wobei ich auch nicht daran glaube das man jemals mehr als ein trisetup auf einem Chip finden wird weil das Trisetup eigentlich nie der Falschenhals ist.

Das Verfahren der Kyro beruht darauf. Bei der Serie 2 war es noch anders und was für die Serie 5 optimal ist, das wird PVR schon rausgefunden haben.

Ich denke schon das es so schon recht optimal ist.

Ja genau, was im Bezug auf Transistorkosten am günstigsten ist, werden die Leute bei PVR sicher irgendwann mal ermittelt haben. Es gibt aber wohl immer mehrere Möglichkeiten und im einfachsten Fall kann man den Rendering-Teil bei PVR ja immer als IMR betrachten, der ein ganz kleines Bild komplett OnChip berechnet. Ein Vorteil wäre dabei immer noch, das man es hier nur noch mit sichtbaren Polygonen zu tun hat.

Die Sache als IMR zu sehen wäre aber eine starke Vereinfachung. Beim IMR kann man ja davon ausgehen das viele Pixel in Folge mit dem gleichen Shader (+Einstellungen) gerechnet werden. Beim TBDR muss eher vom gegenteil ausgehen das für jeden Pixel andere Einstellungen gebraucht werden und teilweise sogar mehr als eine Einstellung für einen Pixel wenn Alpha-Blending ins Spiel kommt. Auf das Design der Pixelshader hat das durchaus auswirkungen. Während man beim IMR gewisse Teile (z.b. Programm und Konstanten speicher) über alle Pipelines sharen könnte verbietet sich so etwas beim TBDR schon von selbst. Ein IMR kann also weitgehen mit syncronen Pixelpipelines arbeiten und die des TBDR müssen voll asyncron sein. Wobei diese Trennung spätestens mit PS 3.0 auch nicht mehr so aufrecht erhalten werden kann.

Ailuros

2002-12-08, 05:43:48

Originally posted by Demirug

laut einer Aussage in einem Interview soll es ja sowieso ein sehr variables Design werden. Ich denke da mal an austauschbare Pixelshader. Von den ganz einfachen reinen MT Shader bis hoch zu einem PS 3.0 nach DX9 Spec.

Möglicherweise erhöht man auch nicht einfach nur die Anzahl der Zellen sonder baut die Logic so auf das mehr als eine Tile gleichzeitig bearbeitet werden kann.

Mehr oder weniger ja. Ich illustrier es mal so: MBX ist grob-genommen eine K2 in SoC Format, dabei wurden aber noch ein paar Kleinigkeiten hinzugefuegt, als auch reduziert (siehe Multitexturing Kapazitaeten beider chips).

Ailuros

2002-12-08, 06:02:02

Uebrigens ist das Argument viel zu viel in hypothetische Bereiche geraten, wo man ohne Hartware in der Hand viel zu viel spekuliert. Derartige Kleinigkeiten die Ihr hier diskuttiert gibt PVR nicht mal fuer Serie3 oder fruehere Produkte offiziell frei, aus verstehlichen Gruenden, ausser dass jemand wie Demirug zu stark in die Tiefe damit nachforscht wozu man aber auch das dementsprechende Werkzeug braucht.

Was ich von Anfang an sage wollte und es vergessen habe, ist dass Leistung mit komplizierten/langen Shadern nur rein theoretisch ist. Gott wir koennen froh sein, wenn wir dx9/PS-VS2.0 Spiele in 2004 haben werden.

Momentan haben wir dx7 T&L optimierte Spiele ala UT2003, und ich sehe fuer die absehbare Zukunft dx8 oder dx8.1 Spiele wobei die puren dx8 Effekte eher limitiert sein sollten (nah so etwa wie DroneZ -igittigitt was gameplay betrifft- oder um so einiges komplizierter).

Ich bezweifle dass PVR momentan den Multi-/Supersampling realm verlassen wird (genauso wie bei ATI oder NV), wobei die Zukunft (und dass gilt fuer alle IHV's genauso) wohl mehr bei exotischen AA-Algorithmen liegen wird (siehe z.B. fragment AA etc.)

Daher schaetze ich auch dass im Jahr 2003 ein high end TBDR nach wie vor einen Vorsprung mit AA-Performance haben wird fuer die vermarkteten Spiele. Noch mehr wenn ein Entwickler mit transparencies/translucencies herumspielt, oder wie auch Demirug schon gesagt hat, PVR kann sich mit Doom III style Spielen nich ohne Grund freuen.

Ailuros

2002-12-08, 06:06:21

Ach uebrigens war der 32bit Zbuffer auf K2 ziemlich klein. Ich hab nicht die geringste Ahnung wie es in dieser Abteilung dann weitergegangen ist.

Demirug

2002-12-08, 06:18:58

Originally posted by Ailuros
Uebrigens ist das Argument viel zu viel in hypothetische Bereiche geraten, wo man ohne Hartware in der Hand viel zu viel spekuliert. Derartige Kleinigkeiten die Ihr hier diskuttiert gibt PVR nicht mal fuer Serie3 oder fruehere Produkte offiziell frei, aus verstehlichen Gruenden, ausser dass jemand wie Demirug zu stark in die Tiefe damit nachforscht wozu man aber auch das dementsprechende Werkzeug braucht.

Ach lass und doch unseren Spass :D. Von welchen Werzeugen sprichts du überhaupt? Alles was ich für das hier brauche ist das Internet und mein Gehirn.

Was ich von Anfang an sage wollte und es vergessen habe, ist dass Leistung mit komplizierten/langen Shadern nur rein theoretisch ist. Gott wir koennen froh sein, wenn wir dx9/PS-VS2.0 Spiele in 2004 haben werden.

Momentan haben wir dx7 T&L optimierte Spiele ala UT2003, und ich sehe fuer die absehbare Zukunft dx8 oder dx8.1 Spiele wobei die puren dx8 Effekte eher limitiert sein sollten (nah so etwa wie DroneZ -igittigitt was gameplay betrifft- oder um so einiges komplizierter).

Klar die Performance der langen shader ist ja auch beim R300 und NV30 vorerst eher theoretisch. Wobei ich glaube das der wechsel von DX8 zu DX9 schneller gehen wird als von DX7 zu DX8. Denn bei diesem wechsel mussten die Engines Shader tauglich gemacht werden. Bei DX9 muss man die Shader jetzt nur noch nutzten.

Ich bezweifle dass PVR momentan den Multi-/Supersampling realm verlassen wird (genauso wie bei ATI oder NV), wobei die Zukunft (und dass gilt fuer alle IHV's genauso) wohl mehr bei exotischen AA-Algorithmen liegen wird (siehe z.B. fragment AA etc.)

PowerVr sind mit Sicherheit die Letzten die auf irgendwas exotische umsteigen. Warum auch? Wenn der Frame komplett in den Tile-Buffer passt bekommen sie das AA ohne Bandbreiten verlust. Das ist ja einer der ganz klaren Vorteile des TBDR. Und der Fillrateverlust hält sich beim MS ja auch in grenzen. Im zweifelsfall müssen halt mehr HSR-Zellen zum Einsatz kommen aber die dürften immer noch biliger kommen als irgendwas exotisches.

Daher schaetze ich auch dass im Jahr 2003 ein high end TBDR nach wie vor einen Vorsprung mit AA-Performance haben wird fuer die vermarkteten Spiele. Noch mehr wenn ein Entwickler mit transparencies/translucencies herumspielt, oder wie auch Demirug schon gesagt hat, PVR kann sich mit Doom III style Spielen nich ohne Grund freuen.

Hoffen wir mal auf einen 3 starken Chip im Markt was bisher so von der Konkurrenz (SIS, Trident, usw.) kamm war ja eher schwach.

Ailuros

2002-12-08, 07:06:50

Wobei Konkurrenz so eine eigenartige Sache ist. Zweifellos wird der Markt von ATI/NV dominiert, aber ImgTec und deren Partner werden hoechstwahrscheinlich nicht so direkt in den 6-month refresh einsteigen. Natuerlich glaube ich dass wenn der erste S5 chip fuer high end ausgesetzt ist, dass auch mainstream und budget Versionen geben wird, aber ich bezweifle dass es alle 6-Monate einen high end refresh geben wird, obwohl dass eigentlich nur vom Partner abhaengt und wieviel diesser investieren kann.

Dabei brauchen sie einen Partner der nicht nur kurzfristig und an schnellem Profit interessiert ist, sondern einen Partner der mit vollem Gewissen einsteigt und es auch einsieht dass Gewinn bei so hoher Konkurrenz nicht von einem Tag auf den anderen kommt. ST Micro war genau das Gegenteil.

Es braucht viel Zeit, Investitionen und Muehe bis man Brand recognition im graphics Markt erhaehlt. Die allzu grosse Luecke zwischen Serie3 und 5 ist ein grosser Nachteil fuer ImgTec/PVR; praktisch muessen sie jetzt nochmal fast von vorne anfangen. Keiner sollte glauben dass selbst wenn S5 hohe Konkurrenz zu ATI/NV sein sollte, dass die jetzt ploetzlich Millionen chips von einem Tag auf den anderen verkaufen. Aber ein high end chip hilft Markt-Akzeptanz zu gewinnen, mind share ueberhaupt fuer die alternativen Maerkte fuer die der Design ebenso gut geeignet ist, wenn nicht noch besser. In relativen Zahlen sollte der PDA/mobile Markt fuenfmal (wenn nicht mehr) als der graphics Markt fuer ImgTec bedeuten. Deshalb wurde auch versucht mit dem MBX sich so hoch wie moeglich in DX Spezifikationen zu halten.

Und jetzt mal ne Kleinigkeit die vielleicht nur wenige wissen: VIA hat tatsaechlich mit ST Micro verhandelt. Nur wollte die letztere gemeinsam mit Serie4 auch noch Serie3 ins Paket druecken, um mehr Kohle rauszuquetschen. Dabei waere S3 fuer VIA nur unnoetige Unkosten gewesen; natuerlich kann sich jetzt ST Micro die Unkosten fuer Serie4 in den *ahem* stecken. Da der Prototyp des STG5500 von ST Micro gebaut wurde, haette ein anderer Partner den Design von PVR kaufen koennen, aber immer ohne den Herstellungs-IP der ST Micro gehoert.

Ailuros

2002-12-08, 08:06:02

PowerVr sind mit Sicherheit die Letzten die auf irgendwas exotische umsteigen. Warum auch? Wenn der Frame komplett in den Tile-Buffer passt bekommen sie das AA ohne Bandbreiten verlust. Das ist ja einer der ganz klaren Vorteile des TBDR. Und der Fillrateverlust hält sich beim MS ja auch in grenzen. Im zweifelsfall müssen halt mehr HSR-Zellen zum Einsatz kommen aber die dürften immer noch biliger kommen als irgendwas exotisches.

Soweit ich weiss liegt der Vorschritt in Sachen Forschung mehr oder weniger gleich bei den IHV's. Dabei muss es nicht immer direkte Haus-eigene tech sein. Zu dem sind ja auch unabhaengige Lizenzen (siehe z.B Compaq) ja auch noch da :D

Ailuros

2002-12-08, 10:29:26

OT:

Ahh Demirug hat sich endlich entschieden bei B3D aktiver zu werden. Nice move - das Forum kann nie genug intelligente und gleichzeitig objektive Meinungen haben.

Gott sei Dank lese ich mehr dort drueben als ich poste. Wenn's zu stark in technische Kleinigkeiten geht, muss ich immer ne Suchmaschine bereit haben und ein paar Stunden leserei um nur ein Viertel davon zu verstehen.... :(

Thowe

2002-12-08, 11:52:03

Originally posted by Demirug

Ich hab das Spielzeug zum durchrechen von Digitalschaltungen nicht hier. Also lasse ich das erst mal offen.

Nö, ich denke nicht, das all die Aktionen die du da aufgezählt hast pro Zelle nötig sind. Soweit ich es verstanden habe, berechnet die HSR bei PVR einfach alle Z-Werte der infinite plane und schreibt dann mittels einer vom Setup erzeugten Schreibmaske die zum Polygon gehörenden in den Z-Buffer. Irgendwelche Randberechnungen pro Pixel fallen dabei nicht an, Pixelstacks gibt es IMHO auch nicht. Diese Randberechnungen unterscheiden sich doch eigentlich in nix vom Trisetup eines IMRs.

Da braucht man aber viel Speicher um den ganzen Z-Buffer im Chip zu halten. Oder habe ich dich jetzt falsch vertstanden?

Ich meine natürlich nur die Z-Werte eines Tiles.

ATI nennt das ganzen Hierarchical-Z. Jeder Early-Z Verfahren das mehr als ein Pixel auf einmal verwerfen kann muss im trisetup durchgeführt werden.

Ich denke mal du meinst eine Early-Z-Verfahren das mehrere Pixel mit einem Z-Wert verwerfen kann.

Du hast hier aber das Early-Z im TriSetup nicht berücksichtigt. Dort müssen nur zwei Werte für eine Kachel besorgt werden. Und da bei aufeinanderfolgenden Dreieicken eine hohe räumliche Lokalität zu erwarten ist dürften die Cachehits ebenfalls sehr hoch. Wobei dieser ganzen Aufwand mit dem Z-Buffer beim TBDR natürlich nicht anfällt. Dieser hat dafür aber die Binning Informationen zu speichern und wieder einzuladen. Und da sind kleine Dreiecke auch nicht sehr gerne gesehen.

Aber mit kleinen Polygonen hat so ein Hierachical-Z auch nicht viel Freude.

ja richtig oder noch eine Einheit dahinter haben die sich um eine eventuelle überscheidung kümmert. Wobei ich auch nicht daran glaube das man jemals mehr als ein trisetup auf einem Chip finden wird weil das Trisetup eigentlich nie der Falschenhals ist.

Aber wenn das TriSetup nicht genug Polygone für die Z-Tests liefert, schränkt es auch deren Effektivität ein. Bsp GeForce FX: 32 Z-Tests pro Takt und 1 Polygon pro 2 Takte, daraus folgt das die volle Anzahl Z-Tests nur bei Polygonen größer 64 Pixel gemacht werden können, egal ob durch Hierachical-Z oder sonstwie. Kommt also schlecht mit kleinen Polygonen zurecht.

Ich denke schon das es so schon recht optimal ist.

Genau und damit effizienter als bei einem IMR.

Die Sache als IMR zu sehen wäre aber eine starke Vereinfachung.

Genau das soll es auch sein. Alle Änderungen gegenüber eines solchen IMRs dürften Optimierungen sein.

Demirug

2002-12-08, 12:59:13

Originally posted by Thowe
Nö, ich denke nicht, das all die Aktionen die du da aufgezählt hast pro Zelle nötig sind. Soweit ich es verstanden habe, berechnet die HSR bei PVR einfach alle Z-Werte der infinite plane und schreibt dann mittels einer vom Setup erzeugten Schreibmaske die zum Polygon gehörenden in den Z-Buffer. Irgendwelche Randberechnungen pro Pixel fallen dabei nicht an, Pixelstacks gibt es IMHO auch nicht. Diese Randberechnungen unterscheiden sich doch eigentlich in nix vom Trisetup eines IMRs.

Da Patent das man dazu kennt deckt ja nur einen Teilbreich der Gesamtlösung ab. Das mit der Schreibmaske ist aus der Sicht der Datenmenge beim Binning die eher schlechtere Lösung (was aber nicht ausschliesst das die benutzt wurde). Bei einer 32*32 Tile benötigt eine solche Maske 1024 Bit = 128 Byte. Eine Randplane höchstens 12.

Die Randberechnung ist ähnlich aber im Detail etwas anders weil man beim TBDR die Stream eigenschaft der verketteten Zellen ausnutzen kann.

Ein Pixelstack oder so etwas in der Art wird gebraucht um mehr als einen Pixelsettingverweis pro Endpixel zu speichern. Das ist notwendig weil aufgrund von Alphablendig sich der endgültige Farbwert aus mehr als nur einem Polygon zusammensetzten kann.

Ich denke mal du meinst eine Early-Z-Verfahren das mehrere Pixel mit einem Z-Wert verwerfen kann.

Aber mit kleinen Polygonen hat so ein Hierachical-Z auch nicht viel Freude.

Ja wir reden über das gleiche. Es sind aber zwei Z-Werte Der grösste und der kleinste inherhabl der Kachel. Damit ergibt ein Test drei mögliche ergebnisse:

1. Alle Pixel des Dreiecks welche in der Kachel sind sind sichtbar. Weitere Prüfungen entfallen und die Pixel gehen direkt in den Pixelshader.

2. Alle Pixel sind verdeckt und werden sofort verworfen

3. Ergebniss ist nicht eindeutig. Das Dreieck wird weiter zerlegt und auf der nächsten Ebene erneut geprüft. Ist man auf der untersten Ebene wird die Prüfung in der Pixelpipeline fortgesetzt.

Aus diesem Grund mag Hierachical-Z kleine Polygone. Kleine Polygone bedecken weniger Kachelen und benötigen daher weniger Tests.

Aber wenn das TriSetup nicht genug Polygone für die Z-Tests liefert, schränkt es auch deren Effektivität ein. Bsp GeForce FX: 32 Z-Tests pro Takt und 1 Polygon pro 2 Takte, daraus folgt das die volle Anzahl Z-Tests nur bei Polygonen größer 64 Pixel gemacht werden können, egal ob durch Hierachical-Z oder sonstwie. Kommt also schlecht mit kleinen Polygonen zurecht.

Ja die Z-Tests in der Pixelpipeline beim IMR leiden nicht gerade an überlastung. Aber ein ähnliche Problem haben wir beim TBDR ja auch. Wenn das Shading der Pixel einer Tile länger dauert als der HSR-Test der nächsten Kachel (weil diese wenige Dreiecke enthält) laufen die HSR-Zellen auch leer.

Die Entkopplung der Vertex und Pixelshader ist bei einem TBDR fast perfekt. Beim IMR sind sie viel stärker verbunden und verursachen gewisse Probleme. Dafür hat der TBDR zwischen dem HSR-Test und den Pixelshader eine Kopplung.

Folgende Regeln gelten dabei:

IMR: Zeit zum Berechnen der Vertexdaten für ein Dreieck sollte gleich der Zeit für das Berechnen aller Pixel sein. Da das aber praktisch nicht machbar ist benutzt man entsprechende Caches die aber auch nur begrennzt helfen. Im Moment sind bei den meisten Spielen die Vertexshader unterbeschäftigt.

TBDR: Zeit zum Berechnen aller Vertexdaten sollte gleich der Zeit für das berechnen aller Pixel sein. Da der Betrachtungsrahmen grösser ist die Abhängigkeit wie gesagt viel kleiner.

Beim TBDR kommt jetzt wie gesagt noch die Kopplung zwischen HSR-Test und Pixelshader dazu. Da der Pixelshader immer um eine Tile versetzt arbeitet entstehen hier schlecht vorherzusagende Abhängigkeiten.

Die Zahl der zu berechneten Pixel ist Konstant (die Tilegrösse). Die Anzahl der Texturen und Shaderops pro Pixel schwankt. Die Anzahl der Dreiecke pro Tile ist ebenfalls dynamisch.

Für jede Tile gibt es also zwei Masszahlen:

Takte die für das HSR-benötigt werden.
Takte die für die Pixelshader benötigt werden.

Dabei muss man immer die HSR-Takte mit den Pixeltakten der vorhergehenden Tile in Realation setzten.

Sind beide gleich läuft es perfekt. Sind die HSR Takte weniger laufen die die HSR-Zellen leer. Bei weniger Pixeltakten sind die Pixelshader unterbeschäftigt.

PowerVR wird da sicher massenhaft Simulationen laufen lassen haben um das beste Verhältniss für die Anzahl der Pixelshader zu HSR-Zellen zu finden.

Aber ohne echten Chip kann man wie ja schon gesagt wurde kaum was über die Performancens im vergleich zu anderen Chips sagen. Dafür ist die Technik auf beiden Seiten (IMR und TBDR) inzwischen zu komplex.

Ailuros

2002-12-08, 13:08:57

Bei einer 32*32 Tile....

*ahem* Koennen wir uns vielleicht auf 32x16 beschrenken? Gigapixel ist nicht mehr.

OT: weiss nicht ob es schon erwaehnt wurde, aber CroTeam arbeitet an einem upgrade deren engine mit PS/VS diesmal ;)

edit: Da uebrigens SA eine Kleinigkeit ueber FP32 auf Tilern bei B3D eingeworfen hat, koennt Ihr beiden diese Kleinigkeit auch noch diskuttieren.

Demirug

2002-12-08, 13:27:16

Originally posted by Ailuros

*ahem* Koennen wir uns vielleicht auf 32x16 beschrenken? Gigapixel ist nicht mehr.

Können schon. Aber am Grundprinzip ändert sich ja dadurch nichts. Die Grösse der Tile ist auch eine Tradeoff entscheidung und ich bin nicht sicher ob PowerVr bei 32*16 bleiben wird.

Ailuros

2002-12-08, 13:38:15

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?

Thowe

2002-12-08, 13:57:56

Originally posted by Demirug

Da Patent das man dazu kennt deckt ja nur einen Teilbreich der Gesamtlösung ab. Das mit der Schreibmaske ist aus der Sicht der Datenmenge beim Binning die eher schlechtere Lösung (was aber nicht ausschliesst das die benutzt wurde). Bei einer 32*32 Tile benötigt eine solche Maske 1024 Bit = 128 Byte. Eine Randplane höchstens 12.

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.

Die Randberechnung ist ähnlich aber im Detail etwas anders weil man beim TBDR die Stream eigenschaft der verketteten Zellen ausnutzen kann.

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.

Ein Pixelstack oder so etwas in der Art wird gebraucht um mehr als einen Pixelsettingverweis pro Endpixel zu speichern. Das ist notwendig weil aufgrund von Alphablendig sich der endgültige Farbwert aus mehr als nur einem Polygon zusammensetzten kann.

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

Ja wir reden über das gleiche. Es sind aber zwei Z-Werte Der grösste und der kleinste inherhabl der Kachel.

Aber zum vollständigen Verwerfen ist nur einer erforderlich. :)

Aus diesem Grund mag Hierachical-Z kleine Polygone. Kleine Polygone bedecken weniger Kachelen und benötigen daher weniger Tests.

Kleine Polygone bedecken auch weniger Tiles.

Ja die Z-Tests in der Pixelpipeline beim IMR leiden nicht gerade an überlastung. Aber ein ähnliche Problem haben wir beim TBDR ja auch. Wenn das Shading der Pixel einer Tile länger dauert als der HSR-Test der nächsten Kachel (weil diese wenige Dreiecke enthält) laufen die HSR-Zellen auch leer.

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.

Die Entkopplung der Vertex und Pixelshader ist bei einem TBDR fast perfekt. Beim IMR sind sie viel stärker verbunden und verursachen gewisse Probleme.

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

Dafür hat der TBDR zwischen dem HSR-Test und den Pixelshader eine Kopplung.

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

Sind beide gleich läuft es perfekt. Sind die HSR Takte weniger laufen die die HSR-Zellen leer.

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

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

Ailuros

2002-12-08, 14:05:57

Quote Orgie :D

Thowe

2002-12-08, 14:09:55

Originally posted by Ailuros
Quote Orgie :D

Genau, ich liebe Orgien :D ;)

Demirug

2002-12-08, 15:16:13

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

2002-12-08, 16:16:59

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.

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.

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?

Aber zum vollständigen Verwerfen ist nur einer erforderlich. :)

Ja

Kleine Polygone bedecken auch weniger Tiles.

Auch richtig

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.

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.

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

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

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

2002-12-08, 17:12:03

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.

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.

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.

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.

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.

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.

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

Warum nicht?

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

Kleinere Dreicke bedeuten nur kleinere 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.

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.

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

2002-12-08, 17:57:10

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

2002-12-08, 18:11:59

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.

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.

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.

Ü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.

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.

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.

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.

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.

Kleinere Dreicke bedeuten nur kleinere Dreiecke. :)

Du weist wie es gemeint war. :)

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.

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

2002-12-08, 18:13:32

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

2002-12-08, 18:54:09

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

2002-12-08, 19:13:57

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.

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.

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.

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?

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?

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?

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.

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.

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.

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.

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

2002-12-08, 19:16:15

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.

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? :O
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.

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.

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.

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

2002-12-08, 19:30:40

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! ;D

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?)
:O

Thowe

2002-12-08, 19:36:28

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.

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

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

2002-12-08, 19:41:58

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

2002-12-08, 19:49:57

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:

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

2002-12-08, 19:57:07

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

2002-12-08, 20:00:13

Einigen wir uns erst einmal darauf.

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

2002-12-08, 20:17:06

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

2002-12-08, 20:27:19

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

2002-12-08, 20:47:46

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

2002-12-08, 20:52:22

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

ActionNews

2002-12-09, 09:27:35

Originally posted by Demirug
(...)
Ein TBDR wird DOOM III lieben. Wenige grosse Polygone mit aufwendigen Pixelshader und viele Stenciloperationen. PowerVRs Traum.
(...)

War das nicht einer der Gründe warum PowerVR die FableMark Demo veröffentlich hat? Kristof Beets wies dabei ja auch auf DoomIII hin und dass solche Stencilops für die Schatten dort zum Einsatz kämen! Da lag der KyroII gar nicht mal schlecht und lies die anderen Karten hinter sich. Viele meinten ja dann, dass der Fablemark einen verdammt hohen Overdraw aufweißt um den KyroII zu begünstigen, aber laut PowerVR besteht der Fablemark zu 95% aus transpatenten Polygonen und da hilft keine HSR-Einheit. Wurde das nicht auch in dem PowerVR Generations Interview erwähnt?

CU ActionNews

Demirug

2002-12-09, 10:28:32

ActionNews, der FableMark geht schon in Richtung DOOM III. In der Gesamtbetrachtung hat man allerdings die Sache die man wirklich gut kann verstärkt genutzt (Stencilops) und bei anderen Sachen sich etwas zurückgehalten (Die Pixel sind einfacher als bei DOOM III).

Ailuros

2002-12-09, 13:12:24

Kleine Unterbrechung: nur weil NV bis jetzt nicht genuegend Erfahrung mit TBDR hat, heisst es bei weitem nicht dass die Technologie und Patente in einer Schublade von Motten verfressen wird. "A little birdy told me that the results so far are very encouraging..." ;)

Exxtreme

2002-12-09, 13:14:01

Originally posted by Ailuros
Kleine Unterbrechung: nur weil NV bis jetzt nicht genuegend Erfahrung mit TBDR hat, heisst es bei weitem nicht dass die Technologie und Patente in einer Schublade von Motten verfressen wird. "A little birdy told me that the results so far are very encouraging..." ;)
Wos? Ich dachte "tiling is bad"??

Ailuros

2002-12-09, 13:22:15

Originally posted by Exxtreme

Wos? Ich dachte "tiling is bad"??

Ein nicht sehr gelungener Scherz. :D

Uebrigens koenntest Du auch mal in ATI Patenten herumschnuppern; wer weiss was ArtX da mitgebracht hat....

Dabei meinte ich im vorigen Post Gigapixel Patente und Technologie, wobei es leider wie schon erklaert um tile based deferred renderrers geht und nicht um einfache Speicher-Optimierungen auf der gleichen Architektur.

R300 ist nach wie vor ein immediate mode renderrer, mit hierarchical Z, early Z, fast Z-clear, Z Kompression etc etc.

Exxtreme

2002-12-09, 13:25:17

Nene, darum geht's nicht. Kirk David himself hat den Spruch losgelassen. War wahrscheinlich wieder eine Marketingkampagne gegen den KyroII.

Ailuros

2002-12-09, 13:25:35

Thema-Wechsel;

SA bei B3D ueber FP precision:

By the way, just thought it was a good time to mention that deferred rendering tilers have a big advantage over IMRs for high precision floating point pipelines (as most here already know).

The major problem with floating point textures and pixel pipelines at the moment is that they do not implement what has become the essential features of the integer pipeline (texture filtering, antialiasing, etc.). This substantially limits their usefulness as a general pipeline for realtime 3d graphics. They are, however, very useful for offline work where filtering can be done in (shader) software and performance is not an issue. They are also currently useful for some specialized realtime pixel shaders.

With integers it is easy to implement a large amount of computation directly in hardware in parallel. Floating point requires far more transistors to implement. As a result, it makes no sense to dedicate all those transistors to fixed functions. Allocating all those transistors to floating point only makes sense if you make the pipeline programmable.

The problem is that while you might do dozens of operations in parallel in a single clock per pipe for integer vectors, you are generally limited to as little as one (or a few) for floating point.

This was a lesson learned long ago for other types of hardware. As soon as you increase the sophistication of the data types and the computations, direct hardware implementation is no longer feasible. You must rely on software. As soon as you do this the entire hardware design picture changes dramatically. It becomes extremely important to maximize frequency, data availability, and software computation parallelism to squeeze the most out of all those transistors in each pipe. Since you can perform far fewer operations per pipe per cycle, you must increase the number of cycles and the number of pipes dramatically.

In the future, I expect to see much more emphasis on frequency and the number of pipelines than in the past.

Ailuros

2002-12-09, 13:29:11

Originally posted by Exxtreme
Nene, darum geht's nicht. Kirk David himself hat den Spruch losgelassen. War wahrscheinlich wieder eine Marketingkampagne gegen den KyroII.

*ahem*

Did you not think about combining some of the work that 3dfx and GigaPixel have done with NVIDIA architecture? Did you consider going deferred rendering or even to 'semi-defer' and cache some geometry data, sort it and then render it?

The challenge with some of those other architectures is with today's level of performance, today's capabilities, and today's requirements for software compatibility no one has really solved the compatibility issues, the corner cases if you will, of those different techniques. Without talking about future products, because someday we may solve those corner cases, we still use a more traditional pipeline in this GPU because what we want is absolute, solid compatibility and stability.

We did acquire technology down the paths of those other architectures and we've got a lot of smart people looking at it. When the time is right to include some of those other ideas, we'll be there, but its not the time for that yet.[/color]

http://www.beyond3d.com/previews/nvidia/nv30launch/index.php?p=3

loewe

2002-12-09, 19:00:59

Originally posted by ActionNews
... da hilft keine HSR-Einheit.

Falsch, gerade die HSR Einheit hilft hier. Sie ermöglicht die sehr effiziente Abarbeitung von Stencil Ops.

3dfx Voodoo5 5500

2002-12-09, 20:03:04

falls es die kyro2 nahcfolgerkarte geben sollte, dann kaufe ich die auf jeden fall, weil sie höchstwahrscheinlich wieder auf einem sehr niedrigen preislevel im vergleich zum gf fx oder 9700pro angeboten wird.

hoffe ich zumindest mal.

ActionNews

2002-12-09, 20:18:53

Originally posted by loewe

Falsch, gerade die HSR Einheit hilft hier. Sie ermöglicht die sehr effiziente Abarbeitung von Stencil Ops.

Ja OK! Ich meinte jetzt in Bezug auf den Overdraw, da ja transparent :).

CU ActionNews

loewe

2002-12-09, 21:08:16

Demirug

2002-12-09, 21:11:40

loewe, da könntest du gut recht haben. Wer immer die Chips/Karte auch bauen wird dürfte einen der Leistung angemessenen Preis verlangen. Sollte man sich endlich zu einem Highend model durcherungen haben wird man auch einen Highend Preis dafür bezahlen.

Thowe

2002-12-09, 21:14:01

Originally posted by Wolfsheim1983
falls es die kyro2 nahcfolgerkarte geben sollte, dann kaufe ich die auf jeden fall, weil sie höchstwahrscheinlich wieder auf einem sehr niedrigen preislevel im vergleich zum gf fx oder 9700pro angeboten wird.

hoffe ich zumindest mal.

Ich würde auf ein excellentes Preis/Leistungsverhältnis tippen. Wobei die Leistung am besten mit sehr beeindruckend gekennzeichnet wäre, ich bleibe persönlich dabei, das PowerVR jetzt! einen Achtungserfolg erringen muss, das Potential haben sie. In der lezten Zeit haben sie auch genau das getan was ich persönlich als das Beste ansehe, endlich eine Abnabelung von "dritten" und somit dürfte es besser durchzusetzen sein, das zu tun was sie wollen. (Grob beschrieben)

Demirug

2002-12-09, 21:18:16

We plan to do this through our well-proven IP licensing business model with the right semiconductor partner(s)

Das hört sich aber nicht danach an das man nun alles selbst machen möchte.

loewe

2002-12-09, 23:08:49

Originally posted by Demirug

Das hört sich aber nicht danach an das man nun alles selbst machen möchte.

AFAIK haben sie das auch nicht vor, aber doch ein gutes Stück mehr als früher. :D

Ailuros

2002-12-09, 23:28:56

Originally posted by Demirug
loewe, da könntest du gut recht haben. Wer immer die Chips/Karte auch bauen wird dürfte einen der Leistung angemessenen Preis verlangen. Sollte man sich endlich zu einem Highend model durcherungen haben wird man auch einen Highend Preis dafür bezahlen.

Da hat er nur teilweise recht; high end zuerst, gefolgt von mainstream und budget spin offs. Man hat den ersten als Schreier und die letzten beiden zum Massen-Verkauf, so wie halt alle anderen auch. Sonst waere ja nur ein high end chip Schwachsinn, von einer Marketing Perspektive ausgesehen.

Uebrigens wuerde ich sagen dass sehr wenig an Spezifikationen kleiner/weniger sein wird als bei der Konkurrenz. Das betrifft Sachen wie Taktraten, Speicher, Transistoren-Anzahl usw usw. Alles natuerlich unter den Limitationen wie Speicherpreise und deren Verfuegbarkeit zum gegebenen Zeitpunkt stehen werden.

Ailuros

2002-12-09, 23:31:10

*cough*prototypes*cough*

edit: testing 1..2..3

Demirug

2002-12-10, 07:35:24

Originally posted by Ailuros

Da hat er nur teilweise recht; high end zuerst, gefolgt von mainstream und budget spin offs. Man hat den ersten als Schreier und die letzten beiden zum Massen-Verkauf, so wie halt alle anderen auch. Sonst waere ja nur ein high end chip Schwachsinn, von einer Marketing Perspektive ausgesehen.

Uebrigens wuerde ich sagen dass sehr wenig an Spezifikationen kleiner/weniger sein wird als bei der Konkurrenz. Das betrifft Sachen wie Taktraten, Speicher, Transistoren-Anzahl usw usw. Alles natuerlich unter den Limitationen wie Speicherpreise und deren Verfuegbarkeit zum gegebenen Zeitpunkt stehen werden.

Ja so meinte ich das ja auch. Deswegen schrieb ich ja auch das man für einen Highend TBDR auch einen Highend Preis zahlen wird. Das man versuchen sollte den gesamten Markt abzudecken ist schon klar.

loewe

2002-12-10, 08:37:22

Originally posted by Demirug

Ja so meinte ich das ja auch. Deswegen schrieb ich ja auch das man für einen Highend TBDR auch einen Highend Preis zahlen wird. Das man versuchen sollte den gesamten Markt abzudecken ist schon klar.

Was ich auch nie anders gemeint hatte. Man spricht halt nicht nur von einer Serie5, es soll wohl auch eine werden. Nur hat PowerVR endlich erkannt, dass ein Highend Modell dabei sein muss, mit nur mainstream ist heute kein Blumentopf mehr zu gewinnen, egal ob die gut sind oder nicht.

Somit hätten wir uns endlich alle Recht gegeben, der Rest liegt jetzt bei PowerVR! :)

Ailuros

2002-12-10, 15:34:10

Das mit den Blumentoepfen muesste ein Mitrax-Fetisch sein; wobei ich immer an Norwegian Flowerpots oder Swedish Meatballs denke...komisch hm? ;D

aths

2002-12-10, 17:24:20

Originally posted by loewe
Nur hat PowerVR endlich erkannt, dass ein Highend Modell dabei sein muss, mit nur mainstream ist heute kein Blumentopf mehr zu gewinnen, egal ob die gut sind oder nicht.Dieser Logik kann ich noch nicht so ganz folgen. Wenn ein Unternehmen die Kräfte darauf konzentriert, soliden Mid-Range zu liefern, entfallen die exorbitanten Entwicklungskosten für's HighTech, für die aufwändigen Versuche mit der Taktbarkeit des Chip-Designs, und man kennt die DX- und OpenGL-Spezifikationen, für die die Karte gedacht ist, besser.

Würde PowerVR - mal theoretisch - eine DX8.1-kompatible TBR-Karte mit 4 Pipelines abliefern, das aber zu einem wirklich guten Preis, hätte die Karte imo gute Chancen. Klar ist das Image nicht so glänzend, aber um mal kurz die Krone zu haben ist sehr viel Geld zu investieren, was dann erst mal wieder verdient werden muss, ehe die Gewinne sprudeln.

Zumal über die Langlebigkeit einer Karte wohl eher hochwertige und perfomante AA/AF-Implementationen entscheidet, als in diesem Falle DX9-Support.

Quasar

2002-12-10, 19:53:27

Originally posted by aths
Zumal über die Langlebigkeit einer Karte wohl eher hochwertige und perfomante AA/AF-Implementationen entscheidet, als in diesem Falle DX9-Support.
Im Prinzip kann man deiner Argumentation folgen, aths. Aber wie so oft schliesst du von den Leuten, die sich hier im Forum herumtreiben auf die Gesamtheit der Käufer und ich möchte fast wetten, dass mehr als die Hälfte der Computerbesitzer, die auch gelegentlich mal ein Spielchen wagen, bestenfalls schonmal von FSAA gehört haben.

Wirklich Geld machen kann eine Firma in der momentanen Marktlage nur, wenn sie sowohl ein Top-Produkt hat, das leistungsmäßig mindestens mit der momentan zweitschnellsten Lösung mithalten kann und dazu ein Midrange-Produkt mit soliden Treibern und möglichst viel RAM, welches durch OEMs mittels Image-Mitnahme den Komplett-PC Käufern angedreht werden kann.

Wie du sicher weisst, war die Voodoo3 noch im Jahr des Ablebens von 3dfx der Topseller im Retailmarkt und trotzdem konnte der so generierte Profit 3dfx (real men have fabs! hätten sie vielleicht nicht so ernst nehmen sollen) nicht retten, und das obwohl man (noch) einen exzellenten Ruf in Gamerkreisen hatte.

Thowe

2002-12-10, 20:52:29

Hi aths,

sagen wir es mal so: Ein Furz ist erst dann ein Furz, wenn man ihn nicht nur riechen sondern auch hören kann. Denn nur so weisst du, aus welcher Richtung er gekommen ist.

Ailuros

2002-12-10, 23:09:51

Originally posted by aths
Dieser Logik kann ich noch nicht so ganz folgen. Wenn ein Unternehmen die Kräfte darauf konzentriert, soliden Mid-Range zu liefern, entfallen die exorbitanten Entwicklungskosten für's HighTech, für die aufwändigen Versuche mit der Taktbarkeit des Chip-Designs, und man kennt die DX- und OpenGL-Spezifikationen, für die die Karte gedacht ist, besser.

Was passiert aber wenn eine Firma die nur streng IP verkauft mehr Maerkte als nur den PC Markt anstrebt? Im Interview wird auch eine Konsolen-Moeglichkeit angegeben. DX8.1 haben wir schon in der Xbox. Entwicklungskosten sind - wenn man alle Aspekte - mitinberechnet weniger als fuer den PC space eine X Architektur zu entwicklen, fuer Konsolen Y, fuer mobile/PDA Z usw usw.

Würde PowerVR - mal theoretisch - eine DX8.1-kompatible TBR-Karte mit 4 Pipelines abliefern, das aber zu einem wirklich guten Preis, hätte die Karte imo gute Chancen. Klar ist das Image nicht so glänzend, aber um mal kurz die Krone zu haben ist sehr viel Geld zu investieren, was dann erst mal wieder verdient werden muss, ehe die Gewinne sprudeln.

NP2a oder STG5500 oder KYRO III (such Dir den Codenamen fuer gewisse vaporware selber aus :D ), war genau das, mit der Ausnahme von dx8.1 Komplianz. Mit 4 pipelines, 250/500MHz + hardwired T&L, lag die Karte ungefaehr irgendwo zwischen den GF4Ti's ohne MSAA. Mit MSAA war es wohl eine ganz andere Geschichte. Serie4 ging dank ST Micro in den Eimer und da macht es nur Sinn weiterzumachen und dem Markt geben fuer was auch hauptsaechlich angefragt wird.

Was haelt den zukuenftigen Partner von ImgTec davon ab eine 150-200$ Variant aus Serie5 auszuschlachten? Ob da nun pipelines ausgeschlachtet werden (wie bei 9500) oder nur die Taktrate reduziert, ist dem Endverbraucher eigentlich egal, solange er eine gute Preis/Performance Relation in seine Maschine bekommt.

Zumal über die Langlebigkeit einer Karte wohl eher hochwertige und perfomante AA/AF-Implementationen entscheidet, als in diesem Falle DX9-Support.

War denn der Anhalt einer etwas aehnlichen Diskussion auf mitrax.de nicht irgendwo zwischen den Linien, dass IMR's zu viel an Effizienz gewonnen haben in der Zwischenzeit. Wobei ein high end TBR heute sowohl wie auch in der Zukunft Vorteile haben kann. Und da der Markt auch ein endloses perpetuum mobile in gewissem Sinne ist: siehe meinen ersten Kommentar in diesem Post ;)

Ailuros

2002-12-10, 23:12:21

Originally posted by Thowe
Hi aths,

sagen wir es mal so: Ein Furz ist erst dann ein Furz, wenn man ihn nicht nur riechen sondern auch hören kann. Denn nur so weisst du, aus welcher Richtung er gekommen ist.

Hmmm ja man kann ihn aber nicht sehen!!! :chainsaw:

aths

2002-12-11, 15:08:51

Originally posted by Quasar
Wirklich Geld machen kann eine Firma in der momentanen Marktlage nur, wenn sie sowohl ein Top-Produkt hat, das leistungsmäßig mindestens mit der momentan zweitschnellsten Lösung mithalten kann und dazu ein Midrange-Produkt mit soliden Treibern und möglichst viel RAM, welches durch OEMs mittels Image-Mitnahme den Komplett-PC Käufern angedreht werden kann.Originally posted by Thowe
Hi aths,

sagen wir es mal so: Ein Furz ist erst dann ein Furz, wenn man ihn nicht nur riechen sondern auch hören kann. Denn nur so weisst du, aus welcher Richtung er gekommen ist. Originally posted by Ailuros
NP2a oder STG5500 oder KYRO III (such Dir den Codenamen fuer gewisse vaporware selber aus :D ), war genau das, mit der Ausnahme von dx8.1 Komplianz. Mit 4 pipelines, 250/500MHz + hardwired T&L, lag die Karte ungefaehr irgendwo zwischen den GF4Ti's ohne MSAA. Mit MSAA war es wohl eine ganz andere Geschichte. Serie4 ging dank ST Micro in den Eimer und da macht es nur Sinn weiterzumachen und dem Markt geben fuer was auch hauptsaechlich angefragt wird.Kyro hat den Markt doch schon - für eine Zeit - verändern können. Günstiger als eine GeForce2 MX, schneller als diese, und das mit fortschrittlichen Features (8x MT, EMBM). Selbst in der Genre-Presse wurde Kyro erwähnt. Der wirklich breite Erfolg blieb aus, aber mit insgesamt nur 2 Produkten (Kyro und Kyro2) ist natürlich kein allgemeines Umdenken zu bewirken. Gäbe es seit Kyro immer eine kostengünstige Alternative für die Mittelklasse, hätte das m.E. deutliche Auswirkungen auf den Markt gehabt, und vielleicht wäre doch so mancher wach geworden und hätte gesehen, dass andere unter großem Namen oftmals nur Schund verkaufen.

Power-Gamer brauchen etwas größeres, und wegen eingeschränkten FSAA-Fähigkeiten bzw. praktischer Unbenutzbarkeit von AF, oder auch nur TF auf Kyro, wäre diese Karte für diese Zielgruppe nicht in der engeren Wahl. Diese Gruppe ist aber schmal.

Intelligente Marketing-Konzepte, z.B. Bundelung der Kyro mit begehrten Spielen inkl. große Ankündigung dessen, hätte einige dazu bringen können, sich diese Hardware wenigstens mal anzusehen. Dann wäre jener von ATI Rage128 nicht auf GeForce2 MX, sondern vielleicht auf Kyro umgestiegen. Nur weil nVidias Marketing so ausgelegt ist, ihre kleinen Spin-offs mit den Namen der großen Flaggschiffe in Verbindung zu bringen heißt das ja nicht, dass reine Mittelklassen-Kampagnen aussichtslos wären.

PowerVR war einfach zu technisch. Mit den - sehr interessanten und lehrreichen - Techdemos locken sie kaum die möglichen Käufer an. Sie hätten ihre Hardware als pfiffige und dabei preiswerte Alternative für den Normalgamer anpreisen sollen. Mit Hercules gab es außerdem einen Vertrieb mit sehr gutem Namen. Die waren alle zusammen einfach zu verzagt.

Man muss dem Käufer ja auch keine komplizierten Erklärungen zum TBR zumuten, sondern könnte einfach mit Benchmarks werben, anstatt die MHz-Zahlen an die große Glocke zu hängen. Bei jedem Spiele-Bundle mit Kyro hätte es einen Press Release geben können, welcher die Effizienz der Karte hervorhebt und die Konkurrenz der Verschwendung von HW-Ressourcen bezichtigt.

Ailuros

2002-12-11, 16:28:36

aths,

Im Grunde hast Du schon recht aber KYRO III war fertig fuer Massen-Produktion Anfang dieses Jahres; das Pech lag daran dass ST Micro aus dem Graphiksmarkt ausgestiegen ist.

Es sah etwa so aus:

STG5500
13um
4 pipelines/1TMU
128bit bus
250/500MHz
dx7 T&L
iDCT unit
dual RAMDAC

Preis etwa um die 200$, wenn nicht ein bisschen mehr. Nach sechs Monaten war ein refresh von ST Micro geplant - STG5800 - auf 300MHz.

Die uralte roadmap war um so einiges anders vor geraumer Zeit. Schon vor dem Vertrag mit ST Micro wurde die roadmap geaendert und Series5 unterging einem kompletten re-Design. ST lizensierte damals Serie3, 4 und 5, und das genau aus dem Grund das eine sehr gewisse Strategie geplant war.

Natuerlich dachte ST dass man dicken Gewinn von einem Tag auf den anderen machen koennte, aber da haben die viel zu wenig investiert und zu wenig Geduld gehabt. Plus der Markt wurde ueberaus kritisch fuer alle Firmen, wo sie sich selbstverstaendlich auf ihr Hauptgeschaeft konzentriert haben und dass Graphiks-Nebengeschaeft dicht gemacht.

Vertraege mit ImgTec fuer den PDA/mobile Markt sind natuerlich nach wie vor gueltig, da da dicke Kohle drinsteckt ;)

Ailuros

2002-12-11, 16:42:48

Power-Gamer brauchen etwas größeres, und wegen eingeschränkten FSAA-Fähigkeiten bzw. praktischer Unbenutzbarkeit von AF, oder auch nur TF auf Kyro, wäre diese Karte für diese Zielgruppe nicht in der engeren Wahl. Diese Gruppe ist aber schmal.

KYRO bekam uebrigens den exact gleichen lahmen anisotropic Algorithmus von Serie2/Neon250. Ich hab dass Thema mit Absicht ins Interview eingeschlossen.

Dass uebrigens 8-layer MT oder EMBM in den Spezifikationen lag, imponierte mir persoenlich nie. TBDR's sind eben optimal wenn's zum multitexturing oder nur texturing kommt (siehe EMBM = texture read) oder Farbenberechnungen. Wenn mich mein Gedaechtnis nicht betruegt ist KYRO theoretisch faehig fuer bis zu 32 Texturen/pass, wobei aber nur (na wenigstens bis zum 15xx Treiber) 4 Texturen/pass in OGL und 8 Texturen/pass durch die Treiber freigeschaltet wurden.

Man muss dem Käufer ja auch keine komplizierten Erklärungen zum TBR zumuten, sondern könnte einfach mit Benchmarks werben, anstatt die MHz-Zahlen an die große Glocke zu hängen. Bei jedem Spiele-Bundle mit Kyro hätte es einen Press Release geben können, welcher die Effizienz der Karte hervorhebt und die Konkurrenz der Verschwendung von HW-Ressourcen bezichtigt.

Soll ich jetzt zitieren womit damals geworben wurde von Hercules, was auf der Schachtel und in den Beilagen stand? Es gab hier sogar lokale Radio-Werbung wo behauptet wurde dass man mit nur 150$ GF2Ultra Performance bekommen kann....aechz. Deshalb vertrau ich Marketing und PR Leuten auch auesserst selten.

mapel110

2002-12-11, 20:58:12

Originally posted by loewe

Was ich auch nie anders gemeint hatte. Man spricht halt nicht nur von einer Serie5, es soll wohl auch eine werden. Nur hat PowerVR endlich erkannt, dass ein Highend Modell dabei sein muss, mit nur mainstream ist heute kein Blumentopf mehr zu gewinnen, egal ob die gut sind oder nicht.

Somit hätten wir uns endlich alle Recht gegeben, der Rest liegt jetzt bei PowerVR! :)

hi loewe, lang nichts mehr von dir gehört :)
weiss man schon, wann powervr etwas neues vorstellen wird ? afaik gibt es gerüchte, dass zur cebit wieder etwas kommt. hast du da mehr einblicke ?

loewe

2002-12-12, 10:44:45

Originally posted by aths
Dieser Logik kann ich noch nicht so ganz folgen. Wenn ein Unternehmen die Kräfte darauf konzentriert, soliden Mid-Range zu liefern, entfallen die exorbitanten Entwicklungskosten für's HighTech, für die aufwändigen Versuche mit der Taktbarkeit des Chip-Designs, und man kennt die DX- und OpenGL-Spezifikationen, für die die Karte gedacht ist, besser.
Wenn alle Menschen vernünftig wären hättest du sicher recht, aber sie sind es nicht und soweit ich das beurteilen kann, werden sie es auch nie.
Die Klientel die durch Gamerakrten angesprochen wird besteht weniger aus Leuten wie uns, sondern eher aus einer etwas jüngeren Altersgruppe, so wie meine Schüler. Dort kennt man aber nur Namen wie NVidia, ATI geht gerade noch so, aber KYRO und PowerVR sind nicht sehr verbreitet. Warum kennen sie aber NVidia nicht weil sie alle GF4Ti Karten hätten, sondern weil halt mit den Highend Karten der Name bestimmt wird. Verfügen tun sie in der Regel selbst nur selten über Karten der Leistungsklasse GF4MX, weshalb sie natürlich auch nur CS spielen können, für viele ist selbst Q3A schon zu anspruchsvoll.

Würde PowerVR - mal theoretisch - eine DX8.1-kompatible TBR-Karte mit 4 Pipelines abliefern, das aber zu einem wirklich guten Preis, hätte die Karte imo gute Chancen. Klar ist das Image nicht so glänzend, aber um mal kurz die Krone zu haben ist sehr viel Geld zu investieren, was dann erst mal wieder verdient werden muss, ehe die Gewinne sprudeln.
Mit etwas mehr Engagement von Seiten STM hätte die K3 genau so etwas werden können, aber dort wollte man mit Null Aufwand schnell viel Geld verdienen, hat nicht so geklappt.

Zumal über die Langlebigkeit einer Karte wohl eher hochwertige und perfomante AA/AF-Implementationen entscheidet, als in diesem Falle DX9-Support.
Ist auch so eine Sache, ich gebe dir zwar Recht, aber die oben genannte Zielgruppe kennt diese Begriffe überhaupt nicht, die spielen eher mit Einstellungen, das jammert einen Hund. Aber was willst du mit ner GF2MX oder weniger auch machen, FSAA oder AF sind da nicht von Bedeutung.

loewe

2002-12-12, 10:50:32

Originally posted by mapel110

hi loewe, lang nichts mehr von dir gehört :)
Hi, das real life beschäftigt mich doch gegenwärtig ganz schön. :)
weiss man schon, wann powervr etwas neues vorstellen wird ? afaik gibt es gerüchte, dass zur cebit wieder etwas kommt. hast du da mehr einblicke ?
Was soll ich sagen, ich habe zwar was gehört, kann aber darüber nicht sprechen. Offiziell weiß ich natürlich aber gar nichts! =)

Sagen wir es mal so, wenn ImgTec auf der CeBIT sein sollte, immerhin wollen ja wohl etwa ein drittel der Austeller des letzten Jahres nicht kommen, dann könnte da auch was Neues kommen.

aths

2002-12-12, 11:46:05

Originally posted by Ailuros
Soll ich jetzt zitieren womit damals geworben wurde von Hercules, was auf der Schachtel und in den Beilagen stand? Es gab hier sogar lokale Radio-Werbung wo behauptet wurde dass man mit nur 150$ GF2Ultra Performance bekommen kann....aechz. Deshalb vertrau ich Marketing und PR Leuten auch auesserst selten. Genau das schlug ich ja nicht vor - sich mit den Flaggschiffen messen zu wollen, sondern eher an den "vernünftigen" Mid-Range-Käufer zu appellieren. Mit ein paar Radiowerbungen ists auch nicht getan, und man muss natürlich beständig auf Markt präsent sein.Originally posted by loewe
Mit etwas mehr Angagement von Seiten STM hätte die K3 genau so etwas werden können, aber dort wollte man mit Null Aufwand schnell viel Geld verdienen, hat nicht so geklappt.Ohne umfassendes Konzept und öfter mal neuen Produkten hat es eine neuartige Technik natürlich schwer. Wenn deine Schüler nicht Kyro und Kyro2 kennen, vielleicht hätten sie dann was von der Kyro3 gehört...

Thowe

2002-12-12, 12:31:46

Mal als Gedankenanstoß das ich der Ansicht bin das PowerVR HighEnd bringen muss.

Es liegt nicht in der Natur des Menschen über den zweiten zu reden, sprich - mit olypisches Silber kommst du zwar aufs Treppchen, aber alle werden sich nur an den erinnern, der Gold hat.

Also bringt PowerVR eine echte Klasse für sich als Karte, dann ist das Potential der Mund zu Mund-Propaganda hoch genug, das viele sich eben diese Karten kaufen oder die kleinen Geschwister. Das ist eben das Konzept das bei NV fruchtet, es ist eben die explizite Nachfrage nach den Produkten. Was letztendlich in einen reinen Office-Rechner landet, das ist eh egal. Aber nVidia hat ein sehr hohes Goodwill und das eben durch sehr gute Image-Werbung und ein Teil davon ist es halt, das man mit den Wölfen heult, aber nur lauter.

aths

2002-12-12, 12:49:20

Originally posted by Thowe
Aber nVidia hat ein sehr hohes Goodwill und das eben durch sehr gute Image-Werbung und ein Teil davon ist es halt, das man mit den Wölfen heult, aber nur lauter. Das Problem hierbei ist, dass es nur einen geben kann. PowerVR muss sich sowohl gegen nV als auch ATI behaupten, und beide würden, falls sie ausgestochen würden, mit Macht versuchen an die Spitze zurück zu gelangen. Mal kurz King of the Hill zu sein, nützt imo wenig - siehe ATI. Und den Kampf "da oben" durchzustehen kostet viel Geld. Würde man das lassen, wäre man weniger bekannt und würde weniger verkaufen - aber dafür muss man nicht zunächst erst mal die exorbitanten Kosten für das letzte HighEnd-Produkt verdienen, ehe sich die Entwicklung rentiert.

Für den HighEnd-Markt wäre es natürlich nur wünschenswert, wenn das momentane Duopol ATI+nV Konkurrenz bekomment.

Außerdem glaube ich noch immer daran: Matrox wird Buße tun und umkehren.

zeckensack

2002-12-12, 12:55:51

Egal,

Die Hauptsache ist, daß Intel endlich aufhört integrierte Grafik(hrhr)kerne zu verkaufen ;)

ollix

2002-12-12, 13:11:22

Originally posted by Ailuros Wenn mich mein Gedaechtnis nicht betruegt ist KYRO theoretisch faehig fuer bis zu 32 Texturen/pass, wobei aber nur (na wenigstens bis zum 15xx Treiber) 4 Texturen/pass in OGL und 8 Texturen/pass durch die Treiber freigeschaltet wurden.Das gleiche hatte ich auch schon gehört, aber es sind AFAIK in D3D nicht mehr als 8 Texturen vorgesehen...

loewe

2002-12-12, 13:27:48

Originally posted by aths
Das Problem hierbei ist, dass es nur einen geben kann. PowerVR muss sich sowohl gegen nV als auch ATI behaupten, und beide würden, falls sie ausgestochen würden, mit Macht versuchen an die Spitze zurück zu gelangen.

Das sehe ich ähnlich. PowerVR ist wohl kaum in der Lage solche Produktzyklen wie ATI oder NVidia durch zu halten, wobei die es selbst ja auch kaum noch schaffen. Die Serie5 wird sicher wieder für 2 Jahre reichen müssen, bevor etwas wirklich Neues kommt.
Ich kann mir aber vorstellen, dass PowerVR gerade in den von dir geforderten Bereichen so einen grossen Sprung machen wird, dass es den anderen schwer fallen wird dieses Niveau mit der nächsten Karte zu erreichen.
Z.B. 16 faches MSAA nahezu for free dürfte mit IMRs recht schwer erreichbar sein, womit ich natürlich nichts gesagt haben will.

2002-12-12, 13:35:07

Originally posted by ollix
Das gleiche hatte ich auch schon gehört, aber es sind AFAIK in D3D nicht mehr als 8 Texturen vorgesehen...

Das ist richtig fuer D3D, in OGL sind es aber lt. zeckensack bis zu 32Tex/pass. Und da macht der Kyro Treiber nur 4.

Die max. Anzahl Tex/pass ist afaik ueberhaupt nicht begrenzt beim Kyro.

Demirug

2002-12-12, 13:55:41

Originally posted by ow

Das ist richtig fuer D3D, in OGL sind es aber lt. zeckensack bis zu 32Tex/pass. Und da macht der Kyro Treiber nur 4.

Die max. Anzahl Tex/pass ist afaik ueberhaupt nicht begrenzt beim Kyro.

Ganz unbegrennzt kann es eigentlich nicht sein. Irgendwo muss der Chip ja die Blendsteps zwischen speichern. Was mich aber mal wirklich interresieren würde ist folgedens:

Was macht der der PowerVr Chip wenn man sagen wir mal 256 Dreiecke mit Alpha-blending übereinander legt und dabei ganz langsam (in Schritten zu 1) einen Farbkanal erhöht. Und als letztes noch einmal ein überdeckendes Dreieck darüber.

Aber ich schweife ab.

Xmas

2002-12-12, 14:07:01

Originally posted by Demirug
Was macht der der PowerVr Chip wenn man sagen wir mal 256 Dreiecke mit Alpha-blending übereinander legt und dabei ganz langsam (in Schritten zu 1) einen Farbkanal erhöht. Und als letztes noch einmal ein überdeckendes Dreieck darüber.
Hm? Wenn am Schluss ein überdeckendes Dreieck darüber kommt, werden die anderen doch gar nicht gerendert.

Demirug

2002-12-12, 14:16:20

Originally posted by Xmas

Hm? Wenn am Schluss ein überdeckendes Dreieck darüber kommt, werden die anderen doch gar nicht gerendert.

OK unglücklich ausgedrückt. Den gleichen Test einmal ohne und einmal mit dem abschliessende Dreieck und am besten sogar mit variabler Anzahl von Schichten. Die Sache um die es mir geht ist folgende. Wie viele Pixeloperationen kann der Chip zwischenspeichern bevor er entweder Fehler macht oder gezwungen wird Pixel für die noch nicht alle Polygone durchs das HSR gelaufen sind doch schon zu berechnen und den Operationsstack für diesen Pixel wieder leer zu bekommen.

aths

2002-12-12, 15:05:06

Originally posted by loewe
Z.B. 16 faches MSAA nahezu for free dürfte mit IMRs recht schwer erreichbar sein, womit ich natürlich nichts gesagt haben will. Das klingt aber schon wieder böse nach OGMSAA, und da ist ja ATIs 6x MSAA-Lösung qualitätsmäßig überlegen.

Vielleicht hätte ich mich weiter oben im Thread so ausdrücken sollen: Wenn PowerVR ein HighEnd-Geschoss bauen will, sollen sie ruhig. Hauptsache, sie übersehen nicht den Massenmarkt und bieten auch günstige (und dabei trotzdem kraftvolle) Lösungen an.

Es müssen ja nicht 16 verschiedene Produkte sein (soviel hat nVidia alleine aus der GeForce2 inkl. Ablegern gemacht, wenn ich mich nicht verzählt habe.)

ActionNews

2002-12-12, 15:36:28

16xFSAA ? Hmm...das wäre sicher mal was :D!

Aber wegen Highend....also falls PowerVR tatsächlich Highend mit der Serie 5 anstrebt, dann werden sie sicher auch günstige Ableger bringen. Ein reines Highend-Flaggschiff kann sich niemand erlauben, weil sowas nur die wenigsten bezahlen könnten. Und wenn ich den EE Times Artikel (http://www.eet.com/semi/news/OEG20021003S0016) richtig in erinnerung habe, dann soll die Serie 5 ja ein sehr variables design bekommen und günstigere Ableger sollten kein Problem sein, oder hab ich das falsch verstanden?...moment...hier:

Metcalfe said that Series-5 architecture would be based on a primary processing pipeline and a series of hardware accelerators that can be optionally switched in and out to render graphics.

CU ActionNews

Kampfsau

2002-12-12, 15:58:34

Dito!

Wir sollten uns um die Leistung und die Ableger keine Sorgen machen, denn da macht PowerVR meiner Meinung nach alles richtig.
Vielmehr beunruhigt mich, ob sie einen Partner finden, der produziert und wieviel der Spass kosten wird!

Ailuros

2002-12-12, 16:48:12

Ohne umfassendes Konzept und öfter mal neuen Produkten hat es eine neuartige Technik natürlich schwer. Wenn deine Schüler nicht Kyro und Kyro2 kennen, vielleicht hätten sie dann was von der Kyro3 gehört...

Ich hab das Gefuehl aths, dass ich die Ereignisse/Tatsachen rund um PVR/ST Micro in diesem Jahr unendliche Male posten kann, genauso wie die roadmap, ohne dass es jemand versteht.

ST Micro entschied sich in 1999 mit ImgTec ins Geschaeft zu setzen. Die letzteren hatten gerade ihre komplette roadmap erneuert wobei Serie4 einen anderen Prozess und hoeheren Takt bekam und Serie5 einen kompletten re-Design.

Serie3= budget
Serie4= mainstream und budget
Serie5= high end, mainstream und budget

Es macht nur absoluten Sinn wenn jemand in den Graphikmarkt eintritt, dass man Schritt fuer Schritt sich in diesem aufbaut, und so war es auch vorgesehen. ST Micro ist Vergangenheit und obwohl Serie4 Produktionsreif war, war es fast unmoeglich eine Karte basierend auf diesem Design noch herauszubringen:

a) PVR haelt das Design-IP, und ST dass Manufacturing-IP. Ohne semiconductor konnte ImgTec den chip nicht herstellen/vermarkten, also waere ein neuer Partner dafuer eine Alternative.

b) Der neue Partner waere gezwungen gewesen von beiden Firmen oben dass IP abzukaufen, wobei ich schon in diesem Thread ausfuehrlich erklaert habe, wer der Partner war und warum es daneben gegangen ist.

c) Ohne ST's Manufacturing-IP hiess es wohl den Design von ImgTec abkaufen und mit der prototype Produktion von null nochmal anfangen, was es nicht mehr wert war. Der Design war schon zu alt dafuer und haette zuviel Zeit und Geld gekostet um nur auf ein weiteres ultra-budget Produkt zu resultieren.

Das sind alles Nebenerscheinungen und negative Aspekte die mit einem IP-selling Konzept mitinbegriffen sind.

Am Ende von 2002 eine dx7 kompliante Karte auf 250MHz zu veroeffentlichen ist Schwachsinn, ueberhaupt wenn Serie5 schon so weit in der Entwicklung liegt.

Das klingt aber schon wieder böse nach OGMSAA, und da ist ja ATIs 6x MSAA-Lösung qualitätsmäßig überlegen.

Ich hab bis jetzt noch keine Kleinigkeiten was FSAA betrifft, aber ich wuerde selber nicht rotated oder sparsely sampled grid von PVR erwarten. Dahingegen ist mein anisotropic Bild ein bisschen klarer.

Was mich bei ATI so weit stoert, ist dass wenn man nicht das Pech hat ein 16bit Spiel spielen zu wollen, dass man manchmal auch ein bisschen beten muss das MSAA selbst in 32bit manchmal laeuft. Die beste Loesung fuer sparsely sampled patterns waere ein Accumulations-buffer, aber der Aufwand fuer die Implementation ist dafuer zu gross, so dass viele IHV's davon abscheuen. Leider ist selten etwas perfekt mit solchen Methoden.

Uebrigens bezweichle ich jetzt schon dass wer immer auch der Partner von ImgTec sein mag, dass ein so dynamischer Eintritt in den Markt passiert, dass sich weder ATI oder NV groessere Sorgen machen sollten. Ausser es wird einem anderem Markt der Vorsprung geliehen um NV die Hosen ein bisschen runterzuziehen; nichtsdestominder es ist schon mal passiert in der Vergangenheit :D

loewe

2002-12-12, 19:19:20

Originally posted by aths
Das klingt aber schon wieder böse nach OGMSAA, und da ist ja ATIs 6x MSAA-Lösung qualitätsmäßig überlegen.

Da können wir wirklich alle nur spekulieren, dafür ist dieses Board ja da! :)

Ob PowerVR jetzt ein OGMSAA oder ein RGMSAA oder ein ganz anderes Verafahren verwenden wird, wissen wir nicht, müssen wir also abwarten. Was ich aber weiß ist, das ihnen durchaus trickreiche Verfahren zur Samplepositionsbestimmung zu zutrauen sind.

loewe

2002-12-12, 19:28:48

Originally posted by Demirug
OK unglücklich ausgedrückt. Den gleichen Test einmal ohne und einmal mit dem abschliessende Dreieck und am besten sogar mit variabler Anzahl von Schichten. Die Sache um die es mir geht ist folgende. Wie viele Pixeloperationen kann der Chip zwischenspeichern bevor er entweder Fehler macht oder gezwungen wird Pixel für die noch nicht alle Polygone durchs das HSR gelaufen sind doch schon zu berechnen und den Operationsstack für diesen Pixel wieder leer zu bekommen.
Ich verstehe das Problem nicht so ganz.
Die HSR Einheit testet für ein Polygone alle Pixel durch, bis ein Polygone gefunden wird, das undurchsichtig ist oder eben alle Polygone durch sind. Die vor dem undurchsichtigen Polygon liegenden durchsichtigen Polygone werden in einer extra Liste in richtiger Reihenfolge im Speicher gesammelt und dann später fürs Blending verwendet. Sicher gibt es da irgendwo eine Grenze, es werden doch aber nur Zeiger gespeichert, da sollte das eine Weile dauern.

Demirug

2002-12-12, 20:31:05

Originally posted by loewe

Ich verstehe das Problem nicht so ganz.
Die HSR Einheit testet für ein Polygone alle Pixel durch, bis ein Polygone gefunden wird, das undurchsichtig ist oder eben alle Polygone durch sind. Die vor dem undurchsichtigen Polygon liegenden durchsichtigen Polygone werden in einer extra Liste in richtiger Reihenfolge im Speicher gesammelt und dann später fürs Blending verwendet. Sicher gibt es da irgendwo eine Grenze, es werden doch aber nur Zeiger gespeichert, da sollte das eine Weile dauern.

loewe, bei diesem massiv Alpha Test handelt es sich um einen super gemeinen Test für einen TBDR. Der Grund dafür ist einfach.

Alle transparenten Layer werden mit der gleichen Z-Koordinate gezeichnet. Diese werden nun ganz normal in Tiles zerlegt. Soweit so gut. Jetzt kommt die HSR Einheit zum Zug. Diese bearbeitet nun Polygon für Polygon. Da Alpha-Blending aktiv ist müssen die Infos für den darunter liegenden Pixel jeweils irgendwo gespeichert werden. Wenn diese Overdraw liste im RAM hinterlegt wird sollte es kein Problem sein (ausser der Speicherblock dafür ist zu klein). Genau diese Information hatte ich aber nicht. Ich war mir nicht sicher wo die Overdraw Liste hinterlegt ist und ging davon aus das aus performancen Gründen die Liste vollständig im Chip gehalten wird.

loewe

2002-12-12, 20:56:50

Originally posted by Demirug

loewe, bei diesem massiv Alpha Test handelt es sich um einen super gemeinen Test für einen TBDR. Der Grund dafür ist einfach.

Alle transparenten Layer werden mit der gleichen Z-Koordinate gezeichnet. Diese werden nun ganz normal in Tiles zerlegt. Soweit so gut. Jetzt kommt die HSR Einheit zum Zug. Diese bearbeitet nun Polygon für Polygon. Da Alpha-Blending aktiv ist müssen die Infos für den darunter liegenden Pixel jeweils irgendwo gespeichert werden. Wenn diese Overdraw liste im RAM hinterlegt wird sollte es kein Problem sein (ausser der Speicherblock dafür ist zu klein). Genau diese Information hatte ich aber nicht. Ich war mir nicht sicher wo die Overdraw Liste hinterlegt ist und ging davon aus das aus performancen Gründen die Liste vollständig im Chip gehalten wird.

Kann ich zwar nicht beweisen, aber da bin ich sicher, die Liste liegt im RAM.
Das das sehr bösartig ist, ist mir klar. Nicht umsonst hat KYRO solche schlimmen Probleme mit Nebel etc., da ist der Chip dann einfach nicht leistungsfähig genug.

Dein Problem mit den 256 Stufen wäre trotzdem mal interessant, vor allem mal zu sehen wie sich dort KYRO im Verhältnis zu anderen schlägt. Sicher ist es Stress, aber ja wohl für jede Karte!

Demirug

2002-12-12, 21:12:17

Ich habe demnächst Urlaub. Dann könnte ich so einen Test schreiben. Du hast doch sicher eine Kyro zum testen, oder?

2002-12-12, 21:19:21

Hier! (Kyro&testen:D)

loewe

2002-12-12, 21:42:20

Originally posted by Demirug
Ich habe demnächst Urlaub. Dann könnte ich so einen Test schreiben. Du hast doch sicher eine Kyro zum testen, oder?
Jede die du haben willst!
Ich kann also KYRO I, KYRO II und auch KYRO IISE bieten, mehr dürfte gegenwärtig außerhalb von PowerVR nicht zu bekommen sein.:)
Sicher wäre eine von den existierenden K3 nicht schlecht, aber da haben wir keine Chance! :(

Ailuros

2002-12-12, 22:03:15

Originally posted by loewe

Da können wir wirklich alle nur spekulieren, dafür ist dieses Board ja da! :)

Ob PowerVR jetzt ein OGMSAA oder ein RGMSAA oder ein ganz anderes Verafahren verwenden wird, wissen wir nicht, müssen wir also abwarten. Was ich aber weiß ist, das ihnen durchaus trickreiche Verfahren zur Samplepositionsbestimmung zu zutrauen sind.

Eventuell in Simon Fenney's Arbeits-Computer einbrechen, wuerde um so manches helfen hehehehe ;D

Ailuros

2002-12-12, 22:10:15

Demirug,

Was meinst Du mit "Overdraw-Liste"?

Demirug

2002-12-12, 22:10:39

Originally posted by loewe

Da können wir wirklich alle nur spekulieren, dafür ist dieses Board ja da! :)

Ob PowerVR jetzt ein OGMSAA oder ein RGMSAA oder ein ganz anderes Verafahren verwenden wird, wissen wir nicht, müssen wir also abwarten. Was ich aber weiß ist, das ihnen durchaus trickreiche Verfahren zur Samplepositionsbestimmung zu zutrauen sind.

Wenn man bei 32 Pixel Tile Breite bleibt reichen 128 HSR-Zellen um ein 4x RGMSAA zu realisieren. Und von mindestens 128 Zellen gingen wir ja sowieso schon aus.

Demirug

2002-12-12, 22:16:31

Originally posted by Ailuros
Demirug,

Was meinst Du mit "Overdraw-Liste"?

Richtig müsste es wohl "Produktiv Overdraw Liste" heisen. Als Ergebnis des HSR muss der Chip ja für jeden Pixel eine Anweisungs-Liste erzeugen in der hinterlegt ist wie die entgültige Pixelfarbe zu berechnen ist. Wenn man nun massiv Alpha-Blendig betreibt wird die Liste sehr lang.

Ailuros

2002-12-13, 07:11:11

Um nochmal auf die maximale MT Kapazitaet von KYRO zurueckzukommen: als ich damals fragte wo genau die "unlimitierte" Texturenanzahl pro pass endet (es gibt nichts das unlimited ist in 3D so wie ich das sehe), war die Antwort 32 Texturen/pass.

Es ist sowieso Schwachsinn mehr als 8MT auf ner KYRO freizusetzen, da dann andere Bottlenecks zum Vorschein kommen werden und wir immer noch bei quad-texturing sind in der Mehrheit von Spielen.

Ailuros

2002-12-13, 07:15:46

Originally posted by Demirug

Wenn man bei 32 Pixel Tile Breite bleibt reichen 128 HSR-Zellen um ein 4x RGMSAA zu realisieren. Und von mindestens 128 Zellen gingen wir ja sowieso schon aus.

Ich hab schon mal angedeutet dass SimonF bei B3D andeutete dass ordered grid patterns fuer Ihn weniger noise im Labor vorzeigte als rotated grid. Fenney ist schon von Anfang an bei Videologic/PVR und ist soweit ich weiss fuer den Design von Algorithmen zustaendig.

Obwohl dass keine definitive Anzeige sein kann, sieht es eher verdammt verdaechtig nach ordered grid aus.

Demirug

2002-12-13, 07:41:34

Originally posted by Ailuros
Um nochmal auf die maximale MT Kapazitaet von KYRO zurueckzukommen: als ich damals fragte wo genau die "unlimitierte" Texturenanzahl pro pass endet (es gibt nichts das unlimited ist in 3D so wie ich das sehe), war die Antwort 32 Texturen/pass.

Es ist sowieso Schwachsinn mehr als 8MT auf ner KYRO freizusetzen, da dann andere Bottlenecks zum Vorschein kommen werden und wir immer noch bei quad-texturing sind in der Mehrheit von Spielen.

Ja ich würde nur gerne wissen ob das limit nun 32 Texturen/pass oder möglicherweise 32 Texturen/Pixel ist. Deswegen ja auch der Test den ich oben vorgeschlagen habe.

Demirug

2002-12-13, 07:44:15

Originally posted by Ailuros

Ich hab schon mal angedeutet dass SimonF bei B3D andeutete dass ordered grid patterns fuer Ihn weniger noise im Labor vorzeigte als rotated grid. Fenney ist schon von Anfang an bei Videologic/PVR und ist soweit ich weiss fuer den Design von Algorithmen zustaendig.

Obwohl dass keine definitive Anzeige sein kann, sieht es eher verdammt verdaechtig nach ordered grid aus.

Es ging mir auch mehr darum das auch mit der HSR-Technik von PowerVR ein RG technisch nicht ganz aus der Luft gegriffen wäre sonder mit relative geringem Aufwand zu realisieren wäre. Ein OG ist natürlich noch einfacher zu machen.

Ailuros

2002-12-13, 14:40:33

OT: Hat schon jemand den Wildcat VP560 (P9) Review bei Tilebase.de gelesen? Sieht nicht allzu schlecht aus im Vergleich zu VP760, aber so "deferred" erscheint mir Slipstream nun auch wieder nicht, wenn ich es mit der K2 und deren Spezifikationen vergleiche.

Schon klar Wildcats sind nicht fuer Spiele optimiert, aber....

ActionNews

2002-12-13, 15:05:50

Ja ich hab's gelesen :)!
Schade, dass Slipstream derzeit anscheinend nur unter DirectX läuft :(! Solche Karten sind IMHO mehr auf OpenGL ausgelegt. Naja und von der Grundgeschwindigkeit ist der VP560 auch nicht so berauschend, aber eigentlich auch kein Wunder, wenn man bedenkt dass fast alles abgespeckt wurde (man könnte sagen es ist nur ein halber VP760 ;) ).
Auf der anderen Seite beeindruckt mich dann doch der Geschwingikeitszuwachs mit Slipstream.
Aber eine Frage: Kann die VP560 Slipstream einfach hinzu oder abschalten? Ist sowas mit einem TBDR möglich?

CU ActionNews

Demirug

2002-12-13, 21:09:33

Ich habe ja schon in einem anderen Thread gesagt das Slipstream wohl nur einen Teil der Framedaten buffern kann und sobald dieser Buffer voll ist muss man etwas Platz machen indem man eine Tile schon mal auf Verdacht vorrendert. Kommt dann später noch was dazu muss die Tile nochmal angefasst werden. Das Verfahren hat den Vorteil das dabei niemals der Binning Speicher ausgehen kann. Die Frage dabei ist nur in wie weit diese Buffergrösse variable ist.

ActionNews, ja man kann auch einen TBDR so bauen das er auch als IMR arbeiten kann. Das ganze müsste dann in etwa so aussehen.

ASCII Art:

Vertex Shader
|
Triangle Builder
|
Cull and Clip
/ \
Tile and save |
|
Load and HSR Generate Pixel Data
| |
Generate Pixel Data |
\ /
Pixel Shader
|

ActionNews

2002-12-14, 10:40:44

Ah ja! Und hab ich das richtig verstanden, dass Slipstream nicht nach tiles rendert sondern wie ein IMR Polygon für Polygon?

CU ActionNews

Demirug

2002-12-14, 11:00:31

Originally posted by ActionNews
Ah ja! Und hab ich das richtig verstanden, dass Slipstream nicht nach tiles rendert sondern wie ein IMR Polygon für Polygon?

CU ActionNews

Scheinbar ist ja beides möglich. Unter OpenGL benutzt man derzeit wohl nur den IMR Pfad und unter D3D scheint der Tile-Pfad aktiv zu sein. Nach welchem Verfahren das Binning aber abläuft kann man naürlich nicht sagen. Das es aber wohl um einen Hybrid Renderer ist gehe ich davon aus das nicht nach dem Infinite Plane Verfahren gearbeitet wird.

loewe

2002-12-14, 19:29:30

Originally posted by Demirug
Scheinbar ist ja beides möglich. Unter OpenGL benutzt man derzeit wohl nur den IMR Pfad und unter D3D scheint der Tile-Pfad aktiv zu sein. Nach welchem Verfahren das Binning aber abläuft kann man naürlich nicht sagen.
Womit ich arge Probleme mit der Effizienz so einens Chips habe. Es dürfte wohl kaum möglich sein in Hardware sowohl einen kompletten TBDR- als auch einen IMR Pfad zu integrieren und dabei auch noch effektiv zu sein. Heir werden dann Zugeständnisse an die Leistung u.a, notwendig, das Ergebnis ist gut sichtbar.

Das es aber wohl um einen Hybrid Renderer ist gehe ich davon aus das nicht nach dem Infinite Plane Verfahren gearbeitet wird.
Was sicher auch zu Problemen mit PowerVR führen würde, soweit ich weiß gehört 3DLabs nicht zu den Lizensnehmern von PowerVR.

loewe

2002-12-14, 19:35:05

Originally posted by Demirug

Ja ich würde nur gerne wissen ob das limit nun 32 Texturen/pass oder möglicherweise 32 Texturen/Pixel ist. Deswegen ja auch der Test den ich oben vorgeschlagen habe.

Ich bin da eigentlich sicher, dass 32 Texturen/pass gemeint ist. 32 Texturen/Pixel wäre einfach eine unzuläßige Beschränkung.

Dein Programm wird es aber sicher zeigen, ich bin schon sehr gespannt.
BTW, wirst du D3D oder OGL oder am Besten beides anbieten? Wäre natürlich sehr schon, wenn wir beides testen könnten, damit hätten wir auch ein sehr gutes Werkzeug für spätere Tests.
Leider kann ich es nicht selbst, habe mich bisher nur unzureichend mit Grafikprogrammierung beschäftigt. :(

Demirug

2002-12-14, 21:04:20

So hier ist es: http://demirug.bei.t-online.de/MassiveAlphaBlend.zip

D3D only.

Die Anzahl der Layer kann in 2er Potenzen erhöht (+) werden 1,2,4,8,16,32,64,128,256. Am Ende muss immer rot herauskommen.

Der alle Überdeckende Layer kann mit Ctrl+L an und ausgeschaltet werden.

Mit CTRL+A kann man das Alphablending abschalten

Mit CTRL+T kann man zwischen dem Textur und Vertexcolor Modus umgeschaltet werden.

loewe

2002-12-14, 21:19:07

Originally posted by Demirug
So hier ist es: http://free.fchost.us/demirug/MassiveAlphaBlend.zip <-- gerade down

Wenn das länger dauert, schicke ihn mir, ich lege ihn auf mitrax.de da ist er immer online! =)

Demirug

2002-12-14, 21:46:49

So jetzt geht es auf beiden Server

loewe

2002-12-15, 00:06:10

Hier ein paar erste Ergebnisse mit K2 auf 185 MHz.
Ob 16 oder 32 bit Farbtiefe verwendet werden ist vollkommen egal, genauso ob Textur oder Vertexcolor benutzt wird. Das Zuschalten des alle überdeckenden Layers bringt auch nichts, die Farbe ändert sich zwar auf Grün, das war es aber auch.

Hier die Werte für 640x480,800x600 und 1024x768, der erste ist jeweils mit Alphablending der zweite ohne.

Anzahl__640x480_____|____800x600_____|___1024x768
1_______84,02;84,02_|____84,59;84,59_|___84,62;84,62
2_______84,02;84,02_|____84,59;84,59_|___84,62;84,62
4_______84,02;84,02_|____84,59;84,59_|___84,62;84,62
8_______84,02;84,02_|____42,30;84,59_|___42,31;84,62
16______42,01;84,02_|____42,30;84,59_|___21,15;84,62
32______28,01;84,02_|____21,15;84,59_|___12,09;84,62
64______16,80;84,02_|____10,57;84,59_|___07,05;84,62
128_____08,40;42,01_|____05,64;42,30_|___03,53;28,20
256_____04,42;28,01_|____02,92;21,15_|___01,80;14,10

Ailuros

2002-12-15, 05:53:52

Hmmmm theoretisch sieht das nicht mal schlecht aus. Schade das es keine analoge OGL Applikation gibt.

Scheinbar ist ja beides möglich. Unter OpenGL benutzt man derzeit wohl nur den IMR Pfad und unter D3D scheint der Tile-Pfad aktiv zu sein. Nach welchem Verfahren das Binning aber abläuft kann man naürlich nicht sagen.

Gleich zwei dumme Fragen:

a) Laufen die Wildcats schon mit OGL2.0 oder nur 1.3?

b) Kann es sein dass das API im gegebenen Fall nicht nach Wunsch "mitspielt", und hingegen OGL2.0 mehr Flexibilitaet aufweisst?

Loewe,

Hast Du uebrigens die geringste Ahnung ob SGL registry extensions nur aus Kompatibilitaet-Gruenden da sind? Ich bezweifle zwar dass es ein SGL.dll noch gibt, aber ich kann mich nicht erinnern ob da sowas ueberhaupt jemals da war in KYRO Treibern...

Ailuros

2002-12-15, 06:52:35

Blend8 Alpha + Texture on (no top layer)

1024x768x32

~115fps 723MPps

Blend8 Alpha + Texture on + Top Layer

1024x768x32

~106fps 670MPps

[Ti4400@300/650]

edit: dabei waere es aeusserst interessant, wenn jemand R300 scores posten koennte. Theoretisch muesste es hoeher als 2x mal so hoch sein.

editNr.2:

Loewe,

Mich wuerden auch Fuellraten interessieren bei 1024 und Blend8/16 und 32.

Demirug

2002-12-15, 09:45:30

Originally posted by loewe
Hier ein paar erste Ergebnisse mit K2 auf 185 MHz.
Ob 16 oder 32 bit Farbtiefe verwendet werden ist vollkommen egal, genauso ob Textur oder Vertexcolor benutzt wird. Das Zuschalten des alle überdeckenden Layers bringt auch nichts, die Farbe ändert sich zwar auf Grün, das war es aber auch.

Hier die Werte für 640x480,800x600 und 1024x768, der erste ist jeweils mit Alphablending der zweite ohne.

Anzahl__640x480_____|____800x600_____|___1024x768
1_______84,02;84,02_|____84,59;84,59_|___84,62;84,62
2_______84,02;84,02_|____84,59;84,59_|___84,62;84,62
4_______84,02;84,02_|____84,59;84,59_|___84,62;84,62
8_______84,02;84,02_|____42,30;84,59_|___42,31;84,62
16______42,01;84,02_|____42,30;84,59_|___21,15;84,62
32______28,01;84,02_|____21,15;84,59_|___12,09;84,62
64______16,80;84,02_|____10,57;84,59_|___07,05;84,62
128_____08,40;42,01_|____05,64;42,30_|___03,53;28,20
256_____04,42;28,01_|____02,92;21,15_|___01,80;14,10

Das mit den Grün ist richtig. Was mich nur wundert ist das sich nichts an der Füllrate ändert. Normalerweise müsste die bei aktiviertem Alphablending steigen wenn man den Top-Layer einschaltet.

Demirug

2002-12-15, 09:48:41

Originally posted by Ailuros
Hmmmm theoretisch sieht das nicht mal schlecht aus. Schade das es keine analoge OGL Applikation gibt.

Gleich zwei dumme Fragen:

a) Laufen die Wildcats schon mit OGL2.0 oder nur 1.3?

b) Kann es sein dass das API im gegebenen Fall nicht nach Wunsch "mitspielt", und hingegen OGL2.0 mehr Flexibilitaet aufweisst?

a) den OpenGL 2.0 Treiber bekommt man nur auf anfrage beim Dev-Support.

b) Die benutzte API dürfte da keine Rolle spielen.

loewe

2002-12-15, 10:34:25

Originally posted by Demirug
Das mit den Grün ist richtig. Was mich nur wundert ist das sich nichts an der Füllrate ändert. Normalerweise müsste die bei aktiviertem Alphablending steigen wenn man den Top-Layer einschaltet.

Das Einschalten des Top-Layers ändert überhaupt nichts an der Füllrate, man merkt es zu keinem Zeitpunkt, außer an der Farbe!

Hier noch mal die Füllraten, gleiches Schema, gleiches System:

Anzahl__640x480___800x800___1024x768
__1______25,81_____40,60______66,55
__2______51,62_____81,21_____133,09
__4_____103,24____162,42_____266,18
__8_____206,48____162,42_____266,18
_16_____206,48____324,83_____304,21
_32_____275,31____324,83_____354,91
_64_____330,37____324,83_____354,91
128_____330,37____346,48_____354,91
256_____347,76____358,42_____362,46

Wie schon gesagt, Top Layer ändert gar nichts, Alpha immer an.

Demirug

2002-12-15, 10:53:42

Scheinbar wird da das HSR durch die vielen Alphaschichten irgendwie etwas ausgehebelt.

Thowe

2002-12-15, 11:21:52

Originally posted by Demirug
Scheinbar wird da das HSR durch die vielen Alphaschichten irgendwie etwas ausgehebelt.

...

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

Scheint wohl doch so zu funktionieren :)

Wie wäre es mit einem Testprogramm, das die Effizienz der HSR-Einheit bei kleinen Polygonen testet?

2002-12-15, 13:12:00

@Loewe

Deine fps-Werte deuten drauf hin, das VSync bei 85HZ eingeschaltet ist. Schalt das mal aus.

Modulor

2002-12-15, 13:20:48

Originally posted by ActionNews
...
Aber eine Frage: Kann die VP560 Slipstream einfach hinzu oder abschalten?
...

Derzeit wohl nicht.Ich habe keine Parameter gefunden, die Slipstream ein-oder ausschalten.

Originally posted by Demirug
...
Das Verfahren hat den Vorteil das dabei niemals der Binning Speicher ausgehen kann. Die Frage dabei ist nur in wie weit diese Buffergrösse variable ist.
...

Der wohl zuständige Eintrag in der registry lautet "P9.BinSizeKb" und ist mit 8000 angegegeben. Eine Änderung des Wertes ergibt jedoch keine Leistungsveränderung (jedenfalls mit dem Villagemark). Ich werde mal einige der im review verwendeten Spiele testen.

Originally posted by Demirug
Scheinbar ist ja beides möglich. Unter OpenGL benutzt man derzeit wohl nur den IMR Pfad und unter D3D scheint der Tile-Pfad aktiv zu sein. Nach welchem Verfahren das Binning aber abläuft kann man naürlich nicht sagen. Das es aber wohl um einen Hybrid Renderer ist gehe ich davon aus das nicht nach dem Infinite Plane Verfahren gearbeitet wird."

Damit hast Du wohl ins Schwarze getroffen:
Die OGL2 Treiber beinhalten folgende Passage: "Added support for user defined vertex attributes (through glVertexAttrib*() calls). This only works in immediate mode."
Der manuelle Eintrag des strings "OpenGL.BinMode" bringt bei 0 und 1 gar nichts, bei 2 bootet der Rechner :)...

Originally posted by loewe
...
Was sicher auch zu Problemen mit PowerVR führen würde, soweit ich weiß gehört 3DLabs nicht zu den Lizensnehmern von PowerVR.
...

3DLabs spricht ja selber von ihrem eigenen patentierten Verfahren. Leider gibt es noch keinerlei öffentlich gemachten Informationen darüber.Ist mir überdies äußerst sympathisch, daß es erneut eine europäische Firma ist, die einen DR Chip zur Marktreife bringt :)...

Originally posted by Ailuros
...
a) Laufen die Wildcats schon mit OGL2.0 oder nur 1.3?
...

Ich habe die OGL2 Treiber installiert. Dennoch zeigt jedes Programm 1.3.0 an. Die wohl einzige implementierte und in 2 Demo Programmen von 3DLabs verwendete OGL2-Extension derzeit scheint "GL_GL2-geometry_shader" zu sein.

Originally posted by Thowe
...
Wie wäre es mit einem Testprogramm, das die Effizienz der HSR-Einheit bei kleinen Polygonen testet?
...

Das könnte evtl. auch eine vom P9 verwendete Methode sein: Mittels des registry strings "VertexShrinkFactor" kann man jedes D3D Programm in seiner Größe reduzieren.Das läuft dann in der entsprechenden Größe oben links im Bildschirm ab. Ich habe Einträge bis 16 ausprobiert. Sehr schön zu sehen ist das Ergebnis z.B. beim Point Sprites Pferd des 3DMark: das Pferd besteht dann nur aus wenigen großen Polygonen.

Hier mal die Füllraten des Alpha Test Programms für die VP560:

Alles in 1024x768x32:

Anzahl__[Alpha active]__[Alpha inactive]__[Alpha active+Top Layer]

__1_______195(179)_______170(155)____________160(141)
__2_______243(223)_______210(193)____________280(237)
__4_______278(256)_______237(219)____________448(360)
__8_______299(276)_______254(235)____________637(485)
_16_______312(287)_______263(244)____________809(585)
_32_______318(293)_______268(249)____________934(654)
_64_______321(296)_______270(251)___________1013(695)
128_______323(297)_______272(252)___________1050(717)
256_______324(298)_______272(253)___________1080(728)

edit:
Ich habe eben den Rechner neu gebootet weil er den ganzen Vormittag lief. Jetzt sind die Messergebnisse noch höher.Die Werte der ersten Messung sind die in Klammern dahinter.

Demirug

2002-12-15, 14:38:44

Interesant, mit Alpha schneller als ohne. Scheinbar mag das Verfahren viele Schichten mit gleichen Z-Wert nicht.

Thowe, ja scheinbar muss beim Alphablending auf IMR Verfahren zurückgegriffen werden. Ich hoffe mal das man das bei der Serie5 etwas entschärft. Sonst könnte bei der DOOM III Engine der durch den schnelle OnChip-Stencilbuffer gewonnen Vorteil beim Alphablending zum Teil wieder verloren gehen.

Wie soll der Test den aussehen?

2002-12-15, 15:18:40

Hier mal meine GF2MX-Werte:

Alles in 1024x768x32:

Anzahl__[Alpha active]__[Alpha inactive]__[Alpha active+Top Layer]

__1_________ 85_____________101__________________ 57
__2_________104_____________128__________________ 80
__4_________116_____________148__________________100
__8_________124_____________161__________________114
_16_________128_____________168__________________123
_32_________131_____________172__________________127
_64_________132_____________174__________________135
128_________132_____________175__________________131
256_________132_____________175__________________148

Werte ab 32 mit alpha active+top layer sind nicht exakt zu ermitteln, gemessene fps bzw. fillrate schwanken stark

Quasar

2002-12-15, 15:41:30

Hier mal die Füllraten des Alpha Test Programms für die Radeon9000Pro:

Alles in 1024x768x32, Fullscreen

Anzahl__[Alpha active]__[Alpha inactive]__[Alpha active+Top Layer]
__1_________360_____________570__________________260
__2_________440_____________670__________________350
__4_________475_____________760__________________415
__8_________495_____________810__________________460
_16_________509_____________835__________________490
_32_________520_____________845__________________497
_64_________520_____________852__________________512
128_________525_____________854__________________520
256_________536_____________862__________________536

Thowe

2002-12-15, 15:52:02

Originally posted by Demirug

Wie soll der Test den aussehen?

Den Bildschirm möglichst mit kleinen (größe einstellbar?) und texturierten Polygonen ausfüllen. Damit man sehen kann, ob das Auswrikungen auf die Füllrate hat, weil das HSR dann der begrenzende Faktor ist. Der Overdraw sollte vielleicht auch wählbar sein.

Quasar

2002-12-15, 15:54:45

Hier mal die Füllraten des Alpha Test Programms für die Radeon9700Pro:

Alles in 1024x768x32, Fullscreen

Anzahl__[Alpha active]__[Alpha inactive]__[Alpha active+Top Layer]
__1_________827____________1072__________________564
__2_________983____________1330__________________770
__4________1087____________1523__________________944
__8________1151____________1643__________________1064
_16________1186____________1711__________________1138
_32________1207____________1748__________________1182
_64________1221____________1770__________________1208
128________1226____________1783__________________1219
256________1228____________1792__________________1224

Ailuros

2002-12-15, 17:32:34

Thowe, ja scheinbar muss beim Alphablending auf IMR Verfahren zurückgegriffen werden. Ich hoffe mal das man das bei der Serie5 etwas entschärft. Sonst könnte bei der DOOM III Engine der durch den schnelle OnChip-Stencilbuffer gewonnen Vorteil beim Alphablending zum Teil wieder verloren gehen.

Ich hab Dich hier und Thowe verloren....

Well alpha blending is all on chip, its effectively how multitexturing is done on KYRO. IMRs have to read and write external memory to do blending which is obviously a huge bandwidth hog. You need to read the old color, blend it with the new layer and write the result out. All of this happens on chip on KYRO, no external costs except for potential texture reads and the final tile complete write out. So it'll most likely be hardware fillrate limited while IMR's will be bandwidth limited.

Falls sich jemand wundern sollte, ich hab gerade heute nochmal nachgefragt um auf Nummer sicher zu gehen.

ow,

Gute Beobachtung. Es kann sein dass Loewe vsync aktiviert hatte.

2002-12-15, 17:57:11

Hier mal meine Kyro1-Werte:

Alles in 1024x768x32:

Anzahl__[Alpha active]__[Alpha inactive]__[Alpha active+Top Layer]

__1_________107_____________134__________________ 73
__2_________146_____________258__________________111
__4_________179_____________488__________________150
__8_________201_____________863__________________181
_16_________214____________1400__________________202
_32_________222____________1671__________________215
_64_________226____________1756__________________222
128_________228____________1801__________________226
256_________229____________1824__________________228

btw. sind mit der Kyro die angezeigten fps und fillraten absolut stabil, da schwankt nix. Auch im einstelligen fps-Bereich nicht (1,13fps im letzten Test).

Originally posted by Demirug
Scheinbar wird da das HSR durch die vielen Alphaschichten irgendwie etwas ausgehebelt.

Sieht so aus.
Wenn ich den Sinn dieser Übung hier richtig verstanden habe, dann verhindert der intransparente Top-Layer nicht, dass voher alle Layer alpha-blended werden.

Quasar

2002-12-15, 18:08:37

Originally posted by ow
Hier mal meine Kyro1-Werte:

Alles in 1024x768x32:

Anzahl__Alpha inactive
128_________1801

Hm...ab da vernichtest du ja glatt meine R300.... *GRMPFL*

2002-12-15, 18:13:31

Klar, solch schwächliche HW schaff ich mit links.:D;);)

Demirug

2002-12-15, 18:22:46

Well alpha blending is all on chip, its effectively how multitexturing is done on KYRO. IMRs have to read and write external memory to do blending which is obviously a huge bandwidth hog. You need to read the old color, blend it with the new layer and write the result out. All of this happens on chip on KYRO, no external costs except for potential texture reads and the final tile complete write out. So it'll most likely be hardware fillrate limited while IMR's will be bandwidth limited.

Das die Framebuffer Zugriffe entfallen war mir schon klar. Die Frage war wie der Chip nun bei Alphablendig genau realisiert.

Wenn das HSR erkennt das ein Pixel überschrieben werden muss und der neue Pixel mit aktivem Alphablending gerendert wurde braucht man ja den Farbwert des darunterliegenden Pixel aus einem anderen Polygon. Wie entsteht nun dieser Wert?

Wird der darunter liegende Pixel gerendert und dann in einer Zelle der Farbwert hinterlegt und später mit dem letzten Pixel verechnet? In dem Fall wäre das HSR nur noch begrenzt wirksam.

Können die Anweisungen von mehreren Pixel die übereinader liegen aufgestabelt werden? Falls ja, wie gross ist der Stack und was passiert wenn er voll ist.

Es gibt da sicher noch mehr fragen in dem Zusammenhang. Aber es dürfte erklären warum NVIDIA im Zusammenhang mit DR gerne von Kompatibilitätsproblemen spricht. Viele Dinge die bei einem IMR überhaupt keine Probleme machen bedürfen bei einem DR besonderer Aufmerksamkeit. Und ich erwarte bei den Chips die gerade mit DR anfangen (z.B. P9) noch ein paar schöne überraschungen.

P.S: Die Bedenken wegen DOOM III habe ich inzwischen wieder aufgeben. Da als erstes ja ein Z-Layer gerendert wird entsteht das entsprechende Problem ja gar nicht.

Demirug

2002-12-15, 18:29:32

Originally posted by ow
Sieht so aus.
Wenn ich den Sinn dieser Übung hier richtig verstanden habe, dann verhindert der intransparente Top-Layer nicht, dass voher alle Layer alpha-blended werden.

Ja das war der Sinn der Übung. Was jetzt nur noch nicht klar wäre ist die Frage ob Alphablending im allgemeinen dazu führt das auch später verdeckte Pixel gerendert werden oder ob es nur wegen der vielen Layer der Fall ist.

P.S. Ich habe gerade gemerkt das die Fillrate bei den Test mit dem Top-Layer nicht stimmt da dieser nicht mitgerechnet wird.

zeckensack

2002-12-15, 18:51:18

Originally posted by Modulor
Die OGL2 Treiber beinhalten folgende Passage: "Added support for user defined vertex attributes (through glVertexAttrib*() calls). This only works in immediate mode."Auf die Gefahr hin dich zu enttäuschen, das hat IMO nichts mit Deferred rendering zu tun ;)

'Immediate Mode' bedeutet unter OpenGL einfach nur, daß man keine Vertex Arrays benutzt, also jeden Eckpunkt einzeln an die API übergibt.

loewe

2002-12-15, 19:19:55

Hier noch mal die KYRO II Werte ohne VSync. Hatte gerade den Treiber neu installiert, wegen eines Probelems mit dem KhzTool und dann vergessen, dass da ja alles zurück gesetzt wird. :(

Ich beschränke mich jetzt auch auf 1024x768x32:

Anzahl__[Alpha active]__[Alpha inactive]__[Alpha active+Top Layer]

__1_________171_____________240__________________117
__2_________234_____________466__________________177
__4_________286_____________874__________________239
__8_________321____________1538__________________289
_16_________343____________2382__________________324
_32_________354____________2669__________________344
_64_________361____________2805__________________355
128_________364____________2877__________________361
256_________365____________2914__________________364

Hier mal die Füllraten des Alpha Test Programms für die VP560:

Alles in 1024x768x32:

Anzahl__[Alpha active]__[Alpha inactive]__[Alpha active+Top Layer]

__1_______195(179)_______170(155)____________160(141)
__2_______243(223)_______210(193)____________280(237)
__4_______278(256)_______237(219)____________448(360)
__8_______299(276)_______254(235)____________637(485)
_16_______312(287)_______263(244)____________809(585)
_32_______318(293)_______268(249)____________934(654)
_64_______321(296)_______270(251)___________1013(695)
128_______323(297)_______272(252)___________1050(717)
256_______324(298)_______272(253)___________1080(728)

Wenn ich mir die Werte von Alpha inactive der VP560 ansehe, habe ich so meine Zweifel bezüglich des deferred Renderers. Bei einem DR würde ich in so einem Overdraw Test, mehr ist es doch eigentlich nicht wenn Alpha inactive, erwarten, dass hier Füllraten oberhalb der realen Werte entstehen, siehe alle KYROs.
Ich weiß zwar nicht was die dort bei Slipstream machen, aber echtes deferred Rendering ist das nicht!

Thowe, ja scheinbar muss beim Alphablending auf IMR Verfahren zurückgegriffen werden. Ich hoffe mal das man das bei der Serie5 etwas entschärft. Sonst könnte bei der DOOM III Engine der durch den schnelle OnChip-Stencilbuffer gewonnen Vorteil beim Alphablending zum Teil wieder verloren gehen.

Dort sehe ich auch wenn du weiter unten die Bedenken bzgl. Doom3 wegen des z Layers aufgegeben hast, keine so großen Probleme.
Wie man oben sieht kommt KYRO recht schnell sehr nah an seine wirkliche Füllrate heran. Wenn du davon ausgehst das das so bleibt bei Serie5, etwa 3000 MPixel sollten doch wohl reichen.
Da mach ich mir ja eher Sorgen um die Radeon 9700pro, hat die nicht etwa 2600 MPixel, erreicht aber nie mehr als 1800.

Was ich nicht verstehe und so auch nicht erwartet hatte, ist das Verhalten mit dem Top Layer. Ich hätte erwartet das dieser undruchsichtige Top Layer in der HSR Einheit erkannt wird und damit auch alle dahinter liegenden Layer verworfen werden, womit er eigentlich immer nur einen Rendern sollte. Das tut er aber selbst bei nur zwei Layern nicht???

Demirug

2002-12-15, 19:40:45

Originally posted by loewe

Wenn ich mir die Werte von Alpha inactive der VP560 ansehe, habe ich so meine Zweifel bezüglich des deferred Renderers. Bei einem DR würde ich in so einem Overdraw Test, mehr ist es doch eigentlich nicht wenn Alpha inactive, erwarten, dass hier Füllraten oberhalb der realen Werte entstehen, siehe alle KYROs.
Ich weiß zwar nicht was die dort bei Slipstream machen, aber echtes deferred Rendering ist das nicht!

ja der VP560 produziert merkwürdige ergebnisse. das "Alpha inactive" langsammer als "Alpha active" deutet auf ein Problem hin wenn viele Polygone die gleichen Z-Werte habe. Allerdings läst das "Alpha active+Top Layer" Ergebniss doch einen DR erkennen. Ich habe noch ein zweites Programm für einen OverdrawTest, wenn du noch ein bischen rumtesten möchteset. http://demirug.bei.t-online.de/ZOverdraw.zip

Dort sehe ich auch wenn du weiter unten die Bedenken bzgl. Doom3 wegen des z Layers aufgegeben hast, keine so großen Probleme.
Wie man oben sieht kommt KYRO recht schnell sehr nah an seine wirkliche Füllrate heran. Wenn du davon ausgehst das das so bleibt bei Serie5, etwa 3000 MPixel sollten doch wohl reichen.
Da mach ich mir ja eher Sorgen um die Radeon 9700pro, hat die nicht etwa 2600 MPixel, erreicht aber nie mehr als 1800.

Der R300 hat wie wir festgestellt haben wohl eine recht gutes Early-Z. Dort dürfte sich der Z-only-Layer positiv auswirken

Was ich nicht verstehe und so auch nicht erwartet hatte, ist das Verhalten mit dem Top Layer. Ich hätte erwartet das dieser undruchsichtige Top Layer in der HSR Einheit erkannt wird und damit auch alle dahinter liegenden Layer verworfen werden, womit er eigentlich immer nur einen Rendern sollte. Das tut er aber selbst bei nur zwei Layern nicht???

Ja genau das kamm mir auch merkwürdig vor und deshalb ja die bedenken wegen DOOM III da ja dort fast alles (ausser ZLayer und den Schattenvolumen) mit aktivem Alpha-Blendig gerendert wird. Aber da würde der Kyro rein theoretisch (die Alpha ging ja scheinbar gar nicht) auch vom ZLayer profitieren.

loewe

2002-12-15, 20:02:16

Originally posted by Demirug
ja der VP560 produziert merkwürdige ergebnisse. das "Alpha inactive" langsammer als "Alpha active" deutet auf ein Problem hin wenn viele Polygone die gleichen Z-Werte habe. Allerdings läst das "Alpha active+Top Layer" Ergebniss doch einen DR erkennen. Ich habe noch ein zweites Programm für einen OverdrawTest, wenn du noch ein bischen rumtesten möchteset. http://demirug.bei.t-online.de/ZOverdraw.zip

Danke habe ich schon mal angetestet, sieht recht lustig aus. :)

Was wäre so interessant? Wie vorher 1024x768x32, Overdraw in Schritten von 10 bis 100? =) Mi und ohne Texturen und sowohl Front to Back als auch Back to Front?

Wenn du aber noch beim Alphatest bist, kannst du nicht den Top Layer auch umschaltbar machen, also mal als Top Layer zum Schluss und das andere Mal gleich zu Beginn, vielleicht gibt es dort dann einen Unterschied. Klingt blöd, aber mir ist momentan nicht klar, was PowerVR da wie tut.

Demirug

2002-12-15, 20:08:33

Originally posted by loewe

Danke habe ich schon mal angetestet, sieht recht lustig aus. :)

Was wäre so interessant? Wie vorher 1024x768x32, Overdraw in Schritten von 10 bis 100? =) Mi und ohne Texturen und sowohl Front to Back als auch Back to Front?

Bisher haben wir immer mit 64 Overdraw, 2 und 4 Texturen jeweils f2B und B2F gemessen. Beispiele: http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=44301&pagenumber=6

Wobei bei einem DR natürlich interesant ist wie weit die "virtuelle" Fillrate skaliert.

Wenn du aber noch beim Alphatest bist, kannst du nicht den Top Layer auch umschaltbar machen, also mal als Top Layer zum Schluss und das andere Mal gleich zu Beginn, vielleicht gibt es dort dann einen Unterschied. Klingt blöd, aber mir ist momentan nicht klar, was PowerVR da wie tut.

Ja kann ich noch einbauen

Edit: Done http://demirug.bei.t-online.de/MassiveAlphaBlend.zip

Modulor

2002-12-15, 20:48:27

Originally posted by Demirug
...
Ja kann ich noch einbauen

Edit: Done http://demirug.bei.t-online.de/MassiveAlphaBlend.zip

Junge,Junge. Bist ja richtig auf Zack mit derlei Programmen :o... Hut ab!

Demirug

2002-12-15, 20:51:13

Originally posted by Modulor

Junge,Junge. Bist ja richtig auf Zack mit derlei Programmen :o... Hut ab!

Ach das war doch keine grosse Änderung. Am längsten hat es wieder mal gedauert bis die von T-Offline die Datei vom FTP ins Web gespiegelt haben.

Modulor

2002-12-15, 21:03:18

Bei der VP560 erzeugt Top Layer First eine um etwa 20-50 MPixel höhere Füllrate als Top Layer Last.
Generell liegen die Werte mit Top Layer etwas über denen der vorherigen Programmversion - ist das nur bei mir so?

Demirug

2002-12-15, 21:07:57

Originally posted by Modulor
Bei der VP560 erzeugt Top Layer First eine um etwa 20-50 MPixel höhere Füllrate als Top Layer Last.
Generell liegen die Werte mit Top Layer etwas über denen der vorherigen Programmversion - ist das nur bei mir so?

Das ist schon Richtig die vorhergehende Version hatte einen Fehler im Berechnen der Fillrate bei aktiviertem Top-Layer. Er wurde bei der Berechnung einfach vergessen. Das habe ich berichtigt.

loewe

2002-12-15, 21:08:45

Originally posted by Demirug
Ja kann ich noch einbauen
Edit: Done http://demirug.bei.t-online.de/MassiveAlphaBlend.zip

Danke, hier zeigt er das Verhalten, das ich auch erwartet habe. Die Sache läuft wie ein Overdraw Test, die Füllraten gehen hoch auf Werte knapp unter 1500 MPixel, aber ab 32 Layer geht die Framerate in den Keller (55 FPS und fallend), liegt wohl an der Grenze der HRS Einheit. Auch wenn die Pipeline nicht vollständig durchlaufen werden muss, er kann ja nicht wissen das du so nett warst und den undruchsichtigen Layer als ersten schickst. =)

Wegen der Sache mit Layer zum Schluss muss ich mal bei PowerVR nach fragen, wiederspreicht eigentlich total dem was ich erwartet hätte.

2002-12-15, 21:30:11

Kyro1, 1024x768x32, 16Layer

+top layer last +top layer first
alpha active 214 215 870
alpha inactive 1358 1380 1406

loewe

2002-12-15, 21:55:21

Originally posted by ow
Kyro1, 1024x768x32, 16Layer

+top layer last +top layer first
alpha active 214 215 870
alpha inactive 1358 1380 1406

KYRO II, 1024x768x32; 16 Layer

+top layer last +top layer first
alpha active 343 343 1387
alpha inactive 2382 2410 2410

Modulor

2002-12-15, 22:19:01

Originally posted by loewe

KYRO II, 1024x768x32; 16 Layer

+top layer last +top layer first
alpha active 214 343 1387
alpha inactive 1358 2410 2410

Hier der dritte im Bunde:

VP560, 1024x768x32; 16 Layer

+top layer last +top layer first
alpha active 311 860 885
alpha inactive 263 455 544
[/SIZE][/QUOTE]

Demirug

2002-12-15, 22:22:21

Originally posted by Modulor

Hier der dritte im Bunde:

VP560, 1024x768x32; 16 Layer

+top layer last +top layer first
alpha active 311 860 885
alpha inactive 263 455 544

Der Chip ist ein Mysterium. Mit Alpha schneller als ohne. Ich muss es ja nicht wirklich verstehen.

Xmas

2002-12-16, 01:48:23

Originally posted by ow
Kyro1, 1024x768x32, 16Layer

+top layer last +top layer first
alpha active 214 215 870
alpha inactive 1358 1380 1406

Bitte noch einmal dasselbe mit 4 und mit 8 Layern. Mir scheint, der Kyro hat ein unerwartet geringes Limit an Layern pro "Pass" (wobei hier HW-Passes gemeint sind)

Ailuros

2002-12-16, 06:51:45

Originally posted by Demirug

Das die Framebuffer Zugriffe entfallen war mir schon klar. Die Frage war wie der Chip nun bei Alphablendig genau realisiert.

Wenn das HSR erkennt das ein Pixel überschrieben werden muss und der neue Pixel mit aktivem Alphablending gerendert wurde braucht man ja den Farbwert des darunterliegenden Pixel aus einem anderen Polygon. Wie entsteht nun dieser Wert?

Wird der darunter liegende Pixel gerendert und dann in einer Zelle der Farbwert hinterlegt und später mit dem letzten Pixel verechnet? In dem Fall wäre das HSR nur noch begrenzt wirksam.

Können die Anweisungen von mehreren Pixel die übereinader liegen aufgestabelt werden? Falls ja, wie gross ist der Stack und was passiert wenn er voll ist.

Es gibt da sicher noch mehr fragen in dem Zusammenhang. Aber es dürfte erklären warum NVIDIA im Zusammenhang mit DR gerne von Kompatibilitätsproblemen spricht. Viele Dinge die bei einem IMR überhaupt keine Probleme machen bedürfen bei einem DR besonderer Aufmerksamkeit. Und ich erwarte bei den Chips die gerade mit DR anfangen (z.B. P9) noch ein paar schöne überraschungen.

P.S: Die Bedenken wegen DOOM III habe ich inzwischen wieder aufgeben. Da als erstes ja ein Z-Layer gerendert wird entsteht das entsprechende Problem ja gar nicht.

Uhmmmm meine Moeglichkeit solche Fragen zu beantworten ist nur auf dem bekannten Fakt begrenzt, dass HSR und texturing in parallel laufen wobei das eine dem anderem nicht extra "cycles" aufzwingen sollte.

Das mit DoomIII ist uebrigens so eine komische Sache mit "application driven deferred rendering". Da alles zweimal prozessiert werden muss wird zwar der render order "unabhaengig", aber es duerfte die Fuellrate halbieren, und es gibt immer noch die Chance dass mehr Bandbreite aufgefressen wird als on DF.

Vergleichsmaessig hat application driven DF und DF auf einem TBDR sehr auspraegende Unterschiede. Ich wuerde uebrigens nicht so stark auf PR Meldungen von NV wetten. Wenn es eine soooo grosse Mysterie sein sollte dann wuerde ich mich eher in Richtung API's umsehen und deren zukuenftigen Evolutionen. Deshalb fragte ich ja auch ueber OGL2.0 da 3DLabs da ein bisschen die "Oberhand" mit dem API momentan hat (nur relative gemeint). Wobei es natuerlich auf von Microsoft abhaengt...

2002-12-16, 09:18:56

Originally posted by Xmas

Bitte noch einmal dasselbe mit 4 und mit 8 Layern. Mir scheint, der Kyro hat ein unerwartet geringes Limit an Layern pro "Pass" (wobei hier HW-Passes gemeint sind)

Kommt heute abend.
Du meinst den Abfall bei active alpha & top layer first, richtig?

Demirug

2002-12-16, 09:36:48

Originally posted by Ailuros

Uhmmmm meine Moeglichkeit solche Fragen zu beantworten ist nur auf dem bekannten Fakt begrenzt, dass HSR und texturing in parallel laufen wobei das eine dem anderem nicht extra "cycles" aufzwingen sollte.

Ja soweit ist das ja mehr oder minder öffentlich bekannt.

Das mit DoomIII ist uebrigens so eine komische Sache mit "application driven deferred rendering". Da alles zweimal prozessiert werden muss wird zwar der render order "unabhaengig", aber es duerfte die Fuellrate halbieren, und es gibt immer noch die Chance dass mehr Bandbreite aufgefressen wird als on DF.

Es ist ja nicht so das DOOM III das ganze macht um da einen Fillrate spareffekt zu erreichen. Der Z-Layer ist notwendig damit die Schatten stimmen. Das man damit auch Early-Z ausnutzen kann ist ein netter nebeneffekt.

Vergleichsmaessig hat application driven DF und DF auf einem TBDR sehr auspraegende Unterschiede. Ich wuerde uebrigens nicht so stark auf PR Meldungen von NV wetten. Wenn es eine soooo grosse Mysterie sein sollte dann wuerde ich mich eher in Richtung API's umsehen und deren zukuenftigen Evolutionen. Deshalb fragte ich ja auch ueber OGL2.0 da 3DLabs da ein bisschen die "Oberhand" mit dem API momentan hat (nur relative gemeint). Wobei es natuerlich auf von Microsoft abhaengt...

In wie fern die Oberhand? OpenGL 2.0 ist ja nicht mal verabschiedet und DX9 ist sehr nahe am Final. Technologisch gesehen bin ich mir auch nicht sicher ob OpenGL 2.0 wirklich ein Segen sein wird. Die Tatsache das man nur auf eine High-Level-Sprache aufbaut dürfte in Summe eine ganze menge Probleme heraufbeschwören. Den jeder Kartenhersteller ist nun gezwungen einen kompletten Compieler in den Treiber einzubauen. Es gibt keinerlei Garantie das ein Shader welcher auf Karte A ohne Problem läuft auch auf Karte B läuft. Da ist mir der DX Weg schon lieber. Genormte Assembler ähnliche Sprache und genau definierte Featuresets in den Shadern. Meldet eine Karte das sie ein Featureset beherscht kann ich den Shader auch benutzten. In Summe ist das Leben damit leichter auch wenn man zugestehen muss das OpenGL 2.0 als im Prinzip unlimitiertes System nicht so häufig an neue Karten angepasst werden muss.

loewe

2002-12-16, 19:04:09

KYRO II, 1024x768x32;

4 Layer
+top layer last +top layer first
alpha active 286 298 1064
alpha inactive 873 1059 1057

8 Layer
+top layer last +top layer first
alpha active 351 326 1315
alpha inactive 1538 1683 1680

16 Layer
+top layer last +top layer first
alpha active 343 343 1387
alpha inactive 2382 2410 2410

Hier noch einmal alle drei Zusammengefaßt.
@Xmas
Was kannst du nun daraus ableiten?

Ailuros

2002-12-17, 03:34:52

In wie fern die Oberhand?

Deshalb sagte ich auch dass es nur unter relativen Bedingungen gemeint ist. Korrigier mich wenn ich was falsch verstanden habe, aber OGL2.0 war ein Vorschlag von 3DLabs, wobei jedoch die entgueltigen Entscheidungen und Finalisierung am ARB board liegt.

Die Tatsache das man nur auf eine High-Level-Sprache aufbaut dürfte in Summe eine ganze menge Probleme heraufbeschwören.

Devil's Advocate mode: Und Vorschlaege wie CG und Rendermonkey sind in dem Bereich besser? Nichtsdestominder wird keine der beiden HLSL von einem "universalem" Board wie ARB zur Finalisierung breitgesetzt. Natuerlich wird M$ ihre eigen HLSL veroeffentlichen, aber das jeder grosse IHV seine eigene "Sprache" dafuer braucht, klingt schon ein bisschen komisch.

Ich hab jetzt wirklich nicht vor die alte CG (idiotische) Diskussion wiederzubeleben, aber ich sehe nichts dort draussen das perfekt ist.

Es ist ja nicht so das DOOM III das ganze macht um da einen Fillrate spareffekt zu erreichen. Der Z-Layer ist notwendig damit die Schatten stimmen. Das man damit auch Early-Z ausnutzen kann ist ein netter nebeneffekt.

Da bin ich aber trotzdem gespannt ob application driven DF im Endeffekt auch wirklich allso mehr bringen wird, als mit alternativen Methoden auf IMR's.

Mal OT: Ich stehe ein dass ich zu faul bin den ganzen Developer-mambojumbo durchzulesen, aber hast Du schon mal die Dokumentation bei www.pvrdev.com durchgelesen was D3D und multitexturing oder alpha blending betrifft? Kann sein dass die dort eine sehr gewisse Routine vorschlagen.

Dumme Frage: musst Du eigentlich als Entwickler guten Grund haben dich unter NDA zu setzen oder geht das auch so z.B. aus reinen Informationsgruenden (z.B. ein Entwickler moechte sich das ganze mal naeher ansehen und testen, ohne etwas standhaftes zu entwickeln...)?

Demirug

2002-12-17, 07:42:13

Originally posted by Ailuros

Deshalb sagte ich auch dass es nur unter relativen Bedingungen gemeint ist. Korrigier mich wenn ich was falsch verstanden habe, aber OGL2.0 war ein Vorschlag von 3DLabs, wobei jedoch die entgueltigen Entscheidungen und Finalisierung am ARB board liegt.

Ja genau so sieht es im Moment aus.

Devil's Advocate mode: Und Vorschlaege wie CG und Rendermonkey sind in dem Bereich besser? Nichtsdestominder wird keine der beiden HLSL von einem "universalem" Board wie ARB zur Finalisierung breitgesetzt. Natuerlich wird M$ ihre eigen HLSL veroeffentlichen, aber das jeder grosse IHV seine eigene "Sprache" dafuer braucht, klingt schon ein bisschen komisch.

Ich hab jetzt wirklich nicht vor die alte CG (idiotische) Diskussion wiederzubeleben, aber ich sehe nichts dort draussen das perfekt ist.

Also CG entspricht HLSL mit dem Unterschied das MS nur einen DX Compiler geschrieben hat und NVIDIA für CG auch noch einen OpenGL Compiler für NVIDIA Chips. Rendermonkey hat ja keinen eignen Compiler sondern ist mehr eine Art Shader IDE in die sich z.B. andere Compiler einbinden können. Also ATI hat derzeit keine Shadersprache.

Zur grundsätzlichen Sache warum IMO der DX Ansatz etwas besser als das OpenGL 2.0 Verfahren ist. Bei DX wird der der Hochsprachenshader durch den Compiler in das DX-Shader-Assembler übersetzt dabei wird auch überprüft ob er einer bestimmten Shader Version entspricht. Von einem solchen Shader kann ich dann sicher sagen das er auf allen Karten welche die entsprechende Shaderversion unterstützen auch laufen wird. Bei OpenGL 2.0 übergebe ich der API direkt den Hochsprachenshader. Ist der von Treiberentwickler gelieferte Compiler aber der Meinung das im der Code nicht schmeckt habe ich ein Problem weil ich dann einen anderen Shader brauche. Durch die reine Hochsprache ist bei OpenGL 2.0 nicht sichergestellt das ein Shader auf allen Chip laufen wird und das heisst dann leider: "Write once, test everywere" für jeden Shader.

Da bin ich aber trotzdem gespannt ob application driven DF im Endeffekt auch wirklich allso mehr bringen wird, als mit alternativen Methoden auf IMR's.

Das hängt von der Qualität des Early-Z ab.

Mal OT: Ich stehe ein dass ich zu faul bin den ganzen Developer-mambojumbo durchzulesen, aber hast Du schon mal die Dokumentation bei www.pvrdev.com durchgelesen was D3D und multitexturing oder alpha blending betrifft? Kann sein dass die dort eine sehr gewisse Routine vorschlagen.

Nein in dieser spezielen Richtung habe ich mir dort noch nichts angeschaut.

Dumme Frage: musst Du eigentlich als Entwickler guten Grund haben dich unter NDA zu setzen oder geht das auch so z.B. aus reinen Informationsgruenden (z.B. ein Entwickler moechte sich das ganze mal naeher ansehen und testen, ohne etwas standhaftes zu entwickeln...)?

Die einzige NDA unter der ich stehe ist die für DirectX-Betas. Dafür musste ich einen Fragebogen ausfüllen warum ich gerne am Betaprogramm teilnehmen würde. MS besteht dabei aber nicht darauf das man gerade an eimen Produkt arbeitet ein guter Grund reicht auch.

Bei ATI und NVIDIA läuft da weniger über NDAs ab (bei neuen Sache sicherlich, aber da kommen nur die grossen ran), da läuft das meiste über die Entwicklerseiten (öffentlich und geschützt). Bei den geschützten muss man eben wieder einen guten Grund haben warum man da rein möchte.

Ailuros

2002-12-17, 16:39:04

Bei ATI und NVIDIA läuft da weniger über NDAs ab (bei neuen Sache sicherlich, aber da kommen nur die grossen ran), da läuft das meiste über die Entwicklerseiten (öffentlich und geschützt). Bei den geschützten muss man eben wieder einen guten Grund haben warum man da rein möchte.

Ich meinte unter NDA bei PVR. Ich fragte eigentlich nur aus dem Grund, weil ich das Gefuehl habe dass es mit Fragen (wie die in diesem Thread erstanden sind), vielleicht besser beantwortet werden koennen.

Ailuros

2002-12-18, 17:28:21

Uebrigens:

http://www.beyond3d.com/articles/vs/

Hoffentlich dauerts nicht allzu lange mit Part Deux :P

Unregistered

2002-12-18, 17:34:26

Originally posted by Ailuros
Uebrigens:

http://www.beyond3d.com/articles/vs/

Hoffentlich dauerts nicht allzu lange mit Part Deux :P Oh yeah!
Kristof Beets ist GOTT!

Ailuros

2002-12-19, 05:30:30

Originally posted by Unregistered
Oh yeah!
Kristof Beets ist GOTT!

Also wenn das relevant zum Interview sein sollte, da bist Du wohl viel zu weit daneben. Ich sag's mal so: ich hatte schon immer gewisse Fragen was PVR betrifft, und Beets war der einzige der bereit stand sie auch zu beantworten. Dabei ging es ueber Bekannten des Bekannten der einen anderen Bekannte hatte usw. bis es soweit kam.

Modulor

2002-12-19, 08:54:58

Überhaupt sind die Leute von PowerVR viel näher an der Basis als andere Firmen. Z.B. aktive Beteiligung in Foren und direkter email Kontakt.Und Kristofs Eigeninitiative auf b3d zeugt von echter Kompetenz und schafft Vertrauen beim interessierten Verbraucher.
Vorbildlich für andere Firmen!

Pussycat

2002-12-19, 15:04:43

Sie waren auch die einige GK-firma mir vernünftigen Messestand auf der CeBit. Keine Kugelschreiber, dafür aber wohl David Harolds tum anfassen :)

Ailuros

2002-12-19, 15:49:14

...dafür aber wohl David Harolds tum anfassen...

Na ja der Kerl ist auch schwer zum uebersehen
;D ;D ;D

Xmas

2002-12-19, 15:57:27

Originally posted by loewe

KYRO II, 1024x768x32;

4 Layer
+top layer last +top layer first
alpha active 286 298 1064
alpha inactive 873 1059 1057

8 Layer
+top layer last +top layer first
alpha active 351 326 1315
alpha inactive 1538 1683 1680

16 Layer
+top layer last +top layer first
alpha active 343 343 1387
alpha inactive 2382 2410 2410

Hier noch einmal alle drei Zusammengefaßt.
@Xmas
Was kannst du nun daraus ableiten?
Offensichtlich werden transparente Layer gesondert behandelt und nur dann nicht gerendert, wenn bereits vorher ein deckender Layer vorhanden ist. Also legt der Chip vielleicht eine Liste mit transparenten Dreiecken an, zu der Dreiecke hinzugefügt, aber nicht mehr gelöscht werden können.

zeckensack

2002-12-19, 16:41:27

Originally posted by Ailuros

Also wenn das relevant zum Interview sein sollte, da bist Du wohl viel zu weit daneben. Ich sag's mal so: ich hatte schon immer gewisse Fragen was PVR betrifft, und Beets war der einzige der bereit stand sie auch zu beantworten. Dabei ging es ueber Bekannten des Bekannten der einen anderen Bekannte hatte usw. bis es soweit kam. Nö, so war's nicht gemeint.

Übrigens war der Unreg ich. "GOTT" war eine kurze Bewertung seiner didaktischen Fähigkeiten. Als Abgehobenheit oder sowas sollte das nicht verstanden werden.

Ich habe nur selten solch wundervolle Erklärungen komplexer Sachverhalte gelesen. Da ich mich damit gerade selbst beschäftige (*hint*hint*), muß ich ihm für seine hervorragende Arbeit meinen Respekt zollen.

loewe

2002-12-19, 20:08:35

Originally posted by Xmas

Offensichtlich werden transparente Layer gesondert behandelt und nur dann nicht gerendert, wenn bereits vorher ein deckender Layer vorhanden ist. Also legt der Chip vielleicht eine Liste mit transparenten Dreiecken an, zu der Dreiecke hinzugefügt, aber nicht mehr gelöscht werden können.

Das mit der Liste war schon klar. Die TBDRs von PowerVR sammeln in der HSR-Einheit alle für die spätere Farbe relevanten Dreiecke je Pixel in einer gesonderten Liste. Das Problem taucht jetzt aber mit dem undurchsichtigen Layer auf. Da dieser Layer auf jeden Fall vor allen transparenten Layern liegt, sollten doch diese Listen eigentlich verworfen werden und dann wirklich nur dieser in der Pixelpipeline verarbeitet werden. Wenn dem so wäre müßte aber die Füllrate weitgehend konstant bleiben bzw. nach Demirugs Rechenvorschrift auf Anzahl der Layer x Füllrate für einen Layer steigen, tut sie aber nicht!
Es gibt vielmehr fast eine indirekte Proportionalität zwischen Füllrate und Anzahl der Layer, zumindest für große Layerzahlen.

@Demirug
Kannst du bitte noch eine kleine Veränderung am Programm vornehmen? Ich würde gern die Anzahl der Layer linear steigern können, dann könnte man das besser überprüfen.

Demirug

2002-12-19, 20:52:33

Originally posted by loewe

Das mit der Liste war schon klar. Die TBDRs von PowerVR sammeln in der HSR-Einheit alle für die spätere Farbe relevanten Dreiecke je Pixel in einer gesonderten Liste. Das Problem taucht jetzt aber mit dem undurchsichtigen Layer auf. Da dieser Layer auf jeden Fall vor allen transparenten Layern liegt, sollten doch diese Listen eigentlich verworfen werden und dann wirklich nur dieser in der Pixelpipeline verarbeitet werden. Wenn dem so wäre müßte aber die Füllrate weitgehend konstant bleiben bzw. nach Demirugs Rechenvorschrift auf Anzahl der Layer x Füllrate für einen Layer steigen, tut sie aber nicht!
Es gibt vielmehr fast eine indirekte Proportionalität zwischen Füllrate und Anzahl der Layer, zumindest für große Layerzahlen.

Ja genau, es sieht so aus als würden die eigentlich verdeckten Layer doch gerendert werden.

@Demirug
Kannst du bitte noch eine kleine Veränderung am Programm vornehmen? Ich würde gern die Anzahl der Layer linear steigern können, dann könnte man das besser überprüfen.

Hier: http://demirug.bei.t-online.de/MassiveAlphaBlend.zip

Ailuros

2002-12-20, 00:55:21

Originally posted by zeckensack
Nö, so war's nicht gemeint.

Übrigens war der Unreg ich. "GOTT" war eine kurze Bewertung seiner didaktischen Fähigkeiten. Als Abgehobenheit oder sowas sollte das nicht verstanden werden.

Ich habe nur selten solch wundervolle Erklärungen komplexer Sachverhalte gelesen. Da ich mich damit gerade selbst beschäftige (*hint*hint*), muß ich ihm für seine hervorragende Arbeit meinen Respekt zollen.

Jetzt bin ich aber neugierig geworden....Hoffentlich bald genug. Uebrigens kann man mit der KISS Methode selten etwas falsch machen. :D

loewe

2002-12-28, 18:49:43

laßt mich diese Sache hier doch noch einmal kurz aufwärmen.

Ich habe da mal ein paar Tests durchlaufen lassen und wie ich denke einige wesentliche Werte der KYRO II und der GF4Ti4200 in einer Grafik zusammen gefaßt:

http://www.mitrax.de/bilder/extremalpha.gif

"Opaque Layer first" und "alpha off" fallen bei der GF4 vollkommen zusammen, das ist so auch zu erwarten. Ist halt ein IMR, dort wird sowieso alles gerendert und die GF4Ti hat leider mit early Z nun auch nichts abbekommen.

Aber um GF4 soll es ja gar nicht gehen, es ging eher um das unerwartete Verhalten der KYRO.
Ich denke die Grafik ist deutlich und bitte um eure Interpretationen, eine eigene kann ich leider nicht beisteuern. :-(

Aber bevor ich es vergesse, noch mals mein Dank an Demirug für das kleine Programm.

nagus

2002-12-28, 19:12:08

unter "options" hab ich alles aktiviert und 30 layer eingestellt... und was sagt das jetzt aus???

nagus

2002-12-28, 19:15:22

.... und das gleiche nochmal mit 256 layer

Demirug

2002-12-28, 19:25:57

nagus, der Test war dafür gedacht das verhalten einer Kyro bei massivem Einsatz von Alpha Blending zu bestimmen. Die IMR Werte dienten nur zum Vergleich. Das Einzige was man bei einem IMR damit Testen kann ist wie gut das Early Z ist. Dafür ist aber mein Overdraw Test besser geignet. Und da schneidet der R300 Chip sehr gut ab.

nagus

2002-12-28, 20:08:06

danke

Ailuros

2003-01-02, 10:54:33

Kleiner update zur Hauptseite, da komischerweise dieses Thema wieder aktuell wurde...:

Die Verhandlungen mit S3/VIA waren wohl am erfolgversprechendsten, scheiterten allerdings angeblich daran, daß S3/VIA eigentlich nur an der momentan in Entwicklung befindlichen PowerVR Series 5 interessiert war, nicht aber an der KYRO III - hier hat man inzwischen mit dem DeltaChrome einen eigenen LowCost-Beschleuniger ...

Das Paket war eher Serie3/4 soweit ich weiss, wobei VIA nur (verstaendlicherweise) an Serie4 aka KYRO III interessiert war. VIA wollte hoechstwahrscheinlich eine potente dx7 Karte fuer zwischendrin, denn SavageXP war ja nie was man als ueberwaeltigend ansehen kann.

... PowerVR hingegen wollte angeblich (konkretes zu diesen Verhandlungen werden wir wohl nie erfahren) nur beides zusammen losschlagen, so daß dieser zur CeBIT 2002 noch hoffnungsvoll erwartete Deal platzte.

Uhmmm nicht ganz so... ST Micro verhandelte dabei zuerst, wobei ImgTec dann mit den Verhandlungen dazuhilf.

Der Deal platzte hoechstwahrscheinlich im letzten Moment weil ST Micro zuviel verlangte und weil VIA um jeden Preis ihre eigene Treiber schreiben wollte.

Allein der letzte Grund macht mich uebermaessig froh, dass der Deal nie realisiert wurde. ;D

PowerVR damit immer noch ohne einen Chip-Mitdesigner da, welcher die kommenden PowerVR-Designs zur Produktionsreife bringt (die Massenfertigung läuft dann bei TSMC). Daß man diesen Job nicht selber übernimmt, hat den einfachen Grund, daß PowerVR im eigentlichen nur die Designs liefern und von den Lizenzen dafür lebt (ähnliche Situation wie bei den Bitboys). Denn das Designen von Chips ist mit "nur" ein paar Millionen Dollar Kostenaufwand im Jahr immer noch wesentlich günstiger, als einen Chip zur entgültigen Produktionsreife zu bringen ...

Die Frage ist derzeit ob jemand schon an Prototypen arbeitet und wer. Falls an keinen fruehen Silicon-Revisionen zeitlich gearbeitet wird, gibt es sehr wenig Chancen dass der Design dieses Jahr noch zu pre-mass production samples kommt.

Der Vergleich zu Bitboys OY ist wohl ein bisschen daneben geraten. Erstmal hat ImgTec mehrere als nur eine Division und zweitens haben sie wenigstens seit 1996 Produkte auf die Ladentische gebracht; zwar nichts uebermaessig tolles, aber wenigstens etwas.

Bitboys koennten den tollsten Multichip Design veroeffentlichen; wenn ich schon hoere dass die Treiber von einer dritten angagierten Firma uebernommen werden, ist bei mir die Lust dafuer schon weg. Dabei steht die Frage dann auch warum einer deren Designs nie lizenziert wurde.

edit: zeitlich versuchen BB es anscheinend in den PDA/mobile Markt zu schaffen. Wer neugierig ist wie kompliziert das Software fuer solche chips sein kann, sollte mal ARM's homesite und die MBX Dokumente durchlesen.