Benchmarks von der R300 mit deaktivierter Color Compression.

[Exxtreme]

Sodele,

ich habe es schon öfter angedeutet, daß die ATi-Treiber interessante (versteckte) Optionen beinhalten. Eine davon ist der Wert "ColorCompression" welchen man in der Registry anlegen muss.

Ich war auch noch sehr neugierig, wie stark sich diese Color Compression auf die Leistung auswirkt. 3DMark2001SE ist zwar nicht unbedingt repräsentativ in Bezug auf echte Spiele, fördert dieser aber IMHO doch sehr interessante Erkenntnisse.

Testsystem: siehe Signatur
Treiberversion: 6249
Einstellung: 6x FSEAA + 0x AF


CC off CC on Unterschied

Car Chase low: 80,1 91,4 +14,1%
Car Chase high: 28,9 28,9 +0%
Dragothic low: 88,3 129,9 +47,1%
Dragothic high: 58,8 74,8 +27,2%
Lobby low: 73,9 86,0 +16%
Lobby high: 36,7 37,6 +2,4%
Nature: 28,1 41,2 +46%
Fillrate ST: 323,5 1287,8 +398%
Fillrate MT: 1928,9 2505,5 +29,8%
High Polygon Count 1L 36,3 39,4 +8,5%
High Polygon Count 8L 13,3 13,8 +3%
Enviroment BM 132,6 157,3 +18,6%
DOT3 BM 57,1 92,2 +61,4%
Vertex Shader 58,6 59,4 +1,3%
Pixel Shader 110,2 120,7 +9,5%
Adv. Pixel Shader 71,5 104,2 +45,7%
Point Sprites 6,6 5,9 -11,8%

3DMarks: 5472 6723 +22,9%

Scheint also doch eine bandbreitenschonende Massnahme zu sein, die wirklich was bringt.

[Demirug]

Mit welchem AA Modus hast du den gebencht?

[Börk]

Die Benches ohne CC sehen aber reichlich schlecht aus, trotz 6xAA.
Da kann ja meist ne Ti4600 locker mithalten. Also entweder CC off funzt bei dem R300 net richtig oder die Karte is nur durch CC einigermaßen schnell (sonst eher langsam).

[Demirug]

Die CC ist ja in den Chip eingebaut und AFAIK gibt es ja eigentlich (ausser forscherdrang) keinen Grund sie abzuschalten.

Deswegen musste sich ja ATI auch nicht bemühen das MSAA ohne CC schnell zu machen. Wenn das Abschalten der CC nicht auch das Tileing deaktivert ist es sogar verständlich das der Chip ohne CC probleme bekommt.

[Börk]

Originally posted by Demirug
Die CC ist ja in den Chip eingebaut und AFAIK gibt es ja eigentlich (ausser forscherdrang) keinen Grund sie abzuschalten.

Deswegen musste sich ja ATI auch nicht bemühen das MSAA ohne CC schnell zu machen. Wenn das Abschalten der CC nicht auch das Tileing deaktivert ist es sogar verständlich das der Chip ohne CC probleme bekommt.
Achso!!!
Wieder was gelernt ;)

[aths]

Originally posted by burk23
Da kann ja meist ne Ti4600 locker mithalten.... mit 6x AA?

[Börk]

Originally posted by aths
... mit 6x AA?
Naja nicht ganz aber der Rechenaufwand von 4xS und 6xAA dürfte im ähnlichen bereich liegen.

EDIT: Ach übrigens seit kurzem kann man ja nen 6x modus aktivieren. Dank aTuner.

[Demirug]

Originally posted by burk23

Naja nicht ganz aber der Rechenaufwand von 4xS und 6xAA dürfte im ähnlichen bereich liegen.

aths ging es wohl weniger um den Rechenaufwand sondern um die benötigte Bandbreite. Umkomprimiert brauchen 6 Sample nun mal das 1,5 fache von 4 Samples.

[aths]

Originally posted by burk23
EDIT: Ach übrigens seit kurzem kann man ja nen 6x modus aktivieren. Dank aTuner. Wobei bei nVidias 6x immerhin 3x Supersampling drin ist. Deshalb kann die Ti 4600 wohl kaum gegen R300 mit 6x Multisampling konkurrieren. Zumal 6x MS à la R300 vieeel besser aussieht als 6xS.

[egdusp]

Bin ich der einzige dem auffällt, dass der Gewinnzuwachs in komplexen Szenen sehr niedrig ist?
Das wird wohl an Exxtremes schwachen 1,2 Ghz Thunderbird liegen. Ich wäre sehr interessiert an Vergleichen auf einem schnelleren System, wo nicht die CPU limitiert.

Außerdem wäre es noch sehr interessant zu sehen, ob noch eine Bandbreitenschoning auch dann eintritt, wenn FSEAA nicht aktiviert ist. Aber wohl auf einem 1,2 Ghz dürfte die CPU immer limitieren. Es wäre aber vielleicht sehr interessant die Fillrate Test zu sehen.

Exxtreme, kannst du das mal testen?

mfg
egdusp

[Exxtreme]

@ egdusp

Also ohne FSEAA gibt es keine Auswirkungen, die Frameraten bleiben gleich.

[robbitop]

nett wäre ein Vergleich 4x FSAA NoAF 1280x1024x32bit
Ti4600 vs R300 ohne FBCompression bei gleichen Taktraten.

Dann könnte man doch mal sehen, was die FBCompression effektiv wert ist und was das 256bit DDR interface effektiv wert ist, wobei man letzteres im Streit 9500provs9700pro schon sehr gut sieht.

Wenn man die 9700Pro auf 275/275 taktet und gegen die 9500 Pro stellen würde bei obigen Bedingungen in einem GPU limitierten Scenario wäre auch dieses sinnvoll.

Ich persönlich schätze, dass das 256bit DDR Interface nicht extrem viel bringt.

Habe noch eine Theorie zur FBCompression:
wenn man die Auflösung höher stellt ohne AA geht der R300 nicht so schnell die Luft aus wie dem NV30 (mehr speicherbandbreite weil FBCompression ohne AA sehr inneffektiv weil bei AA oft gleiche Farbwerte mehrfach gespeichert werden) aber in mittlern auflösungen bei hoher AA Stufe sieht das sicher wieder anders aus.

[AlfredENeumann]

Originally posted by robbitop

Ich persönlich schätze, dass das 256bit DDR Interface nicht extrem viel bringt.



Das bringt genausoviel wie ein Super Hochgetakteter RAM-Speicher. Immer beide seiten sehen.

Interessant wären doch auch mal die Vergleiche vom NV30 und R300 bei gleichem Coretakt und gleicher Bandbreite.

[Wenzula]

@ Exxtreme

Hi, könntest du mir bitte mal ne Anleitung bzw. ne Beschreibung schicken, wie genau du die Color Compression bei der R300 ausgeschaltet hast? Wäre sehr nett von dir...


Greetz

Wenzula

[Razor]

Originally posted by Exxtreme
@ egdusp

Also ohne FSEAA gibt es keine Auswirkungen, die Frameraten bleiben gleich.
Also wirkt die CC nur bei aktiviertem AA ?
???

Also wird damit nicht die theoretische Bandbreite erhöht, sondern lediglich die Bandbreitennutzung bei aktivertem AA etwas abgedämpft (sehr viel bringt sie ja nicht, vom ST-Test mal abgesehen).

Hmmm...

Razor

[Exxtreme]

Originally posted by Wenzula
@ Exxtreme

Hi, könntest du mir bitte mal ne Anleitung bzw. ne Beschreibung schicken, wie genau du die Color Compression bei der R300 ausgeschaltet hast? Wäre sehr nett von dir...


Greetz

Wenzula
Ganz einfach. Du musst den Schlüssel finden in dem sich die Einstellungen begfinden. Diesen findest du am besten wenn du, per Suchfunktion von Regedit, den Wert "AntiAlias" suchst. Dann landest du automatisch im richtigen Schlüssel.

Dann einfach eine Zeichenkette namens "ColorCompression" anlegen und ihr den Wert "0" zuweisen.

[Exxtreme]

Originally posted by Razor

Also wirkt die CC nur bei aktiviertem AA ?
???

So sieht's aus. Da beim aktiven FSEAA viele AA-Samples die gleiche Farbe haben...
Originally posted by Razor
Also wird damit nicht die theoretische Bandbreite erhöht, sondern lediglich die Bandbreitennutzung bei aktivertem AA etwas abgedämpft (sehr viel bringt sie ja nicht, vom ST-Test mal abgesehen).

Hmmm...

Razor
Stimmt auch. Naja, man muss zusätzlich bedenken, daß ich ziemlich CPU-limitiert bin. Wenn ich eine stärkere CPU habe (bald), dann mache ich den Test nochmal. Andererseits, im Schnitt sind es schon 20-40%.

[Demirug]

Was mich ja schon die ganze Zeit wundert ist das sich ATI doch für eine recht grosse Tile entschieden hat. Es macht zwar beim Durchrechnen der angaben sinn.

8*8 Pixel * 6 Samples pro Pixel = 384 Samples

384 Samples * 32 bpp = 12288 Bits

12288 Bits / 24 (max Kompression) = 512 Bits

512 Bits / 2 (Bits pro Takt) / 4 (Burstlänge) = 64 bit

und 64 bit sind ja die breite eines Memorykanals. Aber die maximale Kompression dürfte man nur beim Löschen des Backbuffers erreichen.

Und wenn die Kompression nicht wirkt muss man mindestens 24 Burstzyklen (96 Takte) hintereinader lesen und schreiben um eine unkomprimierte Tile zu verarbeiten. Oder besteht unter umständen die mögliche eine Tile in Subtiles zu spliten. Also aus 8*8 werden 4 4*4 Tiles (max. Kompression 6).

[aths]

Originally posted by Demirug
Und wenn die Kompression nicht wirkt muss man mindestens 24 Burstzyklen (96 Takte) hintereinader lesen und schreiben um eine unkomprimierte Tile zu verarbeiten. Oder besteht unter umständen die mögliche eine Tile in Subtiles zu spliten. Also aus 8*8 werden 4 4*4 Tiles (max. Kompression 6). Wenn ich mich nicht irre, ist genau das Splitting eines der HyperZ-III-Features.

[Demirug]

Originally posted by aths
Wenn ich mich nicht irre, ist genau das Splitting eines der HyperZ-III-Features.

Beim Hierarchical-Z definitive. Da werden die Tiles ja immer geviertelt.

Die Frage ist nur ob man es auch Speichertechnisch so organisiert hat?

Und dazu habe ich noch nichts wirklich aussagekräftiges gefunden.

[Wenzula]

@Exxtreme:
Ich habe da noch zwei weitere Fragen an dich. Zum einen würde ich gerne wissen, ob du vielleicht weist wie man den "early z-check" deaktivieren kann, sofern dies möglich ist und zweistens würde mich auch noch interessieren, ob man "hyper z" ausschalten kann?

Wenn du damit Erfahrungen hast, wäre ich auch über einen Bericht zu den gestellten Fragen sehr dankbar.

Greetz

Wenzula

[Exxtreme]

Also wie man early-Z oder HyperZ komplett abschaltet weiss ich nicht. Man kann aber HierarchicalZ und FastZClear abschalten. HierarchicalZ über den den String "HierarchicalZEnable", auch wieder 0/1 und FastZClear über "FastZClearEnabled", wieder 0/1.

[asus ( ocworkbase )]

Originally posted by Exxtreme

Ganz einfach. Du musst den Schlüssel finden in dem sich die Einstellungen begfinden. Diesen findest du am besten wenn du, per Suchfunktion von Regedit, den Wert "AntiAlias" suchst. Dann landest du automatisch im richtigen Schlüssel.

Dann einfach eine Zeichenkette namens "ColorCompression" anlegen und ihr den Wert "0" zuweisen.

gehts auch ein bissel genauer ?
für die nichtsoftwareprofis :D .

[Exxtreme]

Originally posted by asus ( ocworkbase )


gehts auch ein bissel genauer ?
für die nichtsoftwareprofis :D .
:bonk:
Was verwechselt.

[Indiana]

Er bezog sich aber auf die ColorCompression, und die kann man mit rtool nicht an-/ausschalten.

Ich habe das hier übrigens auch mal getestet und mit einer schnelleren CPU (AthlonXP@1731MHz) werden die Unterschiede geradezu dramatisch:

http://www.indiana.claranet.de/3DMarkColorCompression6xFSAA.png
1024x768x32, 6x FSAA, kein Aniso. Der gelbe Balken ist dabei mit ColorCompression, der rote ohne.

Prozentual sieht das folgendermaßen aus
Total Score: +36%
Car Chase low: +40%
Car Chase high: +4%
Dragothic low: +58%
Dragothic high: +40%
Lobby low: +50%
Lobby high: +20%
Nature: +48%
Fill rate (ST): +303%
Fill rate (MT): +36%
High poly (1 light): +9%
High poly (8 lights): +4%
EMBM: +32%
Dot3 BM: +61%
Vertex Shader: +1%
Pixel Shader: +50%
Advanced PS: +48%
Point Sprite: -11%

[Liquaron]

Jetzt mal ganz kurz von mir eine frage eingeworfen. Habe ich denn irgendeinen relevanten Bildqualitätsunterschied zwischen diesen beiden Optionen?

[Indiana]

Nein.

[Exxtreme]

@Indiana

Stimmt, hab's mit'm anderen Thread verwechselt.

Originally posted by Liquaron
Jetzt mal ganz kurz von mir eine frage eingeworfen. Habe ich denn irgendeinen relevanten Bildqualitätsunterschied zwischen diesen beiden Optionen?
Nein, es hat keine negativen Auswirkungen auf die Bildqualität da es sich um lossless compresion handelt.

[asus ( ocworkbase )]

ja und ? ich höre ;D .
wie gehts nu ?

[aths]

Wieso ist die Differenz beim Single Texturing so drastisch?

[Exxtreme]

Originally posted by asus ( ocworkbase )
ja und ? ich höre ;D .
wie gehts nu ?
Also in der Registry einfach nach dem Wert "AnisoDegree" suchen. Wenn regedit den gefunden hat, ist man im richtigen Reg-Key. Dann einfach eine Zeichenkette namens "ColorCompression" anlegen und ihr den Wert "0" zuweisen.

[zeckensack]

Originally posted by aths
Wieso ist die Differenz beim Single Texturing so drastisch? Blending.
Der ST-Test im 3DMark ist der schlechteste Füllratenbenchmark, den es je gegeben hat.

Im MT-Modus wird pro Pixel das gemacht:
1. Löschen
2. Schreiben

Die erreichten fps werden mit der Anzahl der Texturlagen multipliziert.

Im ST-Modus passiert das:
1. Löschen
2. Schreiben
3. (n-1) mal wiederholen*:
3a. Lesen
3b. modifiziert zurückschreiben

*n=Anzahl der Texturlayer, einen haben wir schon unter Punkt #2 erledigt.

Der genaue Bandbreitenbedarf hängt von der Anzahl der Layer und der Operationen im Z-Buffer ab, liegt aber auf jeden Fall pro gemessener Füllrate um ein Vielfaches über dem MT-Wert.

[zeckensack]

Zusatz:
Man sollte sich vor Augen halten, daß die Karte laut Messung 2,143GAA-Samples/s schreibt (6xAA). Dann noch eine wenig Z-Traffic drauf, und schon ist die Messung im grünen Bereich. (mindestens 64 Bit pro AA-Sample)

[aths]

Originally posted by zeckensack
Blending.
Der ST-Test im 3DMark ist der schlechteste Füllratenbenchmark, den es je gegeben hat.Auch ohne FSAA schafft es R300 bei weitem nicht, die theoretische Füllrate (fast) zu erreichen. Da ist doch was faul?!

[zeckensack]

Die Bandbreite reicht bei dieser Messung nicht für mehr :)

Nochens, 4 Texturlagen:
Pro Pixel:
1)Farbe/Z löschen (32 Bit Farbe raus, Z-Clear 'for free')
2)Farbe/Z schreiben (64 Bit, erster Z-Test 'for free')
3)dann noch 3mal 128 Bit
3a)Z lesen (Z-Test)
3b)Farbe einlesen (Blending)
3c)Farbe rausschreiben
3d)Z rausschreiben

Macht 32b+64b+3*128b=480b, ergo 60 Bytes Speichertraffic pro Pixel. Jeder dieser Pixel bringt 4 'Punkte' in der Texelfüllrate.
60B*357,2M/4 <ein paar Einheiten weggelassen> = 5,35GB/s Speichertraffic.

So, und jetzt das ganze mal sechs, wegen dem AA. Die Karte fährt bandbreitenmäßig voll vor die Wand.

... daß überhaupt dieser Wert erreicht wird, schiebe ich auf Übertaktung, aber vor allem auf 'HyperZ'.

@Exxtreme:
Kannst du bitte bitte diesen Test nochmal mit deaktiviertem HyperZ machen? =)

[Unregistered]

Originally posted by zeckensack

60B*357,2M/4 <ein paar Einheiten weggelassen> = 5,35GB/s Speichertraffic.

So, und jetzt das ganze mal sechs, wegen dem AA. Die Karte fährt bandbreitenmäßig voll vor die Wand.


Ja, die Karte war übertaktet (habe ich vergessen anzugeben, im Rage3D Post steht's drin), hier aber v.a. die GPU mit 385MHz, der RAM-Takt war nur moderat erhöht mit 337MHz.

[Indiana]

Da war ich offensichtlich nicht eingeloggt. Wie auch immer, auch 337MHz Ramtakt würde für den angegebenen Bandbreitenbedarf nicht ausreichen, also muß wohl tatsächlich HyperZ den Rest richten.

[aths]

Originally posted by zeckensack
So, und jetzt das ganze mal sechs, wegen dem AA. Die Karte fährt bandbreitenmäßig voll vor die Wand.Originally posted by aths
Auch ohne FSAA schafft es R300 bei weitem nicht, die theoretische Füllrate (fast) zu erreichen. Da ist doch was faul?! Ohne FSAA erreicht z.B. GF4 Ti fast den theoretischen Wert. Radeon9700 hat doppelte Pipeline-Zahl und ein doppelt so breites RAM-Interface, bleibt beim Single Texturing aber deutlich unter seinen theoretischen Möglichkeiten.

[Exxtreme]

Originally posted by zeckensack

@Exxtreme:
Kannst du bitte bitte diesen Test nochmal mit deaktiviertem HyperZ machen? =)
Das HyperZ-Feature lässt sich in jetzigen Treibern nicht komplett abschalten. Ich kann nur HierarchicalZ und FastZClear deaktivieren. Soll ich trotzdem benchen?

[zeckensack]

@aths,
Menno! Was genau hast du an dem Posting, auf das ich so lang und anstrengend geantwortet habe, eigentlich editiert? :naughty:

@Exxtreme,
Das wäre interessant :)
(ich will eigentlich nur Füllratentests)

[zeckensack]

Originally posted by aths
Ohne FSAA erreicht z.B. GF4 Ti fast den theoretischen Wert. Radeon9700 hat doppelte Pipeline-Zahl und ein doppelt so breites RAM-Interface, bleibt beim Single Texturing aber deutlich unter seinen theoretischen Möglichkeiten. Bevor ich mir jetzt wieder unnötig den Kopf zerbreche, du meinst Single Texturing ohne FSAA, richtig? :)

Wieviel erreicht eine Radeon9k7Pro denn dabei so ungefähr?

[Quasar]

Originally posted by zeckensack
Bevor ich mir jetzt wieder unnötig den Kopf zerbreche, du meinst Single Texturing ohne FSAA, richtig? :)

Wieviel erreicht eine Radeon9k7Pro denn dabei so ungefähr?
3DM2k: ca. ~1800 (32Bit: ~1415)
3DM2k+1: ~2200 (32Bit: ~1750)

[zeckensack]

Danke ;)

[zeckensack]

Originally posted by Quasar
3DM2k: ca. ~1800 (32Bit: ~1415)Gemäß obigem Rechenbeispiel greife ich mir diesen Wert (ich habe mittlerweile doch einige Zweifel am Z-Traffic im 3DM2k1).

60Bytes*1415M/4s = 21,225GB/s

Kommt ungefähr hin. Wenn man 4 Bytes abzieht (entspräche einem eingesparten Z-Write), dann kommt's sogar exakt hin:

56Bytes*1415M/4s = 19,810GB/s
Theoretische Bandbreite = 310MHz*512b=19,840GB/s

Und wieder muß ich konstatieren, daß der ST-Fillratetest im Murx nicht die Füllrate, sondern die Bandbreite mißt. :bäh:

[aths]

Originally posted by zeckensack
Und wieder muß ich konstatieren, daß der ST-Fillratetest im Murx nicht die Füllrate, sondern die Bandbreite mißt. :bäh: Wahrscheinlich nerve ich jetzt rum wie ein Kind, dessen Mutter ihm keine Bonbons kauft :D aber meine Frage war eine andere :D

Du spielst auf die Bandbreiten-Erfordernisse an. GeForce4 Ti ist offensichtlich in der Lage, diese Bandbreite auch im ST Test zur Verfügung zu stellen. Dabei hat man jeweils halbe Pipeline- und halbe Speicherinterface-Breite. Warum kann Radeon9700 Pro das mit der Bandbreite nicht in den Griff kriegen, wenn das sogar 'ne GF4 Ti packt?

[ow]

.

[zeckensack]

Öh :|

Wieviel schafft denn so eine Gf4? Bitte den Takt mit angeben, da kenne ich mich nicht so gut aus :D

[spaßmode]
Vielleicht eine clevere 3DMark-Optimierung :lol:
[/spaßmode]

[zeckensack]

Originally posted by ow
aths:
Effizienz der Mem-Controllers? Die ist bei NV besser.

GF4: 4pipes - 4x32DDR MEM
9k7: 8Pipes - 4x64DDR MEM


Mit 8x32DDR wurde die 9700 besser dastehen. Das würde bei meiner 'Theorie' oder wie auch immer man das nennen will aber keine Rolle spielen. Die Suppe muß ich jetzt irgendwie auslöffeln ...

*kopfqualm*

[aths]

Originally posted by zeckensack
Wieviel schafft denn so eine Gf4? Bitte den Takt mit angeben, da kenne ich mich nicht so gut aus :D

Fill Rate (Single-Texturing) 1121.8 MTexels/s
Fill Rate (Multi-Texturing) &nbsp; 2349.3 MTexels/s

bei 300/"715".

[StefanV]

Und wie wäre es damit, daß die Pipes von der R300 auf MT 'optimiert' sind??

[Xmas]

Originally posted by Stefan Payne
Und wie wäre es damit, daß die Pipes von der R300 auf MT 'optimiert' sind??
Nö, offensichtlich wurde alles auf Color Compression optimiert.

[zeckensack]

So, ich habe jetzt mal meinen Rechner ein wenig gequält...
Vorläufiger Erklärungsansatz:
1.
a)Ich habe oben für den 3DM2k0 pro Pixel 56 Bytes Speichertraffic ausgerechnet.
b)Bisserl Dreisatz mit Quasar's Zahlen ergibt für den 3DM2k1 unter Annahme von totaler Speicherlimitierung 44 Bytes pro Pixel (+- 3% Fehler, ie Verschnitt).
2.
a)Ich bin bei der Rechnung auch für die Gf4 von totaler Banbreitenlimitierung ausgegangen (11,44GB/s).
b)Demnach braucht dieses Dingens 'nur' 40,8 Bytes/(ST-Füllrate*4), was nicht sein kann, ich runde ab auf 40 und schreibe den Rest nicht vermeidbaren Verlusten am Mem-Interface zu.

Mit anderen Worten: Wenn auch nur ein einziger Schreibzugriff gespart werden kann, dann kommen auch diese Zahlen wieder hin.

______________________
Die Radeon hat 1,73 mal soviel Speicherbandbreite.
Damit kommt sie auf 1,56 mal soviel gemessene Füllrate.

Sooo drastisch ist der Unterschied in der Effizienz garnicht.

:| ?-) :bäh:

[Demirug]

zeckensack, nur mal so als gedankenanstoss. Soweit ich mich erinnere haben die Polygone beim 3dmark immer den gleichen Z-Wert. Dadurch müsste die Z-Kompression auch noch zum tragen kommen.

[zeckensack]

Originally posted by Demirug
zeckensack, nur mal so als gedankenanstoss. Soweit ich mich erinnere haben die Polygone beim 3dmark immer den gleichen Z-Wert. Dadurch müsste die Z-Kompression auch noch zum tragen kommen. Ich vermute mal ganz dreist, daß die Gf4Ti Z-Writes verwerfen kann, wenn sie den gleichen Wert rausschreiben soll, den sie vorher eingelesen hat.

... und daß der R300 das nicht (oder nicht immer) hinbekommt.

Pseudo//Z-Test
fragment.z=pixelshader.out.z;
fragment.color=pixelshader.out.color;

z_from_buffer=read_z(x,y);
if (z_test_passes(z_from_fragment,z_from_buffer))
{
write_color(x,y,fragment.color);

//be extraordinarily clever
if (z_from_fragment!=z_from_buffer)
{
write_z(x,y,fragment.z);
}
}

[Demirug]

Originally posted by zeckensack
Ich vermute mal ganz dreist, daß die Gf4Ti Z-Writes verwerfen kann, wenn sie den gleichen Wert rausschreiben soll, den sie vorher eingelesen hat.

... und daß der R300 das nicht (oder nicht immer) hinbekommt.

Pseudo//Z-Test
fragment.z=pixelshader.out.z;
fragment.color=pixelshader.out.color;

z_from_buffer=read_z(x,y);
if (z_test_passes(z_from_fragment,z_from_buffer))
{
write_color(x,y,fragment.color);

//be extraordinarily clever
if (z_from_fragment!=z_from_buffer)
{
write_z(x,y,fragment.z);
}
}

Ja die Idee ist nicht schlecht. Möglicherweise wird das aber auch automatisch über den Memory/Cache Controller gemacht. Also folgendes Prinzip.



Data ReadData (Addr, AllowCache)
{
if (CheckDataInCache (Addr))
return GetDataFromCache (Addr)

Data Result = GetDataFromMemory (Addr);

if (AllowCache)
WriteDataToCache (Addr, Data);

return Data;
}

WriteData (Addr, Data, AllowCache)
{
if (CheckDataInCache (Addr))
{
if (GetDataInCache (Addr) == Data)
return;
}

if (AllowCache)
WriteDataToCache (Addr, Data)
else
WriteDataToMemory (Addr, Data)
}


Der Cache sollte bei diesem Model natürlich ein Modifyflag pro Line haben. Und unter Umständen noch eine Priority damit man entsprechend besser verträngen kann.

[zeckensack]

... außerdem glaube ich nicht Z-Kompression, weder bei NV25 noch R300. Dazu paßt das alles viel zu genau.

Kompression kommt IMO erst bei aktivem Multisampling ins Spiel, ohne macht es auch nicht viel Sinn. Böswillig wäre es zudem, weil synthetische Tests tatsächlich erheblich davon profitieren könnten (1024x768 Pixel, alle haben exakt den gleichen Z-Wert ... hach welch schöne Welt =)).

[Xmas]

Originally posted by zeckensack
... außerdem glaube ich nicht Z-Kompression, weder bei NV25 noch R300. Dazu paßt das alles viel zu genau.

Kompression kommt IMO erst bei aktivem Multisampling ins Spiel, ohne macht es auch nicht viel Sinn.
Was hat Z-Kompression mit Multisampling zu tun?

[zeckensack]

Originally posted by Xmas

Was hat Z-Kompression mit Multisampling zu tun? Beim Multisampling steigt die Wahrscheinlichkeit, daß benachbarte Z-Buffer-Bewohner den gleichen Wert haben auf ein für verlustfreie Kompression brauchbares Maß an :|

[aths]

Originally posted by zeckensack
Beim Multisampling steigt die Wahrscheinlichkeit, daß benachbarte Z-Buffer-Bewohner den gleichen Wert haben auf ein für verlustfreie Kompression brauchbares Maß an :| Behauptung: Eine verlustfreie Kompression zwischen 2:1 und 4:1 lässt sich auch ohne AA, also im "Normalfall" erreichen. Begründung: Nimm den 1. Z-Wert und speichere von den anderen nur 1. Z-Wert xor n. Z-Wert. Man sollte dadrin des öfteren längere Nullfolgen bekommen, welche sich auch komprimieren lassen.

Idee: Die Komprimierung geht solange gut, wie sich nur die unteren 8 Bits ändern. Ansonsten muss wieder mal ein vollständiger Z-Wert geschrieben werden.

Ist aber alles nur Spekulation :|

[Xmas]

Originally posted by zeckensack
Beim Multisampling steigt die Wahrscheinlichkeit, daß benachbarte Z-Buffer-Bewohner den gleichen Wert haben auf ein für verlustfreie Kompression brauchbares Maß an :|
Nö. Nicht mehr als durch erhöhte Auflösung.

[Demirug]

eine andere möglichkeit den Z-Buffer zu Komprimieren ist Plane-Kompression.

Der Z-Block welcher komprimiert werden soll muss mindestens 16 Werte enthalten weil 32 (Breite eine Kanals)*2 (DDR)* 2 (Burst) * 4 (Max Kompression) = 512 Bit = 16 Werte. Bei einem Burst von 4 wäre es 32.

16 wäre eine 4 * 4 Pixel Tile. Kommen nun alle Pixel von gleichen Dreieck lassen sich die Z-Werte der Pixel als Plane speichern (3*24 Bit). Damit bleiben dann noch 56 bit für den Stencil Buffer übrig. Wenn er nicht benutzt wird reicht das auf jeden fall und ansonsten müsste sich da in vielen Fällen auch eine gute kompression erreichen lassen.

[Unregistered]

Originally posted by aths
Behauptung: Eine verlustfreie Kompression zwischen 2:1 und 4:1 lässt sich auch ohne AA, also im "Normalfall" erreichen. Begründung: Nimm den 1. Z-Wert und speichere von den anderen nur 1. Z-Wert xor n. Z-Wert. Man sollte dadrin des öfteren längere Nullfolgen bekommen, welche sich auch komprimieren lassen.

Idee: Die Komprimierung geht solange gut, wie sich nur die unteren 8 Bits ändern. Ansonsten muss wieder mal ein vollständiger Z-Wert geschrieben werden.

Ist aber alles nur Spekulation :|

Und wie schaffst Du es, das alle Komprimierten Z-Werte im Tile immer die gleiche String-Länge haben (ansonsten kommt Chip und Speicherzugriff mächtig in's Schleudern )?

[zeckensack]

Originally posted by Unregistered


Und wie schaffst Du es, das alle Komprimierten Z-Werte im Tile immer die gleiche String-Länge haben (ansonsten kommt Chip und Speicherzugriff mächtig in's Schleudern )? Man nimmt Kacheln. Dann muß man sich nur noch darum kümmern, daß eine komplette Kachel auf einen Wert komprimiert werden kann, der sauber durch die Breite eines Crossbar-Kanals geteilt werden kann.

Bei (Zahlen grob geschätzt!) 8x8 Pixeln pro Kachel und 128bit pro R300-Crossbar-Kanal (64bit DDR) wären diese Verhältnisse möglich:
1)1:12 (Kachel wird auf <=128 bit komprimiert)
2)1:6 (Kachel wird auf <=256 bit komprimiert)
3)1:4 (Kachel wird auf <=384 bit komprimiert)
4)1:3 (Kachel wird auf <=512 bit komprimiert)
5)1:2,4 (Kachel wird auf <=640 bit komprimiert)
...
12)1:1 (Kachel kann nicht komprimiert werden und belegt die vollen 1536 bit = 8*8*24 bit).

Dann muß man nur noch pro möglicher Kachel ein Bit irgendwo auf dem Chip haben, daß sich 'merkt' ob die Kachel komprimiert ist oder nicht. Dafür braucht man bei 2048*1536*6fach-AA läppische 36kByte SRAM ...

(AFAIK sind die Kacheln aber größer)

[Demirug]

ATI hat zu Thema was patentieren lassen:

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,476,811.WKU.&OS=PN/6,476,811&RS=PN/6,476,811

Primär scheint das ganze für die Z-Werte zu sein. In wie weit es sich auch zur Farbkompression einsetzten läst muss ich mir noch anschauen.

@Exxtreme:

Mein kleines Testprogramm erzeugt ja beim Test schöne gleichfarbige Flächen. Diese müssten sich gut komprimieren lassen. Könntest du mal damit deinen R300 benchen? AA kannst du ja über dein rTool erzwingen, oder?

http://demirug.bei.t-online.de/ZOverdraw.zip

[Exxtreme]

Originally posted by Demirug

@Exxtreme:

Mein kleines Testprogramm erzeugt ja beim Test schöne gleichfarbige Flächen. Diese müssten sich gut komprimieren lassen. Könntest du mal damit deinen R300 benchen? AA kannst du ja über dein rTool erzwingen, oder?

http://demirug.bei.t-online.de/ZOverdraw.zip
Kann ich machen aber erst heute Abend.

[Exxtreme]

OK, hier mal die Werte.

1024x768x32 Radeon 9700 Pro @ 325/310 MHz

Overdraw 1, Layer 8, Stages 0



| ColorCompression | FPS | MPix | MTex |
| ON | 309 | 243 | 1944,3 |
| OFF | 201 | 158 | 1265,5 |


Sorry, daß es so spät kommt...

[mapel110]

:o wenn man sich die zahlen so anschaut, könnte man glatt denken, dass ati's 256bit interface garnüscht bringt, und der ganze speed durch diese colorcompression kommt.

[Exxtreme]

Originally posted by mapel110
:o wenn man sich die zahlen so anschaut, könnte man glatt denken, dass ati's 256bit interface garnüscht bringt, und der ganze speed durch diese colorcompression kommt.
Naja, die Colorcompression ist nur dann aktiv wenn FSEAA eingeschaltet ist. Interessant wäre es eine R9700 non-Pro gegen eine R9500 Pro zu benchen mit deaktivierter Colorcompression.

Insgesamt gesehen ist die Colorcompression schon was Feines.

[Unregistered]

Originally posted by Exxtreme

Naja, die Colorcompression ist nur dann aktiv wenn FSEAA eingeschaltet ist. Interessant wäre es eine R9700 non-Pro gegen eine R9500 Pro zu benchen mit deaktivierter Colorcompression.

Insgesamt gesehen ist die Colorcompression schon was Feines.

welches FSAA hast du dann für deinen Bench benutzt? Steht nämlich nicht dabei. Ich dachte deshalb das ganze ist ohne FSAA.

[Exxtreme]

Originally posted by Unregistered


welches FSAA hast du dann für deinen Bench benutzt? Steht nämlich nicht dabei. Ich dachte deshalb das ganze ist ohne FSAA.

Steht im allerersten Posting:
"Einstellung: 6x FSEAA + 0x AF "
:)