Diskussion zum Artikel "Grafikchip-Ausblick 2003"

[Leonidas]

Hier ist der Link. (http://www.3dcenter.org/artikel/2003/01-05_a.php)


Bin gespannt, was sich eventuell noch an neuen Informationen oder Gerüchten einfindet.




/edit 5. Januar 2003, 19:10
Xabre 2 hat 8 Rendering-Pipelines, hinzugefügt

/edit 6. Januar 2003, 18:51
PowerVR Series 5 wird definitiv DirectX9, ergänzt

/edit 7. Januar 2003, 16:25
Infos zum Columbia 2 hinzugefügt

/edit 8. Januar 2003, 23:30
neue Infos zum DeltaChrome hinzugefügt

/edit 10. Januar 2003: 00:55
englische Version hinzugefügt

/edit 10. Januar 2003: 00:58
Update zum Update beim S3-Chip: Der Pixel Shader ist zwar 2.0+, aber nicht besser als jener der R9700Pro

[Tigershark]

Schöner Artikel Leo ;)

Aber im Fazit hat sich der Fehlerteufel eingeschlichen, da hast Du nämlich einmal "RV350 gg GFFX" und einmal "RV350 gg NV31" geschrieben - da meintest Du sicherlich in ersterem R350, oder ?

Ansonsten, Daumen hoch wie immer, und meine nexte GraKa wird nen PVR Chip haben ;)

[Thowe]

Originally posted by Tigershark
Schöner Artikel Leo ;)

Ansonsten, Daumen hoch wie immer, und meine nexte GraKa wird nen PVR Chip haben ;)

Na das will ich doch beides annehmen :D

Meine R9700 bleibt solange im Rechner, bis ich meine nächste PowerVR Karte habe, ok, oder doch das Reißen kriege und dennoch die FX reinschraube. Aber im Plan steht ganz oben der Athlon 64 und in diesen Rechner dann die PVR-S5.

[Leonidas]

Originally posted by Tigershark
Schöner Artikel Leo ;)

Aber im Fazit hat sich der Fehlerteufel eingeschlichen, da hast Du nämlich einmal "RV350 gg GFFX" und einmal "RV350 gg NV31" geschrieben - da meintest Du sicherlich in ersterem R350, oder ?



Jap. Gefixt.

[Unregistered]

Gibt es irgendeinen Grund, weshalb sowohl beim R350/RV350 als auch beim NV31 nicht eine 4 Piplines mit 2 Textureinheiten Architektur als Möglichkeit erwähnt worden ist. Halte ich im Moment für viel sinnvoller/wahrscheinlicher als die Spielerei mit der Taktfrequenz, die in der Übersicht quasi der alleinig bestimmende Faktor im Kampf um die "Preissegment-Krone" ist. DX7/8 OpenGL 1.x Spiele dürften davon jedenfalls noch gewaltig profitieren können.

UT2003 z.B. würde bei der R9700Pro selbst mit nur 325MHz Chiptakt mit 2 Textureinheiten pro Pipeline (sprich R350) bestimmt um einiges schneller werden? - Oder etwa nicht?

Ansonsten eine schöner Abriß!

[ow]

Originally posted by Unregistered
Gibt es irgendeinen Grund, weshalb sowohl beim R350/RV350 als auch beim NV31 nicht eine 4 Piplines mit 2 Textureinheiten Architektur als Möglichkeit erwähnt worden ist.

Der Grund ist, dass dies mit an Sicherheit grenzender Wahrscheinlichkeit nicht der Fall sein wird.;) Ausserdem ist 8x1 immer schneller als 4x2 bei sonst gleichem Chipaufbau.

[Leonidas]

Originally posted by Unregistered
Gibt es irgendeinen Grund, weshalb sowohl beim R350/RV350 als auch beim NV31 nicht eine 4 Piplines mit 2 Textureinheiten Architektur als Möglichkeit erwähnt worden ist. Halte ich im Moment für viel sinnvoller/wahrscheinlicher als die Spielerei mit der Taktfrequenz, die in der Übersicht quasi der alleinig bestimmende Faktor im Kampf um die "Preissegment-Krone" ist. DX7/8 OpenGL 1.x Spiele dürften davon jedenfalls noch gewaltig profitieren können.




Weil bei DX9 scheinbar mehr Textureneinheiten nix mehr bringt bzw. die herkömmlichen TMUs sowieso in dieser Form nicht mehr existieren. Zumindestens ist es bei nVidia auf jeden Fall so, deswegen finden sich bei keinem DX9-Chip Anmerkungen über die Textureneinheiten.

[Unregistered]

Originally posted by Leonidas




Weil bei DX9 scheinbar mehr Textureneinheiten nix mehr bringt bzw. die herkömmlichen TMUs sowieso in dieser Form nicht mehr existieren. Zumindestens ist es bei nVidia auf jeden Fall so, deswegen finden sich bei keinem DX9-Chip Anmerkungen über die Textureneinheiten.

Mmmmhh - Stimmt schon, was du zu den DX9-Chips sagst:

Die Register Combiner aus DX7 (fest in TMUs verdrahtete Texture-/Colour-Ops) sind bei DX8-Chips denn konfigurierbaren Register Combiner TMUs gewichen. Alles weiterhin mit mehr oder weniger Bits (je nach Chip) auf Ganzzahl-Basis. PS1.x Befehle sind quasi durch die / nach den Befehlen konfigurierten Register Combiner(TMUs) "abgearbeitet" worden.

PS2.0 Befehlssequenzen auf einem R300 oder einer GFFX, werden hingegen in einer höchst-flexibelen "Execution-Unit" abgearbeitet, die in ihrem Aufbau vermutlich nichts mit den Register Combiner Units (TMUs) auf DX7/8 Chips zu tun hat. Mit dem R300/GFFX sind nun (fast) beliebige Texture-/Colour-Ops möglich!

Hier nochmal die Frage in anderer Darstellung:
Die max. 16 Texturen pro Rendering-Pass in DX9 können mit dem R300/GFFX nicht mehr wie noch bei DX8-Chips auf die vorhandene TMUs aufgeteilt werden, aber dennoch laufen die 3DMark2001SE Pixelshader Tests (z.B."Nature") auf einem R300 viel schneller als auf einer GF4600 ab.
Weshalb? Wohl nicht wegen der Taktfrequenz! Vielleicht hat der R300 zwecks DX-Abwärtskompatibilität Register Combiner(TMUs) an Bord, oder vermag er die DX8-TMUs und deren Colourblending-/Texture-Ops viel schneller durch superskalare Befehlsabarbeitung in seinem Pixelprozessor zu simulieren? Oder irgendetwas anderes läuft deutlich schneller ab? -> Ich habe leider keine Ahnung, aber:

Nur werden eben ausschließlich DX7/8 Spiele im nächsten Jahr vermessen werden. Sieht man mal vom "3DMark 2002(3)) ab, wären Verbesserungen der Progammierbarkeit hin zu GFFX Niveau einfach nicht lohnenswert/überflüssig, denn DX9-Kompatibel ist man ja schon und anfängliche DX9-Spiele werden wohl PS2.0/VS2.0 nutzen.

Ich glaube eher, daß der R350 mit seinen 8 Pixelprozessoren und der RV350 mit seinen vermutlich 4 Pixelprozessoren eine gesteigerte Verarbeitungsleistung pro Takt haben werden, was mehr TMUs in DX8 entsprechen würde. Die Pixelprozessoren werden eben optimiert. Ähnliches gilt eventuell auch für den NV31/34 und ganz sicher für den NV35.

Gruß,
Tom

[Lost Prophet]

congratz auch von mir, der artikel is toll

nur man weiß wie wackelig specs und vor allem termine sind

dieser markt ist so schnelllebig, das ein vorhersage praktisch unmöglich ist, dh aus dem vorhanden material hast du sicher das beste gemacht

was ich erwarte, das ATI und NV sich wüst bekriegen werden und keiner der anderen ernsthaft in der lage ist in den markt einzusteigen (ausser es gelingt ein absoluter hammer was ich höchstens PowerVR zu traue)




Noch ein kleiner vorschlag meinerseits

wie wärs wenn du aus diesem Artikel eine are STICKY unter den artikeln machst den du all-wöchentlich (-monatlich, -? ? ?) aktualisierst

so in der art wies jetzt is, wenns noch nicht erschienen ist, dann werden specs nachgereicht, dann kommt

ERSCHIENEN mit links auf benchmarks oder eigene artikel (da sonst wahrscheinl die übersichtlichkeit flöten geht wenn man auch benchmarks in den artikel einfließen lässt)

ich denk du verstehst was ich meine, die frage is nur ob du genug zeit findest das zu realisieren, war ja auch nur ein vorschlag


cya axel

[Endorphine]

Originally posted by Purple_Stain
wie wärs wenn du aus diesem Artikel eine are STICKY unter den artikeln machst den du all-wöchentlich (-monatlich, -? ? ?) aktualisierst

Leonidas ist sicher schon gut ausgelastet mit seinen sonstigen Aufgaben, wenn er zwei Seiten zu betreuen hat (!). Warum meldest du dich nicht gleich als Freiwilliger, das vorgeschlagene Projekt zu übernehmen und zu pflegen? :)

[Lost Prophet]

würd ich machen, 4 gründe warum ich nicht der beste dafür bin

ich hab nicht viel erfahrung mit html (nich so das problem) aber noch viel weniger zeit (die 2 seiten sind immerhin leo's job)

ich kenn mich zwar etwas aus im 3d geschäft aber um news zu schreiben reichts dann wohl doch nicht

ich hab keine ahnung wo ich suchen sollte links etc ( obwohl forum könnte helfen siehe unten)

aber noch viel wichtiger: ich bin ab sommer ein jahr weg, dh nicht verfügbar.



wie wär wenn das so eine art workgroup aus dem forum macht?
wär auch bereit mich an so was zu beteiligen aber solo schauts imho nicht so gut aus

oder leo machts einfach mal dann und wann wenn news technisch flaute herrscht.

das war ein vorschlag der mir grad so eingefallen is, mal sehn was draus wird

cya axel

[Unregistered]

hrm, wenn ich mir 2003 so ansehe, dann gibt es nur den FX und ansonsten Low-Costausführungen und gleiche Chips höher getaktet...schade...

[Pirx]

Originally posted by Leonidas
/edit 6. Januar 2003, 18:51
PowerVR Series 5 wird definitiv DirectX9, ergänzt
:jump1:


Originally posted by Thowe
... Aber im Plan steht ganz oben der Athlon 64 und in diesen Rechner dann die PVR-S5.

Das ist auch meine "Roadmap":) (bloss daß es bei mir bis dahin noch die K2 tun muß)

[Unregistered]

Originally posted by Unregistered
hrm, wenn ich mir 2003 so ansehe, dann gibt es nur den FX und ansonsten Low-Costausführungen und gleiche Chips höher getaktet...schade...

Und was ist mit dem R400 und dem NV35?
Beide werden wohl DX9 VS/PS 3.0 realisieren. Von anderen Verbesserungen auf Pixelebene wie AF und AA ganz schweigen.
Nee! Da kommt schon mehr auf uns zu im nächsten Jahr. :-)

Greets
T.

[Xmas]

Originally posted by Unregistered
Die Register Combiner aus DX7 (fest in TMUs verdrahtete Texture-/Colour-Ops) sind bei DX8-Chips denn konfigurierbaren Register Combiner TMUs gewichen. Alles weiterhin mit mehr oder weniger Bits (je nach Chip) auf Ganzzahl-Basis. PS1.x Befehle sind quasi durch die / nach den Befehlen konfigurierten Register Combiner(TMUs) "abgearbeitet" worden.

PS2.0 Befehlssequenzen auf einem R300 oder einer GFFX, werden hingegen in einer höchst-flexibelen "Execution-Unit" abgearbeitet, die in ihrem Aufbau vermutlich nichts mit den Register Combiner Units (TMUs) auf DX7/8 Chips zu tun hat. Mit dem R300/GFFX sind nun (fast) beliebige Texture-/Colour-Ops möglich!

Eine kleine Begriffsentknotung: Register Combiner sind keine TMUs. TMUs sind die Einheiten die Texturkoordinaten als Input und (gefilterte) Texel als Output haben. RCs sind Recheneinheiten, die mit Farbwerten arithmetische Operationen ausführen, generell in der Form (A + B) * C + D. Die PS2.0 ALUs sind da noch etwas flexibler.

[mirp]

Originally posted by Leonidas

/edit 6. Januar 2003, 18:51
PowerVR Series 5 wird definitiv DirectX9, ergänzt
Gibt es dazu auch eine Quellenangabe? In den News drückst du dich auch drumrum. ;-)

[Leonidas]

Originally posted by mirp
Gibt es dazu auch eine Quellenangabe? In den News drückst du dich auch drumrum. ;-)


Nö. Darf ich net sagen.

[MasterElwood]

Gibts eigentlich irgendwo eine Roadmap für zukünftige DirektX Versionen?

Die Dinger scheinen langsam immer weiter ausernander zuliegen...

[Rampage 2]

Originally posted by Thowe


Na das will ich doch beides annehmen :D

Meine R9700 bleibt solange im Rechner, bis ich meine nächste PowerVR Karte habe, ok, oder doch das Reißen kriege und dennoch die FX reinschraube. Aber im Plan steht ganz oben der Athlon 64 und in diesen Rechner dann die PVR-S5.

Sofern AMD noch zu Vernunft kommt und den TCPA-Wucher aus dem Pro-
zessor schraubt - ich werde mir jedenfalls kein TCPA-verseuchtes
System zusammenstellen:P - euch wünsche ich viel Spaß dabei:P

[Leonidas]

Originally posted by MasterElwood
Gibts eigentlich irgendwo eine Roadmap für zukünftige DirektX Versionen?


Nix dazu bekannt.

[Demirug]

Sowas wie eine DX Roadmap gibt es nicht weil MS ja nicht eigenmächtig planen kann/will. Man hat dort keine Lust Features einzubauen die am ende dann doch niemand unterstützt. Aus diesem Grund fragt MS immer bei den Herstellern an was sie gerne hätte und normt diese Dinge.

@Leonidas:

Die News von heute haben mich etwas verwirt

"Interessant sind die DirectX9-Fähigkeiten des DeltaChrome, den hier hebt sich dieser wider Erwarten vom DirectX9-Standard (Radeon 9700 Pro) ab und rangiert beim Vertex Shader auf der Höhe einer GeForceFX, beim Pixel Shader zwischen Radeon 9700 Pro und GeForceFX (DirectX9-Fähigkeiten von Radeon 9700 Pro und GeForceFX siehe hier). Die Bezeichnung "2.0+" für den DeltaChrome Vertex und Pixel Shader hat sich S3 somit also redlich verdient."

Hast du ein Dokument in dem steht welche Optionen der VS und PS 2.0+ unterstützt werden?

[Leonidas]

http://www.s3graphics.com/DeltaChromeDX9.html


Hab es nochmal innen Vergleich gestellt:
http://www.3dcenter.org/artikel/2002/12-19_c.php#dx9specs

[Demirug]

Danke. Da habe ich wohl das more übersehen.

Die "Instruction Slots" sind bei den Pixel Shadern auch noch eine wichtige Kenngrösse. Wenn es nicht zu viel arbeit ist könntest du die auch noch in die Tabelle einfügen.

EDIT: Die FX kann kein "Dynamic Flow Control" in den Pixelshadern.

Warum hast du bei " Instruction Predicates" Zahlen stehen? Das macht dort keinen Sinn weil das ein Feature ist das entweder vorhanden ist oder nicht.

[Leonidas]

Originally posted by Demirug
Danke. Da habe ich wohl das more übersehen.

Die "Instruction Slots" sind bei den Pixel Shadern auch noch eine wichtige Kenngrösse. Wenn es nicht zu viel arbeit ist könntest du die auch noch in die Tabelle einfügen.



Jap. Thx. Was kann GeForceFX dort?

[Leonidas]

Originally posted by Demirug

EDIT: Die FX kann kein "Dynamic Flow Control" in den Pixelshadern.



Laut den NV-Unterlagen zum GeForceFX-Start schon.

[Leonidas]

Originally posted by Demirug
Warum hast du bei " Instruction Predicates" Zahlen stehen? Das macht dort keinen Sinn weil das ein Feature ist das entweder vorhanden ist oder nicht.


Hat nVidia so angegeben.

[Demirug]

Originally posted by Leonidas



Jap. Thx. Was kann GeForceFX dort?

1024

[Demirug]

Originally posted by Leonidas



Laut den NV-Unterlagen zum GeForceFX-Start schon.

Gefunden

aber merkwürdig ist das trotzdem weil in den CineFX unterlagen steht nichts und die OpenGL Spec für den NV30 enthält gar keine Befehle für "Dynamic Flow Control" in den PixelShadern und dort steht auch:

"Condition code support
• But now branch & subroutine instructions"

[Demirug]

Originally posted by Leonidas



Hat nVidia so angegeben.

Sicher das du da nicht in der falschen Zeile gelandet bist?

In der Tabelle die ich kenne stehen die Zahlen welche in deiner Tabelle sind genau in der Zeile darüber.

[Unregistered]

Can someone please post an english translation of it? The google translation of it isn't very good.

Googled translation (Ãœbersetzung) -
Kann jemand eine englische Übersetzung von ihr bitte bekanntgeben? Die googleübersetzung von ihr ist nicht sehr gut.

[Leonidas]

Originally posted by Demirug


1024



Gleich den "maximale Farb Instruktionen"?

[Leonidas]

Originally posted by Demirug


Gefunden

aber merkwürdig ist das trotzdem weil in den CineFX unterlagen steht nichts und die OpenGL Spec für den NV30 enthält gar keine Befehle für "Dynamic Flow Control" in den PixelShadern und dort steht auch:

"Condition code support
• But now branch & subroutine instructions"



Hier muss ich mich einfach drauf verlassen, daß die NV-Unterlagen stimmen. Wenn Du was griffiges hast, was das widerlegt, ändere ich das natürlich. Thx 4 Hilfe.

[Leonidas]

Originally posted by Demirug


Sicher das du da nicht in der falschen Zeile gelandet bist?

In der Tabelle die ich kenne stehen die Zahlen welche in deiner Tabelle sind genau in der Zeile darüber.



Hast vollkommen recht:

http://images.anandtech.com/reviews/video/nvidia/geforcefx/preview/ps20.gif


Die "Instruction Predicates" sind schon in unserem GeForceFX-Artikel falsch, ist aber bisher niemanden aufgefallen. Gefixt.

[Demirug]

Originally posted by Leonidas




Gleich den "maximale Farb Instruktionen"?

Ja. Beim NV30 hat man 1024 Instruction Slots die man ganz nach belieben verwenden darf. Also bis zu 1024 Mathops + bis zu 1024 Texturops aber zusammen höchstens 1024. Beim NV30 muss man sich also nicht so sehr darum kümmern weil Math und Texturops gleichwertig sind. Deswegen habe ich ja auch darum gebeten diese Angabe aufzunehmen weil man sonst auf die Idee kommen könnte das der NV30 1024 Math + 1024 Texturops = 2048 Instructions pro Pixelshader könnte.

[Demirug]

Originally posted by Leonidas




Hier muss ich mich einfach drauf verlassen, daß die NV-Unterlagen stimmen. Wenn Du was griffiges hast, was das widerlegt, ändere ich das natürlich. Thx 4 Hilfe.

Ich kann dir ein paar stellen in anderen NVIDIA Dokumenten zum NV30 (bzw CineFX, NV3x) nennen wo direkt oder indirkt "No Branching" steht. Aber entgültig werden wir das wohl erst wissen wenn jemand eine NV30 Karte hat um die Caps auszulesen.

[Unregistered]

Originally posted by Leonidas




Hier muss ich mich einfach drauf verlassen, daß die NV-Unterlagen stimmen. Wenn Du was griffiges hast, was das widerlegt, ändere ich das natürlich. Thx 4 Hilfe.

guckste bei Beyond3d. Die haben einen sehr umfangreichen Artikel dazu. In dem Artikel wird auch die R300 richtig beurteilt, und nicht so schlecht, wie in den NV30-Werbeunterlagen.

Die Flow Control kann die NV30 nur in den Vertex-Shadern.

[zeckensack]

Originally posted by Unregistered
Can someone please post an english translation of it? The google translation of it isn't very good.Hmmm ... the Inq (http://www.theinquirer.net/?article=7105) finally noticed :D

Maybe we can work something out ...

@Leo:
Darf ich? =)

[Leonidas]

Originally posted by zeckensack


@Leo:
Darf ich? =)


Jederzeit. Viel Spass mit meinem deutsch.

[Leonidas]

Originally posted by Unregistered


guckste bei Beyond3d. Die haben einen sehr umfangreichen Artikel dazu. In dem Artikel wird auch die R300 richtig beurteilt, und nicht so schlecht, wie in den NV30-Werbeunterlagen.

Die Flow Control kann die NV30 nur in den Vertex-Shadern.



Ich nehme es jetzt mal raus, zur Sicherheit.

[Leonidas]

Originally posted by Unregistered
Can someone please post an english translation of it? The google translation of it isn't very good.




Sorry, I have no time for translations.

[nggalai]

Originally posted by Leonidas



Sorry, I have no time for translations. Z-Bag is working on it, mind. So don't fret, English version is on the way. ;)

ta,
-Sascha.rb

[zeckensack]

They call me the lean mean translation machine :naughty:

[nggalai]

translate MY ass, baby. :D

ta,
-Sascha.rb

[Leonidas]

Originally posted by Unregistered
Can someone please post an english translation of it? The google translation of it isn't very good.

Googled translation (Ãœbersetzung) -
Kann jemand eine englische Übersetzung von ihr bitte bekanntgeben? Die googleübersetzung von ihr ist nicht sehr gut.



New english translation by zeckensack and nggalai (THX!!!) (http://www.3dcenter.org/artikel/2003/01-05_a_english.php)