PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Parhelia - Leistung


aths
2002-05-31, 20:47:54
Da heutige Spiele oft nur 2 Texturen nutzen, müsste Ti4600 schneller als Parhelia sein, wenn dieser tatsächlich mit nur 220 MHz auf den Markt kommt.

Selbst wenn 3 Texturen genutzt werden (z.B. Max Payne mit Detail-Texturen) könnte Ti4600 schneller sein. (Grund: Parhelia verschleudert Leistung, da er nicht über LMA verfügt.)

Habe ich da einen Denkfehler?

Exxtreme
2002-05-31, 20:51:44
Also wenn man alles bei Standard-Settings lässt (kein AA & AF) könntest du recht haben. Die GF4Ti kann dann, durch ihre höhere Taktfrequenz bedingt, ihren Füllratenvorteil ausspielen solange sie nicht am Bandbreitenlimit läuft.

Gruß
Alex

aths
2002-05-31, 22:20:24
Hm, mit AA spielt Bandbreite auf jeden Fall eine Rolle. Wenn ich das richtig verstanden habe, verliert Parhelia bei AF aber mehr Füllrate, als GeForce.

Quasar
2002-05-31, 22:34:07
Du vergisst imo Transparenz- und Blending-Effekte. Wenn die Engines so vernünftig programmiert sind, daß sie alle zur Verfügung stehenden TMUs nutzen, sollten gerade die Minimum-Frames auf der Parhelia deutlich höher sein können.

Demirug
2002-05-31, 22:59:02
Originally posted by Quasar
Du vergisst imo Transparenz- und Blending-Effekte. Wenn die Engines so vernünftig programmiert sind, daß sie alle zur Verfügung stehenden TMUs nutzen, sollten gerade die Minimum-Frames auf der Parhelia deutlich höher sein können.

Also für die Transparenzeffekten nützen dir die zusätzlichen TMUs erst mal gar nichts die die Transparenten Fläche ja auch andere Geometriedaten hat und deshalb sowieso getrennt bearbeitet werden muss. Beim Blending nützt es natürlich schon was aber die meisten Spiele nutzen derzeit nur zwei Texturen und das geht auf fast jeder Karte ohne Multipass Blending.

Ein weiteres Problem des Parhelia dürfte auch noch sein das sich bei großen Pixelshader (> 5 ops) die Anzahl der Pipelines auf 2 reduziert.

Quasar
2002-05-31, 23:20:32
Ich glaube nicht, daß das in absehbarer Zeit ein Problem sein wird, auch wenn du da als Entwickler sicher einen besseren Einblick hast.

Wie aktuell zu sehen, scheint sich wohl zunächst die Geometrie-Hälfte der DX8-Funktionen in Games durchzusetzen, da man sie zur Not auch per CPU langsam nachbilden kann (was die Käuferschicht von den DX8-Kartenbesitzern auf sämtliche Gamer erweitert...).

Und dann wird sicher noch Rücksicht auf die nicht so extrem hohe Leistung der ersten Generation von DX8-Hardware genommen werden, ebenfalls zur Steigerung des Absatzes, so daß ich Pixelshader vorerst nicht als großen Flaschenhals bei der Parhelia erkenne.

edit:
Zum vorigen Posting: Bump-Mapping wird aber wohl davon profitieren, oder? Und das kommt grade erst so richtig ins Rollen..

Demirug
2002-05-31, 23:28:10
@Quasar:

In der momentane Situation hast du recht. Aber ich befürchte das sich Matrox wieder viel Zeit bis zum nächsten Chip läst.

EDIT:
Alles was mehr als 2 Texturen pro Polygon braucht profitiert davon.

Quasar
2002-05-31, 23:33:24
Hm, da angeblich jetzt auch Matrox fremdproduzieren läßt, können sie später ohne großen Aufwand einen o,13µ-Parhelia mit den spekulierten 300MHz nachschieben...evtl. sogar mehr. Das würde die Rendering-Einheit wieder ein wenig konkurrenzfähiger machen.

Demirug
2002-05-31, 23:47:29
Originally posted by Quasar
Hm, da angeblich jetzt auch Matrox fremdproduzieren läßt, können sie später ohne großen Aufwand einen o,13µ-Parhelia mit den spekulierten 300MHz nachschieben...evtl. sogar mehr. Das würde die Rendering-Einheit wieder ein wenig konkurrenzfähiger machen.

Matrox läst soweit ich weis schon immer fremdproduzieren. Der Punkt dabei ist nur das der Produzent auch genügend freie 0,13 Produktionseinheiten braucht. Mir ging es aber weniger um einen Dieshrink sonder um einen neuen Chip der dann auch PS 2.0 kann.

Hoffen wir mal das Matrox etwas mehr tempo vorlegt. Was aber noch durchaus interesant werden dürfte ist welche Karte sie bei OpenGL nachbilden werden und wie gross der Leistungsverlust der dabei entsteht sein wird.

Quasar
2002-05-31, 23:50:42
Ach so... ich dachte, es ginge dir um die geringere Leistung bei längeren PS...Na denn :)

Wie meinst du "welchen Chip sie nachbilden"?

Glaubst du, man wird Fremdextensions emulieren?

Demirug
2002-06-01, 00:15:19
Originally posted by Quasar
Ach so... ich dachte, es ginge dir um die geringere Leistung bei längeren PS...Na denn :)

Wie meinst du "welchen Chip sie nachbilden"?

Glaubst du, man wird Fremdextensions emulieren?

Um die geringer Leistung gings mir auch. Wobei da dann mal interesant wäre ob sich eine GForce mit 4 Pipelines mit 2 TMUs oder ein Parhelia mit 2 Pipelines mit 4 TMUs besser schlägt.

Was die Fremdextensions angeht so glaube ich das sie da gar nicht drum herum kommen werden. Ich bin mir nicht sicher ob JC einen Renderpfad für den Parhelia einbauen will solange die Marktlage noch vollkommen unklar ist. Stell dir dann mal das Geschrei vor wenn DOOM III nicht auf einer Parhelia Karte läuft.

Quasar
2002-06-01, 00:26:18
Na, dann wird das wohl oder übel nV sein müssen, da ATi anscheinend nur eine einzige Extension für ihren Shader hat, welcher bekanntlich v1.4 hat, da dürfte die Parhelia sich dann doch verdunkeln, wenn auf einmal ein paar Texture-Lookups zuviel durch den PS1.3 gejagt würden.

Ach ja, 2x4 oder 4x2 ist sicherlich interessant, aber bei der Bandbreite der Parhelia wird sie so füllratenlimitiert sein, daß man evtl. den Unterschied zwischen 2x4 und 2x2 gar nicht merken würde...

Aber moderne Games mit MT werden extrem schnell werden, schätze ich...(UT2k3 z.B.)

BigBen
2002-06-01, 00:36:30
Moin Leute,

hat JC eigendlich schon was zum Parhelia oder zum P10 von 3D Labs gesagt?

Nur damit ich das nicht falsch verstanden habe:
Doom III wird von id (schreibt man das jetzt id oder ID? :-) für die verschiedenen Grafikkarten(serien) extra optimiert?

Also z.B. auch für folgende, zukünftige Karten (wenn id die Details bekannt wären usw...): NV30, ATI`s R300, Parhelia, P10 ...
Andere Karten würden dann aber nicht laufen, wenn es Sie gäbe? Man müsste das Spiel dann erst patchen bzw. die Engine updaten, damit sich was tut.(?)

mfG
BigBen

StefanV
2002-06-01, 00:37:54
@Big Ben

Doch, sie würden laufen, nur würde die Engine dann dan PS nicht nutzen, da er ihn nicht kennt...

Demirug
2002-06-01, 00:41:40
Originally posted by BigBen
Moin Leute,

hat JC eigendlich schon was zum Parhelia oder zum P10 von 3D Labs gesagt?


Soweit mir bekannt gibt es dazu keine Aussagen von JC.


Nur damit ich das nicht falsch verstanden habe:
Doom III wird von id (schreibt man das jetzt id oder ID? :-) für die verschiedenen Grafikkarten(serien) extra optimiert?


Ja das ist bei jeder modernen OpenGL Engine so. Da man an die neuen Features der GraKas nur über Extensions rankommt und die kann jeder Hersteller selbst festlgen.


Also z.B. auch für folgende, zukünftige Karten: NV30, ATI`s R300, Parhelia, P10 etc... aber andere Karten würden dann nicht laufen, wenn es Sie gäbe? man müsste das Spiel dann erst patchen bzw. die Engine updaten, damit sich was tut?

mfG
BigBen

Im Prinzip ja. Oder der OpenGL Treiber für die entsprechende Karte benutzt die Extension eines anderen Herstellers und emuliert dadurch eine andere Karte. SIS will mit dem Xabre woll diesen Weg gehen. Bei NV30 und R300 braucht man sich aber wahrscheinlich keine Gedanken zu machen da ATi und NVidia die Extension ihere alten Chip weiterhin unterstützen werden.

Demirug
2002-06-01, 00:43:10
Originally posted by Stefan Payne
@Big Ben

Doch, sie würden laufen, nur würde die Engine dann dan PS nicht nutzen, da er ihn nicht kennt...

DOOM III läuft mit standard OpenGL ohne extension nicht! Es gibt diesen Renderpfad zwar in der Engine er ist aber deaktiviert weil er echt übel aussieht.

BigBen
2002-06-01, 00:44:45
@Stefan Payne: Aber dann würden gerade die geilsten Effekte fehlen :)

@Demirug: Vielen Dank für die ausführliche Antwort! Jetzt weiss ich schon wieder ein Wenig mehr ;)

Würde man also den Parhelia, in einem dafür optimierten Doom III einsetzen, dürfte man (um mal wieder zum Threadthema zurück zu kommen *G*) durch die Parhelia-Architektur einen deutlichen Performenceschub bekommen bzw. wäre Doom III ein Spiel, wo Parphelia`s Architektur glänzen würde (im sinne der Perfomence :-)?

mfG
BigBen

zeckensack
2002-06-01, 00:54:44
Originally posted by Demirug


DOOM III läuft mit standard OpenGL ohne extension nicht! Es gibt diesen Renderpfad zwar in der Engine er ist aber deaktiviert weil er echt übel aussieht. Bumpmapping nach DOT3, Multitexturing und anderen Krimskrams gehen auch mit standardisierten (==von allen Herstellern unterstützen) Extensions. Nur Pixel Shader sehen duster aus.
Aber es soll doch einen Codepath für Geforce2/Radeon1 geben. Damit müsste es doch klappen???
Ich habe sowieso die Befürchtung, daß man beim Parhelia unter OpenGL die Pixel Shader überhaupt nicht nutzen können wird ...

Quasar
2002-06-01, 00:57:53
@Demirug:

Hey, ich dachte, du machst DX-Sachen....wie kommt's, daß du dich mit den Interna der Doom3-Enginge so gut auskennst?


@BigBen:

Das denke ich schon. Die Parhelia könnte schon so einiges in die Waagschale werfen. Bleibt nur die Frage, wie sie gegen die kommenden DX9-Chips ausschaut (ich hoffe ja immer noch auf den P10, besonders, nach dem hier (http://slashdot.org/comments.pl?sid=25432&cid=2762972), auch wenn's schon älter ist.

So eine Quad-P10 hätte schon was....wer braucht da noch Dual-P4? ;)

Demirug
2002-06-01, 00:58:36
Originally posted by BigBen
@Stefan Payne: Aber dann würden gerade die geilsten Effekte fehlen :)

@Demirug: Vielen Dank für die ausführliche Antwort! Jetzt weiss ich schon wieder ein Wenig mehr ;)

Würde man also den Parhelia z.B. in einem dafür optimierten Doom III einsetzen, dürfte man von der Parhelia-Architektur einen deutlichen Performenceschub bekommen bzw. wäre Doom III ein Spiel, wo Parphelia`s Architektur glänzen würde(im sinne der Perfomence :-)?

mfG
BigBen

von der reinen Architecktur ist die Radeon 8500 derzeit der beste chip. Nur irgenwie kann er das nicht ausnutzen (Treiberprobleme???)

Der Parhelia ist von der Architecktur her der GeForce 3/4 ebenfalls überlegen aber nicht so klar wie die Radeon. Was der Treiber daraus machen kann weis aber noch niemand.

Die GeForce Reihe hat eigentlich die schlechteste Architecktur für DOOM III trotzdem ist die GF 4 TI 4600 die derzeit (käufliche) schnellste Karte für DOOM III.

Demirug
2002-06-01, 01:04:35
Originally posted by Quasar
@Demirug:

Hey, ich dachte, du machst DX-Sachen....wie kommt's, daß du dich mit den Interna der Doom3-Enginge so gut auskennst?


@BigBen:

Das denke ich schon. Die Parhelia könnte schon so einiges in die Waagschale werfen. Bleibt nur die Frage, wie sie gegen die kommenden DX9-Chips ausschaut (ich hoffe ja immer noch auf den P10, besonders, nach dem hier (http://slashdot.org/comments.pl?sid=25432&cid=2762972), auch wenn's schon älter ist.

So eine Quad-P10 hätte schon was....wer braucht da noch Dual-P4? ;)

Ich dachte du wolltest ins Bett???

Was die DOOM III engine angeht: Man darf sich nicht zwanghaft auf eine API versteifen. Ich hab mir bevor wir mit der neuen Engine angefangen haben beides angesehen und dann entschieden das DX benutzt wird. Trotzdem muss man natürlich weiterhin den Markt beobachten und über die Mitbewerber bescheid wissen.

Ein Quad-P10 kostet aber bestimmt mehr als ein Dual-P4. Ich bleib da aber lieber bei meinem Dual-Athlon (im Büro) bis ich einen Dual (oder Quad) Opteron bekomme.

Quasar
2002-06-01, 01:09:32
Bevor ich jetzt endgültig schlafen gehe, noch ein klein wenig JC-Speak:
Other people have outlined the issues in detail in comments already, but the crux is that, even with driver quality removed from the discussion (not counting conformance issues, running at fill limited resolutions), GF4 hardware is still faster than 8500 hardware on basically everything I tested. The 8500 SHOULD have been faster on paper, but isn't in real life.

und:
The hardware we used at E3 was not an 8500, and while the drivers were still a bit raw, the performance was very good indeed.


Beide von Slashdot.org

ad2: Also wohl mit ziemlicher Sicherheit keine R250, denn deren Treiber wären, da es ja nur eine geshrinkte R200 ist, nicht "raw"...

Demirug
2002-06-01, 01:11:55
Originally posted by zeckensack
Bumpmapping nach DOT3, Multitexturing und anderen Krimskrams gehen auch mit standardisierten (==von allen Herstellern unterstützen) Extensions. Nur Pixel Shader sehen duster aus.
Aber es soll doch einen Codepath für Geforce2/Radeon1 geben. Damit müsste es doch klappen???
Ich habe sowieso die Befürchtung, daß man beim Parhelia unter OpenGL die Pixel Shader überhaupt nicht nutzen können wird ...

Ja es gibt für die NV1x und die Radeon1 Chip Reihe auch einen Codepfad aber dort werden anscheinend auch irgendwelche Extensions benutzt. Laut aussage von JC ist der standard OpenGL Renderpfad in der entgültigen Version gespert.


but I ran the game using only standard OpenGL calls (this is not a
supported path, because without bump mapping everything looks horrible)

John Carmack, February 11, 2002


Matrox soll eben die entsprechenden Extension von NVidia benutzen bei SIS geht das ja anscheinend auch. Wenn sie das nich geregelt bekommen zeigt sich das Matrox am Markt vorbei entwickelt hat.

BigBen
2002-06-01, 01:24:52
Ich meine gelesen zu haben, das Carmack eine R300 Karte von ATI für die Doom III Presentation bekommen hat. Aber wegen ein paar Treiberproblemen (?!) musste man die Details auf "medium" stellen :).
JC hat sich ausserdem "kurz und knackig" über ATI`s tolle Treiber geäussert *G* (finde den Text leider nicht mehr)

Hier ein nettes Interiew von der E3, wo John "the voice" Carmack und Trent Reznor (zustädig für den Sound) einige interessante Auskünfte in etwa zwanzig Minuten (!) zu ihrem aktuellen Projekt "Doom III" kund geben:
http://www.wired.com/news/audio/wmp/high/doom3_wmp_hi.wma (18,29 MB)
htp://www.wired.com/news/audio/wmp/low/doom3_wmp_lo.wma (geht im Moment nicht?!)

Quelle: http://www.wired.com/news/games/0,2101,52835,00.html#

Noch nicht ganz angehört, ist aber ganz nett :)

mfG
BigBen

ps: Sorry, das dieser Thread leicht vom Thema abkommt - Matrox rules ;) und wenn JC von der Parphelia wüsste, würde Er im Interview vielleicht nicht so von diesem low-fps-gaming sprechen :-)))

zeckensack
2002-06-01, 01:26:00
@Demirug,

Was ich meinte, war daß alle relevanten Extensions (bis auf EMBM), die Radeon 1 und Geforce 2 so zu bieten haben mittlerweile standardisiert sind, also weder NV_blablalbla noch ATI_blablabla heißen. Diese Sorte Extensions kann jeder Hardwarehersteller benutzen, und es wäre mit Verlaub dämlich von Matrox (und auch 3DLabs btw), nicht das Maximum an freien Extensions zu unterstützen. Ob sie jetzt NV um Erlaubnis anbetteln, deren Pixel Shader Extension implementieren zu dürfen, da bin ich sehr skeptisch. Das wäre dann aber das einzige, was ihnen fehlen würde, alles was man für den Radeon 1 Pfad braucht, kann die Parhelia erstens, und zweitens sind die Extensions offen, ie ohne weitere Kosten direkt einzubauen.

Ein ähnliches Bild sehe ich btw beim SiS Xabre.

Demirug
2002-06-01, 01:42:49
@zeckensack:

Hab ich mir fast schon gedacht das du darauf hinaus möchtest.

Trotzdem wäre es schon irgenwie verdammt blöd wenn man sich eine Parhelia Karte kauft und dann DOOM III nur mit der Geforce2 Qualität läuft. Ich würde mich da verarscht (man verzeiche mir den Kraftausdruck) füllen.

Wobei bist du dir sicher das man wenn man Extensions von anderen benutzen will dort betteln muss???

NVidia benutzt auch ein paar "Fremd" extension von HP, IBM und SGI

Im Moment sind im Xabre Treiber so wie es aussieht wirklich nur Herstellerneutrale Extensions. (Hexeditor rulz)

zeckensack
2002-06-01, 02:03:44
Originally posted by Demirug
@zeckensack:

Hab ich mir fast schon gedacht das du darauf hinaus möchtest.Wieso das denn? OpenGL? Was? Wo? Mir doch egal ... *eg* ;)
Im Ernst: es wäre der einfachste Ausweg aus diesem offensichtlichen Problem. Es kommt dabei primär auf NV's Politik im Bezug auf 'Weitergabe' von Extensions an andere Hersteller an.Trotzdem wäre es schon irgenwie verdammt blöd wenn man sich eine Parhelia Karte kauft und dann DOOM III nur mit der Geforce2 Qualität läuft. Ich würde mich da verarscht (man verzeiche mir den Kraftausdruck) füllen.Ich würde das auch nicht toll finden, keine Frage. Für's Vermarkten der Karte ist es aber wohl am wichtigsten, daß Doom 3 darauf läuft, und das möglichst schnell, wie gut es darauf aussieht ist doch erstmal zweitrangig. Oder nicht?Wobei bist du dir sicher das man wenn man Extensions von anderen benutzen will dort betteln muss???

NVidia benutzt auch ein paar "Fremd" extension von HP, IBM und SGI.Sicher bin ich mir da überhaupt nicht ;)
Aber ich kann mir durchaus vorstellen, daß dabei Lizenzgebühren gezahlt werden müssen, Verträge geschlossen werden müssen etc.

Ich habe zumindest einen Indizienbeweis für diese Vermutung: ATI's OpenGL-Treiber unterstützt die NV_vertex_array_range Extension nicht, obwohl diese sich nur trivial von einer anderen (später verabschiedeten) offenen Extension unterscheidet. Und eben diese wird im Vulpine GLMark benutzt und führt (auf Geforce-Karten) zu verdoppelter bis verdreifachter Performance. Keine ATi-Karte läuft hier mit akzeptabler Geschwindigkeit. Die Programmierer hätten sehr wohl einen anderen Weg (EXT_draw_range_elements) gehen, und damit gute Performance auf allen Karten erreichen können. Haben sie leider nicht ...

Nun ist dieser Benchmark in meinen Augen totaler Käse, aber wenn es um harte Zahlen geht, die wichtig für's Marketing sind, dann hätte eine Firma wie ATi doch wohl etwas dafür getan. Die Hardware ist ohne jeden Zweifel dazu imstande. Dafür muß es andere (-> lizenzpolitische) Gründe gegeben haben.

Demirug
2002-06-01, 02:08:07
@zeckensack

Hab meinen letzten Post ja gerade noch editiert. Einfach so kann Extensions anscheinend wirklich nicht benutzen.

zeckensack
2002-06-01, 02:15:36
Originally posted by Demirug
Im Moment sind im Xabre Treiber so wie es aussieht wirklich nur Herstellerneutrale Extensions. (Hexeditor rulz)Ich habe doch gesagt, ich sehe eine ähnliche Situation beim Xabre *eg*

List.com, uraltes Proggy, klappt wunderbar in einer DOS-Box, kann sich selbst in den 50-Zeilen-Modus schalten. Schluckt leider nur Dateien bis 16MB, aber für Treiber und GL-Extensions reicht's immer ;)

Demirug
2002-06-01, 02:23:02
Für sowas nehme ich meinen Visual. Da kann man auch suchen. Aber um zum Thema zurückzukommen.

Matrox muss jetzt wirklich Dampf machen und die Karte auf den Markt werfen. Und dann hoffen das die Verkaufszahlen hoch genung sind das JC sich erbammt und der DOOM III Engine noch einen Renderpfad spendiert. Sonst gibt es für Matrox wahrscheinlich bald ein böses erwachen.

Diese ganze hickhack mit den Extension war auch der Grund warum ich die Finger von OpenGL für meine Engine gelassen haben. Man kann zwar mit OpenGL durch die Extension meistens mehr mit einer Karte anstellen als mit DX aber dafür hat man dann solche Probleme am hals.

LovesuckZ
2002-06-01, 11:07:02
Originally posted by Demirug

Im Moment sind im Xabre Treiber so wie es aussieht wirklich nur Herstellerneutrale Extensions. (Hexeditor rulz)


Hast du die Treiber schon? Kann man davon schließen, dass du die Karte schon im einsatz gesehen hast?

Demirug
2002-06-01, 11:08:05
Originally posted by LovesuckZ



Hast du die Treiber schon? Kann man davon schließen, dass du die Karte schon im einsatz gesehen hast?

Ich habe die Treiber aber keine Karte.

LovesuckZ
2002-06-01, 11:30:25
Originally posted by Demirug


Ich habe die Treiber aber keine Karte.

Bekommst du die Karte noch?

Demirug
2002-06-01, 11:42:06
Originally posted by LovesuckZ


Bekommst du die Karte noch?

Wenn ich mir eine kaufe wenn es sie dann mal gibt. Ich hab zu den SIS jungs keine Verbindung und bin auch nicht so ein großes Tier wie JC oder TS das mir die Hersteller ihere Karten aufdrängen. Die Treiber hab ich von der offizielen Xabre Site runtergeladen.

Quasar
2002-06-01, 12:12:57
Originally posted by zeckensack
Ich habe zumindest einen Indizienbeweis für diese Vermutung: ATI's OpenGL-Treiber unterstützt die NV_vertex_array_range Extension nicht, obwohl diese sich nur trivial von einer anderen (später verabschiedeten) offenen Extension unterscheidet. Und eben diese wird im Vulpine GLMark benutzt und führt (auf Geforce-Karten) zu verdoppelter bis verdreifachter Performance. Keine ATi-Karte läuft hier mit akzeptabler Geschwindigkeit. Die Programmierer hätten sehr wohl einen anderen Weg (EXT_draw_range_elements) gehen, und damit gute Performance auf allen Karten erreichen können. Haben sie leider nicht ...

Sorry, Z-Bag, aber das liegt nicht an der nV_Vertex_Array_Range....

Hab's zwar selber nicht glauben können, aber eben nochmal nachgemessen. High-Detail und 32Bit, sonst alles abgeschaltet. Einmal mit Vertex Array und einmal ohne: Beide Male 80,3fps...

Mit oGL-Lighting und Texture Compression: 132,8 zu 86,9. Hm.. ein bißchen was scheint's doch zu bringen ;)

LovesuckZ
2002-06-01, 13:11:27
Originally posted by Demirug


Wenn ich mir eine kaufe wenn es sie dann mal gibt. Ich hab zu den SIS jungs keine Verbindung und bin auch nicht so ein großes Tier wie JC oder TS das mir die Hersteller ihere Karten aufdrängen. Die Treiber hab ich von der offizielen Xabre Site runtergeladen.

Sind in den Treiber, die du dir Runtergeladen hast, schon die Advanced Pixelshader eingeschaltet?

Edit: Kenn einer von euch "Genies" einen deutschen Händler, der Karten aus Asien einfuehren laesst?

Xmas
2002-06-02, 02:26:52
Originally posted by BigBen
(schreibt man das jetzt id oder ID? :-)
id. Und man spricht es auch so aus ;)

Originally posted by Demirug
Ein weiteres Problem des Parhelia dürfte auch noch sein das sich bei großen Pixelshader (> 5 ops) die Anzahl der Pipelines auf 2 reduziert.
Nun ja, gegenüber GF3/4 ist das ein deutlicher Vorteil. Parhelia kann 5 Ops pro Takt pro Pipeline ausführen, GF3/4 nur 2.

Demirug
2002-06-02, 12:15:26
Originally posted by Xmas

Nun ja, gegenüber GF3/4 ist das ein deutlicher Vorteil. Parhelia kann 5 Ops pro Takt pro Pipeline ausführen, GF3/4 nur 2.

Mein Fehler. Hab in dem Moment nicht mehr daran gedacht da einem in der Regel auch die TMUs ausgehen wenn man mehr OPS braucht. Wobei 3 OPS pro Pipe wären bei der GF wahrscheinlich auch besser.

Aber das die TMUs nicht trilinear Filtern können ist schon etwas ärgerlich. Den 2 TMUs(triliniear) und 5 OPS sind nicht gerade ausgeglichen.

olescz
2002-06-03, 10:13:40
Im Matrox eigenen tech support forum hat Haig, der Chef vom tech support, geschrieben, dass Matrox eigene fragment shader extensions für Parhelia im OGL-Treiber haben wird. Displacement mapping wird wahrscheinlich nur unter d3d verfügbar sein, evtl. wegen der Lizensierung an Microsoft?

http://forum.matrox.com/mgaforum/Forum8/HTML/001207.html

Ausserdem schrieb die Firingsquad in ihrem Parhelia preview, dass JC Doom III schon auf Parhelia am laufen hat, aber auf Grund eines ndas noch nichts dazu sagen kann.Wenn das stimmt, müsste er doch eigentlich schon einen Matrox Renderpfad geschrieben haben?

http://firingsquad.gamers.com/hardware/parheliapreview/page11.asp

ow
2002-06-03, 10:24:15
Originally posted by olescz
Im Matrox eigenen tech support forum hat Haig, der Chef vom tech support, geschrieben, dass Matrox eigene fragment shader extensions für Parhelia im OGL-Treiber haben wird. Displacement mapping wird wahrscheinlich nur unter d3d verfügbar sein, evtl. wegen der Lizensierung an Microsoft?

http://forum.matrox.com/mgaforum/Forum8/HTML/001207.html




Nein, ich glaube nicht, dass das mit der Lizensierung zusammenhaengt, ergaebe auch keinen Sinn.



Ausserdem schrieb die Firingsquad in ihrem Parhelia preview, dass JC Doom III schon auf Parhelia am laufen hat, aber auf Grund eines ndas noch nichts dazu sagen kann.Wenn das stimmt, müsste er doch eigentlich schon einen Matrox Renderpfad geschrieben haben?

http://firingsquad.gamers.com/hardware/parheliapreview/page11.asp



Nein, der Parhelia wird derzeit sicher nur auf dem Standard Renderpfad von D3 laufen. Wie das ALLE KArten tun koennen.

olescz
2002-06-03, 10:47:09
Möglicherweise gibt das schon Sinn, wenn Microsoft displacement mapping als exklusiv-feature für dx9 haben möchte und Matrox das feature unbedingt im nächsten dx haben wollte, könnte man sich ja darauf geeinigt haben, dass Matrox dm erstmal im ogl Treiber nicht integriert. Oder gibt es da noch andere einleuchtende Gründe, warum Matrox diese Funktionalität für ogl nicht zur Verfügung stellen wird?

Zu Doom III hies es doch in diesem thread, dass JC den Standard Renderpfad deaktiviert hat, oder meinst du damit den nv10/r100 Renderpfad?

Ich könnte mir aber auch vorstellen, dass JC die Parhelia schon länger hat und wenn ihm die Hardware gefallen hat auch schon die Matrox extensions nutzt. Die Parhelia ist zwar noch nicht auf dem Markt und somit noch nicht weit verbreitet, aber JC ist ja dafür bekannt, nicht unter den selben wirtschaftlichen Zwängen zu stehen wie andere Entwickler, bzw. sich manchmal einfach darüber hinwegzusetzen, siehe zb Linux und Mac support, eigenen r200 Renderpfad etc.
Ausserdem wird Matrox da besonders hinterher gewesen sein, denn auf der neuen JC-Engine wird ja nicht nur Doom III laufen...

Demirug
2002-06-03, 11:02:02
Originally posted by olescz
Möglicherweise gibt das schon Sinn, wenn Microsoft displacement mapping als exklusiv-feature für dx9 haben möchte und Matrox das feature unbedingt im nächsten dx haben wollte, könnte man sich ja darauf geeinigt haben, dass Matrox dm erstmal im ogl Treiber nicht integriert. Oder gibt es da noch andere einleuchtende Gründe, warum Matrox diese Funktionalität für ogl nicht zur Verfügung stellen wird?
Zeitmangel.


Zu Doom III hies es doch in diesem thread, dass JC den Standard Renderpfad deaktiviert hat, oder meinst du damit den nv10/r100 Renderpfad?


Es gibt zwei Standardpfade. Den reinen OpenGL Pfad (Deaktiviert) und den standardextension pfad. Dieser nutzt aber nur hersteller neutrale Extension also keine Fragmentshader.


Ich könnte mir aber auch vorstellen, dass JC die Parhelia schon länger hat und wenn ihm die Hardware gefallen hat auch schon die Matrox extensions nutzt. Die Parhelia ist zwar noch nicht auf dem Markt und somit noch nicht weit verbreitet, aber JC ist ja dafür bekannt, nicht unter den selben wirtschaftlichen Zwängen zu stehen wie andere Entwickler, bzw. sich manchmal einfach darüber hinwegzusetzen, siehe zb Linux und Mac support, eigenen r200 Renderpfad etc.
Ausserdem wird Matrox da besonders hinterher gewesen sein, denn auf der neuen JC-Engine wird ja nicht nur Doom III laufen...

Was den eingenen r200 bzw NV2x pfad angeht hat das nichts mit wirtschaflichen Zwängen sonder ist technologischen nicht anders machbar. Beiden Karten benutzen unter OpenGl eine unterschiedliche Fragmentshader-API. Das Matrox natürlich einen eigenen Renderpfad für die Parhelia will ist verständlich nur wie du ja schon gesagt hast ist JC frei von irgendwelchen Zwängen. Da die Karte aber zumindestens beim bilineraren Filtern einen R200 sowie eine NV2x schlagen sollte könnte es durchaus sein das er die 1-2 Wochen Arbeit inverstiert (hat).

Doomtrain
2002-06-03, 12:07:13
Originally posted by Demirug





Es gibt zwei Standardpfade. Den reinen OpenGL Pfad (Deaktiviert) und den standardextension pfad. Dieser nutzt aber nur hersteller neutrale Extension also keine Fragmentshader.

Da die Karte aber zumindestens beim bilineraren Filtern einen R200 sowie eine NV2x schlagen sollte könnte es durchaus sein das er die 1-2 Wochen Arbeit inverstiert (hat).

Ich will hoffen, das Carmack sich die Zeit genommen hat. Wenn es wirklich nur 1 oder 2 Wochen dauert, bis er einen angepaßten Renderpfad geschrieben hat, sollte eigentlich jeder Chip (Alles verfügbare, NV30, R300, Parhelia, P10) unterstützt werden. Das einzig schlechte am Parhelia ist,(wie schon geschrieben) das er 2TMUs für Trillineares Filtern benötigt. Für 64tab aniso. werden sogar alle 16 TMUs in Beschlag genommen. Das sollte ganz schön auf die Performance drücken.

@Demirug
Weißt du mehr über die "8 Way Parallel DMA Engine" ?
Ist das der gesplitteter Memorycontroller, entsprechend LMA?

Unregistered
2002-06-03, 12:20:16
ist euch schon mal aufgefallen - je effizenter die Architektur des Grafikchips - desto besch******* die Treiber

GF3/4 niedrige Eff. - gute Treiber
Radeon bessere Eff. - schlechtere Treiber
Kyro2 super Eff. - miese Treiber

ow
2002-06-03, 12:21:06
Originally posted by Doomtrain


@Demirug
Weißt du mehr über die "8 Way Parallel DMA Engine" ?
Ist das der gesplitteter Memorycontroller, entsprechend LMA?


Klingt fuer mich nicht so. Denn der Grafikchip hat immer direkten Access auf seinen Grafik- Speicher. Der Ausdruck ergaebe also keine Sinn.


Vermutlich ist damit die Arbeitsweise des AGP/PCI Interface gemeint.
Jeder Busmaster ist DMA-faehig und einige nutzen wohl mehrere Kanaele.
Schon ein alter 3dlabs Permedia2 kann 8 DMA Kanaele nutzen.

ow
2002-06-03, 12:22:54
Originally posted by Unregistered
ist euch schon mal aufgefallen - je effizenter die Architektur des Grafikchips - desto besch******* die Treiber

GF3/4 niedrige Eff. - gute Treiber
Radeon bessere Eff. - schlechtere Treiber
Kyro2 super Eff. - miese Treiber


:lol:

Erstens ist die Effizienz von GF3/4 gut und zweitens sind die Kyro Treiber die besten die es gibt. Da kommt nicht mal NV ganz hin.

Doomtrain
2002-06-03, 12:25:30
Originally posted by Unregistered


GF3/4 niedrige Eff. - gute Treiber
Radeon bessere Eff. - schlechtere Treiber
Kyro2 super Eff. - miese Treiber

Dünn, findest du nicht. Also die Kyro hat immer noch die besten Treiber von allen Karten die ich hatte!

ow
2002-06-03, 12:32:57
Da bin ich ganz deiner Meinung, Doomtrain.

Unregistered
2002-06-03, 12:42:52
ich rede von eigener Erfahrung, und leider hatte ich mit meinen Kyro2s (ja mehrere) nur schlechte (habe mehrmals umgetauscht)

ich hatte mit jeder karte andere Probleme, und in vielen Games Grafikfehler

Demirug
2002-06-03, 12:48:45
Originally posted by Doomtrain


Ich will hoffen, das Carmack sich die Zeit genommen hat. Wenn es wirklich nur 1 oder 2 Wochen dauert, bis er einen angepaßten Renderpfad geschrieben hat, sollte eigentlich jeder Chip (Alles verfügbare, NV30, R300, Parhelia, P10) unterstützt werden. Das einzig schlechte am Parhelia ist,(wie schon geschrieben) das er 2TMUs für Trillineares Filtern benötigt. Für 64tab aniso. werden sogar alle 16 TMUs in Beschlag genommen. Das sollte ganz schön auf die Performance drücken.


Er hat mal in irgendeinem Interview erwähnt das es man einen Renderpfad in 1 bis 2 woche programmiert hat. Das Problem dürfte aber eher sein das alle was mal eingebaut ist auch supported werden muss. Und wenn Matrox im Gamebereich nicht genügend Karten verkauft ist der Renderpfad für Parhelia ein schlechtes geschäft.

Was die Performance angeht muss man halt noch ein paar Tests abwarten.


@Demirug
Weißt du mehr über die "8 Way Parallel DMA Engine" ?
Ist das der gesplitteter Memorycontroller, entsprechend LMA?

Wenn ich mir das Diagram anschaue kann es eigentlich kein gesplitteter Memorycontroller ala LMA sein. Denn als solcher müste sie direkt im Memory Control Array liegen.

Eine Möglichkeit wäre das diese Engine irgendwie in Verbindung mit den Vertexstreams von DX steht. Was ich aber eher glaube ist das dort zum Beispiel die Syncronisation der Vertexdaten sowieso der DM-Daten vorgenommen wird.

Also zum Beispiel direkt auf die 4 VS oder erst zur Tessellation (bzw. DM) und dann auf die 4 VS.

Demirug
2002-06-03, 12:53:18
Ich würde das wie folgt ausdrücken

je effizenter die Architektur des Grafikchips desto komplizierter ist sie in den Griff zu bekommen -> es dauert lange bis die Treiber was taugen.

Unregistered
2002-06-03, 12:54:03
wie lange ist lang?

ATI braucht schon ewig :D

Doomtrain
2002-06-03, 13:10:08
Originally posted by Unregistered
ich rede von eigener Erfahrung, und leider hatte ich mit meinen Kyro2s (ja mehrere) nur schlechte (habe mehrmals umgetauscht)

ich hatte mit jeder karte andere Probleme, und in vielen Games Grafikfehler

Das tut mir Leid. Mit meiner 3DProphet 4500 war ich immer top zufrieden. Vor allem ältere Games liefen einfach Spitze damit.

der_guru
2002-06-03, 22:37:16
Hallo erstmal,

ich klinke mich in die diskusion einfach mal ein obwohl ich nicht wirklich in der Materie stecke.

Von wegen der Performace sicht auf die neuen Chips:
Performace spielt doch eigentlich eine gewieße untergeordnete rolle da
es in erster linie darauf ankommt das die Chips eine vernüftige Signal qualität haben sollten(bild qualität da ist ja Matrox numero uno) sowie das die Grafikkarten erschwinglich sein sollten und sie sollten auch ein gewißes zukunfts potential haben um Langfristig bestehen zu können. Desweiteren müssen die Treiber gut sein.

Performace ist wichtig aber doch nicht alles!?! Man nehme Nvidia, bescheidene Bildqualität aber schnell.
ATI bescheidene treiber, halbwegs gute Bildqualität usw.

Aus heutiger sicht ist Performance doch wirklich nicht alles da es mir nicht darauf ankommt ob ich in einem Game 80 oder 100 FPS habe, es sollte zwar noch für die zukunft luft nach oben geben aber wenn es einfach nur schlecht aussieht dann hab ich auch nicht viel davon da kann ich auch gleich ein paar details abstellen und mir nen Schönen Urlaub machen.

Die diskusion von wegen den Verschieden Extensions die in Hardware beschleunigt werden ist zwar nötig aber ich denke doch das OpenGL eine Standartiesierte API ist um Hardware anzusteueren? Das auf bestimmte chips optimiert wird ist klar und ich denke das es nie alle sein können da es auch mit hohen kosten verbunden ist. Stichwort Return on Invenstment(sprich kosten reinhohlen und noch möglichst viel gewinn machen um Überleben zu können).

Ich nehme mal an das JC sich eher darauf konzetriert(zumindest wenn ich seine Aussagen und andeutungen halbwegs richtig interpretiere) auf die NVidia chips hin zu optimieren da die verbreitung der Karten einfach am größten ist.

Um jetzt mal auf die Architektur geschichte einzugehen.
Der neue Chip von Matrox ist sehr beindruckend aber man sollte nie aus den augen verlieren das wenn man ein Chip neu entwickelt drauf achten sollte das der Chip möglichst lang am Markt bleiben kann und hier hat denke ich 3DLabs mit ihrem P10 momentan die besten lösung in der Schublade obwohl ich ein wenig skeptisch bin ob die performance stimmt, denn wenn die nur "ausreichend" für heutige 3D Anwendungen ist(sowohl games als auch CAD usw.) dann wird trotz der Architektur schnell wieder vom Markt verschwinden weil sie einfach keiner kaufen wird.

Zu STM bzw. den Kryo chips.
Der Chip ist zwar nicht schlecht nur denke ich das Kryo aus dem rennen ist und auch bleibt. Mit ihrem Kryo2 chip ist es ihnen gelungen fuß auf dem Markt zu fassen nur haben sie es sich wieder selbst kaputt gemacht da sie einfach zu lange brauchen um eine Weiterentwicklung auf dem Markt zu bringen. Die Treiber sind auch nicht die besten aber immerhin noch besser als die von ATI.

Meiner meinung nach wird auch Pharelia nicht lange auf dem Markt eine Chance gegen Nvidia & Co. haben, da erstens der Chip zu teuer ist und zweites eine "nächste ausbaustufe" bei Matrox sich immer sehr lang hinzieht(ausnahme von G200 auf G400). Und Matrox ist außerdem viel zu klein um wirklich gegen NVidia, ATI und Creative(3DLabs) bestehen zu können. Oder was denkt ihr darüber?

cu der_guru

Demirug
2002-06-03, 23:02:06
@der_guru:

Ja die SQ ist schon wichtig aber was nützt mir eine Spitzen SQ wenn ich dann nur DIA-Show haben. Und DOOM III (bzw. die Engine) ist definitive ein Leistungfresser.

Was die Langfristigkeit angeht so sind das Bei GarKa im Moment maximal 2 Jahre. In diesem Zeitraum wird eine Spitzenkarte zur Lowendkarte.

Was die Standarisierung von OpenGL angeht so reicht diese leider für Games nicht aus. Es gibt keinen Standard für die Fragmentshader und deshalb ist es unumgänglich das eine OpenGL auf jeden Extensionsatz (ATi, NVidia, Matrox, SIS?, usw.) einzeln optimiert wird.

Architektur:
Im Moment spielt die Architecktur keine alzu große Rolle im Bezug auf die Langlebigkeit sondern nur die Leistung und dort liegen die Grossen fast gleichauf. Ergo wird Matrox wenn sie auch weiter mithalten wollen in spätestens 12 Monaten einen Chip mit einer PS 2.0 einheit nachsieben müssen.

Was den P10 angeht so ist die Architektur zukunftsicher der Chip selbst aber nicht. Denn auch 3dlabs muss den Leistungsoutput steigern und eine PS 2.0 Einheit einbauen wenn sie mithaten wollen. Wobei die reine P10 Architektur es erlaubt sich auf die Optimierung des Chips (Signalwege usw) zu konzentrieren. Die anderen Hersteller müssen in die Chiparchitektur die neuen Features einbauen was 3dlabs über Software macht. Ein eindeutiger Vorteil für 3DLabs. Aber zumindestens NVidia plant ja auch schon seit längerem einen Chip mit der gleichen Flexibilität und Ati wird da nicht nachstehen wollen.

Was den Kyro angeht so ist das Design des Kyro III ja angeblich fertig es muss eben nur noch jemand lizenzsieren. Man hat dort aber bereits ein neues betätigungsfeld gefunden bis es auf dem PC-Markt für sie wieder etwas zu holen gibt. Man enwickelt jetzt 3dcores für Handys und Handheld Systeme.

Matrox wird sicher seine Märkte finden und die größe ist dabei nicht mal so entscheident da Matrox eine Privatfirma ist die nicht den Druck der Aktionären ausgesetzt ist. Im Endeffekt müssen nur die Entwicklungskosten eben wieder reinkommen (was sicher zu schaffen ist) und dann wird ohne grosses Risiko mit den Karten wieder Gewinn gemacht.

der_guru
2002-06-03, 23:17:07
Das man den Performance Output ständig und stets erhöhen muss ist klar. Was mir dabei immer im Hinterkopf herumschwirt ist doch die Art und Weise wie man die Performance erhöht.
Man nehme NVidia, meißt konzetrieren die sich auf immer höhere Takte des Chips und des Rams und dadurch ist der Preis auch mit 500,- Euro für ne G4Ti4600 so hoch.
Das selbe ist auch eine andere Art und weise bei Matrox so obwohl die nicht unbedingt die höhsten taktraten einsetzten.

Der neue Chip von Matrox ist irgendwie für mich zu spät dran da ich nicht glaube das Matroxs neuer Chip eine GF4 wirklich übertrupfen kann und matrox hat ja auch schon lange das Problem mit OpenGL. Ich denke da zurück an den G400 Chip.

Um nochmal auf OpenGL zurück zu kommen.
Was wird sich den bei OpenGL 2.0 so alles tun?

cu der_guru

der_guru
2002-06-03, 23:27:58
Nochmal zu Architektur vs. Performance.

Worauf ich damit hinauswollte bzw. will ist das es durch eine gute Architektur leichter möglich ist die Performance zu erhöhen und da hat 3DLabs die allerbesten karten wenn sie es schaffen das Karten mit den Chip/Chips halbwegs erschwinglich werden.
Und 3DLabs hat eben den Vorteil das die unterstützten features über die Treiber reinkommen und nicht komplett über die Hardware.

Und das NVidia auch an sowas arbeitet kann gut sein aber ich denke das 3DLabs hier die führungsrolle übernehmen wird, zumindest vorerst.

cu der_guru

Demirug
2002-06-03, 23:34:16
Originally posted by der_guru
Das man den Performance Output ständig und stets erhöhen muss ist klar. Was mir dabei immer im Hinterkopf herumschwirt ist doch die Art und Weise wie man die Performance erhöht.
Man nehme NVidia, meißt konzetrieren die sich auf immer höhere Takte des Chips und des Rams und dadurch ist der Preis auch mit 500,- Euro für ne G4Ti4600 so hoch.
Das selbe ist auch eine andere Art und weise bei Matrox so obwohl die nicht unbedingt die höhsten taktraten einsetzten.


Wie soll man den Output den sonst erhöhen. Es gibt nur 3 wege die Performance zu steigern:

1. Mehr Takt
2. Mehr Transitoren
3. Bandbreite erhöhen (mehr Leitungen) (führt aber zwangsläufig auch zu 2)

Alle 3 Punkt machen die Karten teurer wobei das reinen Erhöhen des Taktes (Chip) erst mal nichts kostet aber aufgrund der internen Signalwege ein Limit hat. Beim Speichertakt braucht man zwar schnellere Rams diese erfordert aber keine änderung am Board. Die günstigste Lösung ist im Regelfall die Lösung die mit den wenigsten Signalleitugen auskommt.

Selbst bei einem TBR gibt es keine anderen Möglichkeiten den Output zu erhöhen. Dieser setzt eben nur auf einem kleineren Baselevel was die Bandbreite angeht auf.


Der neue Chip von Matrox ist irgendwie für mich zu spät dran da ich nicht glaube das Matroxs neuer Chip eine GF4 wirklich übertrupfen kann und matrox hat ja auch schon lange das Problem mit OpenGL. Ich denke da zurück an den G400 Chip.


Mit der GF4 kann er es aufgrund der Papierform aufnehmen. Allerdings werden die Gegner ja eher NV30 und R300 sind.


Um nochmal auf OpenGL zurück zu kommen.
Was wird sich den bei OpenGL 2.0 so alles tun?

cu der_guru

Auch da ändert sich soviel das ich das gar nicht alles aufzählen kann. Bei 3DLabs gibt es die vorläufige Spec. OpenGL wird vom Umfang her auf DX9 Level gebracht. In manchen Punkte etwas mehr in anderen etwas weniger.

Demirug
2002-06-03, 23:42:19
Originally posted by der_guru
Nochmal zu Architektur vs. Performance.

Worauf ich damit hinauswollte bzw. will ist das es durch eine gute Architektur leichter möglich ist die Performance zu erhöhen und da hat 3DLabs die allerbesten karten wenn sie es schaffen das Karten mit den Chip/Chips halbwegs erschwinglich werden.
Und 3DLabs hat eben den Vorteil das die unterstützten features über die Treiber reinkommen und nicht komplett über die Hardware.


Auch beim P10 hat 3dlabs eigentlich keine anderen möglichkeiten seine ausgangsleistung zu erhöhen als die bereits erwähnten. Man kann natürlich dort nachträglich noch mehr über die Treiber machen aber auch andere Hersteller (NVidia, Ati) erhöhen durch neue Treiber die Leistung.

Was die reine Leistung pro Transitor und Mhz angeht ist der P10 aufgrund seiner Flexibilität sogar eher im Nachteil. Da eine spezialisierte Hardware eine allgemeine in der Leistungsbetrachtung domminieren kann. Dafür kann sie aber dann auch nur das was eben vorgesehen ist und sonst nichts.


Und das NVidia auch an sowas arbeitet kann gut sein aber ich denke das 3DLabs hier die führungsrolle übernehmen wird, zumindest vorerst.

cu der_guru

Die technologische führungsrolle ist aber wertlos wenn man es nicht schaft diese in Verkaufszahlen umzusetzten.

Unregistered
2002-06-03, 23:59:05
Originally posted by Demirug
OpenGL wird vom Umfang her auf DX9 Level gebracht. In manchen Punkte etwas mehr in anderen etwas weniger. Das hat jetzt nichts so direkt mit der Parhelia zu tun, aber trotzdem eine Frage:
Wie es momentan aussieht, wird DX9 (Herbst 2002) einige Monate vor OGL 2.0 (Frühling 2003) veröffentlicht werden; werden Karten, die DX9-kompatibel sind, später durch Treiber OGL2.0-kompatibel gemacht werden können?
Für die Parhelia gilt die DX9-kompatibilität ja ohnehin nur eingeschränkt, aber der R300 soll DX9-kompatibel sein und einige Monate vor OGL2.0 erscheinen.
Mir geht es hier bei aller Schnelllebigkeit der Graka-Marktes um die Zukunftssicherheit von DX9-Chips.
NV30 wird vermutlich erst nach Veröffentlichung von OGL2.0 erscheinen, aber wenn er früher kommen sollte, bestünde die gleiche Frage der Zukunftssicherheit.

Demirug
2002-06-04, 00:10:42
Originally posted by Unregistered
Das hat jetzt nichts so direkt mit der Parhelia zu tun, aber trotzdem eine Frage:
Wie es momentan aussieht, wird DX9 (Herbst 2002) einige Monate vor OGL 2.0 (Frühling 2003) veröffentlicht werden; werden Karten, die DX9-kompatibel sind, später durch Treiber OGL2.0-kompatibel gemacht werden können?
Für die Parhelia gilt die DX9-kompatibilität ja ohnehin nur eingeschränkt, aber der R300 soll DX9-kompatibel sein und einige Monate vor OGL2.0 erscheinen.
Mir geht es hier bei aller Schnelllebigkeit der Graka-Marktes um die Zukunftssicherheit von DX9-Chips.
NV30 wird vermutlich erst nach Veröffentlichung von OGL2.0 erscheinen, aber wenn er früher kommen sollte, bestünde die gleiche Frage der Zukunftssicherheit.

Das ist schwer zu sagen. 3dLabs selbst geht davon aus das eine DX9 Karte (vs 2.0 und ps 2.0) auch OpenGl 2.0 fähig sein müsste. Genaues kann man aber wohl erst sagen wenn sowohl der Standard engültig ist und die Chips verfügbar.

Aber gerade weil der Graka-Markt schnelllebig ist das neue Featureset (und damit die unterstützen APIs) doch sowieso zweitrangig. Bis die ersten OpenGL 2.0 only Spiele kommen vergehen sowieso noch minmal 2 eher 3 Jahre nach der verabschiedung des Standard. Die meisten Gamer haben bis dorthin sowieso eine neue Karte. Die wichtigeste OpenGL Engine (DOOM III) wird auf jedenfall den NV30 und R300 unterstützen und mit hoher wahrscheinlichkeit wird es auch einen optimierten Renderpfad für diese beiden Chips geben.

askibo
2002-06-04, 00:10:53
Hab was interessantes im beyond3d-Forum gefunden
http://www.beyond3d.com/forum/viewtopic.php?t=1158


Sent an email to Matrox for almost two weeks ago asking about Parhelia's OpenGL support, finally got a reply today. They will support OpenGL 1.3, unfortunately, there's currently no plans to expose displacement mapping in OpenGL
The good news is that they will support vertex and fragment shaders through GL_EXT_vertex_shader and their own GL_MTX_fragment_shader extension.

I asked for a list of supported extensions, which they kindly provided me with. This is "most of the supported extensions", indicating there may be more, like the WGL extensions.

GL_ARB_multitexture
GL_ARB_point_parameters
GL_ARB_texture_compression
GL_ARB_texture_cube_map
GL_ARB_texture_env_add
GL_ARB_texture_env_combine
GL_ARB_texture_env_dot3
GL_ARB_transpose_matrix
GL_ATI_element_array
GL_ATI_vertex_array_object
GL_EXT_bgra
GL_EXT_blend_color
GL_EXT_blend_func_separate
GL_EXT_blend_logic_op
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_clip_volume_hint
GL_EXT_compiled_vertex_array
GL_EXT_draw_range_elements
GL_EXT_element_array
GL_EXT_fog_coord
GL_EXT_multi_draw_arrays
GL_EXT_packed_pixels
GL_EXT_point_parameters
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_separate_specular_color
GL_EXT_stencil_wrap
GL_EXT_subtexture
GL_EXT_texture3D
GL_EXT_texture_compression_s3tc
GL_EXT_texture_cube_map
GL_EXT_texture_edge_clamp
GL_EXT_texture_env_add
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_lod_bias
GL_EXT_vertex_array
GL_EXT_vertex_array_object
GL_EXT_vertex_shader
GL_EXT_texture_env_combine
GL_EXT_texture_env_dot3
GL_KTX_buffer_region
GL_MTX_fragment_shader
GL_NV_texgen_reflection
GL_SGIS_multitexture
GL_SGIS_texture_lod


Besides the lack of displacement mapping the OpenGL driver seams quite capable, lot more so than the G400 OpenGL drivers were in the light of what the hardware could do.

Highlights:
GL_ATI_element_array+ GL_ATI_vertex_array_object, very nice! They are going EXT now.
GL_EXT_blend_func_separate, joining the R8500 on supporting this extension. It's very useful, but not widely supported.
GL_MTX_fragment_shader, it's going to very interesting to see how capable this extension is.

Demirug
2002-06-04, 00:15:56
@askibo:

Sehr interessant. Das es eine GL_MTX_fragment_shader Extension gibt bestätigt das man in DOOM III einen spezielen Renderpfad brauchen wird um die volle Qualität auf einem Parhelia Chip zu erreich.

ow
2002-06-04, 09:05:33
Ich vermisse da irgendwie die

GL_ARB_texture_env_embm
GL_EXT_texture_env_embm


kein EMBM bei Matrox mehr?

Unregistered
2002-06-04, 09:32:06
bald wissen wir mehr!
die ersten karten sind bei den reviewern angekommen!
siehe http://www.athlonxp.com

zeckensack
2002-06-04, 10:05:25
Originally posted by ow
Ich vermisse da irgendwie die

GL_ARB_texture_env_embm
GL_EXT_texture_env_embm


kein EMBM bei Matrox mehr? Geht wahrscheinlich nur noch über Pixel Shader.
BTW die einzige mir bekannte EMBM-Extension gibt's bei ATI (ATI_envmap_bumpmap). Eine Herstellerübergreifende Version ist mir bisher entgangen ...

http://oss.sgi.com/projects/ogl-sample/registry/

/edit: Soll heißen, auch bei der G400 war EMBM unter OpenGL nicht nutzbar.

MadManniMan
2002-06-04, 12:56:15
begriffsklärung: Fragmentshader?

zeckensack
2002-06-04, 13:17:49
Originally posted by MadManniMan
begriffsklärung: Fragmentshader? Fragment ~= Pixel.
Fragment Shader ist die unter OpenGL-Menschen geläufige Bezeichnung für Pixel Shader.

Der Unterschied ist ein kleiner, aber feiner:
Pixel kommen am Monitor an. Fragments kommen aus der Rendereinheit raus. Das ist spätestens dann nicht mehr das gleiche, wenn AA ins Spiel kommt.

StefanV
2002-06-05, 00:48:20
GL_ATI_vertex_array_object

^heißt das, daß die Parhelia Truform kann??

Demirug
2002-06-05, 00:56:08
Originally posted by Stefan Payne
GL_ATI_vertex_array_object

^heißt das, daß die Parhelia Truform kann??

Diese Extension ist das OpenGL gegenstück für statische VertexBuffer hat also nichts mit Truform zu tuen.

TruForm (N-Patches) ist eine sache die in der Tessellationseinheit erledigt werden muss. Das bedeutet das der Chip im Prinzip in der Lage dazu sein sollte. Das ganze ist aber eigentlich egal da N-Patches sich wohl nicht durchsetzen werden.

ow
2002-06-05, 09:32:55
Originally posted by zeckensack
Geht wahrscheinlich nur noch über Pixel Shader.
BTW die einzige mir bekannte EMBM-Extension gibt's bei ATI (ATI_envmap_bumpmap). Eine Herstellerübergreifende Version ist mir bisher entgangen ...

http://oss.sgi.com/projects/ogl-sample/registry/

/edit: Soll heißen, auch bei der G400 war EMBM unter OpenGL nicht nutzbar.


Muss mich wohl geirrt haben, gibt anscheinend keine Extension fuer EMBM.


btw. wenn ein Chip eine Extension in der GL_ARB 'Form' unterstuetzt, sollte er dann nicht auch die GL_EXT 'Form" nutzen koennen?

Der Kyro unterstuezt zB. nur GL_ARB_texture_env_dot3 nicht aber GL_EXT_texture_env_dot3

HOT
2002-06-05, 09:38:58
Originally posted by Demirug


Diese Extension ist das OpenGL gegenstück für statische VertexBuffer hat also nichts mit Truform zu tuen.

TruForm (N-Patches) ist eine sache die in der Tessellationseinheit erledigt werden muss. Das bedeutet das der Chip im Prinzip in der Lage dazu sein sollte. Das ganze ist aber eigentlich egal da N-Patches sich wohl nicht durchsetzen werden.

Da wär ich vorsichtig. Es kommt darauf an, welche Chips dieses Feature noch beherrschen. Es sind jetzt immerhin schon 2 davon.

ow
2002-06-05, 09:46:03
???

Wer ausser ATi nutzt den sonst noch truform?

Demirug
2002-06-05, 10:08:11
Originally posted by ow
???

Wer ausser ATi nutzt den sonst noch truform?

Niemand da Truform der ATi Marketing name für N-Patch ist. Ob der Tessellator von Matrox es kann wird man erst sehen wenn die entsprechenden Karten und Treiber verfügbar sind.

Aber die N-Patch Technik ist in der Praxsis sowieso einfach unbrauchbar. Es gibt für mich 2 KO Punkte die gegen den Einsatz von N-Patches sprechen:

1. 3d-Modelle mit harten und weichen Kanten neigen dazu bei N-Patch Process Löcher oder überschneidungen zu bekommen.

2. N-Patch und Bumpmapping vertragen sich nicht richtig.

TBird
2002-06-05, 11:34:16
Originally posted by Demirug

Diese Extension ist das OpenGL gegenstück für statische VertexBuffer...

...und auch dynamische VertexBuffer.

Demirug
2002-06-05, 11:41:09
@TBird:

Danke für die Ergänzung. Also sagen wird einfach:

GL_ATI_vertex_array_object ist OpenGL Extension für VertexBuffer von ATi.

MadManniMan
2002-06-05, 15:21:31
thx @ zecke für the aufklärung

@alle:

ja wie denn nun? kein EMBM unter opengl? oder einfach unter den fragment shadern zusammengefaßt?

ow
2002-06-05, 16:51:04
EMBM als Shaderfunktion aber nicht als 'einfaches' Texturmapping. SO habe ich das verstanden.

Doomtrain
2002-06-05, 21:11:07
Originally posted by ow
EMBM als Shaderfunktion aber nicht als 'einfaches' Texturmapping. SO habe ich das verstanden.

Ist ja eigentlich egal. Gibt es denn eine standardisierte Bumpmapping Extension für OpenGL?

ow
2002-06-05, 21:45:56
Nein, scheinbar nicht.

Doomtrain
2002-06-05, 22:05:09
Originally posted by ow
Nein, scheinbar nicht.

Das ist schlecht. Ich hoffe, GL 2.0 merzt diese Fehler aus.

Unregistered
2002-06-13, 16:44:04
Also, das hab ich heute beim stöbern im Netz gefunden:

------------------------
Lastly, Several hardware sites recieved their review board this week. the NDA totally lifts on the 14th. by Friday we will all see the current product. Thats Why i said round one in the title.
------------------------

Angeblich sehen wir also morgen erste parhelia tests!!!!??!!

mirage
2002-06-13, 19:48:43
Na da bin ich wirklich gespannt, ob der Parhelia wirklich so gut ist, wie er auf dem Datenblatt ausschaut, aber noch interessanter wird wohl der Preis sein. :cowboy:

askibo
2002-06-13, 20:05:42
ein amerik. PC Mag hat erste Benchmarks einer Parhelia Betakarte


Straight from MaximumPC, benchmarks of a beta PArhelia.The system consisted of a P4 2Ghz w/ 512 Megs Ram. They ran the Quake III Benches at 1280x1024 @ 32 bit color, 3DMark 2001 was at 1024x768@32 bit color.


No AA, No anisotropic filtering
Quake 3: 72.1fps
3dmark 2001 SE Game2 High Detail : 56.3 fps
3dmark 2001 SE Game4: 21.1 fps
3DMark 2001 SE Default Score: 7698

16x AA, no anisotropic filtering
Quake 3: Would Not Run
3dmark 2001 SE Game2 High Detail : 47.7 fps
3dmark 2001 SE Game4: 15.0 fps
3DMark 2001 SE Default Score: 6089

No AA, anisotropic filtering On
Quake 3: 56.6fps
3dmark 2001 SE Game2 High Detail : 45.5 fps
3dmark 2001 SE Game4: 10.98 fps
3DMark 2001 SE Default Score: 6526

16x AA, anisotropic filtering On
Quake 3: Would Not Run
3dmark 2001 SE Game2 High Detail : 40.1 fps
3dmark 2001 SE Game4: 8.9 fps
3DMark 2001 SE Default Score: 5241


Schaut ja bis auf die 16xAA Werte nicht so berauschend aus. Aber ist wie gesagt ein Betaboard mit Betatreibern.

aths
2002-06-13, 20:37:11
Die Werte sehen nicht sonderlich gut aus. Da muss Matrox noch nachlegen.