Displayliste und Speicherplatz bei den PowerVR Chips

[loewe]

Für einen Artikel zum Thema PowerVR Technologie brauche ich einige Angaben zu den möglichen Größen der Displayliste(n), die PowerVR ja bekanntlich verwendet.

Wie sicher den meisten hier bekannt, verwendet PowerVR bei seinem TBDR Verfahren eine Displayliste in der alle für die Beschreibung einer Szene notwendigen Daten gesammelt werden. Es guibt dabei grundsätzlich einer Liste für die ganze Szene und weitere Listen für jede Tile, die aber nur noch aus Zeigern auf die entsprechenden Polygone in der Gesamtliste zeigen.
Auch wenn das Macrotile-Patent für die nächste Chipgeneration von wesentlicher Bedeutung sein wird, es ändert an diesem grundsätzlichen Vorgehen nichts, für uns ist hier höchstens wichtig, dass es nun möglich ist beliebig große Szenen mit einer festen Speichergröße zu verwalten.

Was mich jetzt aber nun wirklich interessiert, wie groß ist der für die Displayliste notwendige Speicherplatz heute und in Zukunft.

Hier mal eine kleine Rechnung von mir!

Je Dreieck wird etwa folgendes benötigt:
- 36 Byte (3 x 12 Byte) für die Position der Eckpunkte
- 36 Byte (3 x 12 Byte) für die Richtungsnormalen der Eckpunkte
- 12 Byte (3 x 4 Byte) für die Farben der Eckpunkte
- 12 Byte für die Texturkoordinaten
- 16 Byte für maximal 8 Texturen je Dreieck

macht 112 Byte.
Da fehlt sicher noch was, ich bin aber kein Profi!
Da PowerVR aber grundsätzlich Strips verwendet wird hier natürlich einiges gespart, ich nehme mal an sie kommen damit so bei etwa 80 Byte je Dreieck rein.
Somit hätte ich bei 100.000 Dreiecken schon etwa 8 MegaByte, bei 500.000 Dreiecken 40 MegaByte allein für die Gesamtliste.

Dazu kommt jetzt noch der Bedarf für die Pointerlisten der Tiles. Bei einer Tilegröße von 32x32 Pixel führt das zu 768 Tile bei 1024x768 Pixel und zu 1875 Tile bei 1600x1200 Pixel.
Angenommen ich habe je Tile etwa 50 Dreiecke ergebe sich somit ein zusätzlicher Speicherbedarf von 768x50x3 = 115200 Byte bzw. 1875x50x3 = 281250 Byte, das ist also nicht so sehr viel für die Pointerlisten.

Für Dreiecke mit Shadern ist das nun aber bestimmt ganz anders, aber wie?

Was ist hier falsch und wie sieht es nun bei modernen Games mit Shadern aus, gerade auch mit Shadern der neueren Versionen, also bis Version 3!

[zeckensack]

1)
Für die Position würde ich erstmal 16 Byte veranschlagen.
"w" pro Vertex braucht man primär für perspektivisch korrekte Interpolation von Vertex-Attributen (Farben, fog coord, Texturkoordinaten).
Andererseits kann man davon ausgehen, daß intern (nach Transformation und Clipping) für zumindest x/y nicht mehr zwingend Fließkomma erforderlich ist. Maximale 3D-Auflösung*Subpixelpräzision darstellen zu können, reicht.
ZB bei der durchaus üblichen maximalen 3D-Auflösung von 2048x1536, kommt man mit 12 Bit Fixkomma hin, wenn man auf 16 Bit aufstockt, reicht das auch noch für 16fache Subpixelauflösung.

Kleine Einsparungen sind hier also durchaus möglich.

2)
Texturlayer veranschlagst du mit 16 Byte. Warum?
Die Größe der Koordinaten ist abhängig von der Dimensionalität der Textur, bei stinknormalen 2D-Texturen besteht für die Koordinaten kaum ein Bedarf für mehr als 2 floats => 8 Byte.
Das jeweils gebundene "Textur-Objekt" selbst liesse sich ausreichend über einen 32bittigen Zeiger identifizieren, wobei das schon verschwenderisch gerechnet ist.

3)
Shader sollten von vernünftigen APIs als Objekte gekapselt werden. PowerVR ist IMO klug genug, den gleichen Weg global einzuschlagen. Wieder lässt sich ein komplettes Setup der Pixel-Pipes über einen maximal 32bittigen Zeiger identifizieren. Die eigentlichen Daten liegen dabei natürlich außerhalb der DL.

4)
Der Überlauf der Display List kann nicht endgültig ausgeschlossen werden. Ich sehe hier aber eigentlich kein Problem. Sollte dies passieren, dann muß sie eben zwischendurch geleert werden. Das TBDR-Konzept verliert dadurch zwar einen Teil der erreichbaren Effizienz, es ist aber erstmal wichtiger daß das ganze zuverlässig in allen Lebenslagen funktioniert.
Ein Puffer fester Größe ist zudem viel leichter zu verwalten, und meistens auch effizienter als einer, der dynamisch seine Größe anpasst (optimales Alignment kann garantiert werden, Kopieraktionen bei Größenänderung entfallen).


PS: Das war nicht speziell auf Series 5 bezogen, über die weiß ich sowieso fast garnichts :)

[Demirug]

Wie du eine Displaylist in Stripeform speichern willst ist mir zwar nicht ganz klar aber OK. <- EDIT: Ich blöd zu heiss hier :bonk: natürlich geht das.

Da das PS 3.0 das Speicherintensivste Model ist rechne ich mal damit, OK?

Ein Pixelshader 3.0 braucht folgende Eingangsgrössen:

v0 und v1 als 4*fp
t0 bis t7 als 4*fp
Pos als 2*fp (z,w)´
Pointsize als 1*fp

Für die Rasterisierung sind dann noch 2*fp für die U und V Koordinate des Dreiecks erforderlich. Kann entfallen wenn das Dreieck die Tíle (Makrotile) komplett bedeckt.

= 45*fp

Für jeden Wert braucht man pro Dreieck eine Plane Formel mit 3 Werten.

3*45*fp = 135*fp

Rechent man mit fp24 kommt man auf 405 Byte. mit fp32 sind es dann 540 Byte. Das sind jetzt die Maximalwerte. Werden nicht alle Register gebraucht kann man entsprechend sparen. Mindestens braucht man die Position und die Raster
Packen lässt sich das ganze normalerweise auch noch.

Zudem kommen dann pro Polygone noch ein Satz Konstanten hinzu

32*4*fp
16*4*Int
16*Bool

und dann noch bis zu 16 Verweise auf die zu verwendenen Texturen.

[Demirug]

zeckensack, für das Überlauf problem gibt es ein entsprechendes Patent.

[Demirug]

Kleine ergänzung: Man muss natürlich nicht das Plane verfahren benutzten. Sondern kann Natürlich den Vertexstream hinterlegen und die Planes erst nach dem wieder einladen erzeugen.

Dann kommen wir auf

fp24 = 135 Byte
fp32 = 180 Byte

pro Vertex

Pro Dreieck fallen dann en noch jeweils 3 Verweise auf die Vertexdaten an. Aber auch hier kann man unter umständen noch was sparen in dem man Stripeweise speichert. Also immer den ersten benutzen Vertex und dann die Anzahl der Dreiecke.

[loewe]

Original geschrieben von zeckensack
1)
Für die Position würde ich erstmal 16 Byte veranschlagen.
"w" pro Vertex braucht man primär für perspektivisch korrekte Interpolation von Vertex-Attributen (Farben, fog coord, Texturkoordinaten).
Andererseits kann man davon ausgehen, daß intern (nach Transformation und Clipping) für zumindest x/y nicht mehr zwingend Fließkomma erforderlich ist. Maximale 3D-Auflösung*Subpixelpräzision darstellen zu können, reicht.
ZB bei der durchaus üblichen maximalen 3D-Auflösung von 2048x1536, kommt man mit 12 Bit Fixkomma hin, wenn man auf 16 Bit aufstockt, reicht das auch noch für 16fache Subpixelauflösung.

Kleine Einsparungen sind hier also durchaus möglich.

Das mit den Fixkomma ist eine wirklich gute Idee. Ich bin fast überzeugt, dass sie das tun werden. Die Displayliste wird ja erst vom TA erzeugt, da sind ja alle Messen schon gesungen, die Daten brauchen nur noch der ISP und die TSP, da könnne sie jedes Format verwenden was sie wollen und was ausreichend genau ist.

2)
Texturlayer veranschlagst du mit 16 Byte. Warum?
Die Größe der Koordinaten ist abhängig von der Dimensionalität der Textur, bei stinknormalen 2D-Texturen besteht für die Koordinaten kaum ein Bedarf für mehr als 2 floats => 8 Byte.
Das jeweils gebundene "Textur-Objekt" selbst liesse sich ausreichend über einen 32bittigen Zeiger identifizieren, wobei das schon verschwenderisch gerechnet ist.

Für die Texturlayer habe ich zwei Byte je Layer veranschlagt, zwei Floats wäre sicher besser, somit komme ich aber sogar auf maximal 64 Byte!

3)
Shader sollten von vernünftigen APIs als Objekte gekapselt werden. PowerVR ist IMO klug genug, den gleichen Weg global einzuschlagen. Wieder lässt sich ein komplettes Setup der Pixel-Pipes über einen maximal 32bittigen Zeiger identifizieren. Die eigentlichen Daten liegen dabei natürlich außerhalb der DL.

Genau deshalb frage ich, ich habe von den moderneren Sachen überhaupt keine Ahnung. Aber Demi gibt hier weiter unten Daten an und aus einem bestimmten Grunde, hat sehr viel mit Serie 5 zu tun, könnte ich mir vorstellen das sie die Shader gern gespeichert hätten und nicht nur einen Zeiger darauf. *g*

4)
Der Überlauf der Display List kann nicht endgültig ausgeschlossen werden. Ich sehe hier aber eigentlich kein Problem. Sollte dies passieren, dann muß sie eben zwischendurch geleert werden. Das TBDR-Konzept verliert dadurch zwar einen Teil der erreichbaren Effizienz, es ist aber erstmal wichtiger daß das ganze zuverlässig in allen Lebenslagen funktioniert.
Ein Puffer fester Größe ist zudem viel leichter zu verwalten, und meistens auch effizienter als einer, der dynamisch seine Größe anpasst (optimales Alignment kann garantiert werden, Kopieraktionen bei Größenänderung entfallen).

Doch der Überlauf der Displayliste wird vollkommen ausgeschlossen, siehe hier: 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

Aber du kommst dem schon recht nahe, in so einem Falle verhält er sich dann eben mehr wie ein IMR.

PS: Das war nicht speziell auf Series 5 bezogen, über die weiß ich sowieso fast garnichts :)
Ja da geht es uns allen recht ähnlich! :)
Ich kenne zwar ein paar Leute die fast alles über Serie 5 wissen, aber viel erfahren kann man da auch nicht!
BTW, einer wird hier gerade wieder diskutiert! ;D

[zeckensack]

Original geschrieben von loewe
Für die Texturlayer habe ich zwei Byte je Layer veranschlagt, zwei Floats wäre sicher besser, somit komme ich aber sogar auf maximal 64 Byte!Whoops. Dann habe ich dich falsch gelesen.
Genau deshalb frage ich, ich habe von den moderneren Sachen überhaupt keine Ahnung. Aber Demi gibt hier weiter unten Daten an und aus einem bestimmten Grunde, hat sehr viel mit Serie 5 zu tun, könnte ich mir vorstellen das sie die Shader gern gespeichert hätten und nicht nur einen Zeiger darauf. *g*Daß alle Daten die vom VS and den PS weitergereicht werden sollen, pro Vertex abgespeichert werden müssen, ist schonmal einleuchtend.
Mit dem Zeiger für den Shader meinte ich einen Verweis auf das Programm, nicht auf die Daten :)

Daß man dadurch viel Speicherplatz spart ggü dem Fall, das Programm (bzw das fixed function pipeline setup) für jedes Dreieck voll abzuspeichern, sollte IMO klar sein.
Ergo => Mißverständnis #2 :-)

Man kann natürlich erstmal nur Position berechnen, dann die Sichtbarkeit berechnen, und nur für die dann noch übriggebliebenen Dreiecke den Rest des VS ausführen. Hmmm ...
Doch der Überlauf der Displayliste wird vollkommen ausgeschlossen, siehe hier: http://l2.espacenet.com/espacenet/bnsviewer?CY=gb&LG=en&DB=EPD&PN=GB2378108&ID=GB+++2378108A++I+

Aber du kommst dem schon recht nahe, in so einem Falle verhält er sich dann eben mehr wie ein IMR.Aber im Schnitt eben trotzdem noch effizienter als ein echter IMR :)
Ja da geht es uns allen recht ähnlich! :)
Ich kenne zwar ein paar Leute die fast alles über Serie 5 wissen, aber viel erfahren kann man da auch nicht!
BTW, einer wird hier gerade wieder diskutiert! ;D Ich will jetzt Series 5 sehen und alles wissen! Sofort! :bäh:

[Demirug]

Original geschrieben von zeckensack
Man kann natürlich erstmal nur Position berechnen, dann die Sichtbarkeit berechnen, und nur für die dann noch übriggebliebenen Dreiecke den Rest des VS ausführen. Hmmm ...

Ich bin dir da schon ein Stück vorraus: :D

http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=75598

[loewe]

Original geschrieben von Demirug
Wie du eine Displaylist in Stripeform speichern willst ist mir zwar nicht ganz klar aber OK. <- EDIT: Ich blöd zu heiss hier :bonk: natürlich geht das.

Da das PS 3.0 das Speicherintensivste Model ist rechne ich mal damit, OK?

Ein Pixelshader 3.0 braucht folgende Eingangsgrössen:

v0 und v1 als 4*fp
t0 bis t7 als 4*fp
Pos als 2*fp (z,w)´
Pointsize als 1*fp

Entschuldige wenn ich mich blöde anstelle, aber diese Daten kommen je Vertex zu meinen dazu, wenn ich Pixelshader 3.0 verwende? Oder kann da dann auch was weg gelassen werden? Wir kommen doch so schnell mal auf 200 Byte je Vertex?!!

Für die Rasterisierung sind dann noch 2*fp für die U und V Koordinate des Dreiecks erforderlich. Kann entfallen wenn das Dreieck die Tíle (Makrotile) komplett bedeckt.

Woher sollen die kommen? Die Displayliste wird vom TA erzeugt und der "weiß" nur ob das Dreieck in der Tile ist oder nicht, weitere Angaben sind auch für den ISP nicht erforderlich, das Ding arbeitet immer noch mit infinete planes.

= 45*fp

Für jeden Wert braucht man pro Dreieck eine Plane Formel mit 3 Werten.

3*45*fp = 135*fp

Rechent man mit fp24 kommt man auf 405 Byte. mit fp32 sind es dann 540 Byte. Das sind jetzt die Maximalwerte. Werden nicht alle Register gebraucht kann man entsprechend sparen. Mindestens braucht man die Position und die Raster
Packen lässt sich das ganze normalerweise auch noch.

Zudem kommen dann pro Polygone noch ein Satz Konstanten hinzu

32*4*fp
16*4*Int
16*Bool

und dann noch bis zu 16 Verweise auf die zu verwendenen Texturen.

Da kommen ja Datenmengen zusammen!
Wo blweiben wir denn nun etwa je Dreieck stehen, das ist ja maximal fast 1 KB!?

Du mußt doch mit sowas Erfahrung haben, wo liegen wir denn bei heutigen Entwicklungen, also bei dem was Serie 5 wird bringen müssen?

[loewe]

Original geschrieben von Demirug
Ich bin dir da schon ein Stück vorraus: :D

http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=75598

Ich kenne deine Idee und wir haben sie auch schon einmal in anderer Runde diskutiert! :D

Leider muss ich sagen, so gut ist sie nicht angekommen.
Der wesentliche Vorteil den du nennst ist die Einsparung von Bandbreite, genau das ist aber kein großes Problem für die nächsten Generationen von PowerVR. Dort wird noch einmal massiv angesetzt und die Probleme der KYROs wurden überwunden.

Gerade das Cachen der Daten und das wiederholte Einladen ist sehr negativ bewertet worden. Das Ziel ist eigentlich immer das Polygon einmal an zu fassen und dann nicht wieder zu verwenden.

[Demirug]

Original geschrieben von loewe
Entschuldige wenn ich mich blöde anstelle, aber diese Daten kommen je Vertex zu meinen dazu, wenn ich Pixelshader 3.0 verwende? Oder kann da dann auch was weg gelassen werden? Wir kommen doch so schnell mal auf 200 Byte je Vertex?!!

Das ist der komplette Vertexdatensatz. 45 Floats pro Vertex. Minimum sind 4 Floats.

Woher sollen die kommen? Die Displayliste wird vom TA erzeugt und der "weiß" nur ob das Dreieck in der Tile ist oder nicht, weitere Angaben sind auch für den ISP nicht erforderlich, das Ding arbeitet immer noch mit infinete planes.

Die werden aus den x,y,z Korrdinaten der 3 Eckpunkte bestimmt. spielt aber keine Rolle da wir ja Vertexweise speichern und nicht Dreicksweise. In dem Fall speichert man eben nicht u & v sondern x und Y.

Da kommen ja Datenmengen zusammen!
Wo blweiben wir denn nun etwa je Dreieck stehen, das ist ja maximal fast 1 KB!?

Die Konstanten müssen nur maximal einmal pro Poly(= viele Dreiecke) gepeichert werden und auch nur die welche wirklich vom Shader benutzte werden.

Pro Dreieck brauchen wir zwischen 16 und 540 Byte für die Vertexdaten. Hängt ganz davon ab wie das Polygone gespeichert ist und wie aufwendig der Pixelshader ist.

Du mußt doch mit sowas Erfahrung haben, wo liegen wir denn bei heutigen Entwicklungen, also bei dem was Serie 5 wird bringen müssen?

Das was da oben steht muss im Rahmen des möglichen liegen. Nun muss man dabei aber berücksichtigen das um solch grosse Vertexdatenblöcke zu verarbeiten auch viele Shaderanweisungen notwendig sind. Aber wir sind hier genau am Knackpunkt den ich ja schon länger predige. Die Datenmenge zwischen dem Vertexshader und dem Pixelshader steigt ständig. Bei einem IMR spielt das keine Rolle weil die Daten nur Chipintern gehandelt werden. Ein DR nach dem PowerVR prinzip muss sie aber speichern ausser sie haben sowas gebaut was ich in dem anderen Thread schon länger vorgeschlagen habe.

[Demirug]

Original geschrieben von loewe
Ich kenne deine Idee und wir haben sie auch schon einmal in anderer Runde diskutiert! :D

Leider muss ich sagen, so gut ist sie nicht angekommen.
Der wesentliche Vorteil den du nennst ist die Einsparung von Bandbreite, genau das ist aber kein großes Problem für die nächsten Generationen von PowerVR. Dort wird noch einmal massiv angesetzt und die Probleme der KYROs wurden überwunden.

Gerade das Cachen der Daten und das wiederholte Einladen ist sehr negativ bewertet worden. Das Ziel ist eigentlich immer das Polygon einmal an zu fassen und dann nicht wieder zu verwenden.

Ähm ich habe eigentlich zwei Vorteile aufgeführt. Bandbreite und Rechenleistung werden gespart. Wiederholt wird da kaum etwas eingeladen.

nVidia spielt übrigens mit sowas rum wie ich gestern erfahren habe. Ob es schon in einem käuflichen Chip verbaut ist habe ich aber nicht erfahren können.

[zeckensack]

Original geschrieben von Demirug
<...> Aber wir sind hier genau am Knackpunkt den ich ja schon länger predige. Die Datenmenge zwischen dem Vertexshader und dem Pixelshader steigt ständig. Bei einem IMR spielt das keine Rolle weil die Daten nur Chipintern gehandelt werden. Ein DR nach dem PowerVR prinzip muss sie aber speichern ausser sie haben sowas gebaut was ich in dem anderen Thread schon länger vorgeschlagen habe. Ist das Problem wirklich ein Problem, oder sieht es nur danach aus? ;)
Klar spielt es eine Rolle, man sollte Vertexdaten schon möglichst platzsparend speichern.
Aber davon abgesehen, kann man doch eigentlich erwarten, daß Shader, die viele Daten benutzen auch viele Instruktionen haben. Insofern steigt der Bandbreitenbedarf in Korrelation zur steigenden ALU-Last (und gleichzeitig sinkender Output-Bandbreite).

Oder anders gesagt, wenn die Bandbreitenanforderung extrem steigt, ist die PS-ALU schon längst so verstopft, daß es auch schon wieder egal ist. Vielleicht nicht immer, aber immer öfter :D

[loewe]

Original geschrieben von Demirug
Das was da oben steht muss im Rahmen des möglichen liegen. Nun muss man dabei aber berücksichtigen das um solch grosse Vertexdatenblöcke zu verarbeiten auch viele Shaderanweisungen notwendig sind. Aber wir sind hier genau am Knackpunkt den ich ja schon länger predige. Die Datenmenge zwischen dem Vertexshader und dem Pixelshader steigt ständig. Bei einem IMR spielt das keine Rolle weil die Daten nur Chipintern gehandelt werden. Ein DR nach dem PowerVR prinzip muss sie aber speichern ausser sie haben sowas gebaut was ich in dem anderen Thread schon länger vorgeschlagen habe.

Das Speichern der Daten sollte nicht unbedingt das Problem sein, so teuer ist Speicher nicht und soweit ich PowerVR kenne, neigen sie nicht dazu unbedingt 800 MHz DDR II RAM zu brauchen.

Die Buslast ist nicht höher als bei IMRs und so bleibt es an der Größe der Displayliste hängen, die recht wahrscheinlich natürlich komprimiert wird?!

[Demirug]

Original geschrieben von zeckensack
Ist das Problem wirklich ein Problem, oder sieht es nur danach aus? ;)
Klar spielt es eine Rolle, man sollte Vertexdaten schon möglichst platzsparend speichern.
Aber davon abgesehen, kann man doch eigentlich erwarten, daß Shader, die viele Daten benutzen auch viele Instruktionen haben. Insofern steigt der Bandbreitenbedarf in Korrelation zur steigenden ALU-Last (und gleichzeitig sinkender Output-Bandbreite).

Oder anders gesagt, wenn die Bandbreitenanforderung extrem steigt, ist die PS-ALU schon längst so verstopft, daß es auch schon wieder egal ist. Vielleicht nicht immer, aber immer öfter :D

Kann man ja leicht ausrechnen.

Ein R300 ist zum Beispiel in der Lage maximal 512 Bit Vertexoutput pro Takt zu erzeugen. Das ist natürlich der Extremfall. In der Praxis würde ich von maximal einem virtel davon ausgehen. Also 128 Bit/Takt. Aber da sehe ich gar nicht mal so das Problem. Mir ging es eher darum das die Dreiecke immer kleiner werden aber die Datenmenge pro Eckpunkt steigt.

[loewe]

Original geschrieben von Demirug
... Mir ging es eher darum das die Dreiecke immer kleiner werden aber die Datenmenge pro Eckpunkt steigt.

Gibt es da nicht so eine Eierlegendewollmilchsau mit der man dagegen etwas tun kann? ;D

[Demirug]

Original geschrieben von loewe
Das Speichern der Daten sollte nicht unbedingt das Problem sein, so teuer ist Speicher nicht und soweit ich PowerVR kenne, neigen sie nicht dazu unbedingt 800 MHz DDR II RAM zu brauchen.

Die Buslast ist nicht höher als bei IMRs und so bleibt es an der Größe der Displayliste hängen, die recht wahrscheinlich natürlich komprimiert wird?!

Kompression ist immer eine Möglichkeit aber das machen die IMRs ja inzwischen auch schon.

[zeckensack]

Original geschrieben von Demirug
<...>
Mir ging es eher darum das die Dreiecke immer kleiner werden aber die Datenmenge pro Eckpunkt steigt. Ich sehe die Verbindung zwischen diesen beiden Punkten nicht wirklich???
Ersteres ist ein Problem, auch für 'breite' IMRs btw, letzteres (seperat betrachtet) IMO eher nicht, wie oben ausgeführt.

Ich sehe das ganze im Gegenteil eher so, daß je kleiner die Dreiecke werden, desto mehr kann man gefahrlos Berechnungen in die Vertex-Ebene verschieben, ohne sich große Fehler einzuhandeln.

"Per pixel lighting" zB brauche ich überhaupt nicht mehr, wenn die Dreiecke alle nur ein Pixel bedecken. Dann kann ich das im VS erledigen, und komme mit einem Minimum an durchgereichten Vertex-Attributen aus.

Das war ja die ursprüngliche Idee hinter FF-Lighting. Für präzise Beleuchtung braucht's feine Tesselierung, für den passenden Kompromiss muß dabei der Entwickler sorgen.

[Demirug]

Original geschrieben von zeckensack
Ich sehe die Verbindung zwischen diesen beiden Punkten nicht wirklich???
Ersteres ist ein Problem, auch für 'breite' IMRs btw, letzteres (seperat betrachtet) IMO eher nicht, wie oben ausgeführt.

Ich sehe das ganze im Gegenteil eher so, daß je kleiner die Dreiecke werden, desto mehr kann man gefahrlos Berechnungen in die Vertex-Ebene verschieben, ohne sich große Fehler einzuhandeln.

"Per pixel lighting" zB brauche ich überhaupt nicht mehr, wenn die Dreiecke alle nur ein Pixel bedecken. Dann kann ich das im VS erledigen, und komme mit einem Minimum an durchgereichten Vertex-Attributen aus.

Das war ja die ursprüngliche Idee hinter FF-Lighting. Für präzise Beleuchtung braucht's feine Tesselierung, für den passenden Kompromiss muß dabei der Entwickler sorgen.

Je mehr Daten man zwischen dem VS und PS verschiebt desto mehr Pixel muss man bei einem TBDR daraus erzeugen das am Ende nicht das Zwischenspeichern der berechneten Verticen mehr Bandbreite verbraucht als die Bandbreite die ein IMR dafür verbrauchen würde. Und wenn dann so ein Dreieck vom HSR weggeworfen wird ist es doppelt ärgerlich.

Interpolieren gibt Fehler. Zudem habe ich den Eindruck das die Rechenpower im Pixelbereich schneller steigt als im Vertexbereich. Und sobald man die ganzen schönen neuen Effekte benutzt kommt man da nicht so ohne weiteres um den Pixelshader herum. OK VS 3.0 erlauben auch Texturezugriffe aber nicht so viele wie die PS.

[Demirug]

Original geschrieben von loewe
Gibt es da nicht so eine Eierlegendewollmilchsau mit der man dagegen etwas tun kann? ;D

Ja, auch wenn du und deine Gesprächspartner es nicht glauben.

Meine Idee löst genau dieses Problem weil die Datenmenge pro Eckpunkt welche gespeichert werden muss Konstant ist. Egal wie aufwendig der VS eigentlich ist. Da der aufwendige und datenintensive Teil ja bis nach dem HSR verzögert wird muss davon nichts ins RAM.

[Pitchfork]

Jetzt mal ein dummer Einwurf von der Seite....

eine der höchsten Kosten bei ati und nv ist der Wechsel eines PixelShaders oder eines VertexShaders.

Ein Tiler hat jetzt das Problem, daß im schlimmsten Fall für jedes Dreieck der Pixel Shader gewechselt werden muß. Und wenn man Demirugs Verfahren für die Vertex Shader Optimierung anwenden will, dann auch noch für die Vertex Shader. Uffa.

[Demirug]

Original geschrieben von Pitchfork
Jetzt mal ein dummer Einwurf von der Seite....

eine der höchsten Kosten bei ati und nv ist der Wechsel eines PixelShaders oder eines VertexShaders.

Ein Tiler hat jetzt das Problem, daß im schlimmsten Fall für jedes Dreieck der Pixel Shader gewechselt werden muß. Und wenn man Demirugs Verfahren für die Vertex Shader Optimierung anwenden will, dann auch noch für die Vertex Shader. Uffa.

Ja hier muss natürlich die Architektur so aufgebaut werden das ein möglichst schneller Wechsel möglich ist. Also Programmcaches und umschalten ohne Taktverlust. IMRs haben ja da sie als Streamprocessoren ausgeleg das Designprinzip das man auf viele Daten die gleichen Operationen anwendet. Daher ist der Programmwechsel dort die Operation welche man am weningsten optimiert.

[Ailuros]

Ich hab irgendwie den Eindruck dass heutige high end TBDRs Cache-freundlicher sind, als IMRs.... :weg:

[Demirug]

Original geschrieben von Ailuros
Ich hab irgendwie den Eindruck dass heutige high end TBDRs Cache-freundlicher sind, als IMRs.... :weg:

Cachefreundlicher?

Hättest du jetzt gesagt das sie Bulktransfers besser nutzen können hätte ich sofort zugestimmt.

[Ailuros]

Original geschrieben von zeckensack
Ich will jetzt Series 5 sehen und alles wissen! Sofort! :bäh:

Nein. :ups:

nVidia spielt übrigens mit sowas rum wie ich gestern erfahren habe. Ob es schon in einem käuflichen Chip verbaut ist habe ich aber nicht erfahren können.

Hoch-spekulativ: naechste Generation.

Da ihr schon den Thread (und den Thread zum Thread) erwaehnt habt:

<snip>

In terms of arithmetic capabilities, they are not really all that different. Key difference though is that the amount of pixel processing required is much higher than the number of vertex processing, there are substantially more pixels in a scene than vertices. Another issue is that the pixel side has to cope with a lot more latency than the vertex shader side, the main reason for this is texture access (especially dependent reads and random/noise based arithmetic reads). If a texel fetch fails on the cache an external memory access is required and due to buffering and other memory operations this can lead to latencies of hundreds of clock cycles. Current vertex shaders do not suffer from such long latencies. Hence more parallellism is required in the pixel shader (more pixels processed at the same time) because more latency has to be absorbed.

[loewe]

Original geschrieben von Pitchfork
Ein Tiler hat jetzt das Problem, daß im schlimmsten Fall für jedes Dreieck der Pixel Shader gewechselt werden muß.

Du meinst hier sicher je Pixel. Das wäre für die KYROs sicher ein Problem gewesen, da sie aber keine Shader haben ist es es also nicht so schlimm! ;D

Für Serie 5 wird das so nicht mehr stimmen, die Tiles werden nicht mehr entlang einer Scanline abgearbeitet.

[Gast]

Original geschrieben von loewe
Du meinst hier sicher je Pixel. Das wäre für die KYROs sicher ein Problem gewesen, da sie aber keine Shader haben ist es es also nicht so schlimm! ;D

Für Serie 5 wird das so nicht mehr stimmen, die Tiles werden nicht mehr entlang einer Scanline abgearbeitet.

Upps...

Das hört sich ja jetzt verdächtig nach einer Art Pixel-Planes Konzept an.

[Pitchfork]

Original geschrieben von loewe
Du meinst hier sicher je Pixel. Das wäre für die KYROs sicher ein Problem gewesen, da sie aber keine Shader haben ist es es also nicht so schlimm! ;D

Für Serie 5 wird das so nicht mehr stimmen, die Tiles werden nicht mehr entlang einer Scanline abgearbeitet.

Ich bin tatsächlich davon ausgegangen, daß ein Tiler trotz allem immer ganze Tris abarbeitet, deshalb meinte ich schon pro Tri.
Sollte ein ziemlich großer ziemlich schneller Programm- und Konstantenspeicher sein. Andererseits hat die nv3x Generation ja schon die PixelShader in das VRAM verlegt, ein Tiler müßte das genauso machen, dadurch sollte das leichter zu implementieren sein, gute Caches vorausgesetzt.

[GloomY]

Original geschrieben von Demirug
Cachefreundlicher?

Hättest du jetzt gesagt das sie Bulktransfers besser nutzen können hätte ich sofort zugestimmt. Erklär' mal bitte, was Bulktransfer ist. :) Meiner Wenigkeit ist das nicht präsent.

Bezüglich Caches würde ich mal sagen, dass IMRs eine höhere räumliche Lokalität bevorzugen, weil sie immer komplette Dreiecke rendern. Ein TBDR kann von einem Dreieck auch nur mal einen einzigen Pixel rendern und damit auch nur einen kleinen Teil der Textur verwenden. Hier wäre eine geringere Line Size wahrscheinlich vorteilhafter.

[Demirug]

Original geschrieben von GloomY
Erklär' mal bitte, was Bulktransfer ist. :) Meiner Wenigkeit ist das nicht präsent.

Burstmode sagt dir sicher was?

Ein Bulktransfer ist wenn man eine grossen Speicherbereich linear via Burst ausliest.

Bezüglich Caches würde ich mal sagen, dass IMRs eine höhere räumliche Lokalität bevorzugen, weil sie immer komplette Dreiecke rendern. Ein TBDR kann von einem Dreieck auch nur mal einen einzigen Pixel rendern und damit auch nur einen kleinen Teil der Textur verwenden. Hier wäre eine geringere Line Size wahrscheinlich vorteilhafter.

Die Line Size sollte man aber schon an das Memoryinterface anpassen. Und bei Komprimierten texturen muss man sowieso immer alle benötigten Kacheln einladen.

[Demirug]

Original geschrieben von Pitchfork
Andererseits hat die nv3x Generation ja schon die PixelShader in das VRAM verlegt, ein Tiler müßte das genauso machen, dadurch sollte das leichter zu implementieren sein, gute Caches vorausgesetzt.

OT: Ja, und sie werden auf sehr interesante Art eingeladen. :D

[loewe]

Original geschrieben von Pitchfork
Ich bin tatsächlich davon ausgegangen, daß ein Tiler trotz allem immer ganze Tris abarbeitet, deshalb meinte ich schon pro Tri.
Sollte ein ziemlich großer ziemlich schneller Programm- und Konstantenspeicher sein. Andererseits hat die nv3x Generation ja schon die PixelShader in das VRAM verlegt, ein Tiler müßte das genauso machen, dadurch sollte das leichter zu implementieren sein, gute Caches vorausgesetzt.

Nein, ein Tiler nach PowerVR arbeitet nur im TA (Tileaccelerator) ganze Dreiecke ab. Dort wird die Displayliste erzeugt, welche dann die Grundlage für den ISP, die HSR Einheit, und den TSP, den Textur- und Shading Prozessor bildet.
Innerhalb des ISP erfolgt die Bestimmung der sichtbaren Dreiecke je Pixel dann zwar dreiecksweise je Tile, wobei bisher immer komplette Scannlines (32 Pixel) für ein Dreieck getestet werden, wenn das Dreieck auch nur mit einem Pixel in der Zeile liegt.
Im Extremfall kann es also passieren das für jedes Pixel eines Tiles ein anderes Dreieck sichtbar ist, was sicher für nachfolgende Shaderops nicht lustig wäre.

Wie ich schon andeutete wird Serie 5 hier einiges ändern und wesentlich effektiver werden.

[loewe]

Original geschrieben von Demirug
Burstmode sagt dir sicher was?

Ein Bulktransfer ist wenn man eine grossen Speicherbereich linear via Burst ausliest.


Ich kannte den Begriff nicht, aber er beschreibt das Vorgehen wirklich gut!
Nur wenn du das sagst klingt es immer irgendwie negativ? :D
Was ist schlecht daran eine Technologie zu haben, die von solchen einfachen Methoden sehr profitieren kann?

Die Line Size sollte man aber schon an das Memoryinterface anpassen. Und bei Komprimierten texturen muss man sowieso immer alle benötigten Kacheln einladen.

Ob ich jetzt Linien oder andere Figuren teste, es sollte immer bei allen Technologien auf das Memoryinterface abgestimmt sein.
BTW, deine Schätzung bezüglich der parallel zu testenden Pixel ist viel zu hoch. ;)

[Demirug]

Original geschrieben von loewe
Ich kannte den Begriff nicht, aber er beschreibt das Vorgehen wirklich gut!
Nur wenn du das sagst klingt es immer irgendwie negativ? :D
Was ist schlecht daran eine Technologie zu haben, die von solchen einfachen Methoden sehr profitieren kann?

Nein beim besten Willen nicht. Bulk ist das beste was man dem Speicher antun kann. Ich gebe hier zwar oft den "advocatus diabolus" aber das ist wohl immer noch die Macht der Gewohnheit. Ich musste mal eine ganze Zeit lang Systemdesigns prüfen. Und für jedes mögliche Problem das ich übersehen habe und dann natürlich aufgetreten ist musste ich mir dann was anhören. Ist zum Glück nicht oft passiert.


Ob ich jetzt Linien oder andere Figuren teste, es sollte immer bei allen Technologien auf das Memoryinterface abgestimmt sein.
BTW, deine Schätzung bezüglich der parallel zu testenden Pixel ist viel zu hoch. ;)

Ich meinte die Cachelinesize.

Ich weiss das sie zu hoch ist. Diese Kalkulation ging ja auch davon aus das PowerVr weiterhin auf dumme brachial Power dabei setzt. Ich würde sagen das es 32-64 (absolute Obergrenze 128) Einheiten sind. Abhängig davon mit wie viele MSAA Samples gearbeitet wird.

[loewe]

Original geschrieben von Demirug
Nein beim besten Willen nicht. Bulk ist das beste was man dem Speicher antun kann. Ich gebe hier zwar oft den "advocatus diabolus" aber das ist wohl immer noch die Macht der Gewohnheit. Ich musste mal eine ganze Zeit lang Systemdesigns prüfen. Und für jedes mögliche Problem das ich übersehen habe und dann natürlich aufgetreten ist musste ich mir dann was anhören. Ist zum Glück nicht oft passiert.

Ok, dann klang das nur so!
Ich habe zwar auch eine Menge Dinge die ich mir anders vorstelle, aber mir ist klar das man immer irgendwann sagen muss "ich hab fertig", auch wenn natürlich mehr gehen würde, wenn die Zeit und das Geld nichtwären!
BTW, hab ich heute gerade durch! ;D



Ich weiss das sie zu hoch ist. Diese Kalkulation ging ja auch davon aus das PowerVr weiterhin auf dumme brachial Power dabei setzt. Ich würde sagen das es 32-64 (absolute Obergrenze 128) Einheiten sind. Abhängig davon mit wie viele MSAA Samples gearbeitet wird.
Naja, 32 hatten sie ja schon früher, ein bnischen mehr sollte es für einen Highend Tiler schon sein.

Können wir das Thema FSAA bitte außen vor lassen bis es offiziell ist, dazu sage ich überhaupt nichts!

[Demirug]

Original geschrieben von loewe
Naja, 32 hatten sie ja schon früher, ein bnischen mehr sollte es für einen Highend Tiler schon sein.

Können wir das Thema FSAA bitte außen vor lassen bis es offiziell ist, dazu sage ich überhaupt nichts!

Wenn man den Takt so auf 400 MHz erhöht, nur mit 4xMSAA arbeitet, und die Einheiten richtig nutzt dann reichen 32 Stück. Davor dann noch ein paar Hirachiestufen für ein schnelle Rauswerfen von grossen stücken und fertig ist das ganze. Da ich aber 4xMSAA für etwas zu schäbig halte gehe ich mal von 8xMSAA aus und dann braucht es eben 64 Einheiten. Aber ich höre ja schon auf da war ja schon 3 mal das verbotene Wort drin. :weg:

PS: Ich lese zu viele Patente und Chipdesign unterlagen. :balla:

[Ailuros]

Demi,

Du musst bedenken dass ich das Englisch eines Belgier (der hoechstwahrscheinlich belgisch denkt), umsetzen muss in Deutsch, wobei ich oft griechisch denke. Wenn das verwirrend klingt, stell Dir vor wie verwirrend es oft sein kann, Sachen auseinanderzuhalten. ;)

Zum Thema AA (tschuldige Loewe aber es muss sein): noch mal mir ist der grid pattern um so einiges wichtiger als die Anzahl von samples.

Laien-Illustrierung:

---x--x--x--x---
---x--x--x--x---
---x--x--x--x---
---x--x--x--x---

Igittigitt :igitt:

-------x--------
--x-------------
----------x-----
-----x----------

:w00t:

Dabei waeren ja >6x sparse sampled grid wirklich der Hammer :respekt:

[Demirug]

Original geschrieben von Ailuros
Demi,

Du musst bedenken dass ich das Englisch eines Belgier (der hoechstwahrscheinlich belgisch denkt), umsetzen muss in Deutsch, wobei ich oft griechisch denke. Wenn das verwirrend klingt, stell Dir vor wie verwirrend es oft sein kann, Sachen auseinanderzuhalten. ;)

Zum Thema AA (tschuldige Loewe aber es muss sein): noch mal mir ist der grid pattern um so einiges wichtiger als die Anzahl von samples.

Laien-Illustrierung:

---x--x--x--x---
---x--x--x--x---
---x--x--x--x---
---x--x--x--x---

Igittigitt :igitt:

-------x--------
--x-------------
----------x-----
-----x----------

:w00t:

Dabei waeren ja >6x sparse sampled grid wirklich der Hammer :respekt:

wir ärgern hier nur Loewe. Das Grid ist ein technisches Detail um das ich mir im Zusammenhang mit der Anzahl der Z/Stencil Einheiten keine grossen Gedanken machen weil es da letzten Endes dann nur um den Transitorecount für eine Einheit geht. Je komplexer/variabler das Grid desto mehr Transitoren gehen eben pro Z/Stencil Einheit drauf.

Alle Leistungsbetrachtungen und die benötige Anzahl von Einheiten kann man aber letzten Endes an der Sample Anzahl festmachen.

[Ailuros]

Jetzt hast Du mich verwirrt (und Loewe entschuldige das OT, aber Du weisst wie wichtig mir AA ist):

Das Grid ist ein technisches Detail um das ich mir im Zusammenhang mit der Anzahl der Z/Stencil Einheiten keine grossen Gedanken machen weil es da letzten Endes dann nur um den Transitorecount für eine Einheit geht. Je komplexer/variabler das Grid desto mehr Transitoren gehen eben pro Z/Stencil Einheit drauf.

Gehen mehr Transistoren pro Z/stencil unit drauf zwischen 4x sparse und 16x ordered grid? Ich hab den Eindruck dass die 4-fache Anzahl der samples (selbst nur ordered grid) doch mehr Transistoren verbraucht als 4x sparse.

Ich weiss nichtmal wie gross der Unterschied ist in Transistoren zwischen 4x sparse und 4x ordered grid (?)

4x samples sind zu wenig fuer naechster Generationen Hardware, also sind wohl 8x samples eine sehr gute Wette. Wenn hier die Transistoren zwischen 8x sparse und 16x ordered grid etwa auf gleichem Niveau liegen, ist mir der erste natuerlich lieber. Und das war auch der Sinn meines vorigen Posts.

[Demirug]

Original geschrieben von Ailuros
Jetzt hast Du mich verwirrt (und Loewe entschuldige das OT, aber Du weisst wie wichtig mir AA ist):

Gehen mehr Transistoren pro Z/stencil unit drauf zwischen 4x sparse und 16x ordered grid? Ich hab den Eindruck dass die 4-fache Anzahl der samples (selbst nur ordered grid) doch mehr Transistoren verbraucht als 4x sparse.

Für eine 16X ordered grid Z/Stencil Einheit gehen weniger Transitoren drauf als für eine Z/Stencil-Einheit für ein 4x sparse. Dafür braucht man aber um diesen Punkt nicht zum falschenhals werden zu lassen auch die 4 fache Anzahl von Einheiten für ein 16x ordered grid.

Ich weiss nichtmal wie gross der Unterschied ist in Transistoren zwischen 4x sparse und 4x ordered grid (?)

Schwer zu sagen. Ich arbeite hier nur mit tendenze weil es mir echt zuviel arbeit ist meinen Chipcompiler anzuwerfen. Vorallem müsste ich erst mal den ganzen VHDL Code dafür schreiben. Und mein VHDL ist inzwischen doch etwas eingerostet.

4x samples sind zu wenig fuer naechster Generationen Hardware, also sind wohl 8x samples eine sehr gute Wette. Wenn hier die Transistoren zwischen 8x sparse und 16x ordered grid etwa auf gleichem Niveau liegen, ist mir der erste natuerlich lieber. Und das war auch der Sinn meines vorigen Posts.

8x sparse sollte in Summe weniger verbrauchen als 16x ordered grid. Dafür ist dann aber (bei richtiger Verschaltung) ein für 16X ordered grid ausgelegter Chip bei einem verzicht auf AA an diesem Punkt 16 mal so schnell die 8x sparse Variante nur 8 mal.

[aths]

Original geschrieben von Demirug
8x sparse sollte in Summe weniger verbrauchen als 16x ordered grid. Dafür ist dann aber (bei richtiger Verschaltung) ein für 16X ordered grid ausgelegter Chip bei einem verzicht auf AA an diesem Punkt 16 mal so schnell die 8x sparse Variante nur 8 mal. \/\/007!

Die No-AA-Leistung ist imo ungefähr so relevant, wie die Pixelfüllrate bei single Texturing mit bilinearem Fiter :]

[Demirug]

Original geschrieben von aths
\/\/007!

Die No-AA-Leistung ist imo ungefähr so relevant, wie die Pixelfüllrate bei single Texturing mit bilinearem Fiter :]

Die Aussage bleibt gleich wenn man nicht das volle AA nutzt. Und warum regst du dich bei einfachen Sachverhalten den so auf? Ich zeige doch nur Optionen mit den entsprechenden Konsequnzen.

[Ailuros]

Danke Demi. Sehr berauschend klingen die Alternativen ja gerade nicht. So wie ich das sehe sollten IHVs spaetestens bei der uebernaechsten Generation auf exotischere Algorithmen umsteigen, wie alternative fragment AA Methoden oder was auch immer.

[GloomY]

Original geschrieben von Demirug
Burstmode sagt dir sicher was?

Ein Bulktransfer ist wenn man eine grossen Speicherbereich linear via Burst ausliest.Ja, jetzt ist es klar.
Original geschrieben von Demirug
Die Line Size sollte man aber schon an das Memoryinterface anpassen.Ja sicher, aber imho auch an die Arbeitsweise.
Original geschrieben von Demirug
Und bei Komprimierten texturen muss man sowieso immer alle benötigten Kacheln einladen. Meinst du mit Kachel die einzelnen Blöcke der komprimierten Texturen?

Da haste natürlich Recht, also ist eine Line Size in der Größenordnung der Kachelgröße eher sinnvoll.
Original geschrieben von Demirug
Nein beim besten Willen nicht. Bulk ist das beste was man dem Speicher antun kann.Was die Bandbreite angeht sicher...

Ansonsten bin ich mal lieber still, weil es hier eigentlich ja um was anderes geht, und ich davon keine Ahnung habe :X ;)

[Ailuros]

GloomY,

Es war eigentlich mein Fehler da ich den Ansatz dazu gegeben habe und was falsch interpretiert habe. Demi hat der Sache aber wohl die akkurate Interpretation gegeben. Nur hab ich wirklich nicht auch eine genaue Ahnung um was es sich genau handelt hehehe :D

[Gast]

Original geschrieben von aths
\/\/007!

Die No-AA-Leistung ist imo ungefähr so relevant, wie die Pixelfüllrate bei single Texturing mit bilinearem Fiter :]

Die 1xAA-Leistung ist genau dann extrem relevant, wenn die Karte ein wenig in die Jahre kommt und man nicht mehr die Reserven hat, AA in aktuellen Games zuzuschalten.

Damit neuere Games richtig flutschen, muss man angeblich auf einer Ti4600 teilweise auf 640x480 zurückschalten und dabei aufgrund der geringen Zeilenzahl auf einem 19"-Zoll Monitor oder höher auf ein vielfaches der Qualität verzichten, die AA wieder hereinbringt.

q@w

[mapel110]

Original geschrieben von Gast
Die 1xAA-Leistung ist genau dann extrem relevant, wenn die Karte ein wenig in die Jahre kommt und man nicht mehr die Reserven hat, AA in aktuellen Games zuzuschalten.

Damit neuere Games richtig flutschen, muss man angeblich auf einer Ti4600 teilweise auf 640x480 zurückschalten und dabei aufgrund der geringen Zeilenzahl auf einem 19"-Zoll Monitor oder höher auf ein vielfaches der Qualität verzichten, die AA wieder hereinbringt.

q@w

allerdings ist der "performancegewinn" beim abschalten von AA auf ner 4600er grösser als auf ner 9700er/9800er.

[Ailuros]

Original geschrieben von mapel110
allerdings ist der "performancegewinn" beim abschalten von AA auf ner 4600er grösser als auf ner 9700er/9800er.

Ich hab jetzt keine Prozente oder genauen Zahlen zur Hand, aber da NV25 fuer 2xAA/SchmierCunx und R300 (mehr) fuer 4xAA optimiert wurden, sollten die Unterschiede nicht allzu gross sein, wenn bei der ersten 2xAA und bei der letzteren 4xAA abschaltet.

Was aber die NV25 mehr an Leistung kostet ist dann natuerlich AF.

640*480 ist momentan immer noch eine grobe Uebertreibung fuer heutige Spiele und NV25; so weit sind wir Gott sei Dank noch nicht.

[aths]

Original geschrieben von Gast
Die 1xAA-Leistung ist genau dann extrem relevant, wenn die Karte ein wenig in die Jahre kommt und man nicht mehr die Reserven hat, AA in aktuellen Games zuzuschalten. Ich glaube nicht, dass die Mehrheit der Leute, die eine so schnelle Karte für AA (und AF) gekauft haben, "später" darauf verzichten werden, wahrscheinlich werden sie die Karte dann ausmustern.
Original geschrieben von Gast
Damit neuere Games richtig flutschen, muss man angeblich auf einer Ti4600 teilweise auf 640x480 zurückschalten und dabei aufgrund der geringen Zeilenzahl auf einem 19"-Zoll Monitor oder höher auf ein vielfaches der Qualität verzichten, die AA wieder hereinbringt. Alternativ muss man sich auf das flutschen verzichten und sich mit "flüssiger" Grafik zufrieden geben.