Matrox Parhelia - Fragen Fragen Fragen!

[Hellspawn]

Ja würd dass gerne wissen weil ich überlege mir die radeon8500 zu verkaufen und mir vielleicht eine Parhelia zuzulegen.. weiß jemand in welchem Preissegment sie einsteigen würde? Und würde sich der Tausch eigentlich auszahlen? Wie sind die Treiber etc.. für alle nützlichen Informationen wäre ich sehr sehr dankbar!

MfG Hellspawn

[Quasar]

Also, die vier Treiberversionen, die Matrox in den letzten Monaten veröffentlicht hat, sind durchweg ziemlich gut, leider gibt's noch keinen brauchbaren OpenGL-ICD, aber der soll nächste Woche rauskommen.

Besonders ältere Games leidern jedoch an der 4Pipes/4TMU-Auslegung, da sie oft nicht von mehr als 2 TMUs pro Pipe profitieren können (siehe Kyro2) und so die Parhelia nicht allzuviel schneller als eine GF4 ist.

Die FSAA-Qualität ist natürlich sehr gut, auch wenn die unbehandelten Texturen teils einen ziemlichen Kontrast zu den wunderbar glatten Kanten erzeugen und so wieder die Unausgewogenheit hervorheben. Bei den meisten Games ist jedoch Füll- und Transferrate in ausreichender Menge vorhanden, um AF zuzuschalten.
Das sieht dann schon recht geil aus.


Alles in allem hat sich der Kauf der Parhelia doch gelohnt, auch wenn ich noch beinahe €300 auf den Verkaufspreis meiner GF4Ti4600 draufzahlen musste.

[Hellspawn]

Originally posted by Quasar
Also, die vier Treiberversionen, die Matrox in den letzten Monaten veröffentlicht hat, sind durchweg ziemlich gut, leider gibt's noch keinen brauchbaren OpenGL-ICD, aber der soll nächste Woche rauskommen.

Besonders ältere Games leidern jedoch an der 4Pipes/4TMU-Auslegung, da sie oft nicht von mehr als 2 TMUs pro Pipe profitieren können (siehe Kyro2) und so die Parhelia nicht allzuviel schneller als eine GF4 ist.

Die FSAA-Qualität ist natürlich sehr gut, auch wenn die unbehandelten Texturen teils einen ziemlichen Kontrast zu den wunderbar glatten Kanten erzeugen und so wieder die Unausgewogenheit hervorheben. Bei den meisten Games ist jedoch Füll- und Transferrate in ausreichender Menge vorhanden, um AF zuzuschalten.
Das sieht dann schon recht geil aus.


Alles in allem hat sich der Kauf der Parhelia doch gelohnt, auch wenn ich noch beinahe €300 auf den Verkaufspreis meiner GF4Ti4600 draufzahlen musste.


waaas du hast sie schon?? und die ist 300€ teurer als ne 4600er? nana ok dann bleib ich wohl bei der radeon. ist die parhelia nun dx8 oder 9?

[GloomY]

Originally posted by Quasar
Besonders ältere Games leidern jedoch an der 4Pipes/4TMU-Auslegung, da sie oft nicht von mehr als 2 TMUs pro Pipe profitieren können (siehe Kyro2) und so [...]Was meinst du damit?

[ernesto.che]

Originally posted by Hellspawn



waaas du hast sie schon?? und die ist 300€ teurer als ne 4600er? nana ok dann bleib ich wohl bei der radeon. ist die parhelia nun dx8 oder 9?

schau mal unter Ironie nach...

[ow]

@gloomy


Er meint damit, dass von aeltere Games meist nur 2TMUs genutzt werden und alles andere brachliegt (3. TMU im Radeon, 3.+4.TMU im Parhelia).

Den Kyro betrifft das in etwas anderer Form. Er wird bei mehr als 2 Tex zum multipass gezwungen, obwohl er dies noch singlepass schaffen wuerde.

[Hellspawn]

Originally posted by ernesto.che


schau mal unter Ironie nach...

was is mit dir? gehirnschaden?

[Demirug]

Originally posted by ow
@gloomy


Er meint damit, dass von aeltere Games meist nur 2TMUs genutzt werden und alles andere brachliegt (3. TMU im Radeon, 3.+4.TMU im Parhelia).

Den Kyro betrifft das in etwas anderer Form. Er wird bei mehr als 2 Tex zum multipass gezwungen, obwohl er dies noch singlepass schaffen wuerde.

Aber beim Kyro wird Multipass bei weitem nicht so teuer erkauft wie bei anderen Karten da das zwischenspeichern im Framebuffer wegfält.

[Quasar]

Originally posted by ow
@gloomy


Er meint damit, dass von aeltere Games meist nur 2TMUs genutzt werden und alles andere brachliegt (3. TMU im Radeon, 3.+4.TMU im Parhelia).

Den Kyro betrifft das in etwas anderer Form. Er wird bei mehr als 2 Tex zum multipass gezwungen, obwohl er dies noch singlepass schaffen wuerde.

Jo, so isses.

BTW, gleiches gilt für ernesto.che ;)

@Demirug:
Nein, viel schlimmer:
Beim Kyro geht's direkt in die eh schon knappe Füllrate...

[Doomtrain]

Originally posted by Quasar



Nein, viel schlimmer:
Beim Kyro geht's direkt in die eh schon knappe Füllrate...

Aber der Kyro hat doch gerade bei Multitexturing eine klasse Performance!!!

[Quasar]

Lies doch den ganzen Kontext:

Es ging um alte Games, die pari von 2 TMUs ausgehen und auch wenn mehrfaches Single-Pass MT möglich wäre, einfach nach 2 Texturen einen neuen Pass initiieren.

Und da suffert der K2 greatly, to bleib straight in einer Language.

[Demirug]

@Quasar:

Füllrate??? Irgendwie habe ich da jetzt einen Knoten im Hirn. Bei der Kyro dürfte es doch keinen unterschied machen ob ich einmal 4 oder 2*2 Texturen auf einen Punkt lege. Einen Nachteil hat es jedoch im Bezug auf den Geometriedurchsatz.

[Quasar]

Öh, nee, den Knoten hatte ich im Hirn.

Füllrate hat damit natürlich nichts zu tun. Tststs...ich glaub ich brauch auch mal Urlaub.

[ow]

Ist es wirklich so, dass der Kyro nicht nach jedem Pass in den Framebuffer schreibt???

Woher weiss der Chip denn, wieviel Passes denn noch kommen?

Und wie ist das bei konventionellen Renderern mit zB. 2TMUs?

Wird nicht die komplette Szene erst mit 2 Texturen gerendert und dann der komplette Prozess (die komplette 3D pipe) nochmals durchlaufen?

[Demirug]

Originally posted by ow
Ist es wirklich so, dass der Kyro nicht nach jedem Pass in den Framebuffer schreibt???

Woher weiss der Chip denn, wieviel Passes denn noch kommen?

Und wie ist das bei konventionellen Renderern mit zB. 2TMUs?

Wird nicht die komplette Szene erst mit 2 Texturen gerendert und dann der komplette Prozess (die komplette 3D pipe) nochmals durchlaufen?

Soweit mir bekannt macht die Kyro das ohne Zwischenspeichern im Framebuffer. Das mit dem erkennen ist eigentlich sehr einfach. Der Kyro sucht ja für jeden Texel das höchste Dreieck. Ist nur bei diesem Dreieck alphablending aktiviert muss eben das darunterliegende Dreieck gesucht und zuerst berechnet werden. Das ganze geht auch über mehrer Stufen.

Meinst du bei den 2 TMUs Multipass oder Multitextur mit mehr als 2 Texturen?

Bei Multipass wird nochmal die komplette 3D pipe durchlaufen. Beim Multitextur wird das mit einem Loopback inerhalb des Fragmentshaders gemacht. Die genaue vorgehensweise hängt dabei starkt von der Hardware ab.

[Unregistered]

Ich hatte mir bis vor kurzem auch darüber Gedanken gemacht, ob ich zur Parhelia (allerdings von GF3) wechseln sollte, vor allem wegen der 2D-Geschwindigkeit.
Wie es aber nach einem Test von aceshardware (http://www.aceshardware.com/read.jsp?id=45000191) ausschaut, ist Matrox mit der G550 unter 2D ziemlich lahm, also 2D-Fetischisten dürften von Matrox wohl die Finger lassen.

[jedi]

Originally posted by Quasar
Also, die vier Treiberversionen, die Matrox in den letzten Monaten veröffentlicht hat, sind durchweg ziemlich gut, leider gibt's noch keinen brauchbaren OpenGL-ICD, aber der soll nächste Woche rauskommen.


Ach, dann haben Dich wohl auch auf der Parhelia das Texturflackern und die Darstellungsfehler bei Jedi Knight II gestört? Aber das waren wir ja schon von den schlechten Matrox-OpenGL-Treibern gewohnt. Ich habe meine Parhelia inzwischen schon wieder bei eBay abgestossen und für den Verkaufserlös konnte ich mir zwei GF4-Ti4200-Karten und eine XBox kaufen und endlich alle Spiele wieder fehlerfrei zocken.

*eg*

[templecarres]

ich dachte immer dass der kyroII 4x loopback beherrscht, jedoch einen taktzyklus pro extra loopback benötigt. also bei 8 texturen im single pass rendering 8 taktzyklen.... kann mir jemand erklären was das auf sich hat?

[ow]

Originally posted by Demirug


Soweit mir bekannt macht die Kyro das ohne Zwischenspeichern im Framebuffer. Das mit dem erkennen ist eigentlich sehr einfach. Der Kyro sucht ja für jeden Texel das höchste Dreieck. Ist nur bei diesem Dreieck alphablending aktiviert muss eben das darunterliegende Dreieck gesucht und zuerst berechnet werden. Das ganze geht auch über mehrer Stufen.

Meinst du bei den 2 TMUs Multipass oder Multitextur mit mehr als 2 Texturen?



Ich meine Multipass, also zB. Auftragen von 4 Texturen bei nur 2TMUs.

Wenn man nach dem ersten der 2 passes einen Screenshot vom Framebuffer erstellen könnte, hätte ich dann nicht die komplett Szenerie bis auf die fehlenden 2 Texturlagen korrekt gerendert?

Es wird doch nicht ein Dreieck zweimal hintereinader an den Rasterizer geschickt und komplett in 2 passes texturiert, bevor das nächste Dreieck an der Reihe ist?
Denn die Dreiecke müssen bei Multipass ja auch zweimal über den AGP.

Und dies könnte auch beim Kyro gelten, so dass auch die HSR-Stufe zweimal durchlaufen wird. Oder doch nicht???




Bei Multipass wird nochmal die komplette 3D pipe durchlaufen. Beim Multitextur wird das mit einem Loopback inerhalb des Fragmentshaders gemacht. Die genaue vorgehensweise hängt dabei starkt von der Hardware ab.

[ow]

Originally posted by templecarres
ich dachte immer dass der kyroII 4x loopback beherrscht, jedoch einen taktzyklus pro extra loopback benötigt. also bei 8 texturen im single pass rendering 8 taktzyklen.... kann mir jemand erklären was das auf sich hat?


Die Architektur des Kyro unterstützt theoretisch unendliches Loopback, jedes Pixel wird erst in den Framebuffer geschrieben wenn es fertig berechnet ist.

Nur die APIs/Treiber begrenzen die MT Fähigkeit des Kyro. Unter D3D gehen 8 Tex/pass (API-Beschränkung DX8) unter OGL gehen 4Tex/pass (Beschränkung durch Treiber, OGL kann AFAIR 32Tex/pass)

[Unregistered]

Originally posted by Demirug


Aber beim Kyro wird Multipass bei weitem nicht so teuer erkauft wie bei anderen Karten da das zwischenspeichern im Framebuffer wegfält.

Nein, Multipass belastet ihn genau so, wie alle anderen Grafikchips. Der Vorteil der Kyros liegt eben darin, dass mehrere Passes durch Loopback vermieden werden. Das geht aber nur, wenn auch genügend TMUs unterstützt werden. Bei 2 TMU-Unterstützung muss Kyro für die dritte Textur genau so einen neuen Pass anfangen, wie andere Chips auch.

[Demirug]

Originally posted by ow


Ich meine Multipass, also zB. Auftragen von 4 Texturen bei nur 2TMUs.

Wenn man nach dem ersten der 2 passes einen Screenshot vom Framebuffer erstellen könnte, hätte ich dann nicht die komplett Szenerie bis auf die fehlenden 2 Texturlagen korrekt gerendert?

Es wird doch nicht ein Dreieck zweimal hintereinader an den Rasterizer geschickt und komplett in 2 passes texturiert, bevor das nächste Dreieck an der Reihe ist?
Denn die Dreiecke müssen bei Multipass ja auch zweimal über den AGP.

Und dies könnte auch beim Kyro gelten, so dass auch die HSR-Stufe zweimal durchlaufen wird. Oder doch nicht???


Du kannst bei einem Kyro nicht so einfach zwischendurch einen Screenshot machen. Wenn du es trotzdem machts veränderst du dadurch die Arbeitsweise des Kyro in der von dir beschriebehnen Weise.

Wenn man wärend des gesamten Frames den Framebufer in ruhe läst wird zuerst die ganze geometrie zwichengespeichert und dann Tile für Tile ausgewertet. Dabei werden dann auch die Multipass vorgänge aufgelöst.

Da der Kyro im Normalfall ja keinen Z-Buffer erzeugt muss er eine Tile komplett in einem Schritt durchrechnen. Das ist technisch auch nicht besonders schwer.

Mit der Aussage das die Dreiecke zweimal über den AGB müssen hast du allerdings recht. Deshalb sprach ich ja auch davon das die Geometrielast beim Multipass höher ist als bei Multitextur.

[Demirug]

Originally posted by Unregistered


Nein, Multipass belastet ihn genau so, wie alle anderen Grafikchips. Der Vorteil der Kyros liegt eben darin, dass mehrere Passes durch Loopback vermieden werden. Das geht aber nur, wenn auch genügend TMUs unterstützt werden. Bei 2 TMU-Unterstützung muss Kyro für die dritte Textur genau so einen neuen Pass anfangen, wie andere Chips auch.

Ee ging bei meiner Aussage nicht um die Füllrate sonder um die Bandbreite die gespart wird. Da ein IMR bei Multipass die Farbwerte erst in den Framebuffer schreibt und sie beim nächsten Pass erst wieder einlessen muss bracuht ein IMR pro Pixel und Pass 8 Byte zusätzlich Bandbreite im Vergleich zur Kyro.

[Quasar]

Das Problem na der Sache ist imo nur, daß der Kyro einfach darauf ausgelegt ist (sowohl Architektur, als auch zur Verfügung stehende Leistung, sprich Taktraten), alles in einem Schritt zu machen.

Wenn er das auch irgendwelche Gründen nicht kann oder darf bricht er leider meist gnadenlos ein.

Und darum, daß dies eben nicht immer die Schuld des Kyro, sondern oft auch die Schuld der Games ist, ging es mir.

BTW, lt. Kristof gibt's bald wieder was schönes neues an PowerVR-Tech Demos....

[Demirug]

Originally posted by Quasar
Das Problem na der Sache ist imo nur, daß der Kyro einfach darauf ausgelegt ist (sowohl Architektur, als auch zur Verfügung stehende Leistung, sprich Taktraten), alles in einem Schritt zu machen.

Wenn er das auch irgendwelche Gründen nicht kann oder darf bricht er leider meist gnadenlos ein.

Und darum, daß dies eben nicht immer die Schuld des Kyro, sondern oft auch die Schuld der Games ist, ging es mir.

BTW, lt. Kristof gibt's bald wieder was schönes neues an PowerVR-Tech Demos....

Richtig bei allen Techniken die zwischendurch zugriff auf den Framebuffer oder noch schlimmer den Z-Buffer erfodern bricht der Kyro weg da man in damit zum IMR machen kann. Zum Glück für alle Kyro besitzer sind diese Techniken aber zunehmend nicht mehr im gebrauch da sie auch auf IMR Karten zu Performanceneinbrüchen führen. So lassen zum Beispiel die NVidia-Treiber unter DX den Zugriff auf den Z-Buffer nicht mehr zu.

[ow]

Originally posted by Demirug


Du kannst bei einem Kyro nicht so einfach zwischendurch einen Screenshot machen. Wenn du es trotzdem machts veränderst du dadurch die Arbeitsweise des Kyro in der von dir beschriebehnen Weise.

Wenn man wärend des gesamten Frames den Framebufer in ruhe läst wird zuerst die ganze geometrie zwichengespeichert und dann Tile für Tile ausgewertet. Dabei werden dann auch die Multipass vorgänge aufgelöst.

Da der Kyro im Normalfall ja keinen Z-Buffer erzeugt muss er eine Tile komplett in einem Schritt durchrechnen. Das ist technisch auch nicht besonders schwer.

Mit der Aussage das die Dreiecke zweimal über den AGB müssen hast du allerdings recht. Deshalb sprach ich ja auch davon das die Geometrielast beim Multipass höher ist als bei Multitextur.

Also jetzt versteh ich gar nichts mehr.

Die Geometrie muss 2x ueber den AGP, aber du bearbeitest jedes Tile nur einmal?
IMO muesste der zuerst Kyro alle Tiles im ersten Pass abarbeiten, diese in den FB schreiben und dann im 2. pass die einzelnen Tiles wieder aus dem FB auslesen und weiterbearbeiten.


Wenn der Kyro zum Multipass ausschliesslich sein loopback benutzt, dann braucht er doch die Geoemtriedaten kein 2. Mal???

[ow]

Originally posted by Demirug


Ee ging bei meiner Aussage nicht um die Füllrate sonder um die Bandbreite die gespart wird. Da ein IMR bei Multipass die Farbwerte erst in den Framebuffer schreibt und sie beim nächsten Pass erst wieder einlessen muss bracuht ein IMR pro Pixel und Pass 8 Byte zusätzlich Bandbreite im Vergleich zur Kyro.


Und ich denke, der Kyro arbeitet hier genauso wie ein IMR.

[Demirug]

@ow:

Ich glaube du bringst da ein bischen was durcheinader. Der Kyro arbeiten ja bekanntlich nicht mit der normalen 3d pipeline sonder in 2 Stufen.

1. Stufe:
T&L der gesamten Geometrie.
Culling
Cliping
Aufteilen auf die Tiles und speichern im GraKa Speicher

2.Stufe (bei DX eingeleitet duch EndScene)

Render der Tiles.

Dafür werden nun einfach alle Dreiecke die zu einer Tile gehören ausgelesen und durchgeprüft. Dabei wird nun für jeden Pixel festgestellt welches Dreieck ganz oben liegt. Da an denn Dreiecken die Renderstates gebunden sind ist es nun leicht festzustellen ob Alphablending aktiviert ist oder nicht. Für den Fall das es aktiviert ist muss eben auch das entsprechende darunter liegende Dreieck gesucht und die Texelfarbe bestimmt werden. Diese beiden Werte werden dann laut den Blendingsettings verechnet.

Das ganze ist aber zugegebenermassen etwas kompliziert. Deswegen hat die Kyro auch mit manchen Spielen Probleme die "merkwürdige" Dinge mit den Renderstates veranstalten. Dies dürfte auch einer der Gründe sein warum NVidia nicht TBR zu übergehen möchte.

Bei einem TBR ohne Z-Buffer im GraKa-Ram ist das die einzige Möglichkeit multipass aufzulösen. Und die Kyro schreibt laut den Spec nur dann einen Z-Buffer wenn bei Init angegeben wird das man Zugriff auf den Z-Buffer braucht.

[ow]

Jetzt hast du mich ganz verwirrt.

Ich frag mal so:

Wieso muss der Kyro die Geometriedaten ein zweites Mal (uber den AGP) bekommen, wenn er doch eh nicht nach dem ersten Pass in den Framebuffer schreibt, sondern die Tiles gleich weiterverarbeitet?

Also wie ist das jetzt:

Durchlaufen zuerst alle Tiles nacheinander den ersten Pass und anschliessend genauso nacheinander den zweiten Pass?

Oder durchläuft ein Tile beide Passes direkt hintereinander und dann kommt erst das nächste Tile. In diesem Fall brauch ich aber doch kein zweites Mal die Geometriedaten, oder doch??


Oder nichts von beidem?

[Demirug]

@ow:

Anscheinend bin ich zu blöd es dir zu erklären. Ich hab dir mal einen Link rausgesucht mit einer Beschreibung des gesamten Verfahrens

http://www.pvrdev.com/doc/f/PowerVR%20Tile%20based%20rendering.htm

Hoffe das hilft dir weiter.

[Quasar]

So, wie ich das verstehe, werden Tiles komplett (inkl. aller Passes) durchgerechnet. Die Daten sollten dazu eigentlich lokal vorliegen und nicht für jeden Pass nochmals über den AGP wandern. Wie sollte die CPU das auch anstellen? Sie kriegt im Normalfall ja keine Rückmeldung, ob die 3D-Pipe nun Single-Pass oder Multi-Pass arbeitet.

Geometriedaten sind in herkömmlichen Engines doch "fire&forget" oder?

[Demirug]

Originally posted by Quasar
So, wie ich das verstehe, werden Tiles komplett (inkl. aller Passes) durchgerechnet. Die Daten sollten dazu eigentlich lokal vorliegen und nicht für jeden Pass nochmals über den AGP wandern. Wie sollte die CPU das auch anstellen? Sie kriegt im Normalfall ja keine Rückmeldung, ob die 3D-Pipe nun Single-Pass oder Multi-Pass arbeitet.

Geometriedaten sind in herkömmlichen Engines doch "fire&forget" oder?

Ja genau so ist es. Das mit dem fire&forget ist zwar bei DX8 nicht zwanghaft so da man seine Daten in Buffer ablegen kann. Das ist aber in diesem Zusammenhang nebensächlich.

[ow]

Originally posted by Quasar
So, wie ich das verstehe, werden Tiles komplett (inkl. aller Passes) durchgerechnet. Die Daten sollten dazu eigentlich lokal vorliegen und nicht für jeden Pass nochmals über den AGP wandern. Wie sollte die CPU das auch anstellen? Sie kriegt im Normalfall ja keine Rückmeldung, ob die 3D-Pipe nun Single-Pass oder Multi-Pass arbeitet.




Hab ich das jetzt verstanden???.
Also müssen die Geo-Daten nur einmal für alle passes über den AGP beim Kyro.
Und in den Framebuffer schreibt er auch nicht nach jedem pass.

Aber wo ist denn dann der Unterschied zwischen single- und multipass beim Kyro?

[Demirug]

@ow:

"Also müssen die Geo-Daten nur einmal für alle passes über den AGP beim Kyro."

Bei Kyro gehen die gleichen Geo-Daten über den AGP wie bei allen anderen Karten auch. Wenn man eine Dreieck einmal mit 4 Texturen rendert gehen die Daten einmal über den Bus wenn man das gleiche Dreick 2mal mit 2 Texturen (Multipass) rendert gehen die Daten zweimal über den AGP. Hier gibt es absolute keinen unterschied zu den IMR.

"Und in den Framebuffer schreibt er auch nicht nach jedem pass."

Genau der Framebuffer wird am Ende Tile für Tile gefüllt.

"Aber wo ist denn dann der Unterschied zwischen single- und multipass beim Kyro?"

Das bei Multipass mehr Geometriedaten bearbeitet werden müssen. Im Kyro selbst stellt das in der Regel kein problem dar. Das Problem ist eher die CPU da ja dort bei Multipass mehr T&L Leistung gebraucht wird.

[ow]

AH, ich glaub jetzt hab ich´s.=)

Jedes Dreieck geht dierekt zweimal nacheinander für die 2 passes über den Bus und wird komplett (2*2 im Beispiel) texturiert.
Sowohl bei IM, wie auch bei TBR Renderern.
Und nicht alle Dreicke zuerst einmal und dann alle Dreiecke ein zweites Mal.

[Demirug]

Originally posted by ow
AH, ich glaub jetzt hab ich´s.=)

Jedes Dreieck geht dierekt zweimal nacheinander für die 2 passes über den Bus und wird komplett (2*2 im Beispiel) texturiert.
Sowohl bei IM, wie auch bei TBR Renderern.
Und nicht alle Dreicke zuerst einmal und dann alle Dreiecke ein zweites Mal.

Stimmt fast.

Beim Multipass müssen die beiden Dreiecke nicht zwangsläufig direkt hintereinader übertragen werden. Im Regelfall werden sie das auch nicht.

Das Texturieren wird erst später beim Berechnen der Tiles durchgeführt. Deshalb braucht der Kyro ja auch viel weniger Fillrate und Bandbreite weil er nur die Dreiecke texturiert die auch sichtbar sind. Das schliesst die unteren Multipasslayer oder transparents effecte mit ein.

[Quasar]

Im Ernst???

Erst stimmst du mir zu, daß die Geometrie nur einmal über den AGP wandert (auch bei Multipass) und jetzt dann doch wieder nicht?

AFAIK ist Multipass ein komplett Graka-Internes Problem....

[Demirug]

Originally posted by Quasar
Im Ernst???

Erst stimmst du mir zu, daß die Geometrie nur einmal über den AGP wandert (auch bei Multipass) und jetzt dann doch wieder nicht?

AFAIK ist Multipass ein komplett Graka-Internes Problem....

Sorry ich dich beim letzten mal wohl falsch verstanden. Tatsache ist das die GraKa eingentlich gar nicht von Multipass weis. Für sie ist das einfach eine Blending operation. Der Unterscheid zwischen Multipass und Transparenzeffect ist das bei Multipass 2* die gleiche Geometrie benutzt wird und bei Transparenz die Geometrie normalerweise eine andere ist. Was nun das zweimalige übertragen der Geometriedaten über den AGP angeht ist das beim Kyro definitive so. Bei einer Hardware T&L karte können theoretisch aber auch Geometriedaten in der Grafikkarte wie Texturen hinterlegt werden. In diesem Fall müssten die Daten nur einmal über den AGP übertragen werden würden dann aber beim zweiten Zugriff von der internen Bandbreite etwas abzweigen.

Was du wahrscheinlich gemeint hast ist ein loopback. Dieser wird benutzt um z.B. mit nur 2 TMUs 4 Texturen aufzutragen. In diesem Fall werden die Geo-Daten wirklich nur einmal übertragen das ist dann aber kein Multipass sonder Multitextur und wirklich ein Garka-internes Problem.

[Quasar]

Hm, das war mir neu. Ich hätte nicht gedacht, daß ein 2fach texturiertes Dreieck nochmal zur CPU muss um sich Instruktionen für die nächsten (max.) 2 Layer abzuholen...
Macht ja auch logisch keinen Sinn irgendwie, wenn ich Basemap, Lightmap und bsw. Detailmap draufbacken will, hat die CPU ja eigentlich nix mehr groß damit zu tun...



(und nein, Loop-Back habe ich nicht gemeint, das kenne ich ein bißchen..)

edit:
Ich meine Multipass in dem Sinne, daß einfach, sagen wir, 4 Texturen genutzt werden (ohne Alpha), aber einfach nur 2 TMUs vorhanden sind und eben kein Loopback unterstützt wird.

[Demirug]

@Quasar:

Nur zur Sicherheit es ging darum wie man z.B. bei einer TNT2 4 Texturen auf ein Dreieck bekommt?

Das man für die zweiten Pass aber nochmal die CPU braucht macht durchaus Sinn. Zum Beispiel könnten die zusätzlichen Texturen andere u/v Kordinaten haben oder es werden andere Berechnungen im VS benötigt. Aus diesem Grund gibt es seit DX8 ja auch ein Multistream verfahren für Vertexdaten. Das heist ich kann meine daten zu Beispiel auf 3 Buffer aufteilen:

1. Buffer: Position + Normale
2. Buffer: u/v für Layer 1 und 2
3. Buffer: u/v für Layer 3 und 4

Bei ersten Pass benutzt man dann die Buffer 1 und 2.
Bei zweiten Pass benutzt man die Buffer 1 und 3.

Zusätzlich kann ich natürlich für jeden pass auch einen anderen VS benutzen.

[Quasar]

Ja, darum ging's mir.

Aber wie macht die CPU das, wenn der Grafikchip bsw. 4 TMUs (à la Parhelia, um mal aufs Topic zurückzukommen ;)) besitzt und alle Single-Pass auftragen kann?

Dann müssen die entsprechenden Instruktionen doch auch schon gleich auf einen Schlag mitgeschickt werden, richtig?

Und gibt's für solche Späße und um die CPU ein wenig zu entlasten nicht 'nen Buffer, der das Ganze lokal speichert. Bei HW-TnL Karten geht das, wie du ja angemerkt hast. Beim Kyro-200 z.B., der sich ja "EnTnL"-fähig rühmt, sollte es also auch so einen Buffer geben und demzufolge müsste er sich doch bei jeder Karte Treiberseitig erwzingen lassen, um den AGP und die CPU zu entlasten, oder?

[ow]

hmmm... *grübel grübel*

Also für einen IM scheint mir das klar.

Der Chip bekommt zuerst alle Dreiecke für den ersten pass, klebt zwei Texturen drauf, schreibt in den Frambuffer.

Im 2. pass übergibt die CPU (Game-Engine) alle Dreiecke nochmals, der Chip rechnet wie im ersten Pass nur dass er zuvor die alten (2-fach texturierten) Pixel wieder aus dem Frambuffer ausliest und dann zwei weitere Texturen draufpappt.

Der Chip weiss nichts von multipass, sondern nur die Game-Engine.

Aber wie ist das beim Kyro?

Ich habe mir das wie beim IM vorgestellt.

Geo-Daten von der CPU zum Chip, Tilen, HSR durchführen, auf die verbleibenden (Teil-)Dreiecke die Textur drauf.
Und dann die Tiles in den Framebuffer.

Und nochmals von vorne füer den nächsten pass. Mit dem Unterschied dass jetzt (änhnlich wie beim IM) tileweise aus dem FB gelesen wird und jedes Tile dann nochmals berechnet wird mit den alten FB-Pixeln aus Ausgangsfarbe.


Wenn die Tiles direkt multipass berechnet würden, wie läuft dass denn mit dem 2. Geo-Datensatz in der Tiling und der HSR Unit des Kyro ab?

Die Tiles werden ja sequentiell abgearbeitet und wenn sie nicht zwischengespeichert werden, dann müsste der Kyro doch immer dasselbe Tile 2x nacheinander bearbeiten.

Es existiert ja sonst kein Bezug zwischen den Pixeln des ersten Pass und den Geo-Daten im 2.pass.

Beispiel:

Der Kyro beginnt mit Tile 1, errechnet die zu sichtbaren Pixeln gehörenden Dreiecke und texturiert sie anschliessend. 1. pass für diese Tile ist damit abgeschlossen.

Der Kyro beginnt mit Tile 2.

Und nun?
Was machen mit Tile 1?
Der 2. Geo-Datensatz (zum 2. pass) ist doch evtl. dem Chip noch garnicht übergeben worden?

Denn der erste Pass ist ja noch garnicht für alle Tiles abgeschloessen und ich dachte, die Dreiecke des 2. pass würden von der Game-Engine erst geliefert, nachdem der erste pass komplett fertig ist.

(man merkt hier, dass ich keine Ahnung von 3D Programmierung habe, sorry:D)


[Idee]
Oder läuft das so:

Der Kyro kriegt zweimal die kompletten Geo-Daten, bevor er überhaupt mal beginnt irgendwelche Pixel zu berechnen?

Dann könnte er sicher für jedes Tile den Multipass direkt ausführen direkt.

Wobei er doch eigentlich den 2. Geo-Datensatz nicht braucht, aber natürlich nicht verhindern kann, dass dieser von der Game-Engine geliefert wird.

....

ich geb´s auf.:(

[Demirug]

Originally posted by Quasar
Ja, darum ging's mir.

Aber wie macht die CPU das, wenn der Grafikchip bsw. 4 TMUs (à la Parhelia, um mal aufs Topic zurückzukommen ;)) besitzt und alle Single-Pass auftragen kann?

Dann müssen die entsprechenden Instruktionen doch auch schon gleich auf einen Schlag mitgeschickt werden, richtig?


Genau in diesem Fall kan man alles auf einmal schicken. Um auf mein Beispiel zurückzukommen. Es werden die Buffer 1,2 und 3 auf einmal benutzt.


Und gibt's für solche Späße und um die CPU ein wenig zu entlasten nicht 'nen Buffer, der das Ganze lokal speichert. Bei HW-TnL Karten geht das, wie du ja angemerkt hast. Beim Kyro-200 z.B., der sich ja "EnTnL"-fähig rühmt, sollte es also auch so einen Buffer geben und demzufolge müsste er sich doch bei jeder Karte Treiberseitig erwzingen lassen, um den AGP und die CPU zu entlasten, oder?

Bei einer DX8 Grafikkarte wird die CPU bei diesen Aktionen kaum belastet. Die Daten sollten sowieso schon im AGP Bereich liegen. Es werden also nur ein paar Renderstates geändert und ein Draw Call abgeschickt. Das sich die CPU trotzdem immer am Anschlag befindet hat andere Gründe.

Nun zu den Buffern welche ja nur bei T&L und VS durch die CPU von interesse sind (die wenigsten Spiele sind durch den VS oder das T&L limitiert). In den meisten Praxsisfällen kommt man damit nicht unbedingt weit.

Das Problem ist das zu dem Zeitpunkt an dem man die Daten speichern müsste noch nicht weis ob sie überhaupt ein zweites mal benutzt werden. Dadurch würde der Overhead für das speichern von nicht benutzten Daten höher als der Gewinn durch die eingesparten Rechnungen.

Bei den VertexBuffer kann man deshalb dem Treiber auch extra durch ein Flag sagen das die Geometrie statisch (Wände usw.) ist damit der Treiber weis das sich ein einlagern der Daten in den GraKa-Ram lohnt.

EnTnL: Was die da genau machen ist nicht bekannt. Ich denke aber mal eher das die daten nach dem T&L in einem Kyro freundlicheren Format abgelegt werden. Und wenn dieser Schritt auch ohne EnTnL notwendig ist spart man natürlich Power(Memorybandbreite) da jeder Vertexdatenblock nur einmal angefast werden muss.

[Demirug]

Originally posted by ow

(man merkt hier, dass ich keine Ahnung von 3D Programmierung habe, sorry:D)


Macht doch nichts dafür hast du sicher andere Talente.



[Idee]
Oder läuft das so:

Der Kyro kriegt zweimal die kompletten Geo-Daten, bevor er überhaupt mal beginnt irgendwelche Pixel zu berechnen?

Dann könnte er sicher für jedes Tile den Multipass direkt ausführen direkt.

Wobei er doch eigentlich den 2. Geo-Datensatz nicht braucht, aber natürlich nicht verhindern kann, dass dieser von der Game-Engine geliefert wird.

....

ich geb´s auf.:(

Genau so läuft das ab. Wobei er den 2. Geo-datensatz meistens doch braucht weil die u/v Koordinaten für die zusätzlichen Texturen ja anders als beim 1 Satz sein können.

[aths]

Originally posted by Quasar
Besonders ältere Games leidern jedoch an der 4Pipes/4TMU-Auslegung, da sie oft nicht von mehr als 2 TMUs pro Pipe profitieren können (siehe Kyro2) und so die Parhelia nicht allzuviel schneller als eine GF4 ist.


Stimmt so nicht. Zunächst "leiden" sie nicht, sondern bekommen nur die Vorteile nicht ab.

Wird eine Textur trilinear gefilert, belegt das beim Parhelia bekanntlich 2 TMUs. So liegt pro Pipeline (Lightmaps werden nicht trilinear gefiltert) nur noch 1 TMU brach.

[Dunkeltier]

Originally posted by Quasar
Also, die vier Treiberversionen, die Matrox in den letzten Monaten veröffentlicht hat, sind durchweg ziemlich gut, leider gibt's noch keinen brauchbaren OpenGL-ICD, aber der soll nächste Woche rauskommen.

Besonders ältere Games leidern jedoch an der 4Pipes/4TMU-Auslegung, da sie oft nicht von mehr als 2 TMUs pro Pipe profitieren können (siehe Kyro2) und so die Parhelia nicht allzuviel schneller als eine GF4 ist.

Die FSAA-Qualität ist natürlich sehr gut, auch wenn die unbehandelten Texturen teils einen ziemlichen Kontrast zu den wunderbar glatten Kanten erzeugen und so wieder die Unausgewogenheit hervorheben. Bei den meisten Games ist jedoch Füll- und Transferrate in ausreichender Menge vorhanden, um AF zuzuschalten.
Das sieht dann schon recht geil aus.


Alles in allem hat sich der Kauf der Parhelia doch gelohnt, auch wenn ich noch beinahe €300 auf den Verkaufspreis meiner GF4Ti4600 draufzahlen musste.


Da scheint wohl jemand unserer Zeit vorraus zu sein, bzw. ein Zeitreisender zu sein. :)

[Quasar]

Originally posted by aths


Stimmt so nicht. Zunächst "leiden" sie nicht, sondern bekommen nur die Vorteile nicht ab.

Wenn du nach dem "leiden" weitergelesen hättest, würde dir aufgefallen sein, daß ich genau das geschrieben habe.

[aths]

Naja, nicht genau das... :)

Im übrigen darf ich die Spekulation äußern, dass Parhelia wohl trotz Matrox-Aufschlag wohl nicht sooo teuer werden dürfte.

[Quasar]

Das wäre schön. €350...so in der Gegend?

[Razor]

Dürfen tust Du alles, aths...
Würde mich aber trotzdem interessieren, woher Du das hast !

Oder war das frei nach dem Motto: niedrige Leistung = niedriger Preis ?
:D

Razor

[aths]

Quasar, angesichts der Marktsituation halte ich 150 € über dem Preis, der dann für die beste verfügbare Marken-GF4Ti genommen wird für vertretbar, damit Parhelia genügend Abnehmer findet. Oder aber die lassen das mit dem Gamer-Sektor gleich sein und verkaufen dort, wo man generell höhere Preise verlangen kann.

[Quasar]

...und wieder das Denken mit DM-Werten bei Euro-Beträgen. 150€ klingen zwar nicht so viel, weil wir die Summe oft im Kopf noch mit DM gleichsetzen, aber umgerechnet sind's immerhin fast 300DM richtigen Geldes.

Ob die Parhelia dann wirklich ihre +/-650€ wert ist, werden wir wohl nach ersten Tests und an den Verkaufszahlen sehen. Ich denke, daß wird für den Massenmarkt doch eher ein wenig zuviel sein.

Für den durchschnittlichen Verdiener ist das sicher mehr, als man in einem oder zwei Monaten einfach so beiseite legen kann...

[geforce]

Originally posted by Quasar
Ob die Parhelia dann wirklich ihre +/-650€ wert ist, werden wir wohl nach ersten Tests und an den Verkaufszahlen sehen. Ich denke, daß wird für den Massenmarkt doch eher ein wenig zuviel sein.

Nicht nur das! Die Frage ist ja eher die ob die Karte zum Zeitpunkt des Erscheinens die +/-65€ wert ist. Und ich hoffe stark das Matrox das berücksichtigt!

[Axel]

Ich halte die 150€ mehr für die Parhelia gegenüber der GeForce 4600 für "etwas" übertrieben. Wenn ich mich recht erinnere, war zu TNT2-Zeiten die G400 auf gleichem Preisniveau bei etwas höherer Leistung.

[Schnitzl]

hi,
woher habt ihr denn die 650 Euro ?
Vor allem, für welches Modell ?
Laut meinen Infos soll das 128 MB- Modell für 550 Euro kommen...

[Axel]

Originally posted by Schnitzl
hi,
woher habt ihr denn die 650 Euro ?
Vor allem, für welches Modell ?
Laut meinen Infos soll das 128 MB- Modell für 550 Euro kommen...

Alles reine Spekulationen.
Es gibt weder offizielle Kartenkonfigurationen noch irgendwelche Preise.
Da die Parhelia wahrscheinlich schneller als die GeForce 4600 ist, wird deren Preis als Basis genommen plus einem "Matrox-Zuschlag".

[aths]

Axel, ob der Parhelia (so er mit 220 MHz ausgeliefert wird) bei heutigen (!) Spielen wirklich schneller sein wird, werden Benchmarks zeigen müssen.

Matrox hat natürlich beste 2D-Technologie, einige DX9-Features und nicht zulesetzt ihren eigenen Namen vorzuweisen. Daraus "berechnete" (also schätzte) ich den Aufschlag. Selbstverständlich kann diese Vermutung grundlegend falsch sein.

[aths]

Quasar,

ich für mein Teil denke absolut und auch relativ in €- und nicht DM-Beträgen. Wenn Matrox es schafft, zu diesem Zeitpunkt die beste Karte zu haben, ist das alleine vermutlich eine Menge wert. (Vom teuren Chip mal ganz abgesehen.)

[Axel]

Originally posted by aths
Axel, ob der Parhelia (so er mit 220 MHz ausgeliefert wird) bei heutigen (!) Spielen wirklich schneller sein wird, werden Benchmarks zeigen müssen.

Matrox hat natürlich beste 2D-Technologie, einige DX9-Features und nicht zulesetzt ihren eigenen Namen vorzuweisen. Daraus "berechnete" (also schätzte) ich den Aufschlag. Selbstverständlich kann diese Vermutung grundlegend falsch sein.

Alles richtig. Auf jeden Fall ist der Parhelia schnell genug für heutige und zukünfige Spiele, wenn die Entwickler die Möglichkeiten des Chips auch nur ansatzweise nutzen.
Das er vielleicht nicht der schnellste ist, ist mir persönlich eigentlich egal. Zumindest ist er deutlich schneller als meine G400. ;D

[Axel]

Es wäre eigentlich noch zu klären "Was sind heutige Spiele".
Ist es Quake3 in HQ oder DX8-Spiele wie Morrowind, werden die Spiele mit AA und AF gespielt oder ohne.
Je nach dem wie man diese Fragen für sich beantwortet, ist entweder die GeForce oder der Parhelia schneller.

[Torian.cc]

Oh jaaaa,

die Kostenfrage zur Parhelia....

Ich bin schon bereit, zu zahlen, was auch immer MATROX für ihre 256MB Graka verlangen wird!

Was ich nun aber hoffe ist, daß MATROX sich wieder etwas Zeit läßt, bis ein neuer Grafikchip erscheinen wird.

Tröstlich für mich war die Meldung seitens MATROX, daß sie nicht auf den "6-Monats-Erscheinungs-Intervall" Zug von NVidia aufspringen werden.
Das heißt aber noch lange nicht, daß es wieder 3-4 Jahre dauern wird, bis z.B. eine "echte" DX9 oder DX10 Graka von MATROX kommen wird...

Also wenn ich jetzt z.B. im Herbst für ca. 800-1000 Euro das 256MB-Monster der Parhelia kaufen werde, weiß ich mit Sicherheit, daß ich nächstes Jahr nicht wieder soviel Geld für eine neue Graka übrig haben werde!

Aber stand nicht irgendwo, daß MATROX die Erscheinungsintervalle verkürzen wird?? (bloß nicht!!)
Aber wenn MATROX tatsächlich wieder auf dem 3D-Gamer-Markt Fuß fassen will, und nicht wieder ein halbes Jahr nach der Parhelia in Vergessenheit geraten will, müssen die das wohl oder übel...
Es sei denn, NVidia und ATI passen sich MATROX an und treten auch mal ein bissl kürzer und geben uns Gamern die Chance, den Erwerb der neuen Graka etwas länger genießen können! *wunschdenkensei*

Schon klar!! Bevor Ihr mich jetzt mit übelsten Beschimpfungen über meine miese Logik bombadiert..., mir ist schon klar, daß es soweit NIE kommen wird/kommen darf!
Und anscheinend sind es ja größtenteils die Spiele-Programmierer, die sich darauf verlassen, daß die Graka-Entwickling schnellstens voranschreitet.

MfG
Tori
__________

MATROX RULEZ

[Schnitzl]

Originally posted by aths
Axel, ob der Parhelia (so er mit 220 MHz ausgeliefert wird) bei heutigen (!) Spielen wirklich schneller sein wird, werden Benchmarks zeigen müssen.

Matrox hat natürlich beste 2D-Technologie, einige DX9-Features und nicht zulesetzt ihren eigenen Namen vorzuweisen. Daraus "berechnete" (also schätzte) ich den Aufschlag. Selbstverständlich kann diese Vermutung grundlegend falsch sein.
Ich glaube kaum dass Matrox den Fehler macht, eine langsamere Karte als die GF4-4600 rauszubringen
und als Gamerkarte anzupreisen.
Selbst wenn sie nur 10% schneller ist reicht das schon - dass sie 2mal so schnell ist,
glaub ich allerdings bei aller Matrox-liebe nicht...

Ansonsten stimme ich zu, aber seh den GF4-Preis nicht so fix ;)