28.04.2024, 04:56
Sprache ändern
Registrieren
Anmelden
Sie sind nicht angemeldet.
Lieber Besucher, herzlich willkommen bei: Aqua Computer Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.
Re: Schlechte CS-Grafik unter Radeon 9700 Pro(Pix)
Donnerstag, 9. Januar 2003, 11:35
Zitat von »Man_In_Blue«
@ EpS
Wie du exkrementirst und womit ist mir gleich.
Ich kann es einfach nur ned ab wenn jemand unbegründeten Schwachfung über einen solch Renomirten und guten Hersteller wie ati schreibt!!
Und das ich mich jetzt hier ned weiter äußern will hat nix damit zu tun das mir di Argumente ausgehen oder weil ich "den Schwanz einzihe" sondern weil ich ned will das ich oder sonst wer hier aus dem Forum fliegt!
Hiermit nominiere ich die Wortkreation "exkrementirst" zur Wortschöpfung des Jahres !
Übrigens ist Eure Debatte so sinnlos wie ein Kropf !
Gruß Finest
Re: Schlechte CS-Grafik unter Radeon 9700 Pro(Pix)
Donnerstag, 9. Januar 2003, 18:33
Bandbreite, und das sollte man wissen, ist heutzutage nicht mehr alles, sondern vielmehr was man daraus macht. Wenn du zu große Blöcke gleichzeitig adressiert bzw. es nur effizient ist große Blöcke aus dem Speicher zu lesen, so wirkt sich das sehr auf den eigentlichen Durchsatz aus, da der Speicher auch ausgenutzt werden muss. Und bei heutigen Architekturen kann man da im Durchschnitt von knapp 40% sprechen, wenn nicht noch weniger. Wer ein gutes Speicherinterface entworfen hat waren die finnischen BitBoys, leider ist es um die ja auch etwas still geworden. Im Endeffekt ist sowieso irgendwann Schluß mit noch mehr Takt, das halten die Platinen auch gar nicht aus und dann bleiben zwei Möglichkeiten. Das was man hat besser ausnutzen oder den Speicher in den Core miteinbinden, aber das ist natürlich auch wieder eine sehr fragliche Lösung. Oder man steigt auf andere Materialien um, aber was bietet sich da denn schon marktreifes an?
Hyper Z 3 rulez! OK die neue Technick vom GFFX scheint besser zu sein ABER wenn man mal vegleicht 16 GB/Sek (GFFX) vs. ~30 GB/sek (R9900Pro) dann scheint her masse vor klasse zu liegen
Hmm, korrigier mich wenns nicht stimmt, aber hat der R300 nicht 4 Pipelines mit je 2 TMUs ? Was willst du denn erweitern? Die Pipelines oder die TMUs pro Pipeline?
Ne 8 Pixelpipelines mit je einer TMU. Einzige ausname ist der R9500 mit nur 4 Pipelines...
Man wird sehen, aber wie schon oben angesprochen, die Speicher kommen so langsam an ihre Grenzen. Habe gehört, dass das neue DDR2 RAM recht heiß im Vergleich zu normlane RAM werden soll, und noch mehr Kühlung... Naja, ich weiß nicht so recht, das sollten sich die Leute wirklich mal was anderes überlegen, wie sie die Datenflut bewältigen können. Für die Zukunft (auch ohne TCPA und Palladium
Schon mal was vom "G-DDR3" gehört? Wenn ned sollteste dich da mal schlau machen... Ich weiß auch ned sooooooo viel dadrücber aber der R400 wird mit solchen Ram zusammenarbeiten und endsprechende Plantinen mit ihm bestückt werden... damit sollen neue geschwindichkeitsrekorde aufgestellt werden... aber frag mich jetzt ned wo da die besonderheit liegt...
Hmm, ich glaube in diesem neuen Artikel von 3DC stand etwas über die übernächste Generation von nVidia drinne, kann mich aber auch irren. Jedenfalls denke ich nicht, dass die schon so wild darauf sind, Gerüchte über die übernächste Karte zu verbreiten, wenn nicht einmal die nächste schon draußen ist. Und mit der überarbeiteten NV30 wirste wohl recht behalten, da die Entwicklungszeit bis dahin für eine komplett neue Architektur einfach zu kurz ist und das sich rein kostentechnisch auch nicht rentiert.
Allerdings wissen wir jetzt auch noch überhaupt nichts über den R400 und ich würde mir nicht so sicher sein, dass dieser so einen gewaltigen Leistunssprung zu machen vermag. ATi hat bis jetzt ja ihre Chips immer mit einer neuen DX Version zusammen präsentiert, allerdings (und das stand auch in dem 3DC Artikel) wird bis dann noch keine neue Version fertig sein und es wird wohl nur darum gehen, mehr RAW-Power in den Core zu bekommen, oder sich einem renderzeitsparenden Algo zu bedienen, wie es ja der Kyro bzw. Kyro2 auch getan hat. Ich bin gespannt darauf, was sich die Hersteller noch alles einfallen lassen, aber lasst es euch gesagt sein, irgendwann wird die Entwicklung so schwierig werden (TSMC hat ja jetzt schon Probleme mit ihren Herstellungsverfahren, das wird sich noch häufen), dass sich die Produktionszyklen wieder verlängern, da man durch bloßes Transistorenbooster net mehr weit kommt
aLso nen bissel weiß ich shcon über den R400... er wird halt sehr in richtung kühl und genügsam gehen... also ned mehr so viel Saft futtern und dank 13µ auch ned mehr so heiß werden... OK 13µ sind keine GaRa für einen Kühlen Chip (siehe GFFX) aber ich denke schon das die das hin bekommen... zudem soll ein neuartiger Speicher eingesetzt werden... (og. G-DDR3 Rams...) in sachen Technick wird wohl erstmald as vorhandene überarbeitet und verbessert... zudem kann ATi bestimmte Features auch unabhängig von der API einbinden wie zB TrueForm, AA und AF... (ja weiß sind allesammt ned wirklich unabhängig aber du weißt schon was ich meine ;D
)
hmm
Donnerstag, 9. Januar 2003, 22:29
Also ich weiß net, aber das hier hört sich irgendwie anders an ???
Also das hört sich ja nicht besonders dolle an, interessant wäre mal die Aufnahme von QDR (was ja beim P4-System-Bus abläuft) in die RAM-Spezifikationen.
cya
liquid
Nach einem Artikel der EE Times, welcher den von ATi vorangetriebenen Speicherstandard GDDR-3 als mehr oder weniger nur Marketing-Trick bezeichnet, da jener kaum Änderungen zum kommenden DDR/II Standard hätte, gibt es einige Konfusion zu den verschiedenen Speicherstandards und deren Unterschiede. Gemeinsam ist DDR, DDR/II, GDDR-2 (dazu später mehr) und GDDR-3, daß es alles Speicher nach dem einfachen DoubleDataRate-Verfahren sind, die Leistung ist also bei gleicher Taktfrequenz mehr oder weniger identisch ...
Also das hört sich ja nicht besonders dolle an, interessant wäre mal die Aufnahme von QDR (was ja beim P4-System-Bus abläuft) in die RAM-Spezifikationen.
cya
liquid
Re: Schlechte CS-Grafik unter Radeon 9700 Pro(Pix)
Freitag, 10. Januar 2003, 17:11
Hyper Z 3 rulez! OK die neue Technick vom GFFX scheint besser zu sein ABER wenn man mal vegleicht 16 GB/Sek (GFFX) vs. ~30 GB/sek (R9900Pro) dann scheint her masse vor klasse zu liegen
Sowas wie HyperZ oder LMA (wie es bei nv heißt) meine ich gar nicht, das sind zwar bandbreitschonende Methoden, jedoch erhöhen sie nicht zwangsläufig die Effizienz bei Übertragungen. Sagen wir mal du hast einen 256-Bit Bus, der übertragt bei SDR (lassen wir DDR mal außen vor, sonst alles mit 2 multiplizieren) genau 32Bytes/Clock, auch wenn die angefordete Datenmenge diesen Wert unterschreitet. Sprich, du überträgst von der reinen Datenmenge (Anzahl Bytes) zwar 32 Stück, jedoch kann es sein, dass du nur 16 Bytes effektiv übertragst, da die anderen Bytes alle Null sind. Effizienz ist dann nur noch 50% und bringen tut der dicke Speicherbus dann auch nix mehr.
Sowohl Treiber, API als auch Anwendung müssen entsprechned designt sein, damit das überhaupt effizient abläuft und pro Takt entsprechend maximale Gewinne erwirtschaftet werden. Das erreicht man dann meistens durch Assembler-Optimierungen, wo man die Daten dann "aligned", man richtet sie an gewissen Speichergrenzen aus, sagen wir mal sie werden an 32 Byte Grenzen ausgerichtet. Wenn dann noch alles stimmt, läuft das holen und hochladen von Informationen mit 100% Effizient ab, allerdings auch nur solange wie die GraKa auch einen 256-Bit Bus hat, wenn dieser nur 128-Bit beträgt, fällt wieder alles ins Wasser, denn nun müsste man ein anderes Alignment nehmen, um maximale Performance zu bekommen. Sprich, du müsstest praktisch für jede Hardware eine neue Engine bzw. Code-Path schreiben und das ist wohl auch etwas zu viel von den Entwicklern verlangt. Sicherlich kann der Compiler sehr viel optimieren, jedoch weiß er leider nie auf welchem Target der Code denn nun eigentlich ausgeführt wird. Er tappt im Dunkeln und da kann es leicht passieren, dass es sich den Kopp stösst.
So finde ich eigentlich das Prinzip von nv besser zwar weniger Bits/Clock zu liefern, jedoch die Menge der parallel laufenden Busse zu erhöhen, sodass die physikalische Übertragungsrate zwar gleich bleibt, allerdings die Effizienz steigt, da bei einer kleinen Blockgröße der prozentuale Anteil von Nutzdaten in diesem Block wächst. Im schlimmsten Fall muss ein Leseaufruf gesplittet werden, da er mehr Bytes anfordert, als der Bus in einem Takt lesen kann, dann kann aber immer noch der parallele Bus einspringen und den "Rest" auslesen.
(Part2 folgt)
Re: Schlechte CS-Grafik unter Radeon 9700 Pro(Pix)
Freitag, 10. Januar 2003, 17:11
Man sieht, das viel auszulesen sich zwar auf dem Papier gut anhört (512-Bit Bus hört sich beim Marketing natürlich immer nach einem Knaller an), aber wenn man mal genau hinguckt, dann fällt einem auf, dass doch nicht alles so rosig ist und da vermehrt Probleme auftreten. Genauso werden Probleme auftreten, wenn man die Zugriff noch weiter parallelisiert und dann wird man sich auch da etwas neues einfallen lassen müssen. Jedoch denke ich, dass man dieses Prinzip weiter verfolgen sollte, auch die Kompression von Nutzdaten bei Übertragung ist sinnvoll, allerdings sprechen ja alle Hersteller von einer Kompression BIS ZU und daher weiß man auch nie, wie viel genau jetzt überhaupt gespart wird.
Benutzt die GFFX nicht schon 0.13 Micron-Technik oder täusche ich mich da? Also entweder muss ATi dann die Strukturbreite noch weiter senken oder sie erhöhen die Chipfläche oder sie lassen sich etwas völlig neues einfallen. Auf jeden Fall würde ich vermuten, dass es nicht bei den 0.13 Micron bleibt, denn man sieht ja, dass es praktisch noch zu wenig zusätzliche Power gibt und die Wärmeabstrahlung auch nicht großartig reduziert werden kann. Es ist ja nun einmal so, dass die Hersteller sofort den Takt anfange hochzuschrauben, wenn es die Halbleiterkonzerne wieder einmal geschafft haben entweder den Wärme-Output zu bändigen oder die Strukturbreite zu verkleinern. Es hält sich ja keiner damit auf und sagt: Hey, wir haben hier einen neuen Chip, es sind jetzt nur noch 0.13 Micron! Der Takt ist zwar gleich, aber die Karte ist deutlich kühler! Damit gibt sich doch logischerweise keiner zufrieden, es wollen doch alle nur hohe MHz-Zahlen sehen, wie sonst erklärt man es sich, dass ahnungslose User meinen der P4 wäre schneller, da er ja so viel MHz unter der Haube hat. Auf MHz fahren halt alle ab und es ist ja auch immer wieder schön zu sehen, dass man die 1GHz Grenze durchbrochen hat, dann noch die 2GHz Barrier, vielleicht in den nächsten Jahren die 10GHz Grenzen. Sein wir doch ehrlich, wir gucken immer erst auf die Performance und wenn die nicht stimmt, dann hat das Produkt doch schon quasi verloren.
cya
liquid
aLso nen bissel weiß ich shcon über den R400... er wird halt sehr in richtung kühl und genügsam gehen... also ned mehr so viel Saft futtern und dank 13µ auch ned mehr so heiß werden... OK 13µ sind keine GaRa für einen Kühlen Chip (siehe GFFX) aber ich denke schon das die das hin bekommen... zudem soll ein neuartiger Speicher eingesetzt werden... (og. G-DDR3 Rams...) in sachen Technick wird wohl erstmald as vorhandene überarbeitet und verbessert... zudem kann ATi bestimmte Features auch unabhängig von der API einbinden wie zB TrueForm, AA und AF... (ja weiß sind allesammt ned wirklich unabhängig aber du weißt schon was ich meine ;D
Benutzt die GFFX nicht schon 0.13 Micron-Technik oder täusche ich mich da? Also entweder muss ATi dann die Strukturbreite noch weiter senken oder sie erhöhen die Chipfläche oder sie lassen sich etwas völlig neues einfallen. Auf jeden Fall würde ich vermuten, dass es nicht bei den 0.13 Micron bleibt, denn man sieht ja, dass es praktisch noch zu wenig zusätzliche Power gibt und die Wärmeabstrahlung auch nicht großartig reduziert werden kann. Es ist ja nun einmal so, dass die Hersteller sofort den Takt anfange hochzuschrauben, wenn es die Halbleiterkonzerne wieder einmal geschafft haben entweder den Wärme-Output zu bändigen oder die Strukturbreite zu verkleinern. Es hält sich ja keiner damit auf und sagt: Hey, wir haben hier einen neuen Chip, es sind jetzt nur noch 0.13 Micron! Der Takt ist zwar gleich, aber die Karte ist deutlich kühler! Damit gibt sich doch logischerweise keiner zufrieden, es wollen doch alle nur hohe MHz-Zahlen sehen, wie sonst erklärt man es sich, dass ahnungslose User meinen der P4 wäre schneller, da er ja so viel MHz unter der Haube hat. Auf MHz fahren halt alle ab und es ist ja auch immer wieder schön zu sehen, dass man die 1GHz Grenze durchbrochen hat, dann noch die 2GHz Barrier, vielleicht in den nächsten Jahren die 10GHz Grenzen. Sein wir doch ehrlich, wir gucken immer erst auf die Performance und wenn die nicht stimmt, dann hat das Produkt doch schon quasi verloren.
cya
liquid
Re: Schlechte CS-Grafik unter Radeon 9700 Pro(Pix)
Freitag, 10. Januar 2003, 20:18
Es hält sich ja keiner damit auf und sagt: Hey, wir haben hier einen neuen Chip, es sind jetzt nur noch 0.13 Micron! Der Takt ist zwar gleich, aber die Karte ist deutlich kühler! Damit gibt sich doch logischerweise keiner zufrieden...
Ach neine? Wie erklärst du dir dan den RV350? (ned zu verwechseln mit dem R350!!!) ~300 Mhz Core, 4 Shader @ 13µ
OK ist nen MAinstream Chip aber du siehst; Der Takt wurde sogar etwas gedrosselt und das Ding wird trozdem in 13µ gefertigt...
Zur Bandbreite undder effektivtät: Wenn das wirklich soooooooo wichtig wäre und ATi da sooooo großen Mist gebaut hätte warum ist die R9700Pro trotzt geringeren Speichertaktes in Bandbreitelimitirten Benchs sooooooooooo viel schneller als eine Ti4600?
Re: Schlechte CS-Grafik unter Radeon 9700 Pro(Pix)
Freitag, 10. Januar 2003, 20:51
Ach neine? Wie erklärst du dir dan den RV350? (ned zu verwechseln mit dem R350!!!) ~300 Mhz Core, 4 Shader @ 13µ
OK ist nen MAinstream Chip aber du siehst; Der Takt wurde sogar etwas gedrosselt und das Ding wird trozdem in 13µ gefertigt...
Ich rede hier von Neuentwicklungen und nicht über irgendwelche beschnittene Versionen einer bereits entwickelten Architektur. Denn die RV-Version sind keine parallel laufenden Entwicklungen, sondern entstehen aus dem original R-Branch und werden dann auf Low-Cost Produktion getrimmt, damit der Mainstream Markt (wie du es ja selbst ausgedrückt hast) gesättigt wird.
Zur Bandbreite undder effektivtät: Wenn das wirklich soooooooo wichtig wäre und ATi da sooooo großen Mist gebaut hätte warum ist die R9700Pro trotzt geringeren Speichertaktes in Bandbreitelimitirten Benchs sooooooooooo viel schneller als eine Ti4600?
Auch wenn du es nicht glaubst, dieses Aligning ist seeeeeeehr wichtig und wirkt sich drastisch auf die Performance aus. Und wie du weißt, die 9700Pro und Ti4600 kann man nicht vergleichen, außerdem... die Ti4600 hat dieses Feature gar net, ich rede hier primär von der FX-Architektur
PS: Noch was zu den selbstständigen Entwicklungen, wo du als Beispiele AA, AF und TruForm angesprochen hast. Du brauchst für alle drei "Entwicklungen" eine neue DX-Version, wenn du willst, dass die Apps selbst entscheiden können, ob sie das Feature nutzen wollen oder nicht. Bei OpenGL ist das einfacher, da kreiert man einfach eine neue Extension, die dann weiter als Extension bestehen bleibt oder, wenn sie gut ist, von der ARB aufgenommen wird. Demnach wäre ich vorsichtig zu sagen, dass eigene Entwicklungen sofort genutzt werden können, Sicherlich kann man das Feature dem App per Treiber aufzwingen, aber das ist immer die schlechteste Alternative, da ein generell überall angewandtes Feature immer schlechter ist, als ein für sein Anwendungsbereich präzise ausgewähltes Feature.
Will dazu ein kurzes Beispiel geben. AA und HUDs. Da wird bei per Treiber aufgezwungenem AA der Framebuffer komplett antialiased. Das ist schlecht, da Symbole und Schrift in den Menus und dem HUDs unscharf bei dem Verfahren wird, wobei es auch egal ist welches Verfahren angewandt wird (denn eine unnötige Filterung erzeugt immer ungewollt Artefakte und verbraucht dazu noch Leistung). Besser wäre es nur die Geometrie zu AAen und DANACH erst das HUD (oder Menu) ohne AA zu zeichnen. Schrift kann dann seperat gefiltert werden, besonders unter dem Hinblick, dass TrueType unter Win32 sowieso standardmäßig einen (angepasstet Algo) AA-Durchlauf bekommt.
Re: Schlechte CS-Grafik unter Radeon 9700 Pro(Pix)
Freitag, 10. Januar 2003, 21:07
Ich rede hier von Neuentwicklungen und nicht über irgendwelche beschnittene Versionen einer bereits entwickelten Architektur. Denn die RV-Version sind keine parallel laufenden Entwicklungen, sondern entstehen aus dem original R-Branch und werden dann auf Low-Cost Produktion getrimmt, damit der Mainstream Markt (wie du es ja selbst ausgedrückt hast) gesättigt wird.
Du brauchst mir ned erkläen was die RV Reihe ist noch wie die endsprechenden Chips endstehen... aber wollte dir nur Zeigen das es Hersteller gibt die ned immer nur das eine wollen ( ;D ) und nur ganz am Rande: der R350 wird weiterhin in 15µ gefertigt werden.. ich schätze mal wegen der ausbeute...
Auch wenn du es nicht glaubst, dieses Aligning ist seeeeeeehr wichtig und wirkt sich drastisch auf die Performance aus. Und wie du weißt, die 9700Pro und Ti4600 kann man nicht vergleichen, außerdem... die Ti4600 hat dieses Feature gar net, ich rede hier primär von der FX-Architektur
Äm. Angeblich kann das schon der GF3! Also das steht jedenfalls in meiner GS aus der Zeit...
Das ist schlecht, da Symbole und Schrift in den Menus und dem HUDs unscharf...
Äm. Schonmal das AA einer R9700Pro gesehen? Aslo von unschärfe ist da nx zu sehen! ;D
ne mir ist schon klar was du meinst und du hast natürlich recht. Aber bei Force AF ist dem jan ed so... und wie wär's denn mit ne, 16XAA oder 32XAF? Oder echte 64Bit Farbtiefe... ansonsten kann ATi ja noch an der Speicherarchitektur arbeiten
xyz
Samstag, 11. Januar 2003, 00:04
Du brauchst mir ned erkläen was die RV Reihe ist noch wie die endsprechenden Chips endstehen... aber wollte dir nur Zeigen das es Hersteller gibt die ned immer nur das eine wollen ( ;D ) und nur ganz am Rande: der R350 wird weiterhin in 15µ gefertigt werden.. ich schätze mal wegen der ausbeute...
Aber du verstehst doch mein Argument, dass die Hersteller quasi gezwungen werden am meisten auf Performance zu setzen, weil mit dem Feature "wird nicht so warm" sich die wenigsten Anwender hinter dem Tisch herlocken lassen werden?
Äm. Angeblich kann das schon der GF3! Also das steht jedenfalls in meiner GS aus der Zeit...
Könnte ich jetzt nicht bestätigen und würde ich auch nicht für richtig halten. Falls GS für Gamestar steht dann sowieso nicht. Für Spieletests mag die zwar ganz in Ordnung sein, aber den Hardwarebereich kann man in meinen Augen vergessen.
Das Prinzip der parallelen Ansteuerung wird ja erst dann interessant, wenn man zu breiteren Speicherinterfaces kommt, da die Blöckgrößen überhaupt nicht mehr mit den tranferierten Nutzdaten "harmonisieren". Praktisch wäre ja ein Speichermanager, der vollkommen dynamisch bis zu einer bestimmten Grenze hin arbeitet. Sagen wir mal man könnte maximal in einem Takt 512 Bits aus dem Speicher lesen bzw. schreiben, dann wäre es doch optimal, wenn man sich seine Bits/Lesevorgang "einteilen" könnte. Sagen wir mal das Programm ist auf 128 Bit Alignment optimiert. Dann sagt man dem Core, dass man bitte 128Bit pro Zugriff haben will und der schaltet das dann frei. Der Clue dabei wäre, dass der Speichermanager nun in den 4x Parallel-Modus schaltet, sodass 128Bits/Zugriff 4mal gleichzeitig (parallel) gelesen bzw. geschrieben werden können.
Technisch ist das wohl nicht realisierbar, weil ja die Leiterbahnen die Busbreite bestimmen und wie will man die Bahnen dynamisch zuordnen? Geht leider net, aber wie gesagt, der Quantencomputer macht sowas vielleicht möglich, schließlich erlaubt er auch blitzschnelle (fast instante) Faktorisierung von kollosalen Zahlen, ein Problem woran sich heutige PCs immer noch die Zähne ausbeißen
(Part2 folgt)
Re: Schlechte CS-Grafik unter Radeon 9700 Pro(Pix)
Samstag, 11. Januar 2003, 00:04
Äm. Schonmal das AA einer R9700Pro gesehen? Aslo von unschärfe ist da nx zu sehen! ;D
Besonders beim AA komme ich immer wieder auf die Frage zurück, in welchen Dimensionen das überahaupt noch Sinn macht. Sagen wir mal ich lasse ein App mit 1600x1200 auf meiner zukünftigen (noch lange hin ;D) GraKa laufen, mit nur 2x2 AA (Supersampling). Ich erkenne ja selbst jetzt mit 1600x1200 und nix AA keine Treppeneffekte bei Spielen. 4x4 wäre in dieser Auflösung wohl der absolute Overkill, ich bezweifle, ob man den nächsten Modi (6x6) überhaupt von diesem mit dem Auge unterscheiden kann.
Da bin ich doch lieber für höhere Auflösung (2048x1536), die dann komplett ohne AA auskommen.
Noch kurz was zu den 64Bit Farbtiefe. Meiner Meinung nach rentiert sich das nur, wenn der Chip rein intern damit arbeitet, denn 32Bit reichen für die Ausgabe allemal. Man muß darauf achten, dass das menschliche Auge sehr stark auf Kontraständerungen reagiert, sprich besonders S/W Unterschiede bemerkt. Bei Farben spielt das nicht so eine große Rolle, da sind schon 16Bit ein wahrer Overkill. Wenn du jetzt protestieren willst, dass man bei 16Bit ein sauschlechtes Bild hat, dann lass mich erklären. Das Problem liegt einmal darin begründet, dass Blending verwendet wird (dazu später) und dann, dass die Farben nicht indexiert sind. Es wird also jedem Farbraum (teilen wir es mal spaßeshalber in RGB auf) eine gleiche Anzahl von Farben zugeordnet und da hackt es dann auch schon. Bei 16Bit fehlen dann in problematischen Farbräumen die Helligkeitsabstufene UND das wiederum sieht das Auge ganz deutlich. Möglichkeit: Bits dynamisch den Farbräumen zuweisen, an problematische Bereiche natürlich mehr. Umsetzung ist schwierig, aber sinnvoll, wenn man in noch höhere Dimensionen kommt.
Zweiter Aspekt: Blending... was sehr penibel auf 16Bit reagiert. Ein Hauptgrund warum besonders Muzzle Flashes (diese Mündungsfeuer) und andere Transparenzeffekte in 16Bit absolut beschissen aussehen. Erhöht man nun die interne Farbtiefe des Chips so lässt sich dieser Effekt sehr reduzieren, besonders beim Kyro hat man das gesehen, da er ja (wie du weißt ;D) alles mit 32Bit durchrechnet.
Ich würde genauso wie du 64Bit empfehlen, allerdings nur intern, nach außen hin kann ruhig ein 32Bit Framebuffer erzeugt werden, das spart schön Speicher (64Bit wäre ja doppelt so groß, man solls ja nicht übertreiben) und der RAMDAC hat nicht so schwer zu arbeiten und er kann dazu mehr Vertikalfrequenz ausgeben (bei 64Bit würde diese sinken, man müssten ihn dann schneller takten, lohnt sich in meinen Augen nicht).
cya
liquid
(Langsam macht es richtig Spass mit dir zu diskutieren!
)
Re: Schlechte CS-Grafik unter Radeon 9700 Pro(Pix)
Samstag, 11. Januar 2003, 01:16
Das das menschliche Auge 64 Bit Farben ned mehr wirklich von 32 Bit Farben unterscheiden kann war mir bewusst... aber ich neme mal an das 64 Bit Farben sehr viel bei spiegelungen (vor allem mehrfachen und ned nur eunfachne wie das zZ meist der Fall ist) und anderen tansparenteffekten ausmachen können... Aber wenn ich jetzt ned falsch informirt bin muss dazu auch der frambuffer 64 Bit unterstützen oder ned?
Das Mit der Bandbreite ist son Ding... klar dieses System vom NV scheint recht gut zu sein aber wenn ich das jetzt richtig verstanden hab dürfte das nur was bei einem sehr breitem Interface wirkliche Vorteile bringen... nun leider verfügt die GFFX nicht über ein solches interface daher neme ich mal an das sich der Geschwindichkeitszuwachs in Grenzen hält. Zudem hat NV ja selber verauten lassen das man dieses "Prop" Mit em Interface umgehen will indem man einfach en Takt hochschraubt... ich mein das klingt ja vernünftig nur wer hindert Ati (und andere Hersteller) daran das selbige zu tun? Für den R350 ist ja bereits DDR 2 Ram angekündigt worden...
Zum AA möchte ich vollgendes sagen: Wenn ich mit 1600*1200 Pixel zocke seh ich zwar keine/kaum direkte treppen aBER dieses "fackern" oder "Flimmern" von Pixeln in größerer endfernung hab ich trotzdem... sehr auffällig wenn man BumpMapping einsetzt... (guck dir mal die Advanced Shader Demo von 3D MArk an... da sieht man das recht gut was ich meine) diesen Effekt kann man mit AA recht gut in den Griff bekommen. Und bei den heutigen Bandbreitemonstern ist es (zumindest für die R9700Pro) leicher AA ein zu setzen als eine hohe auflöseung... sprich mit 1024*768 @ 4X AA bin ich meist schneller unterwegs als mit 1600*1200 @ 0X AA... Das mag nun daran liegen das die Pixelpipelines der R9700Pro etwas unterdemensionirt sind aber soweit ich weiß hat der GFFX auch ned mehr... halt nur mehr Textureinheiten... und wenn AA richtig sauber eingesetzt wird (wie beim VooDoo5 oder halt der R9700) wird das Bild nicht/kaum unscharf und es der Effekt sieht halt sehr gut aus... über die GF Karten will ich jetzt ned urteilen da mir dazu wahrscheinlich die objektivität fehld aber ich persönlich fand das AA meiner GF2GTS & GF3Ti200 lächerlich... aber jedem das seine ;-D
Aber gegen 32XAF alá Ati kann man ja nun wirklich nix sagen oder? (also die GF KArten können dieses zwar schon aber das kann man ned vergleichen... die technicken und die Qualli ist einfach zu unterschiedlich... THG hatte dazu mal einen sehr schönen Artikel...)
Den letzten Satz nem ich einfach mal als kompliment und werwider das gleich mal
PS: Hoffe du kannst das noch endziffern
Man In Blue
Das Mit der Bandbreite ist son Ding... klar dieses System vom NV scheint recht gut zu sein aber wenn ich das jetzt richtig verstanden hab dürfte das nur was bei einem sehr breitem Interface wirkliche Vorteile bringen... nun leider verfügt die GFFX nicht über ein solches interface daher neme ich mal an das sich der Geschwindichkeitszuwachs in Grenzen hält. Zudem hat NV ja selber verauten lassen das man dieses "Prop" Mit em Interface umgehen will indem man einfach en Takt hochschraubt... ich mein das klingt ja vernünftig nur wer hindert Ati (und andere Hersteller) daran das selbige zu tun? Für den R350 ist ja bereits DDR 2 Ram angekündigt worden...
Zum AA möchte ich vollgendes sagen: Wenn ich mit 1600*1200 Pixel zocke seh ich zwar keine/kaum direkte treppen aBER dieses "fackern" oder "Flimmern" von Pixeln in größerer endfernung hab ich trotzdem... sehr auffällig wenn man BumpMapping einsetzt... (guck dir mal die Advanced Shader Demo von 3D MArk an... da sieht man das recht gut was ich meine) diesen Effekt kann man mit AA recht gut in den Griff bekommen. Und bei den heutigen Bandbreitemonstern ist es (zumindest für die R9700Pro) leicher AA ein zu setzen als eine hohe auflöseung... sprich mit 1024*768 @ 4X AA bin ich meist schneller unterwegs als mit 1600*1200 @ 0X AA... Das mag nun daran liegen das die Pixelpipelines der R9700Pro etwas unterdemensionirt sind aber soweit ich weiß hat der GFFX auch ned mehr... halt nur mehr Textureinheiten... und wenn AA richtig sauber eingesetzt wird (wie beim VooDoo5 oder halt der R9700) wird das Bild nicht/kaum unscharf und es der Effekt sieht halt sehr gut aus... über die GF Karten will ich jetzt ned urteilen da mir dazu wahrscheinlich die objektivität fehld aber ich persönlich fand das AA meiner GF2GTS & GF3Ti200 lächerlich... aber jedem das seine ;-D
Aber gegen 32XAF alá Ati kann man ja nun wirklich nix sagen oder? (also die GF KArten können dieses zwar schon aber das kann man ned vergleichen... die technicken und die Qualli ist einfach zu unterschiedlich... THG hatte dazu mal einen sehr schönen Artikel...)
Den letzten Satz nem ich einfach mal als kompliment und werwider das gleich mal
PS: Hoffe du kannst das noch endziffern
Man In Blue
Re: Schlechte CS-Grafik unter Radeon 9700 Pro(Pix)
Sonntag, 12. Januar 2003, 15:02
1. Ja, noch da, hab aber gestern meine Bestellung von AC eingebaut und dabei ist recht viel Zeit draufgegangen. Jedenfalls ist jetzt alles drinne und bis jetzt hab ich auch noch keine Leckage bemerkt ;D - Jetzt muß ich bloß langsam mal anfangen mich auf die Englisch Klausur vorzubereiten, denn am Dienstag ist es schon so weit. Wirst also verstehen, das ich nicht viel Zeit habe hier noch in aller Ausführlichkeit zu antworten.
Zu den Speicherinterfaces: Da muss ich mich auch erst informieren, ich würde allerdings schon jetzt Zweifel an den 32 Bit (bei nv) äußern. Nimm mal einen einfachen Vertex, da kommt man selbst ohne Farbinformation und UV-Koordinaten auf 48 Bit (bei 16Bit Floating-Point-Precision und ohne den W-Wert). Ich denke das nVidia nicht so doof ist und einen dermaßen großen Overhead durch das Splitten von Fetch-Anweisungen haraufbeschwört. Aber wie gesagt, wenn die Klausur gelaufen ist informier ich mich
cya
liquid
PS: Geht man davon aus, dass die GFFX noch einen "Pro-Nachfolger" bekommt, so wäre es ein leichtes das Speicherinterface von 128Bit auf 256 anzuheben, von der reinen Transferrate wäre man da bei knapp 32 GB/s - keine Ahnung wie lange man sich damit vor ATi halten könnte.
Zu den Speicherinterfaces: Da muss ich mich auch erst informieren, ich würde allerdings schon jetzt Zweifel an den 32 Bit (bei nv) äußern. Nimm mal einen einfachen Vertex, da kommt man selbst ohne Farbinformation und UV-Koordinaten auf 48 Bit (bei 16Bit Floating-Point-Precision und ohne den W-Wert). Ich denke das nVidia nicht so doof ist und einen dermaßen großen Overhead durch das Splitten von Fetch-Anweisungen haraufbeschwört. Aber wie gesagt, wenn die Klausur gelaufen ist informier ich mich
cya
liquid
PS: Geht man davon aus, dass die GFFX noch einen "Pro-Nachfolger" bekommt, so wäre es ein leichtes das Speicherinterface von 128Bit auf 256 anzuheben, von der reinen Transferrate wäre man da bei knapp 32 GB/s - keine Ahnung wie lange man sich damit vor ATi halten könnte.
Re: Schlechte CS-Grafik unter Radeon 9700 Pro(Pix)
Montag, 13. Januar 2003, 15:09
Also ich hab mal nachgeguckt wie das jetzt mit dem Speicherinterface aussieht. Erstmal, beide Chips haben einen CBMC, das kompensiert beim Fetching so einiges, allerdings auch nicht alles.
Weiterhin, NV hat Segmentierungsgrenzen von 32Bit, ATi hingegen schon 64Bit. Da kann man nicht genau sagen was besser ist, nur soviel, je kleiner der Wert ist, desto genauer kann adressiert werden und desto weniger muß gelesen bzw. geschrieben werden, wenn ein Wert innerhalb dieses Segmentes verändert werden soll. Auf die Sache mit den Segmenten hat MiB auch schon hingewiesen, allerdings mit etwas falschem Vokabular. Hab ich aber dennoch verstanden.
Kommen wir zu dem eigentlichen Unterschiede. Das ist einmal die Bandbreite, mit der jeder Speicherchip an den MC gekoppelt ist, dann die Taktfrequenz und schließlich die max. parallel ablaufenden Bursts. Zu der Bandbreite ist zu sagen, dass es eigentlich Bandbreite pro Burst heißen muß, da sie angibt wieviele Bits pro Burst übertragen werden können. So wie ich das jetzt mitbekommen habe, bewirkt DDR2 gegenüber DDR1 folgendes. Die Taktfrequenz kann enorm erhöht werden, allerdings nur wenn entsprechend viele Waitstates beim Fetching eingebaut werden. Das führt dazu, dass Bursts die einzig effektive Alternative sind und der Core deshalb gesynced werden sollte, damit er optimal mit dem Speicher zusammenarbeitet. Man baut also entweder in die Pipes oder den MC Waitstates ein, damit die Synchronizität gewahrt bleibt. DDR2 bringt, soweit ich das verstanden habe, den Vorteil, dass mehrere Bursts gleichzeit durchgeführt werden können. Die Waitstates zwischen den Bursts sind verhältnismäßig lang, sodass der MC dafür sorgen muß, dass die Bursts auch alle möglichst effizient genutzt werden, da käme wohl dann der CBMC ins Spiel. Soweit ist DDR2 eigentlich nur Taktfrequenzerhöhung auf Kosten von Latenzzeit. Das zieht natürlich bei den Kunden, da man dementsprechnend mit hohen MHz-Zahlen prahlen kann, aber seine Effektivität spielt es auch erst aus, wenn das drumherum stimmt.
Und sein wir ehrlich, die GFFX ist noch nicht raus und wenn sie draußen ist, dann sind die Treiber wohl auch noch relativ bescheiden, wie will man da im Vorfeld schon eine gültige Prognose stellen. Geht nicht, finde ich. Genauso wie der neue von ATi, du sprichst ja selber von Gerüchten MiB und da es zu den neuen R-Chips nichtmal technische Datenblätter gibt, sollte man auch nicht groß spekulieren.
cya
liquid
Weiterhin, NV hat Segmentierungsgrenzen von 32Bit, ATi hingegen schon 64Bit. Da kann man nicht genau sagen was besser ist, nur soviel, je kleiner der Wert ist, desto genauer kann adressiert werden und desto weniger muß gelesen bzw. geschrieben werden, wenn ein Wert innerhalb dieses Segmentes verändert werden soll. Auf die Sache mit den Segmenten hat MiB auch schon hingewiesen, allerdings mit etwas falschem Vokabular. Hab ich aber dennoch verstanden.
Kommen wir zu dem eigentlichen Unterschiede. Das ist einmal die Bandbreite, mit der jeder Speicherchip an den MC gekoppelt ist, dann die Taktfrequenz und schließlich die max. parallel ablaufenden Bursts. Zu der Bandbreite ist zu sagen, dass es eigentlich Bandbreite pro Burst heißen muß, da sie angibt wieviele Bits pro Burst übertragen werden können. So wie ich das jetzt mitbekommen habe, bewirkt DDR2 gegenüber DDR1 folgendes. Die Taktfrequenz kann enorm erhöht werden, allerdings nur wenn entsprechend viele Waitstates beim Fetching eingebaut werden. Das führt dazu, dass Bursts die einzig effektive Alternative sind und der Core deshalb gesynced werden sollte, damit er optimal mit dem Speicher zusammenarbeitet. Man baut also entweder in die Pipes oder den MC Waitstates ein, damit die Synchronizität gewahrt bleibt. DDR2 bringt, soweit ich das verstanden habe, den Vorteil, dass mehrere Bursts gleichzeit durchgeführt werden können. Die Waitstates zwischen den Bursts sind verhältnismäßig lang, sodass der MC dafür sorgen muß, dass die Bursts auch alle möglichst effizient genutzt werden, da käme wohl dann der CBMC ins Spiel. Soweit ist DDR2 eigentlich nur Taktfrequenzerhöhung auf Kosten von Latenzzeit. Das zieht natürlich bei den Kunden, da man dementsprechnend mit hohen MHz-Zahlen prahlen kann, aber seine Effektivität spielt es auch erst aus, wenn das drumherum stimmt.
Und sein wir ehrlich, die GFFX ist noch nicht raus und wenn sie draußen ist, dann sind die Treiber wohl auch noch relativ bescheiden, wie will man da im Vorfeld schon eine gültige Prognose stellen. Geht nicht, finde ich. Genauso wie der neue von ATi, du sprichst ja selber von Gerüchten MiB und da es zu den neuen R-Chips nichtmal technische Datenblätter gibt, sollte man auch nicht groß spekulieren.
cya
liquid
Re: Schlechte CS-Grafik unter Radeon 9700 Pro(Pix)
Montag, 13. Januar 2003, 15:58
Das ATI die Techniken von 3DFX benutzen kann und darf bezweifle ich sehr. Vielleicht ähnliche Techniken vom Prinzip her aber niemals nie die gleichen...
Falls du es noch nicht wusstest: (ich gehe aber nicht davon aus)
3DFX wurde vor einiger Zeit von Nvidia aufgekauft und die Jungs waren massgeblich beteiligt am Design der GFFX!
Daher heisst die Karte auch, um die 3DFX-Leute zu ehren, nicht Geforce 5 sondern eben Geforce (3D)FX...
An 3D FX Effekte glaub ich auch ned... abe rich halte es für möglich das man noch was an en Shadern rum gespielt hat...
Und das mit dem FX im GeForce namen ist für mich nen schlechter Witz! 3D FX hatte ine komplet andere Mentalität als N-Vidia! Der GeForce FX ist ein echter GeForce und keine VooForce! Lediglich einige Effekte in sachen Filmrealismus wurde aus dem T- bzw. M-Buffer von 3D FX übernommen... eine Paralele zwichen 3D FX und der GeForce FX halte ich trotzdem für völlig unangebracht! Zumal 3D FX und NV komplet andere absichten hatte...
Die Voodoo Karten waren stehts gute scnelle und vor am Hochqualitative 3D Beschleuniger... das augenmark lag fast nur auf den PC-Zocker... abgespeckte Mainstream Varianten gab es von den Voodoo Karten nur sehr wenige und diese setzten sicha uch ned durch... 3D FX wollte also quasi nur HighEnd 3d Karten bauen... Und zwar welche die in Leistung und quallität einfach nur ginial sind... (zB. gab es ab dem VooDoo3 nur noch 3D FX Karten mit hervoragender Billdqualli und ned nur mit guter Leistung...) und das haben die Jungs auch bis zum bitteren Ende getan...
Bei NV siehts dagegen ganz anders aus... ein Produkt muss nicht gut sein sondern sich nur gut anhören und viel verkauft werden... in fast jedem Mainstream PC saß bis vor kurzem endweder eien TnT2M64 oder eine GF2MX... klar NV baut auch viele und Teils auch gute HighEnd Karten (zB. die GeForce 256... das ist eine Karte die ich bis heute für ihre Zeit als sehr gut empfinde...), aber halt nicht so wie 3D FX es getan hat... bzw. oft muss die Quallität der Leistung weichen...
@ LiquidAcid
Wenn DDR2 Ram zwar eine takterhöhung bedeutet baer auch gleichzeitig schlechte Latenzen dann ist der doch weitgehend sinnlos! Der einzige Vorteil wär die bessere Ausnutzung der bandbreite durch den hohen takt... aber da hätte man sich auch was bessere einfallen lassen können...
Mit dem Synchronsiesiren ist auch son Dingen... bis vor kurzem gab es bei aTi nur GraKas mit synchronem Takt... der R7500 war der erste mit asynchronem Takt... daher denke ich mal das das ATi ed all zu schwer fallen sollte wieder auf synchronen Takt um zu steigen...
Mit den treibern stimm ich mit dir überen... und hier Hat ATi wohl einen echten Vorteil! Da der R350 dem R300 so änlich ist wird es wohl nicht all zu schwer sein dort schnell einen vernünftigen Treiber auf die Beine zu stellen...
Das mit den Datenblättern des R350 isr wohl war... Ati hat aber vollgendes angekündigt:
drastische Taktsteigerung beim VPU... schätzungsweise auf ca. 400 Mhz
DDR2 Ram
2 X Füllrate
HyperZ3+
Wobei das mit HyperZ3 nen werbegag sein könnte...
MFG
Man In Blue
EDIT:
3D Center am 12.01.03
Diese werden zudem mit ca. 600 Euro für die 5800 und ca. 700 Euro für die 5800 Ultra regelrecht teuer unters Volk gebracht
Werden wohl doch was teurer als geplant.
EDIT2:
Ich muss mich in einer meiner Ausführungen korrigiren: Der R300 beherscht bereits 128 Bit rendering (intern)!
EDIT3:
Übrigens gibt es eine Art "späten Triumph" für TruForm: Jede Displacement Mapping fähige Karte könnte auch TruForm-anbieten. Das eigentliche TruForm wurde für R300 nun auch noch verfeinert. Bestimmte Probleme des original TruForm können nun umgangen werden.
Re: Schlechte CS-Grafik unter Radeon 9700 Pro(Pix)
Montag, 13. Januar 2003, 18:47
EDIT3:
Übrigens gibt es eine Art "späten Triumph" für TruForm: Jede Displacement Mapping fähige Karte könnte auch TruForm-anbieten. Das eigentliche TruForm wurde für R300 nun auch noch verfeinert. Bestimmte Probleme des original TruForm können nun umgangen werden.
Zum übrigen äußere ich mich später...
Kommen wir kurz auf TruForm zurück, so hat ATi das, übrigens genauso wie NV mit seinen RT-Patches vollkommen eingestampft. Dazu (und das kann man auch überall nachlesen) beherrscht alles oberhalb des R200 TruForm in Hardware so gut wie der Riva128 Chip T&L. Du wirst sicherlich schonmal gebencht hat, da merkt man ziemlich schnell, dass die Tesselation-Einheit für den De-Casteljau-Algo nicht mehr so ganz in der Hardware steckt. 99% davon wird in Software berechnet, weil die entsprechenden Chipbereiche, die dafür zuständig waren, auch ganz schnell wieder verschwunden sind. Ich denke das lässt sich nicht leugnen.
Dazu kommt noch das die Cores, die es momentan auf dem Markt gibt, DM bis auf EINE Ausnahme, mies oder noch miserabler unterstützen, sowohl ATi als auch NV. Matrox macht da eine Ausnahme, sie sind aber wirklich auch die einzigen.
Und ich habe doch starke Zweifel daran, dass nur weil es bald wirklich DM-fähige Karten geben wird, dessen Hersteller sofort TruForm bei sich einbauen werden, da haben die absolut keinen Grund für. Was ATi liefern wird, ist erstmal ungewiss, die können ja von mir aus ihre Tess-Einheit wieder einbaun, damit sie endlich mal ordentliche Werte liefern. Aber momentan wird es für sie ganz schön schwierig einen annehmbaren Tess-Algo auf ihrer aktuellen Architektur zu basteln, denn die Vertex-Shader können sie dafür leider Gottes nicht benutzen und eine andere Möglichkeit steht ihnen wohl auch nicht offen.
TruForm hatte seine Zeit und er hat es nicht erreicht sich durchzusetzen, das wird er auch in Zukunft nicht tun, da schreibe ich dem DM eine größere Chance zu, da es viel genauer gesteuert werden kann.
cya
liquid