PowerVR Serie5 doch mit (teilweisem) Z-Buffer?

[Demirug]

Wir sind im Sommerloch und es ist mitten in der Nacht also darf ich solche Schock Threads aufmachen.

Unseren TBDR Freunden hier dürften die Begriffe "Macro Tile" und "Parameter Management" etwas sagen und PowerVR hat in dieser Richtung weiter geforscht.

Die Jungs sind dabei jedenfalls zu der Erkenntniss gekommen das man das was alles so an Daten pro Frame anfällt nicht mehr in den Speicher bekommt ohne davon riesige Mengen zu verbrauchen. Das gleiche gilt für die Bandbreite. Man befrüchtet das wenn man alles einfach so in eine Displaylist speichert auch viel zu viel Bandbreite braucht. Das erste Problem (Speichermenge) will man ja nun laut dem bereits bekannte Patent dadurch lösen das man sobald der Buffer voll ist anfängt einzelne Tiles schon einmal zu rendern. Als Ergebniss dieses Vorgangs erhält man nun einen Z-Buffer (komprimiert), die entsprechenden Framebuffer daten und wieder Platz in der Display-Liste. Nun musste aber noch eine Lösung für das zweite Problem her die man scheinbar gefunden (http://l2.espacenet.com/espacenet/viewer?PN=WO03010717&CY=gb&LG=en&DB=EPD) hat. Dort wird eine Art Early-Z für TBDR beschrieben. Es gibt dafür zwei Stufen. In der ersten wird versucht das einladen von einzelnen Teile der Display-List zu unterdrücken indem man vor dem Laden der Details prüft ob das entsprechenden Dreiecksfragment überhaupt noch im sichtbaren bereich liegen kann. Dafür wird ein vorher für dieses Fragment abgespeicherter Z-Wert gegen die aktuell gültige Z-Range des Z-Buffer welcher auf dem Chip ist gebrüft und bei bedarf wird so das gesamte Fragment verworfen und das einladen der Details gespart. Nun scheint man bei PowerVR aber davon überzeugt zu sein das ein teilweise rendern von Tiles in Zukunft häufiger vorkommt den man möchte die Gewonnen Z-Daten (hauptsächlich die Z-Range) der Tiles auch schon im TA (Tile Accelerator) nutzen. Dabei sollen dann dort neue Fragmente noch vor dem speichern dahingehend gebrüft werden ob sie aufgrund ihrer Z-Werte überhaupt sichtbar sein können. Falls das mit Sicherheit ausgeschlossen werden kann werden diese Fragmente direkt verworfen. Dies funktioniert aber nur wenn das neue Dreiecks-Fragment in einer Tile liegt welche schon teilweise bearbeitet wurde aber dieser Fall scheint ja aufgrund der Gedankengänge von PowerVr nun häufiger vorzukommen. Es sieht wohl schwer danach aus das sich PowerVR entgültig von der Idee des totalen DR verabschiedet hat und den Z-Buffer als Mittel zur Bandbreiten und Speichermengen Reduktion entdeckt hat. Nun gut dadurch besteht dann zumindestens die Möglichkeit das sie auch von einem First Z-Pass profitieren können. Da das Patent schon etwas älter ist erwarte ich für Serie5 noch weitere Verbesserungen an diesem Grundprinzip. So scheint mir ein Hir-Z Buffer welcher aber nicht bis zur Pixel ebene geht durchaus im Bereich des möglichen.

Um nun nochmal zur Überschrift zurückzukommen. Ich meine natürlich keinen Z-Buffer im Sinne eines IMR aber ganz ohne Z-Daten im Speicher kommt nun wohl auch PowerVR nicht mehr aus.

[Gast]

Da gibt’s patente von, ja von nvidia über hybriden könnte sein das es dir weiterhilft.

Ich verstehe es nämlich so das es nicht mehr anders geht (für Power VR) anscheinend ist das tile based rendering mit zunehmender Komplexität nicht mehr zu halten da zuviel Objekt Polygone usw.

Flame Mode :)
da sagte auch mal jemand tiling is bad :)

[Demirug]

Original geschrieben von Gast
Da gibt’s patente von, ja von nvidia über hybriden könnte sein das es dir weiterhilft.

Ja die kenne ich doch.

Ich verstehe es nämlich so das es nicht mehr anders geht (für Power VR) anscheinend ist das tile based rendering mit zunehmender Komplexität nicht mehr zu halten da zuviel Objekt Polygone usw.

Tile based wäre es ja immer noch nur nicht mehr komplett DR. Es ist aber nun mal leider eine für PowerVR traurige Wahrheit das die Bandbreite zwischen den Vertex sowie dem Pixelbereich ständig starkt ansteigt der Bandbreitenbedarf für den Z-Buffer aber eher moderat zulegt.

[Ailuros]

Ich muss Zeit finden dass Ding mal durchzulesen, momentan wuerde es nur fuer Kopfschmerzen sorgen.

Ich bezweifle dass sie bei 32*16 tiles geblieben sind, wie im Patent an einer Stelle aufgefuerht wird (hab das Ding schnell mal durchgeblaettert).

[Gast]

nur so nebenbei
gebrüft schreibt man mit p = geprüft :)

Ansonsten wie immer ein hoch interessanter Beitrag :)

[Modulor]

Original geschrieben von Demirug
...
aber ganz ohne Z-Daten im Speicher kommt nun wohl auch PowerVR nicht mehr aus.

Sollen sie alles machen was machbar ist und uns endlich einen richtig schnellen (und von mir aus auch kostspieligen) TBR anbieten :)...

Wer eine KYRO Karte hat wird z.B. die unsägliche Umschaltung auf die Z-Load and Store Funktion aufgrund der um etwa 50% reduzierten Performance schon so manches mal verflucht haben...

[Demirug]

Original geschrieben von Modulor
Sollen sie alles machen was machbar ist und uns endlich einen richtig schnellen (und von mir aus auch kostspieligen) TBR anbieten :)...

Wer eine KYRO Karte hat wird z.B. die unsägliche Umschaltung auf die Z-Load and Store Funktion aufgrund der um etwa 50% reduzierten Performance schon so manches mal verflucht haben...

Ich vermute mal das "Parameter Managment" bei den Kyros noch sehr am Anfang stand und wirklich nur als Notlösung gedacht war weil man zu diesem Zeitpunkt noch davon ausging das man die Displayliste immer komplett speichern kann.

EDIT: PS: Slipstream von 3dlabs scheint ja ähnlich zu arbeiten.

[Modulor]

Original geschrieben von Demirug
...
EDIT: PS: Slipstream von 3dlabs scheint ja ähnlich zu arbeiten.

Hatte ich auch sofort assoziiert :)...

[loewe]

Original geschrieben von Demirug
Wir sind im Sommerloch und es ist mitten in der Nacht also darf ich solche Schock Threads aufmachen.

Unseren TBDR Freunden hier dürften die Begriffe "Macro Tile" und "Parameter Management" etwas sagen und PowerVR hat in dieser Richtung weiter geforscht.

Die Jungs sind dabei jedenfalls zu der Erkenntniss gekommen das man das was alles so an Daten pro Frame anfällt nicht mehr in den Speicher bekommt ohne davon riesige Mengen zu verbrauchen. Das gleiche gilt für die Bandbreite. Man befrüchtet das wenn man alles einfach so in eine Displaylist speichert auch viel zu viel Bandbreite braucht. Das erste Problem (Speichermenge) will man ja nun laut dem bereits bekannte Patent dadurch lösen das man sobald der Buffer voll ist anfängt einzelne Tiles schon einmal zu rendern. Als Ergebniss dieses Vorgangs erhält man nun einen Z-Buffer (komprimiert), die entsprechenden Framebuffer daten und wieder Platz in der Display-Liste. Nun musste aber noch eine Lösung für das zweite Problem her die man scheinbar gefunden (http://l2.espacenet.com/espacenet/viewer?PN=WO03010717&CY=gb&LG=en&DB=EPD) hat. Dort wird eine Art Early-Z für TBDR beschrieben. Es gibt dafür zwei Stufen. In der ersten wird versucht das einladen von einzelnen Teile der Display-List zu unterdrücken indem man vor dem Laden der Details prüft ob das entsprechenden Dreiecksfragment überhaupt noch im sichtbaren bereich liegen kann. Dafür wird ein vorher für dieses Fragment abgespeicherter Z-Wert gegen die aktuell gültige Z-Range des Z-Buffer welcher auf dem Chip ist gebrüft und bei bedarf wird so das gesamte Fragment verworfen und das einladen der Details gespart. Nun scheint man bei PowerVR aber davon überzeugt zu sein das ein teilweise rendern von Tiles in Zukunft häufiger vorkommt den man möchte die Gewonnen Z-Daten (hauptsächlich die Z-Range) der Tiles auch schon im TA (Tile Accelerator) nutzen. Dabei sollen dann dort neue Fragmente noch vor dem speichern dahingehend gebrüft werden ob sie aufgrund ihrer Z-Werte überhaupt sichtbar sein können. Falls das mit Sicherheit ausgeschlossen werden kann werden diese Fragmente direkt verworfen. Dies funktioniert aber nur wenn das neue Dreiecks-Fragment in einer Tile liegt welche schon teilweise bearbeitet wurde aber dieser Fall scheint ja aufgrund der Gedankengänge von PowerVr nun häufiger vorzukommen. Es sieht wohl schwer danach aus das sich PowerVR entgültig von der Idee des totalen DR verabschiedet hat und den Z-Buffer als Mittel zur Bandbreiten und Speichermengen Reduktion entdeckt hat. Nun gut dadurch besteht dann zumindestens die Möglichkeit das sie auch von einem First Z-Pass profitieren können. Da das Patent schon etwas älter ist erwarte ich für Serie5 noch weitere Verbesserungen an diesem Grundprinzip. So scheint mir ein Hir-Z Buffer welcher aber nicht bis zur Pixel ebene geht durchaus im Bereich des möglichen.

Um nun nochmal zur Überschrift zurückzukommen. Ich meine natürlich keinen Z-Buffer im Sinne eines IMR aber ganz ohne Z-Daten im Speicher kommt nun wohl auch PowerVR nicht mehr aus.

Man muss nicht immer alles mit Serie 5 in Zusammenhang bringen was von PowerVR kommt! ;)

In den letzten Jahren hat PowerVR zwei Schienen massiv bearbeitet, das eine war und ist die nächste Generation für uns also Serie 5 und das andere ist ihr MBX. Bei letzterem würde ich erst einmal die wesentliche Anwendung dieser Technologie sehen.

MBX ist vor allem als Grafikcore für Handys, PDAs und ähnliche sehr "kleine" Geräte gedacht. Dort wird es garantiert immer Speicherengpässe geben und dafür wird eine Lösung gebraucht. Mit Hilfe des Macrotilling Patentes und des hier angeführten wird zwar dann nicht die Effiziens eines echten DR erreicht, aber TBDR funktioniert garantiert immer und es sollte effektiver bleiben als es ein IMR sein könnte.

So ganz abwegig ist aber die Anwendung bei Serie 5 sicher auch nicht.
(reine Spekulation)
Serie 5 wird ja wie ich schon früher andeutete bezüglich des Speichers für ihre Daten (Displayliste und Binning Space) doch einiges ändern, was auf jeden Fall zu einer festen Größe für diesen Speicher führt. Sollte ich jetzt vielleicht eine Karte mit wenig Speicher haben, könnte vielleicht eine Mainstream Version von Serie 5 Highend sein?, wird auch hier wieder auf das Zwischenspeichern der Tiles zurückgegriffen und das hier genannte Patent erlaubt durchaus, die Daten noch sinnvoll zu verwenden.

Das Ziel von PowerVR bleibt aber sicher nach wie vor auf diese Dinge zu verzichten und wie bisher vollständig als DR zu arbeiten.

[loewe]

Original geschrieben von Gast
Da gibt’s patente von, ja von nvidia über hybriden könnte sein das es dir weiterhilft.

Ich verstehe es nämlich so das es nicht mehr anders geht (für Power VR) anscheinend ist das tile based rendering mit zunehmender Komplexität nicht mehr zu halten da zuviel Objekt Polygone usw.


Falsch, wir werden es sehen! ;D

[Ailuros]

Flame Mode
da sagte auch mal jemand tiling is bad

Kommt ganz drauf an was man mit tiling eigentlich meint. Kirk weiss besser als ich, mit was Karten die unter seiner Aufsicht entwickelt werden eigentlich speichern.

[StefanV]

Original geschrieben von Gast
Ich verstehe es nämlich so das es nicht mehr anders geht (für Power VR) anscheinend ist das tile based rendering mit zunehmender Komplexität nicht mehr zu halten da zuviel Objekt Polygone usw.

Flame Mode :)
da sagte auch mal jemand tiling is bad :)

QUatsch mit Sauce!!

Sogar der ATI R300 und alle darauf basierten Chips sind Tiler (zumindest mit FSAA)!!
Allerdings TB-IMR und keine TB-DR...

[Demirug]

Original geschrieben von Ailuros
Kommt ganz drauf an was man mit tiling eigentlich meint. Kirk weiss besser als ich, mit was Karten die unter seiner Aufsicht entwickelt werden eigentlich speichern.

Mit Tiles natürlich. Wobei mit unterschiedlichen Grössen gearbeitet wird.

Aber das Zitat bezog sich ja auf einen etwas grösseren Kontext als die reine Speicherung.

[Ailuros]

Mit Tiles natürlich. Wobei mit unterschiedlichen Grössen gearbeitet wird.

Man kann auf einem TBDR keine macro/micro Tiles verwenden?

Aber das Zitat bezog sich ja auf einen etwas grösseren Kontext als die reine Speicherung.

Ich hab zwar Zweifel dass die beiden grossen IHVs je zu vollen Tile-based/deferred rendering Architekturen umsteigen werden, aber wenn ich z.B. alten "Maze" Kram ausgraben wuerde, waere es mehr als tragische Ironie fuer das selige 3dfx; ueberhaupt nach dem Aufkauf von Gigapixel.

Wie sah die Marketing-Perspektive bei der NV30 Vorstellung und 256bittigen busse aus? So etwa "wir implementieren einen 256bit bus nur wenn wir empfinden dass es notwendig ist blah blah blah...". Komischerweise kam diese Notwendigkeit nur 6 Monate danach.

Ob ein breiterer bus jetzt wirklich notwendig war ist ein anderes Kapitel, mein Widerspruch beruht nur auf dem sinnlosen Marketing-Geblubber, das sich an jegliche Situation anpasst.

Wie falsch liege ich wenn ich sagen wuerde dass ein Z-only pass in Doom3 z.B. den rendering Prozess verzoegert ergo das rendering "deferred" wird (wenn auch nur teilweise)?

Tschuldige den langen "rant", aber Kirk koennte oefters ein bisschen gelassener mit seinen Aussagen sein; genauso unnoetig war der "Michelin-Maennchen" Kommentar fuer Truform.

[Demirug]

Original geschrieben von Ailuros
Man kann auf einem TBDR keine macro/micro Tiles verwenden?

Sicher so meinte ich das jetzt auch nicht.

Ich hab zwar Zweifel dass die beiden grossen IHVs je zu vollen Tile-based/deferred rendering Architekturen umsteigen werden, aber wenn ich z.B. alten "Maze" Kram ausgraben wuerde, waere es mehr als tragische Ironie fuer das selige 3dfx; ueberhaupt nach dem Aufkauf von Gigapixel.

Meine Zweifel das sowas kommt werden eher grösser den kleiner.

Wie sah die Marketing-Perspektive bei der NV30 Vorstellung und 256bittigen busse aus? So etwa "wir implementieren einen 256bit bus nur wenn wir empfinden dass es notwendig ist blah blah blah...". Komischerweise kam diese Notwendigkeit nur 6 Monate danach.

Ja wobei es bei einem 400MHz Core mit 500MHz Speicher wohl noch gepasst hätte.

Ob ein breiterer bus jetzt wirklich notwendig war ist ein anderes Kapitel, mein Widerspruch beruht nur auf dem sinnlosen Marketing-Geblubber, das sich an jegliche Situation anpasst.

Für diese Flexibilität werden die Leute bezahlt.

Wie falsch liege ich wenn ich sagen wuerde dass ein Z-only pass in Doom3 z.B. den rendering Prozess verzoegert ergo das rendering "deferred" wird (wenn auch nur teilweise)?

IMHO eher falsch. Es wird ja weiterhin alles direkt gerendert der Z-Pass führt ja nur das das dieses direkte Rendern frühzeitig abgebrochen wird wenn es keinen Einfluss haben kann.

Tschuldige den langen "rant", aber Kirk koennte oefters ein bisschen gelassener mit seinen Aussagen sein; genauso unnoetig war der "Michelin-Maennchen" Kommentar fuer Truform.


Lästern gehört zum Geschäft. Ich bin da weitaus schlimmeres gewohnt.

[Ailuros]

Ach Du weisst schon wie ich das alles meinte...:)

Meine Zweifel das sowas kommt werden eher grösser den kleiner.

Deshalb juckt es mich auch so endlich einen high end TBDR zu sehen, um dafuer oder dagegen ueberzeugt zu werden. Von einer oeden KYRO kann ich keine guten Schlussvolgerungen ziehen. PowerVR hat ja jetzt anscheinend die Chance ihre Behauptungen zu beweisen; selbst wenn dann sehe ich trotzdem keinen IMR-Killer im Vergleich zu gleichen Proportionalen.

Wenn es eine Moeglichkeit geben wuerde, dass bei gleichen specs und bei gleichen Faehigkeiten sagen wir mal =/>50% schneller herauskommen sollten, dann koennte ich mir vorstellen dass es vielleicht Anhieb auf Bedenken geben koennte; was aber anscheinend nie der Fall sein wird.

Ja wobei es bei einem 400MHz Core mit 500MHz Speicher wohl noch gepasst hätte.

Es verbleibt dass das high end Modell mit 500/500 und nur 6 Monate spaeter ein Nachfolger mit doppelt so breitem bus und niedrigeren Taktraten auftrat. Natuerlich verstehe ich was Du meinst und wie Du es meinst. Die PR Erlaeuterung klang mir einfach zu doof. Wenn Du mich fragst bin ich immer noch nicht sicher ob momentan der 256bittige bus fuer die spezifische Architektur und den heutigen Applikationen wirklich notwendig war. Hoehere Taktraten waeren ja umso einiges schwerer gewesen als beim NV30, also war es auch die beste Loesung unter den gegebenen Umstaenden.

Für diese Flexibilität werden die Leute bezahlt.

Herr Kirk ist NICHT Herr Burke. Du als Entwickler verhaelst Dich auch so wie ich es erwarten wuerde und das hat nichts mit Schmeicheleien oder aehnlichem zu tun.

Lästern gehört zum Geschäft. Ich bin da weitaus schlimmeres gewohnt.

Ich verweigere jeglichen Vergleich mit Derek Smart LOL ;D

[Demirug]

Original geschrieben von Ailuros
Herr Kirk ist NICHT Herr Burke. Du als Entwickler verhaelst Dich auch so wie ich es erwarten wuerde und das hat nichts mit Schmeicheleien oder aehnlichem zu tun.

In einem so grossen Laden wie nVidia bist du als Entwicklungschef auch in einer Marketingsituation. Du must deine Ideen
- den Teams
- der Geschäftsleitung
- der Presse (man ist immer ein Aushängeschild und muss daher Interviews geben)
verkaufen.

Das ist zwar auch in kleineren Firmen so nur sind da die persönlichen beziehungen untereinader doch noch etwas enger wodurch so etwas nicht so heftig rüber kommt. Natürlich geht es auch ohne diese Marketing aber mit macht man sich das Leben leichter. Wenn die Teams davon überzeugt sind das richtige zu tun arbeiten sie viel besser als wenn sie etwas nur tun weil der da oben (der einen auf die Strasse setzten kann) gesagt hat das es so gemacht wird. Überzeugt man die Geschäftsleitung von seinen Ideen steht man wenn es schief geht wenigsten nicht ganz so dämmlich dar weil ja alle der Meinung waren das es der richtige Weg ist. Die Presse ist ja sowieso ein Thema für sich. Man kann sich natürlich weigern sich Interviews zu geben dann wird aber geheult wegen Primadona und so. Gibt man aber Interviews ist es auch nicht recht weil man ja gezwungernermassen sowieso immer den gleichen Müll erzählen muss. Das alte Produkt war gut aber das neue ist ja soviel besser. blah blah usw.

[Ailuros]

Verstaendlich es ist schon aus der Perspektive, aber notwendig ist trotzdem so mancher Kommentar nun auch wieder nicht. Zum groben Gegensatz hoert man von ATI's chief-engineer nicht so leicht die gleichen "Kronen" (ausser dass ich in letzter Zeit was verpasst habe), und ATI ist nicht gerade ein kleiner Laden. Es geht hier nicht um anti-NV Kritik; es gibt Faelle da dreht sich selbst der Magen bei deren eigenen Angestellten mit zeitlichen PR stunts.

Es handelt sich hier um eine generelle Atmosphaere bei NV und aggressivem marketing/PR, wobei ich persoenlich es nicht notwendig finde, dass da auch der chief engineer davon beiinflusst sein muss. Das eigene Personal ergo engineers und auch das Publikum bei einer Presse-Konferenz kann man genauso leicht und vielleicht sogar effektiver ueberzeugen, wenn man sich rein an technische Aspekte als engineer haelt.

Wenn ich mich an das Poster in Huang's Buero erinnere, das mehr oder weniger behauptete "...after making a killing to 3dfx, Trident etc etc. this is really a no-brainer" wird es mir genauso schlecht. Besagte IHVs gingen ein durch ihre beschi***ne Entscheidungen und ihrer Unfaehigkeit zu konkurrieren, und solcher Krampf ist im besten Fall selbst als Witz geschmacklos.

Weisst Du was der erste Kommentar eines NV-engineer's war als ich letztes Jahr direkt nach der R300 Vorstellung nach Eindruecken fragte ? (frei uebersetzt)... wir werden sie schon in der Preis/Leistung Abteilung schlagen. Wir sollten real sein das Ding ist imposant aber es ist gross, heiss und verbraucht eine Unmenge von Strom...

Soll ich darauf antworten wie NV30 nach seiner Vorstellung im Vergleich zur R300 aussah?

Ich sag es schon seit Jahren, NV muss ihre eigenen Leute unter die Massen auf messageboards schicken und fuer aktiven Support sorgen. Jetzt erst kommt es so langsam. Zu viel Arroganz und Abstand vom Verbraucher tut keinem gut. Ich behaupte zwar nicht jede Kleinigkeit ueber NVIDIA's internas zu wissen, aber ein gutes Verstaendnis von der Situation hab ich schon.

NVIDIA ist auch derjenige IHV wo IMHO mehr Kleinigkeiten geleakt werden als woanders. Manchmal sogar um die wahren Tatsachen zu zeigen wie sie auch wirklich sind und da weisst Du auch was ich momentan damit meine. Nichts dass das jemand jetzt falsch versteht, das Arbeitsklima bei NV ist ausgezeichnet, was ich hier zu sagen versuche ist ganz was anderes.

[Demirug]

Ja nv betreibt ein sehr aggressive Marketing aber ich haben auch den Eindruck das sich das in letzer Zeit etwas bessert. Aber irgendwie sind wir jetzt verdammt Offtopic

[Ailuros]

Ja das Talent hab ich (threads OT zu leiten) :D

Aber zum originalen Thema des Threads gibt es sowieso momentan nicht mehr viel zu sagen. Wie waer's mit Kochrezepten? *rennt um sein Leben* :chainsaw:

[ram]

Original geschrieben von Demirug
Nun scheint man bei PowerVR aber davon überzeugt zu sein das ein teilweise rendern von Tiles in Zukunft häufiger vorkommt den man möchte die Gewonnen Z-Daten (hauptsächlich die Z-Range) der Tiles auch schon im TA (Tile Accelerator) nutzen. Dabei sollen dann dort neue Fragmente noch vor dem speichern dahingehend gebrüft werden ob sie aufgrund ihrer Z-Werte überhaupt sichtbar sein können. Falls das mit Sicherheit ausgeschlossen werden kann werden diese Fragmente direkt verworfen. Dies funktioniert aber nur wenn das neue Dreiecks-Fragment in einer Tile liegt welche schon teilweise bearbeitet wurde aber dieser Fall scheint ja aufgrund der Gedankengänge von PowerVr nun häufiger vorzukommen. Es sieht wohl schwer danach aus das sich PowerVR entgültig von der Idee des totalen DR verabschiedet hat und den Z-Buffer als Mittel zur Bandbreiten und Speichermengen Reduktion entdeckt hat. Nun gut dadurch besteht dann zumindestens die Möglichkeit das sie auch von einem First Z-Pass profitieren können.

Deiner Interpretation des Patents kann ich nicht folgen. Dieses Konzept ist doch komplett in-line mit dem Konzept des TBDR. Dabei handelt es sich nur um ein Mittel, gewisse Flächen pro Tile bereits vor dem Ray-Casting auszusortieren, indem während des Binnings ein oder mehrere pro Tile gecachte Z-Ranges geprüft werden. Der Z-Range definiert sich IMO aus dem vorangehenden Frame, und nicht aus einem vom gleichen Frame schon gerenderten Tile. Was lässt dich darauf schliessen, dass dies nur bei (teilweise) gerenderten Tiles des aktuellen Frames funktionieren soll?

[Demirug]

Original geschrieben von ram
Deiner Interpretation des Patents kann ich nicht folgen. Dieses Konzept ist doch komplett in-line mit dem Konzept des TBDR. Dabei handelt es sich nur um ein Mittel, gewisse Flächen pro Tile bereits vor dem Ray-Casting auszusortieren, indem während des Binnings ein oder mehrere pro Tile gecachte Z-Ranges geprüft werden. Der Z-Range definiert sich IMO aus dem vorangehenden Frame, und nicht aus einem vom gleichen Frame schon gerenderten Tile. Was lässt dich darauf schliessen, dass dies nur bei (teilweise) gerenderten Tiles des aktuellen Frames funktionieren soll?

Du kannst doch nicht die Z-Ranges vom vorgehenden Frame benutzen sowas führt unweigerlich zu Renderartefakten.

Zudem steht auf Seite 5:

To perform this type of culling the Tile Accelerator compares incoming objects with information about the range of depths stored in the ISP during pervious partial renders

Auf Seite 14:

Culling in the Tile Accelerator operates when parameter mangement is active. This is, when the system begins to render small parts on the screen (called macro tiles) before the whole image has been stored in the display list memory.

und dann geht es auf der gleichen Seite noch weiter

A small amount of memory is used, shown a "Z-Range Memory" ...

Also für mich ist das eindeutig:

- Z-Range culling im ISP arbeitet immer aber mit einer bestimmten Latenz.

- Z-Range culling im TA arbeitet nur wenn für die entsprechende Tiles vom ISP schon eine Z-Range im entsprechenden Speicher hinterlegt wurde. Damit das passiert muss diese Tile schon einmal teilweise gerendert worden sein.

[Gast]

Original geschrieben von ram
Deiner Interpretation des Patents kann ich nicht folgen. Dieses Konzept ist doch komplett in-line mit dem Konzept des TBDR. Dabei handelt es sich nur um ein Mittel, gewisse Flächen pro Tile bereits vor dem Ray-Casting auszusortieren, indem während des Binnings ein oder mehrere pro Tile gecachte Z-Ranges geprüft werden. Der Z-Range definiert sich IMO aus dem vorangehenden Frame, und nicht aus einem vom gleichen Frame schon gerenderten Tile. Was lässt dich darauf schliessen, dass dies nur bei (teilweise) gerenderten Tiles des aktuellen Frames funktionieren soll?


Ähh nein. Es geht wirklich darum, eine Art "EarlyZ für Vertex" durchzuführen nachdem das Parameter-Management die Display-List zum ersten Mal gelehrt hat. Bis zu diesem Zeitpunkt funktioniert der Chip wie ein 100%iger DR und die Display-List füllt sich "schnell". Durch die gesammelten Informationen wird dann beim weiteren (wiederholten) Auffüllen der Display-List Speicherplatz und Bandbreite gespart indem nur noch Vertex abgespeichert werden, die den Early-Z Test bestehen.

Die Z-Range Informationen werden dann im TA und im ISP generiert und sollten viele aber nicht alle hidden Vertex aussortieren. Als zweite Stufe wird dann in der Pointer-Datei für jedes Vertex noch einmal die Z-Range Info mit nochmals reduzierter Genauigkeit abgespeichert um beim laden der Pointer in den ISP für eine Tile die übrigen hidden Vertex (nach Möglichkeit) auszusortieren. Das reduziert zwar die Display-List nicht, hilft aber Bandbreite zu sparen.


PS.: einmal ein leicht zu verstehendes Patent. Was für eine Ausnahme :D



Das was du meinst ist mehr oder weniger (soweit ich das verstanden habe) der Revi-Algorithmus von Fluidstudios. Leider ist aus der Sache ja anscheinend nichts geworden.

[ram]

:bonk: Ach, ja natürlich geht Stufe 2 nur für Tiles desselben Frames. Stufe 1 des Verfahren beschreibt eigentlich was ich meinte, diese funktioniert ja auch ohne Parameter Management auf den zuvor angekommenen pro Tile gecachten z-Ranges der Vertices desselben Frames.

Und ja, ImgTec Patente sind eigentlich schon verständlich. ;)

[micki]

sie sollten sowas wie polygon-kompression einführen, gerade wenn man scenen hat, die man im multipass rendert, wäre sowas vielleicht angebracht, z.B. ändern sich die positionen dann wohl nicht, die texturcoordinaten oft auch nicht. wenn sie vielleicht sogar die berechnungen dafür umgehen könnten (weil sie im multipass merken könnten, wenn zwei shader die gleichen berechnungen durchführen werden), könnten sie sogar performance gewinnen.


ich weiß nicht ob das renderingverfahren allgemein gut ist, aber wenn ich mir z.B. doom3 anschauen, die wirklich lowpoly objekte haben (z.B. würfelfinger), dann wäre das spiel eher fillrate limitiert und der polycount eher nicht so hoch, wenn pVR den ganzen stencilkram durchrechnen kann ohne zbuffer, wäre das ein performancevorteil. ich frage mich aber auch, wie da die shaderswitches zu bewerkstelligen sein sollten.(aber das hatten wir ja schonma, right?

MfG
micki

[Ailuros]

Keine Ahnung was Geometrie-Kompression betrifft, obwohl es gute Vorraussetzungen dafuer wohl gibt.

Ich sehe kein Problem mit Doom3 style rendering und Serie5. Obwohl Fablemark deren eigenes Techdemo ist, schnitt selbst die KYRO2 relativ gut ab in dem sehr fuellraten limitierten Test (kein Wunder heh). Dabei war KYRO aber auch nicht so toll unter allen stencil Situationen, was wohl nicht mehr der Fall sein wird. KYRO hat 32Z/stencil Einheiten und kommt etwa auf die Haelfte der Leistung einer NV35 ran.

Natuerlich ist Fablemark viel zu vereinfacht um mit Doom3 zu vergleichen (nichtmal dot3 oder cube maps), aber wiederum bleibt weder die Anzahl von den Z/units auf gleichem Niveau, noch Taktraten oder auch wesentlich wichtigere Spezifikationen. Ob jetzt z.B. Parameter Bandwidth die Leistung beinflussen koennte oder nicht hab ich keine Ahnung. Es ist auch viel zu weit weg von meinem Wissensbereich.

***edit:

...wie da die shaderswitches zu bewerkstelligen sein sollten...

Was genau meinst Du jetzt mit shaderswitches? (entschuldige die dumme Frage).

[micki]

ich meinte ja auch, dass mit doom3 kein problem wegen der hochen polygonmengen auftritt, sodass der chip doch kein (teilweises) zBuffering durchführen muss.

polygonkompression (eigentlich vertex) ist meiner meinung nach gut möglich, wobei es viel treiberlogic verlangt!!

mit ShaderSwitches meine ich, dass man ja normalerweise für ein objekt einen shader hat (pixel und vertex), und wenn das objekt fertig ist, dann wird der shader eventuell gewechselt. Bei DR-TBR, wird ja nicht das ganze objekt gerendert, sondern nur vielleicht ein poly vom ganzen, kann also sein, dass zig verschiedene shader (jeweils nur für ein poly) benötigt werden, das ist dann ein extremer overhead. als beispiel wäre da multipass rendering fürs bumpmapping mit jeder lichtquelle, pro pixel werden mehrere polys zusammenaddiert, natürlich muss man dann pro poly ein color errechnen, dafür dann pro poly den richtigen shader wählen. ein einziges register hat schon 16bytes, es gibt wohl über 50 (zu faul nachzusehen *g*), stell ich mir schwierig vor.

MfG
micki

[Demirug]

Original geschrieben von Ailuros
Keine Ahnung was Geometrie-Kompression betrifft, obwohl es gute Vorraussetzungen dafuer wohl gibt.

Ich sehe kein Problem mit Doom3 style rendering und Serie5. Obwohl Fablemark deren eigenes Techdemo ist, schnitt selbst die KYRO2 relativ gut ab in dem sehr fuellraten limitierten Test (kein Wunder heh). Dabei war KYRO aber auch nicht so toll unter allen stencil Situationen, was wohl nicht mehr der Fall sein wird. KYRO hat 32Z/stencil Einheiten und kommt etwa auf die Haelfte der Leistung einer NV35 ran.

Natuerlich ist Fablemark viel zu vereinfacht um mit Doom3 zu vergleichen (nichtmal dot3 oder cube maps), aber wiederum bleibt weder die Anzahl von den Z/units auf gleichem Niveau, noch Taktraten oder auch wesentlich wichtigere Spezifikationen. Ob jetzt z.B. Parameter Bandwidth die Leistung beinflussen koennte oder nicht hab ich keine Ahnung. Es ist auch viel zu weit weg von meinem Wissensbereich.

Der Fabelmark ist sehr dominant auf Stencil-Leistung ausgelegt alles andere spielt da kaum eine Rolle.

Das Problem mit den Z/Stencil Einheiten bei den Kyros ist aber das sie im Vergleich zu den Z/Stencil Einheiten in einem IMR einen schlechteren Wirkungsgrad haben weil sie am Anfang der Pixelpipeline sitzen und auf Tileebene arbeiten und die Tiles relative gross sind.

[Modulor]

Original geschrieben von micki
...
polygonkompression (eigentlich vertex) ist meiner meinung nach gut möglich, wobei es viel treiberlogic verlangt!!
...

K.A. ob das hier rein paßt aber die VPUs haben einen registry string der es erlaubt die Vertexdaten zu schrumpfen ("VertexShrinkFactor")...

Beim Faktor 4 und einer Auflösung von 1024x768 sieht das Ergebnis auf dem Bildschirm dann so aus (auf 640x480 verkleinert):
http://www.tilebase.de/screenies/temp/3DMVertexShrink.jpg

Die Meßwerte steigen zudem (bis auf den Vertex Test) dramatisch an:

(jeweils 1024x768 / VertexShrinkFactor 4)
Wings of Fury: 66,1 / 149,1
Proxycon: 7,6 / 25,3
Troll`s Lair: 6,7 / 20,3
Fillrate single: 758,6 / 6588,8
Fillrate multi: 989,8 / 10548,5
Vertex Shader: 8,3 / 8,6
Ragtroll: 4,3 / 8.0

Für die Applikation erscheint die Einstellung transparent - sie geht nach wie vor von einer Auflösung von 1024x768 aus (könnte man gut benchmarks mit faken :D )...
Könnte das auf eine Implemtierung einer Vertexkomprimierung im nächsten 3DLabs Chip hindeuten?

[Gast]

Original geschrieben von Modulor
K.A. ob das hier rein paßt aber die VPUs haben einen registry string der es erlaubt die Vertexdaten zu schrumpfen ("VertexShrinkFactor")...



Eher wohl nicht. Es schaut so aus, als ob die Auflösung um den Faktor 16 reduziert wird. Dadurch steigt dann die virtuelle Füllrate so stark an. Deshalb wird dann auch das realle Bild so klein.

Der Parameter verschiebt damit das Bild in die Linke obere Ecke (zum Nullpunkt) da die Vertex(e) kleiner werden.

[Modulor]

Original geschrieben von Gast
Es schaut so aus, als ob die Auflösung um den Faktor 16 reduziert wird. Dadurch steigt dann die virtuelle Füllrate so stark an. Deshalb wird dann auch das realle Bild so klein.

Der Parameter verschiebt damit das Bild in die Linke obere Ecke (zum Nullpunkt) da die Vertex(e) kleiner werden.

Ist schon klar,aber wozu sollten sich die Programmierer bei 3Dlabs die Mühe machen die Geometrieprozessoren des P9/10 derart arbeiten zu lassen - ein sinnfreies easter egg scheint mir das nicht zu sein...

[Gast]

Original geschrieben von Modulor
Ist schon klar,aber wozu sollten sich die Programmierer bei 3Dlabs die Mühe machen die Geometrieprozessoren des P9/10 derart arbeiten zu lassen - ein sinnfreies easter egg scheint mir das nicht zu sein...


Wie wärs mit Hardware-Scaling für 3D-Grafik ohne das die Software was davon merkt. zB. sinnvoll für AA, bei negativen Werten. Mehr fällt mir nicht ein.

[zeckensack]

Original geschrieben von Modulor
Könnte das auf eine Implemtierung einer Vertexkomprimierung im nächsten 3DLabs Chip hindeuten? Das ist ein post-clip scaling. Traditionelle VS können das nicht, aber es trotzdem Skalierung, und nicht Kompression :)

Kompression verkleinert den benötigten Speicherplatz für Daten, Skalierung modifiziert die Daten. Ich sehe da keinen Zusammenhang.

[Ailuros]

mit ShaderSwitches meine ich, dass man ja normalerweise für ein objekt einen shader hat (pixel und vertex), und wenn das objekt fertig ist, dann wird der shader eventuell gewechselt.

Kann immer noch sein dass ich was falsch verstanden habe, aber ich versuche es trotzdem: PS sind vom VS entkoppelt; praktisch Probleme hat ein TBDR mit den VS wenn sie da nicht extra aufgepasst haben, und mehr im Bereich vom Vertex-Data Bandwidth. Wenn sie aber als Seitennoetiz kein Meta-Talent im VS benutzen werden, sind sie schon bloed :)

Bei DR-TBR, wird ja nicht das ganze objekt gerendert, sondern nur vielleicht ein poly vom ganzen, kann also sein, dass zig verschiedene shader (jeweils nur für ein poly) benötigt werden, das ist dann ein extremer overhead.

TBDRs sind nicht die einzigen Architekturen heutzutage die viel vor dem Rendern verwerfen, selbst wenn es hauptsaechlich auf front to back konzentriert ist. Radeons sind momentan bei drei-stufigem hierarchical Z, bis zu fuenf Stufen sind problemlos moeglich soweit ich weiss. Wo hab ich hier was verpasst? Uebrigens theoretisch arbeitet ein TBDR ideal wenn man ihm die ganze Geometrie info im vorraus gibt, es ist aber keine Vorraussetzung.

[Ailuros]

Original geschrieben von Demirug
Der Fabelmark ist sehr dominant auf Stencil-Leistung ausgelegt alles andere spielt da kaum eine Rolle.

Hab ja auch nicht was anderes behauptet; Doom3 ist tonnenweise komplexer da es sich ja um ein volles Spiel handelt und nicht ein statisches Techdemo. Wie dem auch sei soweit ich weiss haben sie versucht die multipass Methode des Spiels so genau wie moeglich zu imitieren, aber im Endeffekt wollte sie wohl nur zeigen dass sie hohe Stencil-Fuellraten haben koennen in auschliesslich auf stencil op konzentrierten Situationen. Anders koennte ich das gar nicht interpretieren. Zu "allem anderen" ist ja KYRO auch nicht faehig ;)

Das Problem mit den Z/Stencil Einheiten bei den Kyros ist aber das sie im Vergleich zu den Z/Stencil Einheiten in einem IMR einen schlechteren Wirkungsgrad haben weil sie am Anfang der Pixelpipeline sitzen und auf Tileebene arbeiten und die Tiles relative gross sind.

Das duerfte wohl nicht alles sein, aber es ist auch nicht mehr so wichtig heutzutage.

*edit: verdammter UBB :D

[Demirug]

Ailuros, micki meint mit Shaderswitches das folgende Problem:

Bei einem IMR wird ein PS einmal geladen und dann für sehr viele Pixel benutzt wodurch sich der Aufwand fürs laden auf viele Pixel verteilt. Ein TBDR muss aber nun wenn er die zu renderden Pixel herausgefunden hat für jede Tile alle Pixel aufgrund des benutzten Pixelshaders sortieren. Dann jeden Shader laden und die betroffenen Pixel rendern. dann geht es mit dem nächsten Shader weiter. Dadurch besteht die gefahr das die Shaderwechsel (die als teuer gelten) sehr viel häufiger statfinden als bei einem IMR.

Das Problem könnte man natürlich umgehen indem man nach dem ISP noch einmal ein nach Shader sortiertes binning betreibt. Also pro Shadersetup eine Liste hat in der die zu renderen Dreiecke und bei bedarf einer entsprechenden PixelMaske hinterlegt werden.

[Demirug]

Original geschrieben von Ailuros
Hab ja auch nicht was anderes behauptet; Doom3 ist tonnenweise komplexer da es sich ja um ein volles Spiel handelt und nicht ein statisches Techdemo. Wie dem auch sei soweit ich weiss haben sie versucht die multipass Methode des Spiels so genau wie moeglich zu imitieren, aber im Endeffekt wollte sie wohl nur zeigen dass sie hohe Stencil-Fuellraten haben koennen in auschliesslich auf stencil op konzentrierten Situationen. Anders koennte ich das gar nicht interpretieren. Zu "allem anderen" ist ja KYRO auch nicht faehig ;)


Ja die einzelnen Passes haben sie schon nur eben ein bischen anders gewichtet als bei DOOM III. DOOM III benutzt ja ein Shadermodel mit bis zu 6 Textureinputs (wobei 5 davon im Prinzip wiederun das Ergebniss einer Blendoperation aus mehrern Texturen sein kann). Bei diesen Lichtpasses ist der Fabelmark da wesentlich einfacher gehalten.

Aber wo du durchaus recht hastist das die Kyros sowas wie Early Stencil test beherschen. Ein Pixel welcher also durch einen Stenciltest blockiert wird erreicht bei den Kyros niemals den Shadingbereich. Das bringt aber auch nur dann etwas wenn es absolute Lichtfreie Zonen gibt.

[Ailuros]

Bei einem IMR wird ein PS einmal geladen und dann für sehr viele Pixel benutzt wodurch sich der Aufwand fürs laden auf viele Pixel verteilt. Ein TBDR muss aber nun wenn er die zu renderden Pixel herausgefunden hat für jede Tile alle Pixel aufgrund des benutzten Pixelshaders sortieren. Dann jeden Shader laden und die betroffenen Pixel rendern. dann geht es mit dem nächsten Shader weiter. Dadurch besteht die gefahr das die Shaderwechsel (die als teuer gelten) sehr viel häufiger statfinden als bei einem IMR.

*klonk* (<---das war ein Groschen :D )

Das Problem könnte man natürlich umgehen indem man nach dem ISP noch einmal ein nach Shader sortiertes binning betreibt. Also pro Shadersetup eine Liste hat in der die zu renderen Dreiecke und bei bedarf einer entsprechenden PixelMaske hinterlegt werden.

Umgeht man das Problem damit total, oder handelt es sich nur um einen "workaround"? Ein nach Shader extra binning klingt mir persoenlich ja nicht gerade als ideal, ueberhaupt bei sehr komplexen und langen Shadern, die ja bei 3.0 Vorraussetzung sein sollten.

[Demirug]

Original geschrieben von Ailuros
Umgeht man das Problem damit total, oder handelt es sich nur um einen "workaround"? Ein nach Shader extra binning klingt mir persoenlich ja nicht gerade als ideal, ueberhaupt bei sehr komplexen und langen Shadern, die ja bei 3.0 Vorraussetzung sein sollten.

Man umgeht dadurch auf jeden Fall das Problem das man eine Shadersetup mehr als einmal pro Frame laden muss. Allerdings kommt dafür ja wieder das zweite zusätzliche Binning nach dem HSR hinzu. Da müsste man lange den Servercluster Quälen um das mal durchzurechnen welches Verfahren nun wie schnell sein würde bei typischen Anwendungen.

[Ailuros]

Klingt mir zu kompliziert um ehrlich zu sein. Hoffentlich konnten sie bessere Loesungen dafuer finden.