Erste Tests und Meinungen zur Matrox Parhelia

Update Jan-Frederik Timm
64 Kommentare

Die ersten Parhelia Karten mit 128 MB werden in Kürze im Handel zu einem empfohlenen Verkaufspreis von 549 Euro auftauchen. Im Internet sind nun die ersten Testberichte über eben diese Grafikkarte mit Triple-Monitor-Support und vielen netten theoretischen Features einsehbar.

Das derzeit zu ziehende Fazit ist einfach enttäuschend. Die Treiber wirken unausgereift, Fragment Anti-Aliasing arbeitet teilweise noch fehlerhaft und die theoretische Leistung kann nur in geringen Maßen umgesetzt werden. Näheres dazu in den ersten Reviews der Karte:

Auch John Carmack, der momentan mit der Entwicklung von Doom 3 beschäftigt ist, hat sich zu der Leistung der Parhelia kurz geäußert. So wird die Karte zwar genügend Leistung für Doom 3 aufbringen, steht jedoch in keiner Konkurrenz zum ATi Radeon 8500 oder nVidia GeForce4 Ti4600.

"The performance was really disappointing for the first 256 bit DDR card. I tried to set up a "poster child" case that would stress the memory subsystem above and beyond any driver or triangle level inefficiencies, but I was unable to get it to ever approach the performance of a GF4."

Weiterhin heißt es, dass keine (bzw., nicht alle) der neuen Features der Parhelia für Doom 3 besonders hilfreich sein werden.

"The 10 bit color framebuffer is nice, but Doom needs more than 2 bits of destination alpha when a card only has four texture units, so we can't use it. Anti aliasing features are nice, but it isn't all that fast in minimum feature mode, so nobody is going to be turning on AA. The same goes for "surround gaming". While the framerate wouldn't be 1/3 the base, it would still probably be cut in half."

Die kompletten Aussagen Carmacks gibt es im letzten Plan-File Update zu lesen. Auch in unserem Forum wird die Leistung der Parhelia bereits heiß diskutiert.

Update

In einer weiteren Stellungnahme, die unteranderem an Position 24 in den Kommentaren zu dieser News zu finden ist, hat Carmack zumindest einen Teil seiner Kritik an der Parhelia zurück genommen. So hat sich das zuerst kritisierte "Displacement Mapping" doch als tauglich erwiesen, auch wenn es in Doom III noch keine Verwändung finden soll.

their implementation of hardware displacement mapping is NOT quad based. I was thinking about a certain other companies proposed approach. Matrox's implementation actually looks quite good, so even if we don't use it because of the geometry amplification issues, I think it will serve the noble purpose of killing dead any proposal to implement a quad based solution.

Darüber hinaus konnte Carmack nun auch eine '3Dlabs P10' genauer unter die Lupe nehmen und scherzhaft fügt er hinzu, dass der erste Eindruck oftmals über die weitere Arbeit mit einer Grafikkarte entscheidend ist. So frohr er den Kontak mit ATI kurzerhand ein, nachdem deren erstes Modell der 8500 die Konsole nicht korrekt darstellen konnte.

I didn't speak to ATI for months after they gave me a beta 8500 board last year with drivers that rendered the console incorrectly. :-)

Allerdings scheint der P10 mit den an ihn gestellten Anforderungen bis auf einen Ausrutscher zurecht gekommen zu sein.

I was duly impressed when the P10 just popped right up with full functional support for both the fallback ARB_ extension path (without specular highlights), and the NV10 NVidia register combiners path. I only saw two issues that were at all incorrect in any of our data, and one of them is debatable. They don't support NV_vertex_program_1_1, which I use for the NV20 path, and when I hacked my programs back to 1.0 support for testing, an issue did show up, but still, this is the best showing from a new board from any company other than Nvidia.

Interessant sind darüber hinaus auch Carmacks Ausführungen über die Experimente mit OpenGL 2.0 und dem Rendern von sieben Texturen in einem Durchlauf auf der P10.

Given the good first impression, I was willing to go ahead and write a new back end that would let the card do the entire Doom interaction rendering in a single pass. The most expedient sounding option was to just use the Nvidia extensions that they implement, NV_vertex_program and NV_register_combiners, with seven texture units instead of the four available on GF3/GF4. Instead, I decided to try using the prototype OpenGL 2.0 extensions they provide.