TBR/HSR Limits (Split aus :NV30-Speichergerüchte )

[GloomY]

Originally posted by robbitop
und ausserdem wirken TBRs in bestimten situationen eher limitierend.
Argh! Bei dem Satz sträuben sich meine Haare.
Ein Tiler ist in keiner Weise einem IMR benachteiligt. Im Gegenteil: Er hat in vielen Situationen durchaus Vorteile gegenüber einem IMR.

Originally posted by robbitop
TBR sind nützlich, wenn man nicht so viele Transistoren verbauchen möchte/ geringe Bandbreite hat -> Mainboad / Konsole..doch HighEnd Chips sind einfach besser dran als IMR, sonst hätte man so etwas schon realisiert, denn AFAIK hat NV ein eigenes TBR Team.

NV hat wahrscheinlich gar keine (rechtliche) Möglichkeit einen Tiler zu realisieren, da ihnen dafür die nötigen Lizenzen für die Patente von PowerVr fehlen (die laufen glaube ich noch ein paar Jahre).
Ausserdem würde mich mal interessieren, woher du deine Information bezüglich des TBR Teams hast.
Selbst wenn es das gäbe, würde nV das nicht öffentlich zugeben, da man ja schliesslich nicht ihren eigenen Behauptungen widersprechen wollen...

[Demirug]

Originally posted by GloomY
Argh! Bei dem Satz sträuben sich meine Haare.
Ein Tiler ist in keiner Weise einem IMR benachteiligt. Im Gegenteil: Er hat in vielen Situationen durchaus Vorteile gegenüber einem IMR.


Der Hauptvorteil liegt definitive bei Stencil ops (s. fabelmark). Allerdings wird es mit zunehmender länge der Fragmentshaderprogramme und der Verwendung von mehr texturen pro Fragment immer schwieriger einen guten DR zu bauen.


NV hat wahrscheinlich gar keine (rechtliche) Möglichkeit einen Tiler zu realisieren, da ihnen dafür die nötigen Lizenzen für die Patente von PowerVr fehlen (die laufen glaube ich noch ein paar Jahre).
Ausserdem würde mich mal interessieren, woher du deine Information bezüglich des TBR Teams hast.
Selbst wenn es das gäbe, würde nV das nicht öffentlich zugeben, da man ja schliesslich nicht ihren eigenen Behauptungen widersprechen wollen...

NV hat Patente für DR von 1999 und das verfahren ist gar nicht mal so schlecht allerdings etwas out of Date. Ob NVIDIA nun ein ganze Team hat das sich mit DR beschäftigt weis ich nicht zu sagen. Aber David Kirk hat in einem Interview gesagt das sie durchaus Leute haben die sich mit dem Thema DR auseinandersetzten. Nur hatte die IMR Leute bei den Initialmeatings für einen neuen Chip bisher immer die besseren Argumente.

[ow]

Originally posted by GloomY
Argh! Bei dem Satz sträuben sich meine Haare.
Ein Tiler ist in keiner Weise einem IMR benachteiligt. Im Gegenteil: Er hat in vielen Situationen durchaus Vorteile gegenüber einem IMR.


Bei hohen Polygonmengen ist ein Tiler im Nachteil.

Es gibt genuegend Szenen, wo mein Kyro auf dem AMD XP durch seine HSR Einheit limitiert ist und sonst nichts.

Den Polygondurchsatz des Kyro wurde ich als sehr schlecht einstufen. Teils schafft mein uralt RivaTNT da mehr.

[Demirug]

Originally posted by ow


Bei hohen Polygonmengen ist ein Tiler im Nachteil.

Es gibt genuegend Szenen, wo mein Kyro auf dem AMD XP durch seine HSR Einheit limitiert ist und sonst nichts.

Den Polygondurchsatz des Kyro wurde ich als sehr schlecht einstufen. Teils schafft mein uralt RivaTNT da mehr.

Ack

Wenn der IMR und der DR-TBR die gleiche Anzahl von Dreiecken pro Sekunden verarbeiten können gewinnt der IMR da beim TBR durch das Tiling eine höhere Anzhal von Dreiecken entsteht. Ist bei Tesselationsverfahren wie N-Patch, DM (ATI: Trueform) natürlich ein besonderer Nachteil der mit zusätzlichen Transitoren ausgelichen werden muss wenn man bei gleichem Takt auf identische Leistung kommen will.

[GloomY]

Originally posted by ow


Bei hohen Polygonmengen ist ein Tiler im Nachteil.

Es gibt genuegend Szenen, wo mein Kyro auf dem AMD XP durch seine HSR Einheit limitiert ist und sonst nichts.

Den Polygondurchsatz des Kyro wurde ich als sehr schlecht einstufen. Teils schafft mein uralt RivaTNT da mehr. 3DConcept (http://www.3dconcept.ch/reviews/3dprophet4500/7.htm) spricht von 180000 Dreiecken pro Szene bei 60 fps für den Kyro II.
Ich weiss nicht, in wie fern sich diese Zahl auch auf deinen Kyro I auswirkt (ist ja deutlich geringer getaktet), aber imho sollte da doch kein Flaschenhals entstehen.

Originally posted by Demirug
Ack

Wenn der IMR und der DR-TBR die gleiche Anzahl von Dreiecken pro Sekunden verarbeiten können gewinnt der IMR da beim TBR durch das Tiling eine höhere Anzhal von Dreiecken entsteht.

Sicher? Immerhin muss ein TBR (mit HSR) nicht alle Dreiecke bearbeiten (z.B. wenn welche verdeckt sind).

EDIT: :bonk: Quatsch gelöscht

[ow]

Originally posted by GloomY
3DConcept (http://www.3dconcept.ch/reviews/3dprophet4500/7.htm) spricht von 180000 Dreiecken pro Szene bei 60 fps für den Kyro II.
Ich weiss nicht, in wie fern sich diese Zahl auch auf deinen Kyro I auswirkt (ist ja deutlich geringer getaktet), aber imho sollte da doch kein Flaschenhals entstehen.



Wenn ich einen Bench mache bei einer bestimmten Aufloesung und dann denselben Bench 2 Aufloesungsstufen tiefer nchmal mache und feststelle, dass sich die Leistung kaum aendert, dann kann kein Fillratelimit vorliegen.
Limitierung durch SW T&L liegt bei mir ebenfalls nicht vor, mein XP1700 kriegt wesentlich mehr Triangles T&L't als der Kyro verarbeitet.

Es kann nur Limitierung durch Tiling/HSR sein.

Beispiel: 3DM2k1SE, nur SW T&L

1024x32Bit etwa 2500 Punkte auf der Kyro und der GF2MX
640x32Bit: etwa 5000 Punkte auf der MX, etwa 3100 auf dem Kyro

Ein Fillratelimit liegt auf dem Kyro nicht vor, die T&L Leistung des XP1700ist hoch genug (10Mio/3.8Mio tris/s bei 1 bzw. 8Lichtern auf der MX), also auch hier keine Limitierung.

-> die HSR Unit im Kyro hat Probleme mit der hohen Polygonlast.

[ow]

Originally posted by GloomY


EDIT: :bonk: Quatsch gelöscht

Heh, gerade noch rechtzeitig.:D

Ich war schon dabei den Quatsch zu kommentieren, mir aber selbst nicht ganz sicher dabei (IMO ist die Sichtbarkeistpruefung abhaengig von der Anzahl Polys/Tile ;)). Deshalb hab ich es dann gelassen.

[GloomY]

Originally posted by ow
Heh, gerade noch rechtzeitig.:D

Ich war schon dabei den Quatsch zu kommentieren, mir aber selbst nicht ganz sicher dabei (IMO ist die Sichtbarkeistpruefung abhaengig von der Anzahl Polys/Tile ;)). Deshalb hab ich es dann gelassen. Kommentier ruhig wenn's dir Spaß macht ;)

Ich hab' grad' mal gegoogled und noch einen etwas älteren Artikel von PowerVr.org.uk (http://www.powervr.org.uk/articles/tilerpoly/hpcat3.htm) gefunden. In dem heisst es zum Poligoncount:

"Finally, one of the myths surrounding this area is processing time for HSR. The hidden surface removal in PowerVR (this is most likely different for other tilers, such as the Gigapixel GP1) works by tracing a ray from the camera to the most front facing polygon. The amount of processing time is not dependant on the number of poylgons in the tile, just the number of pixels in the tile. This means that (ignoring memory constraints) you could theoreticly throw infinite polygons at a PowerVR card and the HSR stage would never become the bottleneck."

Ich bin jetzt gerade am Überlegen, in wie fern dies der Aussage von 3Dconcept widerspricht, aber ich bin momentan noch etwas confused... ???

[Demirug]

ow, GloomY:

Bei PowerVr Modle weis ich nicht 100% genau wie es arbeitet es wird aber definitive ein Z Buffer benutzt. Dieser hat zwar nur die größe einer Tile und liegt im Chip selbst aber er ist vorhanden. Desweitern wäre alles andere als die Daten für jede Tile linear einzulesen und dann in den Chipinternen Buffer einzutragen zu aufwendig (gerade bei Stencil ops). Der primare unterschied liegt dann im Texturieren denn das wird erst durchgeführt wenn für jeden Pixel feststeht aus welchen blendvorschriften und Texturen er sich zusammensetzt.

P.S: Offtopic eigener Thread?

[ow]

Originally posted by GloomY
The amount of processing time is [B]not dependant on the number of poylgons in the tile, just the number of pixels in the tile[/B


?? Wie ist denn das zu verstehen?
Die Anzahl Pixel/tile ist ja bekannt (32*16pixel?)und konstant.

Also die processing time auch, so dass der Kyro immer konstante fps-Werte liefern muesste?

*gruebel*

[ow]

Hab's gesplittet.

[Richthofen]

"
NV hat Patente für DR von 1999 und das verfahren ist gar nicht mal so schlecht allerdings etwas out of Date. Ob NVIDIA nun ein ganze Team hat das sich mit DR beschäftigt weis ich nicht zu sagen. Aber David Kirk hat in einem Interview gesagt das sie durchaus Leute haben die sich mit dem Thema DR auseinandersetzten. Nur hatte die IMR Leute bei den Initialmeatings für einen neuen Chip bisher immer die besseren Argumente.
"


Jop des is korrekt.
NV hat wohl 3 oder mehr echte Design Teams. Die beschäftigen sich dann immer mit je einer Chipgeneration zb das eine GF3 das nächste GF4 usw...
Zusätzlich hat NV mehere kleinere ich nenn sie mal Forschungsgruppen unter die auch eine Gruppe fällt die für das Thema TBR bzw DR zuständig ist.
Fortlaufend setzen sich die Designteams und Forschungsteams zusammen und diskutieren über neue Technische Möglichkeiten die herausgefunden wurden und ob man sie implementiert oder nicht.
Bisher wurde vom TBR bzw DR Team nichts zu 100% umgesetzt, da wohl andere Wege geeigneter waren für die bisherigen Architekturen.

Das war D.Kirks Aussage in einem Interview.

Die haben in jedem Fall ein DR Team und ich denke mal da werden Gigapixelleute arbeiten und noch andere. Patente haben sie auch die allerdings wie gesagt älteren Datums ist. Da Technik eh immer verbessert wird, würden für den Fall eines Einsatzes eh neue Patente angemeldet werden.
PowerVR hat auch eine patentierte Technik aber den Einsatz einer ähnlichen Technik bei NV durch Gigapixel Know How verhindert das nicht im geringsten.
Da werden die schon gut aufpassen das da nix überschneidet und wenn doch mal mei dann kaufen wie bei 3dfx gelle :)

[Demirug]

"Finally, one of the myths surrounding this area is processing time for HSR. The hidden surface removal in PowerVR (this is most likely different for other tilers, such as the Gigapixel GP1) works by tracing a ray from the camera to the most front facing polygon. The amount of processing time is not dependant on the number of poylgons in the tile, just the number of pixels in the tile. This means that (ignoring memory constraints) you could theoreticly throw infinite polygons at a PowerVR card and the HSR stage would never become the bottleneck."

Ich will dem Autor ja nicht zu nahe treten aber was er da schreibt ist irgendwie blödsinn und zwar in mehrfacher hinsicht.

1. Eine Raycast engine (was das ja dann wäre) braucht keinen Z-Buffer. Power Vr redet aber immer gerne davon das ihr Z-Buffer immer mit höchster Genauigkeit arbeitet unabhängig von der Farbtiefe.

2. Eine Raycast engine ist sehr wohl abhängig von der Anzahl der Dreiecke. Der Sichtstrahl für jedes Pixel muss ja gegen jedes Dreieck geprüft werden um das Dreieck zu finden das am nächsten liegt.

3. Was ist mit Dreiecken die überhaupt keine gültige Z-Koordinate haben. das HUD wird zum Beispiel vorzugsweise mit deaktiviertem Z-Test als letztes gerendert. Dabei wird dann nur auf die X/Y (im Screenspace) Kordinaten geachtet.

4. Was ist mit Multipass. Dabei wären alle Dreiecke räumlich an der gleichen Position. Damit der Pixel aber so aussieht wie der Entwickler sich das vorgestellt hat muss das Blending in der richtigen reihenfolge durchgeführt werden. Das ist zwar beim Raycast möglich aber aufwendig.

5. Transparenz: Raycast engines beherschen "orderindepent Transparenz" das könnte zu abweichungen in der Darstellung führen. Ein weiteres Problem mit der Transparenz ist das wenn der Raycaster nun das richtige Dreieck gefunden hat und erkennt das diese Transparent ist (bzw eine Blendfunktion mit einem dahinterligenden hat (Mulitpass)) muss er alle Dreiecke nocheinmal durchsuchen.

[Unregistered]

Richtig, jetzt weiss ich was mich an der Aussage stoerte.

Dein Punkt 2.

Es muessen ja immer alle Dreiecke geprueft werden und die Zeit dafuer kann ja nicht unabhaengig von der Polyanzahl/tile sein.

Die anderen Punkte... hmmm..... sind/waren etwas zu hoch fuer mich, soviel versteh ich nicht von der Sache.

Wieder was dazugelernt.:)

[wowbagger]

wieso sollte ein hsr texturabhängins sein? der chip muss doch nur von der sichtebene aus prüfen welches der am nächsten ist und weis dann das alle anderen unsichtbar sind. also wird pro pixel (oder tile beim tbr) doch nur einmal geprüft welches polygon am nächsten ist. jetzt mal leienhaft ausgedrpckz muss der chip doch nur eine linie im 100° winkel von der sichtebene aus nach hinten ziehen, und das erste polygon, auf das der "Strahl" trifft ist halt sichbar. und bei dieser technik wäre die polygonzahl pro pixel egal! oder seh ich da was falsch??

[Demirug]

Originally posted by wowbagger
wieso sollte ein hsr texturabhängins sein? der chip muss doch nur von der sichtebene aus prüfen welches der am nächsten ist und weis dann das alle anderen unsichtbar sind. also wird pro pixel (oder tile beim tbr) doch nur einmal geprüft welches polygon am nächsten ist. jetzt mal leienhaft ausgedrpckz muss der chip doch nur eine linie im 100° winkel von der sichtebene aus nach hinten ziehen, und das erste polygon, auf das der "Strahl" trifft ist halt sichbar. und bei dieser technik wäre die polygonzahl pro pixel egal! oder seh ich da was falsch??

Ja. Um herauszufinden welche Dreieck am nächsten ist müssen alle Dreiecke in der Tile überprüft werden ob sie:

1. Den Strahl überhaupt schneiden.
2. Die Länge des Strahls bis zum Schnittpunkt kürzer ist als bei allen bisher überprüften Dreiecken.

Grundverfahren für Raycast:



Entfernung = max
gewähltes Dreieck = keins

für jedes Dreieck in der Tile
{
wenn der Sichtstrahl das Dreieck nicht schneidet dann
nächstes Dreieck

NeueEntfernung = Länge des Sichtstrahl bis zum Dreieck

wenn NeueEntfernung kleiner Entfernung dann
{
gewähltes Dreieck = aktuelles Dreieck
Entfernung = NeueEntfernung
}
}

wenn gewähltes Dreieck = keins dann
PixelFarbe = Hintergrundfarbe
sonst
PixelFarbe = BerechneFarbe für gewähltes Dreieck an den Schnittpunkt Strahl Dreieck



Damit geht aber kein Blending (Transparenz), Stencil (Schatten) und 2D Operationen (HUD)

[wowbagger]

hmm, gäbe es keine möglichkeit den starhl von der sichtebene asu zu verfolgen und zu stoppen sobald er auf das erste polygon trifft???

[ow]

Originally posted by wowbagger
jetzt mal leienhaft ausgedrpckz muss der chip doch nur eine linie im 100° winkel von der sichtebene aus nach hinten ziehen, und das erste polygon, auf das der "Strahl" trifft ist halt sichbar. und bei dieser technik wäre die polygonzahl pro pixel egal! oder seh ich da was falsch??


Falls es noch nicht ganz klar geworden ist:

Mit oben fett gedrucktem implizierst du ja schon, dass die Dreiecke von vorne nach hinten sortiert sind ("das erste Poly, auf das der Strahl trifft ist sichtbar").

Dann brauch ich auch kein HSR mehr zu machen.

Es geht ja darum, das vorderste Polygon zu bestimmen. Und dazu muessen ALLE Polygons betrachtet werden.

[ow]

Originally posted by wowbagger
hmm, gäbe es keine möglichkeit den starhl von der sichtebene asu zu verfolgen und zu stoppen sobald er auf das erste polygon trifft???


s.o.

welches ist denn das erste Polygon??

es geht doch gerade darum, dieses zu bestimmen!

[Demirug]

Originally posted by wowbagger
hmm, gäbe es keine möglichkeit den starhl von der sichtebene asu zu verfolgen und zu stoppen sobald er auf das erste polygon trifft???

Nein, den die Dreiecke liegen in der Rheienfolge in der sie der API übergeben wurden im Speicher. Aus diesem Grund muss man von einer unsortieren Menge ausgehen die komplett durchsucht werden muss.

Und bevor du jetzt auf die Idee kommst das man die Dreiecke ja sortieren könnte muss ich dir sagen das auch das keine gute Idee ist. Selbst das beste Sortierverfahren (QSort) würde eine ungeheurer Menge an Bandbreite verschlingen. Hinzu kommt noch das Problem das man Dreiecke die sich überschneiden trennen müsste. Das herausfinden welche Dreiecke sich überschneiden erfordert ebenfalls eine grosse Menge ( 1+..+N-1 N=Anzahl der Dreiecke) an vergleichen die zu lasten der Bandbreite gehen.

Ich habe zuhause einen Vergleich der Verfahren zum ermitteln von sichtbaren Pixel beim Rendern. Kann die Zahlen gerne mal Posten. AFAIK hat Raycast da nicht so gut abgeschnitten.

[Unregistered]

Also, wenn ich das ganze richtig verstanden habe, dann funktioniert ein deferred renderer so (zumindest der Kyro) :

die Vertex-Daten werden über den AGP-Port von der CPU geschickt.

Die Vertex werden je nach x,y - Screen-Position "geindexed"

Die Vertex-Daten werden im Vertex-Puffer, der ein ganzen Frame aufnimmt zwischengespeichert (incl. einem Index-Header).

Der Index-Puffer für das Frame wird ebenfalls gespeichert (Info über die Vertex-Daten mittels Header und Info, zu welchem und wievielen Tile's die Daten gehören )

der Chip liest die Index-Daten Tile für Tile wieder ein nachdem das gesamte Frame abgearbeitet ist und liest basierend auf den Indexdaten die zugehörigen Vertex-Daten ein. Anschließend arbeitet der Chip die Vertex-Daten wie ein IMR Tile für Tile ab ( mit Hilfe des onchip Framebuffers (=Tilebuffer) und des zugehörigen onchip Z-buffers ).

Probleme :

Bandbreite für die Vertex-Daten ( mindestens 1x schreiben + 1xlesen pro Vertex; meistens aber muss jedes Vertex mehr als einmal gelesen werden, da das zugehörige Polygon größer als ein Tile ist; Je mehr Polygone/Frame desto seltener tritt dies jedoch auf ).

Speicher für die Vertex-Daten. Jedes Polygon (3Vertex) ist bei DX IMO 64byte groß. Entsprechend ist der Bedarf an Speicherplatz. Da immer ein Frame abgearbeitet wird (Rendern) und ein Frame "geindexed" wird müssen 2Frames gespeichert werden.

Abhilfe :

Kompression von Vertex-Daten:
- Java3D unterstützt z.B. eine bis zu 10fache Kompression; allerdings nicht in Echtzeit
- Strips and Fans ermöglichen bereits eine ca. 2fache Kompression
- siehe Internet für andere Verfahren (es gibt jede Menge, allerdings nur in Software und natürlich nicht in Echtzeit)

-> hier muss IMG also Arbeit rein stecken (und hat es IMHO auch bereits getan)

[robbitop]

@Gloomy
ich meinte genau das , was Richthofen und Demirug zum Anfang sagten.

All das hat JC mal auch in einem Interview gesagt.

AFAIK wäre ein NV30 als TBR wohl nicht so schnell wie ein IMR mit HSR NV30 ...schon allein aufgrund der Komplexität. Die Tilingeinheit müsste dazu VIEL schneller sein.

Ich weiss es auch nicht so genau, aber sie werden schon ihre Gründe haben, sonst würden sie sicher TBRs baun, denn können, könnten sie es..

ich kann mich aber auch irren..wer weiss, wenn man eine entsprechend starke Tiling Einheit verbaut (vieleicht ja extra chip mit Vertexshadern, den man dann schön hochtaktet (ich weiss ..is quatsch hehe)), könnte es aber was werden..nur JC meint, dass er die Transitoren lieber anders umsetzt.

[Unregistered]

zu dem ganzen "Sortiervorgang" hat 3DConcept einen guten Artikel, der auf dem entsprechenden PVR-Patent von IMG basiert. Ich weiß aber nicht, ob der Kyro immer noch so arbeitet (das Patent betrifft die PCX1/2 - Chips).

Um die Sortierung zu ermöglichen/vereinfachen benutzten die PCX1/2 - Chips auf jeden Fall "Infinite Planes". Dabei handelt es sich um eine alternative Form Polygone zu berechnen und zu speichern.

[Demirug]

Ja die Dreiecke werden vom Chip in Tiles eingeteilt und im Speicher hinterlegt. Wie das beim Kyro genau abläuft weis ich nicht da PowerVR AFAIK das verfahren dazu nie genau offengelegt hat.

Die größe eines DX8 Vertexdatensatz hängt immer von mehreren Faktoren ab kann aber sehr gross werden. Soweit mir bekannt benutzt der Kyro aber bereits ein Kompresionsverfahren.

Was das Render einer Tile angeht so sehe ich das genauso. Der Chip liest die Daten in der gleichen Reihenfolge wie sie ursprünglich vom Programm übergeben wurden wieder ein und ermittelt über den Z-Buffer für jeden Pixel das richtige Dreieck. Sobald das geschen ist werden diese Pixel dann geshadet. Was mir allerdings noch nicht ganz klar geworden ist ist das Verfahren für das Alphablending. Denn dafür muss ja mehr als ein Dreieck pro Pixel berücksichtigt werden.

"da das zugehörige Polygon größer als ein Tile ist"

Oder das Dreieck auf einer Tilegrenze liegt.

[GloomY]

Also:

Nach längeren Nachforschungen bei unterschiedlichen Quellen bin ich nun auch zu der 3DConcept-Meinung zurückgekehrt, d.h. der Aufwand für das HSR ist abhängig von der Anzahl der Dreiecke in dem entsprechenden Tile.

Wie hier (http://www.ping.be/powervr/ISPexpl.htm) sehr schön zu sehen ist wird jedes Dreieck mit dem Sehstrahl geschnitten und die Z-Werte aller Dreiecke (temporär) gespeichert.
Aus diesen Werten kann man dann eine Referenz für das am nächsten zum Betrachter liegende Dreieck in den Z-Buffer schreiben.
Ich nehme an, dass transparente Dreiecke ebenfalls die "vor" dem nicht tranparenten liegen ebenfalls in dem Z-Buffer gespeichert werden (ist ja nur eine Referenz, die nicht viel Speicherplatz benötigt).

Und dann wird Pixel für Pixel die Farbwerte des Tiles bestimmt.

[GloomY]

Originally posted by Unregistered
zu dem ganzen "Sortiervorgang" hat 3DConcept einen guten Artikel, der auf dem entsprechenden PVR-Patent von IMG basiert. Ich weiß aber nicht, ob der Kyro immer noch so arbeitet (das Patent betrifft die PCX1/2 - Chips).
Wenn du das Ray-Casting mit dem Schnitt der 4 Ebenen meinst (ein Dreieck wird ja dabei mit Hilfe von 4 sich schneidenden Ebene geschreiben), dann ja :)

Originally posted by Unregistered
Um die Sortierung zu ermöglichen/vereinfachen benutzten die PCX1/2 - Chips auf jeden Fall "Infinite Planes". Dabei handelt es sich um eine alternative Form Polygone zu berechnen und zu speichern. Jein.
Infinitive Planes ist richtig, aber das Verfahren wird zur Sichtbarkeitsprüfung verwendet.
Zusätzlich dazu wird noch etwas Vektormathematik verwendet um die Entfernung der geschnittenen Dreiecke vom "virtuellen Auge" zu berechnen.

Originally posted by robbitop
ich kann mich aber auch irren..wer weiss, wenn man eine entsprechend starke Tiling Einheit verbaut (vieleicht ja extra chip mit Vertexshadern, den man dann schön hochtaktet (ich weiss ..is quatsch hehe)), könnte es aber was werden..nur JC meint, dass er die Transitoren lieber anders umsetzt.
Meine Rede.
Ich will endlich einen TBR (am Besten mit noch mit HSR, aber nicht zwingend notwendig), der gleiche Rohleistungsdaten (Füllrate, Speicherbandbreite, T&L-Durchsatz) hat wie in aktueller IMR...
Das Teil würde rocken... *träum*

[Demirug]

Ich hab mich jetzt mal durch das Patent gearbeitet.

Infinite Planes werden aus zwei gründen benutzt:

1. Sie erlauben eine extreme einfache Berechnung (1 addition) der Z Werte von Benachbarten zellen.

2. Sie brauchen weniger Platz zu Speichern.

Für jeden Pixel gibt es eine Zelle. Diese Zellen sind miteinader verbunden. Im Ideelfall wird bei jedem Takt in die erste Zelle ein neues Dreieck (als Infinite Planes) eingeschoben und nach x Takten ist das Dreieck durchgelaufen. Da aber immer nachgeschoben wird berechnet der Chip bei jedem Takt einen Z-Wert. Aufgrund eines zusätzlichen steuerflag pro Dreieck entscheidet die Zelle dann was sie tun soll.

Z-Buffer prüfen/schreiben
Stencil bearbeiten
Stencil test
Alpha test
Overwrite
Alten Wert in FIFO sichern

Nachdem nun alle Dreiecke der Tile durchgelaufen sind werden die Im zwischenspeicher hinterlegten Renderanweisungen für jeden Pixel entnommen und durchgeführt und das ergebniss in den Backbuffer geschrieben.

[Xmas]

Originally posted by GloomY
3DConcept (http://www.3dconcept.ch/reviews/3dprophet4500/7.htm) spricht von 180000 Dreiecken pro Szene bei 60 fps für den Kyro II.
Das ist leider nicht ganz richtig. Korrekt sind ca. 182000 Dreiecksfragmente (sprich: Anzahl der Tiles die ein Dreieck bedeckt), bei großen Dreiecken also erheblich weniger.

Der Kyro braucht pro Dreieck pro Tile 16 Takte (32 Z-Checks pro Takt, bei 32x16-Tiles)

[wowbagger]

Originally posted by Demirug


Nein, den die Dreiecke liegen in der Rheienfolge in der sie der API übergeben wurden im Speicher. Aus diesem Grund muss man von einer unsortieren Menge ausgehen die komplett durchsucht werden muss.

Und bevor du jetzt auf die Idee kommst das man die Dreiecke ja sortieren könnte muss ich dir sagen das auch das keine gute Idee ist. Selbst das beste Sortierverfahren (QSort) würde eine ungeheurer Menge an Bandbreite verschlingen. Hinzu kommt noch das Problem das man Dreiecke die sich überschneiden trennen müsste. Das herausfinden welche Dreiecke sich überschneiden erfordert ebenfalls eine grosse Menge ( 1+..+N-1 N=Anzahl der Dreiecke) an vergleichen die zu lasten der Bandbreite gehen.

Ich habe zuhause einen Vergleich der Verfahren zum ermitteln von sichtbaren Pixel beim Rendern. Kann die Zahlen gerne mal Posten. AFAIK hat Raycast da nicht so gut abgeschnitten.

jo mir is jetzt klar warum ich das falsch gesehen hab... sorry hatte nen denfehler drin. nur den zu schlidern is mir jetzt zuviel aktion ;-)

[HOT]

Originally posted by Demirug
ow, GloomY:

Bei PowerVr Modle weis ich nicht 100% genau wie es arbeitet es wird aber definitive ein Z Buffer benutzt. Dieser hat zwar nur die größe einer Tile und liegt im Chip selbst aber er ist vorhanden. Desweitern wäre alles andere als die Daten für jede Tile linear einzulesen und dann in den Chipinternen Buffer einzutragen zu aufwendig (gerade bei Stencil ops). Der primare unterschied liegt dann im Texturieren denn das wird erst durchgeführt wenn für jeden Pixel feststeht aus welchen blendvorschriften und Texturen er sich zusammensetzt.

P.S: Offtopic eigener Thread?

PowerVR nutzt KEINEN Z-Buffer. Nur einen internen Speicher, der die Raycastingpointer speichert.

[ow]

Wo werden denn dann die Z-Werte abgelegt?

[Demirug]

Originally posted by HOT


PowerVR nutzt KEINEN Z-Buffer. Nur einen internen Speicher, der die Raycastingpointer speichert.

Aus: http://www.powervr.com/pdf/TBR3D.pdf


On PowerVR, the z buffer for hidden surface removal is on chip and always operates at full 32bit Z/Stencil accuracy, irrespective of the render mode.


Und bleibt mir bitte mit dem Raycasting weg. Da hat mal irgendwer was in das Patent hinein interpretiert was dort aber nicht steht und bei einer API wie OpenGL und DirectX auch keinen Sinn macht. Der Chip arbeitet nach dem ganz normalen Z-Buffer Prinzip. Die wirklich geniale Idee dabei ist aber das man die Dreiecksfragmente als infinite plane speichert. Damit es es möglich die Z-Werte in einer form von Schieberegister (jede Zelle entspricht dabei einem Fragment) zu berechnen welches einfach beim übernehmen des wertes aus der Nachtbarzelle eine Addition durchführt um den neuen Z-Wert zu erhalten.

[GloomY]

Originally posted by Demirug
Aus: http://www.powervr.com/pdf/TBR3D.pdf
On PowerVR, the z buffer for hidden surface removal is on chip and always operates at full 32bit Z/Stencil accuracy, irrespective of the render mode.
Und bleibt mir bitte mit dem Raycasting weg. Da hat mal irgendwer was in das Patent hinein interpretiert was dort aber nicht steht und bei einer API wie OpenGL und DirectX auch keinen Sinn macht. Der Chip arbeitet nach dem ganz normalen Z-Buffer Prinzip.
Hmm, also ich bin bis jetzt auch immer davon ausgegangen, dass in dem OnChip-Buffer keine Z-Werte (also Skalare) stehen, sondern Referenzen auf das am nächsten zum Betrachter liegende Dreieck.
Wie soll der Kyro denn sonst nach dem Füllen des Z-Buffers wissen, zu welchem Dreieck der Z-Wert gehört, der dann im Z-Buffer steht?
Originally posted by Demirug
Die wirklich geniale Idee dabei ist aber das man die Dreiecksfragmente als infinite plane speichert. Damit es es möglich die Z-Werte in einer form von Schieberegister (jede Zelle entspricht dabei einem Fragment) zu berechnen welches einfach beim übernehmen des wertes aus der Nachtbarzelle eine Addition durchführt um den neuen Z-Wert zu erhalten.
Gibt's das Patent öffentlich zur Einsicht? URL?

[Xmas]

Originally posted by GloomY
Hmm, also ich bin bis jetzt auch immer davon ausgegangen, dass in dem OnChip-Buffer keine Z-Werte (also Skalare) stehen, sondern Referenzen auf das am nächsten zum Betrachter liegende Dreieck.
Wie soll der Kyro denn sonst nach dem Füllen des Z-Buffers wissen, zu welchem Dreieck der Z-Wert gehört, der dann im Z-Buffer steht?
Wie jetzt, er speichert keine Tiefenwerte, aber füllt trotzdem den Z-Buffer? ;)
Selbstverständlich wird beides benötigt.

[GloomY]

Originally posted by Xmas

Wie jetzt, er speichert keine Tiefenwerte, aber füllt trotzdem den Z-Buffer? ;)
Er könnte auch keine Tiefenwerte speichern, sondern nur für jeden Pixel das Dreieck, was am weitesten vorne liegt.

Oder er schreibt den Tiefenwert hinein. Meine Fragewar aber dabei, erstens welche dieser beiden Varianten der Kyro benutzt und zweitens wie er bei der zweiten Methode dann auf Grund des gespeicherten Tiefenwertes auf das Dreieck schliessen kann, was an dieser Stelle geshadet werden soll.

[Xmas]

Originally posted by Xmas
Selbstverständlich wird beides benötigt.

[[fu]121Ah]

mal was anderes... ihr sprecht da von DR... was ist das? dumme frage aber ich hab den kürzel noch nie gehört...

hmm, weis denn einer wie das gigapixelverfahren arbeitet? bei 3dconcept war mal n artikel wo die performance des gp2 oder gp3 abgelichtet war, war ganz schön schnell... irgendwas um 110mhz, 3 mio transistoren und geforce 2 pro leistung...

[Demirug]

DR = deferred Renderer (verzögertes Rendern. Es wird erst dann gerendert wenn alle daten des Frames vorliegen)
IMR = Immediate Mode Renderer (sofortiges Rendern alle ankommenden Polys werden sofort gerendert)

[Pussycat]

Originally posted by [fu]121Ah
mal was anderes... ihr sprecht da von DR... was ist das? dumme frage aber ich hab den kürzel noch nie gehört...

hmm, weis denn einer wie das gigapixelverfahren arbeitet? bei 3dconcept war mal n artikel wo die performance des gp2 oder gp3 abgelichtet war, war ganz schön schnell... irgendwas um 110mhz, 3 mio transistoren und geforce 2 pro leistung...

Zusatz zu Demirug: oftmals wird DR auch als TBR (Tile Based Renderer) bezeichnet, weil die Kyro als erst GraKa mit tile arbeitete. Heutzutage machen alle neue Karten dass (spart z-zugriffe -> schneller), aber oftmals wird mit TBR ein DR gemeint.

[Unregistered]

Originally posted by Pussycat


Zusatz zu Demirug: oftmals wird DR auch als TBR (Tile Based Renderer) bezeichnet, weil die Kyro als erst GraKa mit tile arbeitete. Heutzutage machen alle neue Karten dass (spart z-zugriffe -> schneller), aber oftmals wird mit TBR ein DR gemeint.


Gab es nicht schon vor dem Kyro eine Karte, die ein TBR war? Ja, z. B. die Matrox m3D, basierend auf dem PowerVR PCX2.

MfG JaDz

[Pussycat]

Stimmt. War jedoch durch die nicht ganz IMR-kompatibel implementierte lösung nicht erfolgreich. Kyro war der erste TBR auf PC der gut funktioniert hat, aber in der Tat nicht der erste.