Parhelia-Treiber 228 NEU

[Denniss]

Neben den 584Final Win2K/XP-Treibern für G200-550 hat Matrox auch schon wieder neue Parhelia-Treiber rausgebracht !

http://www.matrox.com/mga/support/drivers/latest/home.cfm

[ernesto.che]

Ich gehe mal davon aus, das der neue Parhelia Treiber wieder ein Plus an Leistung mitbringen wird.

[Kai]

Originally posted by ernesto.che
Ich gehe mal davon aus, das der neue Parhelia Treiber wieder ein Plus an Leistung mitbringen wird.

Ich nicht ;)

[Andre]

Originally posted by Kai


Ich nicht ;)

Richtig.
Leo hats ja in seinem neuen Artikel über das FAA der Parhelia ja bereits gesagt.

[ow]

Ich auch nicht.;)

[ernesto.che]

Es hat nicht zufällig im Hinterkopf, wie es bei der G400 1999 aussah?

[Frank]

Originally posted by ernesto.che
Es hat nicht zufällig im Hinterkopf, wie es bei der G400 1999 aussah?
G400 ist aber nicht gleich Parhelia.

Und Verbesserungen bringt die Zeit bei jeder Grafikkarte mehr oder weniger.

[ernesto.che]

Originally posted by Frank

G400 ist aber nicht gleich Parhelia.

Und Verbesserungen bringt die Zeit bei jeder Grafikkarte mehr oder weniger.
damals waren es aber mehr als 2%, 40 % waren bei einem Treibner update drin

[Frank]

richtig - in OpenGL

Aber dieser Effekt trat weder bei G450 noch bei G550 in Erscheinung. Deswegen würd ich beim Parghelia auch nicht mehr diese großen Sprünge erwarten - man kann nicht einfach implizit diese Schlussfolgerung treffen (G400 -> Parhelia)

[StefanV]

@Frank

Richtig, aber die G400 war fast ein komplettes neu Design, die Parhelia ist ein komplettes Neu Design.

Aber ersteinmal wird Matrox sich bemühen das Kärtchen zum Laufen zu bringen, danach kommen dann die 40-50% mehr Leistung :naughty:

[Quasar]

Mal wieder in die Kristallkugel geschaut, Payne?

[Frank]

@SP

1. Die Karte läuft denk ich schon halbwegs ok

2. Das mit den 40-50% ist wohl sehr weit hergeholt. Evtl 10%. Mehr auf keinen Fall. Dazu ist da einfach zu wenig Füllrate (mal abgesehen von den 4 TMUs pro Pipe).

[ow]

wenn wir schon alle dabei sind, ich tippe auf 0-100%, anwendungsabhaengig :D:D

[StefanV]

Originally posted by Frank
@SP

1. Die Karte läuft denk ich schon halbwegs ok

2. Das mit den 40-50% ist wohl sehr weit hergeholt. Evtl 10%. Mehr auf keinen Fall. Dazu ist da einfach zu wenig Füllrate (mal abgesehen von den 4 TMUs pro Pipe).

1. wissen wir nicht...
Ich weiß es nicht, da ich die Karte noch nie gesehen hab...

2. Wir wissen nicht, wie Matrox die Treiber geschrieben haben, wieviele Bremsen drin sind und wieviel sie noch optimieren können.
40% könnten durchaus möglich sein...

Ich nehme an, daß Matrox den Treiber erstmal so geschrieben hat, daß die wichtigsten Funktionen der Parhelia funzen, ohne rücksicht auf die Performance und das sie sich der Performance irgendwann mal annehmen.

In der Parhelia steckt sicher noch einiges, nur weiß keiner soo genau, wieviel...

@Quasar
hast du diese Option in deinem Profil aktiviert??

Show image attachments and [img] code in Posts?

[Andre]

Originally posted by Stefan Payne
Ich nehme an, daß Matrox den Treiber erstmal so geschrieben hat, daß die wichtigsten Funktionen der Parhelia funzen, ohne rücksicht auf die Performance und das sie sich der Performance irgendwann mal annehmen.

Von einer funktionsfähigen Karte incl. Treiber hab ich aber bisher nicht viel gesehen.
So gesehen haben sie also gar nix optimiert.

[Schnitzl]

ups

[Schnitzl]

Originally posted by Stefan Payne

1. wissen wir nicht...
Ich weiß es nicht, da ich die Karte noch nie gesehen hab...

2. Wir wissen nicht, wie Matrox die Treiber geschrieben haben, wieviele Bremsen drin sind und wieviel sie noch optimieren können.
40% könnten durchaus möglich sein...

3.Ich nehme an, daß Matrox den Treiber erstmal so geschrieben hat, daß die wichtigsten Funktionen der Parhelia funzen, ohne rücksicht auf die Performance und das sie sich der Performance irgendwann mal annehmen.

4.In der Parhelia steckt sicher noch einiges, nur weiß keiner soo genau, wieviel...
1. läuft ganz gut :)

2. Wunschdenken

3. die hatten fast 2 Jahre Zeit, wenn kein Wunder eintritt, dann bleibt die Karte so "langsam" wie sie ist.

4. schau dir den Sharkmark an bei Tom an (see attached file)

Im Prinzip müsste die Leistung bei Spielen usw. mehr als doppelt so hoch sein, also irgendwas wurde da ganz gewaltig verbockt.

[StefanV]

Originally posted by Schnitzl

1. läuft ganz gut :)

2. Wunschdenken

3. die hatten fast 2 Jahre Zeit, wenn kein Wunder eintritt, dann bleibt die Karte so "langsam" wie sie ist.

4. schau dir den Sharkmark an bei Tom an (see attached file)

Im Prinzip müsste die Leistung bei Spielen usw. mehr als doppelt so hoch sein, also irgendwas wurde da ganz gewaltig verbockt.

1. schön ;)

2. nö, optimismus ;)

3. die Frage ist nur, wieviel sie von den 2 Jahren gebraucht haben, bis sie mit den Treibern anfangen konnten...

4. ist mir bekannt, da steckt irgendwo der Wurm drin...

[ow]

Originally posted by Schnitzl

4. schau dir den Sharkmark an bei Tom an (see attached file)



Typischer Fall eines herstellerspezifischen Benches.
Der Sharkmark ist sicher ganz auf die Parhelia-Architektur zugeschnitten (so wie Villagemark auf Kyro).
Daraus lassen sich aber kaum Aussagen über die Praxis-Leistung der Parhelia ableiten.

[Schnitzl]

Na, das ist mir schon klar.

Aber einerseits kam doch die Aussage von dir, dass man bei D3D nicht wirklich optimieren kann...

Ich frage mich nun, wie kann es sein, dass die Karte sonst mit Mühe halb so schnell ist wie eine GF4-4600 und dann beim Sharkmark dann 1,5mal so schnell ist ???
*wunder*

[StefanV]

Originally posted by Schnitzl
Na, das ist mir schon klar.

Aber einerseits kam doch die Aussage von dir, dass man bei D3D nicht wirklich optimieren kann...

Ich frage mich nun, wie kann es sein, dass die Karte sonst mit Mühe halb so schnell ist wie eine GF4-4600 und dann beim Sharkmark dann 1,5mal so schnell ist ???


'ganz einfach'

4 Texturen und entsprechend viel PS Ops, damit die Shader der Parhelia ausgelastet sind und schon deklassiert sie alles, was es gibt ;)

BTW: man kann immer auf eine Karte hin optimieren...

[ow]

Originally posted by Schnitzl
Na, das ist mir schon klar.

Aber einerseits kam doch die Aussage von dir, dass man bei D3D nicht wirklich optimieren kann...




Das ist richtig und bezieht sich auf die Unversalität des D3D API.
Und insbesondere auch solche Standard-Benches wie den 3DMarks, denen zwar immer wieder 'Optimierung' vorgeworfen wird, was ich aber für baren Unsinn halte.
Dafür ist der 3DMark viel zu primitiv. Der 2001er läuft ja bis auf PS Tests absolut komplett und fehlerfrei auf alter DX5/6 HW (zB. Intel i740).


Ansonsten hat SP hier recht.
Die NV/ATi/Matrox/SiS Chips können unterschiedlich viel texturen/pass oder auch tex/1clk verarbeiten und auch die entsprechenden PS Einheiten haben unterschiedliche Möglichkeiten (->Leistung).

[Unregistered]

hm, ok, kann ich daraus dann ableiten, das das Design der Parhelia "ein Kalter" ist ?
Was will man mit den ganzen Shadern, wenn sie nirgends so richtig eingesetzt werden ?

Ich hab mal etwas getestet: bei ut1 in der 1024*768*32 ist es sowas von egal, ob 16FAA und aniso an ist oder beides aus.
Die fps sind beidesmal identisch, mit allem an sogar etwas höher (ich schätze mal Meßgenauigkeit)

Ebenso sind die min. fps bei der Parhelia höher als bei der R8500, bei jener dann dafür mehr average...
P.: 25-34-50
8,5: 23-37-60

[Schnitzl]

einloggen will gelernt sein :eyes:

[ow]

Originally posted by Unregistered
hm, ok, kann ich daraus dann ableiten, das das Design der Parhelia "ein Kalter" ist ?
Was will man mit den ganzen Shadern, wenn sie nirgends so richtig eingesetzt werden ?




Nein, das wuerde ich so nicht sehen.
Die Faehigkeiten des Parhelia werden in Zukunft sicher nur noch staerker genutzt werden als dies heute der Fall ist. Er kann also nur noch an Leistung dazugewinnen.


Mit zunehmender freier Programmierbarkeit der GPUs ist leider sehr viel mehr einseitige Optimierung auf gewisse Chips moeglich.

Vergleich mit CPUs:
Athlon und P4 koennen immer dasselbe Ergebnis berechnen (=haben selbe Faehigkeiten), aber schneller ist der, auf den die SW optimiert wurde.


Und fuer Grafikchips wird dies in Zukunft auch gelten.

[Schnitzl]

Sprich : wenn man nicht vom Marktführer kauft, wird man um Leistung beschissen ???

Da wird man dann als Parhelia-Käufer doppelt bestraft. Erst am Preis und dann an der Leistung. Wer optimiert schon seine SW für einen Grafikchip, der weit unter 10% Marktanteil hat...

So ein VollMüll. :(

[TBird]

Originally posted by Schnitzl
Wer optimiert schon seine SW für einen Grafikchip, der weit unter 10% Marktanteil hat...


www.ig3.de

;)

[Exxtreme]

Originally posted by Schnitzl
Sprich : wenn man nicht vom Marktführer kauft, wird man um Leistung beschissen ???

Da wird man dann als Parhelia-Käufer doppelt bestraft. Erst am Preis und dann an der Leistung. Wer optimiert schon seine SW für einen Grafikchip, der weit unter 10% Marktanteil hat...

So ein VollMüll. :(
So würde ich das nicht sehen. Andererseits könnte es tatsächlich irgendwelche Billig-Klitschen geben, die nur auf den Marktführer optimieren und andere Hersteller aussen vor lassen. Sowas straft man am besten ab und kauft deren Games nicht. Je eher so 'ne Klitsche pleite geht desto besser, IMHO. Denn solche Games sind meist verbuggt und machen auch woanders Schwierigkeiten. Und eigentlich kann man unter Direct3D kaum auf Hersteller optimieren und unter OpenGL muss Matrox halt die wichtigsten Extensions der anderen Hersteller in die Treiber einbauen. Einige Extensions von ATi und nVidia dürften schon drin sein in den Matrox-Treibern.

Gruß
Alex

[ow]

Originally posted by Exxtreme

Und eigentlich kann man unter Direct3D kaum auf Hersteller optimieren

Gruß
Alex



Die habe ich gerade oben zu relativieren versucht.
Bis DX7 mit den starren (=unflexiblen) Funktionseinheiten der Chips ist das richtig. Mit DX8 (und in Zukunft noch mehr) werden die Chips frei(er) programmierbar und dann gilt hier dasselbe wie fuer CPUs.

Der D3D Code ist natuerlich fuer alle Chips derselbe.
Aber wieviele Shader-Instruktionen/pass welcher Chip optimal verarbeiten kann ist eine andere Sache.`

[Schnitzl]

Heisst dass man kann sagen der Parhelia ist der P-IV der Grafikkarten ?
Unoptimiert grottenlahm, optimiert gehts ab ?

btw: was ich immer noch nicht verstehe, ist, warum ich bei der Matrox-Karte bei gleichen bzw. geringfügig niedriegeren frames ein subjektiv flüssigeres Gefühl hab als bei der ATI.
Wie z.B. mit der V5 bei UT (Glide), nur nicht so extrem.

MfG

[ow]

Originally posted by Schnitzl
Heisst dass man kann sagen der Parhelia ist der P-IV der Grafikkarten ?
Unoptimiert grottenlahm, optimiert gehts ab ?



So in etwa wuerde ich das sehen. Allein ein Beweis dafuer fehlt noch.


btw: was ich immer noch nicht verstehe, ist, warum ich bei der Matrox-Karte bei gleichen bzw. geringfügig niedriegeren frames ein subjektiv flüssigeres Gefühl hab als bei der ATI.
Wie z.B. mit der V5 bei UT (Glide), nur nicht so extrem.

MfG

Vermutlich sind die fps auf der Matrox konstanter. Auch auf meiner Radeon1 habe ich es schon erlebt, dass Szenen zwar mit hohen fps laufen, aber leichte Ruckler und Stocker das ganze doch stark verderben.



/edit: Schnitzl, koenntest du mal dies hier http://www.3dconcept.net/files/benchmark/ddspeed2.exe

auf der Parhelia laufen lassen, und zwar die BLT Tests und cpu read-write Test(am besten unter 1024x768 in 16 und 32Bit).

[Demirug]

Originally posted by ow
Die habe ich gerade oben zu relativieren versucht.
Bis DX7 mit den starren (=unflexiblen) Funktionseinheiten der Chips ist das richtig. Mit DX8 (und in Zukunft noch mehr) werden die Chips frei(er) programmierbar und dann gilt hier dasselbe wie fuer CPUs.

Der D3D Code ist natuerlich fuer alle Chips derselbe.
Aber wieviele Shader-Instruktionen/pass welcher Chip optimal verarbeiten kann ist eine andere Sache.`

ow, das ist so nicht ganz richtig. In der Spec steht das eine Shader-Instruktionen genau einen Takt brauchen darf. Es geht also nur darum wieviel Instruktionen unter welchen Bedigungen gleichzeitig ausgeführt werden können. Die DX8 Shader machen es sogar schwerer auf spezifische Karten zu optimieren als es mit der DX7 Pipeline möglich ist. Um einen bestimmten effekt zu erreichen gibt es immer ein ideales Programm (das mit den wenigsten Instruktionen, Konstanten, usw). Diese Programm ist dann aber für alle Chips das beste zum erreichen diese Effekts. Schreibt man nun ein nicht ganz so optimales Programm kommen die Treiber in Spiel. NVIDIA Treiber neigen dazu diese Programme bevor sie die Karte bekommt noch etwas zu optimieren. Es gibt das Gerücht das die Shader der Geforce in der Lage sind gewisse Kombinationen von Instruktionen in einem Takt auszuführen für die andere 2 oder mehr Takte brauchen. Der Treiber soll diese erkennen und anpassen. Ist aber nur ein Gerücht.

Bei DX7 dagegen kann man die Pipeline viel spezifischer auf einen Chip ausrichten. Da gibt es Kombinationen von Einstellungen die nur mit einem Chip funktionieren. Damit lassen sich dann auf einem Chip effekte in einem Pass rendern für die andere 2 brauchen. obwohl sie bei den relevanten DX-Caps gleiche Werte liefern.

Ist immer eine Frage wie gut der Treiber die DX-Specs auf die Hardware abbilden kann.

[Schnitzl]

Originally posted by ow
/edit: Schnitzl, koenntest du mal dies hier http://www.3dconcept.net/files/benchmark/ddspeed2.exe

auf der Parhelia laufen lassen, und zwar die BLT Tests und cpu read-write Test(am besten unter 1024x768 in 16 und 32Bit).
einfach so durchlaufen lassen ?
Kann da was im Hintergrund dabei laufen ?

[Quasar]

AFAIK einfach so laufen lassen, am besten nichts im Hintergrund, was das Graka-RAM belastet, wie eine Website mit Flash oder sowas. Esel sollte kein Problem sein.

[Schnitzl]

*g*

ich dachte eher an Photoshop, Maple oder Scientific Workplace ...

nix für ungut
=)

/edit: ich machs dann heute Abend

MfG

[Quasar]

Wenn du die Proggies minimierst, sollte es keine Probleme geben. Bin schon gespannt...

[Frank]

Originally posted by Schnitzl
... Maple ...
wenn das mal nicht Systemressourcen frißt

[Schnitzl]

@ Frank : du sagst es... :(

Also ich hab ja keinen Plan von dem Programm (ich mein jetzt wieder ddspeed =) )
also hab ich auch erst nochmal mit der R8500 laufen lassen:

[Schnitzl]

und nun mit Paella:

[zeckensack]

Öh, das Programm misst offenbar Transfers vom System-RAM ins Graka-RAM ... das bringt uns leider keinen Schritt weiter :bawling:

[Schnitzl]

scheiiisseee... ;(

bist auch sicher das ich alles richtig gemacht hab ?

MfG

[ow]

Ich glaube Benchen mit eingeschaltetem Vsync macht nicht viel Sinn. Erstaunlicherweise läuft´s ohne Vsync aber nicht auf meiner Radeon1 DDR. ???

zeckensack: kan man BLTs nicht entweder ganz im System-/Graka-RAM oder von einem zum anderen RAM durchführen?

[zeckensack]

Originally posted by ow
zeckensack: kan man BLTs nicht entweder ganz im System-/Graka-RAM oder von einem zum anderen RAM durchführen? Das sollte man können, nur bin ich da nicht so bewandert, wie genau das vonstatten geht.

Ich habe nur im Hinterkopf, daß man eine 'Direct Draw Surface' (in den Screenshots mit lpDDS-> ... gekennzeichnet) auch im Vid-RAM ablegen kann, und dann in eine andere kopieren. Vielleicht mal wieder Demirug fragen ?-) :D

Das was ihr zwei da jetzt gemessen habt, ist ganz klar Sys-->Vid. Ein 350MHz RAMDAC braucht alleine schon 1,4GB/s. Interessanterweise sehe ich da an mehreren Stellen ca 532MB/s, was sicher nur ganz zufällig dem AGP2x-Transfermaximum entspricht. ;)

[Quasar]

Macht am besten mal nur den Blt-Test.

Dazu folgende Erklärung vom Author:
The bit block transfer test (BltTest):

This test transfers an picture from an invisible secondary surface in the video memory to a visible surface in the video memory. If the video card supports the bit block transfer mode in hardware it gives an impression how fast the internal memory speed is. A 128 bit design which claims to have an 1,6 GB bandwidth has been tested with 570 MB/s transfer rate which come close to its maximum because the video chip must fist reads with 570 MB/s and than writes with 570 MB/s (1140 MB/s video memory speed). The transfer rate is very low when Direct Draw uses the software emulation. The test uses the BltFast and the Blt (more options like stretching) function of Direct Draw. It although test one of the color key modes.If you turn on vSync, the program will wait for the vertical blank for the next transfer (no benchmark).

Hier meine Werte (ohne VSync, und nur der Blt-Test):

[Demirug]

Originally posted by zeckensack
Ich habe nur im Hinterkopf, daß man eine 'Direct Draw Surface' (in den Screenshots mit lpDDS-> ... gekennzeichnet) auch im Vid-RAM ablegen kann, und dann in eine andere kopieren. Vielleicht mal wieder Demirug fragen ?-) :D


Ja genau so läuft das ab. Surfaces kann man im Grafikspeicher oder im Systemram anlegen und dann mit den Blt-funktionen ausschnittsweise kopieren. Dabei lassen die blt verschiedene Spezialeffekte zu.

[Schnitzl]

Anmerkung zwecks vsync:

Bei der R8500 ging der Test mit vsync nicht. (wie bei ow)

Bei der Parhelia schmiert Rechner ab, wenn man ohne vsync testen will :(

MfG

[Quasar]

So ein Ärger....Mist!

[ow]

Ja, ist wirklich schade.

Hab hier noch die Werte meiner GF2MX.

[Quasar]

Beim Blt-Fast scheint sich das ja ziemlich genau auszugehe, trotz der nur verdoppelten Übertragungsrate und nicht der halbierten Latenzen von DDR-RAM.

Ich nehme an, deine MX lief mit 166MHz Speichertakt?

[ow]

Originally posted by Quasar

Ich nehme an, deine MX lief mit 166MHz Speichertakt?


Da nimmst du richtig an.
Sofern nicht anders angegeben sind alle von mir geposteten Benches mit der kompletten HW auf Default-Takten.
Ansonsten wird´s schwer, was zu vergleichen.

[Quasar]

Originally posted by Schnitzl
Bei der Parhelia schmiert Rechner ab, wenn man ohne vsync testen will

Wie gesagt, schade. Andererseits, wenn ich meinen 128Bit-Bus tarnen müsste, würde ich wohl auch aus Versehen solcherlei Testmethoden unterbinden wollen.

Mehr kursiv und mehr irrealis ging leider nicht, es soll kein Flame sein, also bitte bitte nicht falsch verstehen!!!

[Demirug]

Ihr seid euch aber schon bewust das man durch einen 2d Test nicht unbedingt auf die tatsächliche Bandbreite schliessen kann. Es ist durchaus möglich das der 2d Core nicht mit der vollen Bandbreite angeschlossen ist.

[Quasar]

Nein, dessen war ich mir nicht bewusst. Warum sollte man sowas machen? Energie sparen? Transistoren sparen?

Hast du eine Idee, wie man möglichst ungeschönt die Rohe Transferrate herausbekommen kann?

[Demirug]

Originally posted by Quasar
Nein, dessen war ich mir nicht bewusst. Warum sollte man sowas machen? Energie sparen? Transistoren sparen?


Genau Transitoren sparen wäre ein guter Grund. Es muss aber nicht zwangsläufig sein.


Hast du eine Idee, wie man möglichst ungeschönt die Rohe Transferrate herausbekommen kann?

Gute Frage. Vielleicht mit massivem Datentransfer von Textur zu Textur. Bin mir aber nicht sicher ob dafür überhaupt eine Hardwarebeschleunigung vorgesehen ist. Müsste erst mal das DDK überprüfen.

[Unregistered]

Originally posted by Schnitzl

1. läuft ganz gut :)

2. Wunschdenken

3. die hatten fast 2 Jahre Zeit, wenn kein Wunder eintritt, dann bleibt die Karte so "langsam" wie sie ist.

4. schau dir den Sharkmark an bei Tom an (see attached file)

Im Prinzip müsste die Leistung bei Spielen usw. mehr als doppelt so hoch sein, also irgendwas wurde da ganz gewaltig verbockt.

rofl! Das eine MAtrox bei einem (gefakten) Matrox Test besser als ne NV TI4600 läuft ist doch klar oder?

[ow]

Originally posted by Unregistered


rofl! Das eine MAtrox bei einem (gefakten) Matrox Test besser als ne NV TI4600 läuft ist doch klar oder?


a) ich wüsste nicht, was an dem Test gefakt sein sollte. Er läuft ja scheinbar auf allen DX8 Karten.


b) das Matrox hier besser abschneidet ist soooo klar zunächst einmal nicht.
NV hätte sich wohl auch kaum vorgestellt, dass in ihrem Vorzeige-T&L-Bench DMZG eine Geforce einer Kyro Karte klar unterlegen ist.

[Demirug]

Mist mein erster Doppelpost.

[Demirug]

So ich habe mich jetzt gerade durch das DDK und den Permedia2 Source code gewühlt. Textur zu Textur Datentransfer wird vom Treiber durchgeführt und sollte deshalb normalerweise von der HW gemacht werden.

[Quasar]

Das hiesse, für eine Maximalberechnung der Bruttoleistung des Interfaces könnte man render-to-texture benützen?

[Demirug]

Originally posted by Quasar
Das hiesse, für eine Maximalberechnung der Bruttoleistung des Interfaces könnte man render-to-texture benützen?

Nicht Render to Texture sondern Texture2Texture Copy. Soweit mir bekannt gibt es aber keinen aktuellen Test für sowas.

[Quasar]

Ich werd' mal suchen....programmieren kann ich ja leider nicht *hint* ;)

[Demirug]

Originally posted by Quasar
Ich werd' mal suchen....programmieren kann ich ja leider nicht *hint* ;)

Ist ja schon gut. Wenn ich morgen etwas zeit habe nagel ich etwas zusammen.:D

[Quasar]

Supi! Vielen Dank schonmal im Voraus.

BTW, wieso klingt das bei dir immer so einfach...? ("nagel ich was zusammen.")

Selbst wenn ich Ahnung hätte, würde ich sicher Tage oder mehr brauchen für sowas...

[Schnitzl]

Heute sind die 230er rausgekommen, werd sie dann später noch testen...
(muss erst wieder umbauen ;) )

Immerhin tut sich was =) normal für Matrox wäre alle 1-3 Monate

MfG

[Unregistered]

Leider keine Verbesserungen festgestellt gegenüber 228.
NWN hüpft immer noch auf Desktop zurück :(
Immerhin läuft das Reef-Demo nun ohne dass beim Ladebildschirm Psychofarben zu sehen sind :D

Das suckt voll. Will jemand der NICHT NWN spielt ne Parhelia ? ;)

[kaasboer]

@unreg:

ich hätte Deine Parhelia genommen, weil ich so ein sentimentaler Knochen und langjähriger Matrox-Fan bin. Aber spätestens seit den heutigen Radeon 9700 Specs/Benches habe ich wegen Matrox den dicken Hals, den ich eigentlich schon letztes Jahr beim G550-Desaster hätte haben sollen.

Mein Fazit zur Matrox Parhelia: DOA!

nix für ungut,
kaasboer

[Henry]

war unreg nur schnitzl?

[Quasar]

Originally posted by Unregistered
Das suckt voll. Will jemand der NICHT NWN spielt ne Parhelia ? ;)

Wieviel?

[Schnitzl]

Originally posted by Henry
war unreg nur schnitzl?
ups, ja stimmt das war ich, sorry

Originally posted by Quasar

Wieviel?
Bei ernsthaftem Interesse bitte Angebot per PM
z.Z. überleg ich noch ob...
Wenn dann in 1-2 Monaten Wundertreiber kommen, kauf ich sie eben wieder :biggrin:

[Henry]

Originally posted by Schnitzl
Wenn dann in 1-2 Monaten Wundertreiber kommen, kauf ich sie eben wieder :biggrin:

vielleicht steigen dann die preise:D